llama.cpp を Azure VM で動かしてみた

きっかけは「リクエスト数を気にしないLLMが欲しい」というものでした。

OpenAI APIは非常に便利ですが、試行錯誤のための処理にもお金がかかります。

例えば、

* プロンプトを少し変えて結果を比較する
* READMEをまとめて要約してみる
* 面白そうなアイデアを大量に試す
* 品質評価のために何度も実行する

といった処理です。

これらは事業上必須というより、
「ちょっと試してみたい」「面白そうだからやってみたい」
という性質のものが多くありました。

そのたびにコストを意識すると、
自然と実験回数が減ってしまいます。

私は「どうでもいい処理」や「失敗するかもしれない実験」にこそ
気軽にAIを使いたかったため、
コストをほとんど気にせず実行できるローカルLLMに興味を持ちました。

品質よりもまず、
「思いついたらすぐ試せる環境」を作りたかったのです。

今回利用したモデルは Qwen 2.5 3B Instruct の量子化版（Q4_K_M）です。

実行環境には Azure Virtual Machine の Standard_D4ps_v6 を利用しています。

CPUは Arm64 アーキテクチャの Ampere Altra を採用しており、
4 vCPU・16GBメモリの構成です。

当初はもっと大きなモデルや高性能な構成も検討しましたが、
今回の用途は

* README要約
* テキスト分類
* スライド生成の前処理
* バッチ処理

が中心でした。

そのため、

「最高品質の回答を得る」

ことよりも、

「十分な品質で大量に処理できる」

ことを重視しました。

実際に運用してみると、
Standard_D4ps_v6 + Qwen 2.5 3B Instruct の組み合わせは、
レスポンス速度と月額コストのバランスが非常に良く、
個人開発用途としては十分実用的だと感じています。

特に『失敗しても気にならない処理を大量に回せる』という点は、
商用APIにはない大きなメリットでした。

最初はAKS上でllama.cppを動かしていました。

ただ、実際に運用してみるとリソース調整がかなり難しいことが分かりました。

LLMはCPUやメモリを継続的に消費するため、

* requestsをどれくらいにするか
* limitsをどれくらいにするか
* ノードサイズをどうするか
* 他のPodとどう共存させるか

を常に考える必要があります。

特に個人開発環境では、

* Webアプリ
* Sidekiq
* GitHub Actions Runner
* 検証用Pod

など様々なものが同じクラスタ上で動いているため、
LLMがクラスタ全体の設計に影響を与えるようになっていました。

本来は『LLMを動かしたい』だけなのに、
気付くと『Kubernetesのリソース管理』に時間を使っていたのです。

そこで発想を変え、
LLMだけをAzure VMへ切り出しました。

結果として、
リソース調整に悩む時間が大幅に減り、
LLMそのものの活用に集中できるようになりました。

今回の検証ではLlama系やQwen系など、
複数のモデルを試しました。

用途は主に

* README要約
* テキスト整理
* スライド生成の前処理
* バッチ処理

です。

そのため最新・最大のモデルではなく、
3Bクラスの小型モデルを中心に評価しました。

最終的には Qwen 2.5 3B Instruct が
最もバランスが良いと感じました。

日本語の要約品質や指示追従性能は十分実用的で、
私の用途では期待していた水準を満たしていました。

推論速度については、
OpenAI APIのような即時応答と比べると明らかに遅いです。

ただし今回の用途はチャットではなく、

* 定期実行ジョブ
* バッチ処理
* 非同期処理

が中心です。

そのため数秒〜十数秒程度かかる処理であっても、
ジョブとして裏側で実行するのであれば十分許容できる範囲でした。

結果として、

「多少遅くてもいいから安く大量に回したい」

という目的には、
Qwen 2.5 3B Instruct が最も適していました。

用途によっては商用APIを使わなくても十分実用的だった。

モデルの性能差が大きく、
ベンチマークだけでは実運用の品質が分かりにくかった。

リアルタイム応答よりも、
定期実行やバックグラウンド処理との相性が良いと感じた。

全てを置き換えるというより、
用途に応じて商用APIと使い分けるのが現実的。

将来的にはAI開発基盤の一部として組み込み、
自動化処理をさらに増やしていきたい。