今回はオープンソース・ローカルLLM回。Ollamaがモデル起動ツールから「エージェントCLI」へと役割を広げ、Mistralはより大きなオープンウェイトMoEモデルを7月にアーリーアクセス投入予定と表明。あわせて、ローカル推論の定番であるllama.cppとvLLMの使い分け・量子化の考え方も整理する。
Ollama、ただの「モデル起動ツール」から「エージェントCLI」へ
Ollamaの v0.32系アップデートで、ターミナルで ollama とだけ打ったときの挙動が大きく変わった。これまでのようにモデル名を指定してチャットに入るのではなく、会話・コード生成/実行・Web検索・タスク委任までこなすインタラクティブなエージェントが起動するようになった。
- 新しい「スキル」システムを搭載し、機能を後から追加できるようになった。
- クラウドモデル利用時はデフォルトでツール呼び出し回数の上限が撤廃された。
- Claude Codeのチャンネル連携が維持され、外部エージェントツールとの接続も強化。
- CodeLlama、Qwen2.5(-coder)、Llama 3.x、Mistralの旧テキストモデル、StarCoder、無印DeepSeek-R1といった旧世代エージェント向けタグには非推奨警告が出るようになった。
後続の0.32.1ではGemma 4のツール呼び出しと複数ターン推論の安定性が改善され、Apple Silicon向けMLXバックエンドのモデルキャッシュリークも修正された。単体のランチャーとして始まったOllamaが、Claude CodeやChatGPT系アプリと並ぶ「常駐エージェント」の立ち位置を明確に狙い始めている。
出典: Ollama GitHub Releases / Dedimax Blog
Mistral、Large 3を上回る新オープンウェイトMoEを7月アーリーアクセスへ
Mistral AIのCEOアルチュール・マンシュ氏が、新しいMixture-of-Experts(MoE)モデルファミリーの存在を明らかにした。本人いわく「太いがスパース(fat but sparse)」な構成で、7月中にアーリーアクセスとして提供が始まる見込み。パラメータ数など詳細は明言を避けているが、現行フラッグシップのMistral Large 3(総パラメータ675B・アクティブ41BのスパースMoE、Apache 2.0ライセンス)よりもかなり大きくなる見通しだという。
ライセンスはこれまで同様Apache 2.0が有力視されており、実現すればダウンロード・ファインチューニング・商用再配布まで許可なく行える大型オープンウェイトモデルとして、企業がクローズドAPI一辺倒から離れる選択肢を増やすことになる。閉鎖的なフラッグシップを維持するOpenAIやAnthropicとの対比で、「主権を保てるヨーロッパ製の代替」というポジションをMistralは強く打ち出している。
| モデル | 総パラメータ | アクティブパラメータ | ライセンス | 状態 |
|---|---|---|---|---|
| Mistral Large 3 | 675B | 41B | Apache 2.0 | 提供中 |
| 新MoEファミリー(未公表) | Large 3超と推定 | 非公表 | Apache 2.0見込み | 7月アーリーアクセス |
出典: Tech Times / Sean Kim Blog
ローカルLLM導入が進むほど「非推奨モデル」の整理も課題に
Ollamaが旧世代タグに警告を出し始めたように、ローカルLLMの選択肢が増えるほど「どのモデルをいつ引退させるか」の判断も運用課題になってきている。Mistralの新モデルが実際にリリースされれば、既存のMistral系ローカル運用にも入れ替えの検討が必要になりそうだ。
推論エンジンの選び方: llama.cppとvLLM、どちらを使うか
ローカル・オンプレでLLMを動かす際の定番エンジンとして挙げられるのがllama.cppとvLLMだ。両者はアーキテクチャの思想が異なり、向いている用途もはっきり分かれる。
- llama.cpp: 単一の可搬バイナリで動き、GGUF形式の量子化とCPU/GPUハイブリッド実行に対応。ピークのバッチスループットよりも、シンプルな導入と単発リクエストの性能を優先した設計。
- vLLM: PagedAttentionと連続バッチングにより、同時多数のリクエストが来てもGPU使用率を高く保てるよう設計されている。
- 単一プロンプトの応答速度だけで比べると、同じGPU上でvLLMとllama.cpp(CUDAバックエンド)はほぼ同等(例: A10でLlama 8Bが毎秒40〜50トークン程度)。ただしGGUF形式の重みを使う場合、品質は保てるがvLLM側の性能は伸びにくいため、GGUF運用ならllama.cppが無難。
- 4bit量子化はメモリ使用量を最大75%削減できるとされ、16/32bit浮動小数点の重みを4bitや2bitの整数に圧縮する手法が主流になっている。
- 大規模・高スループットな本番提供が目的ならSGLangやTensorRT-LLMが推奨され、vLLMはそれより手前の「そこそこのスループット」向けデフォルト選択という位置づけになる。
| 観点 | llama.cpp | vLLM |
|---|---|---|
| 得意な形式 | GGUF量子化 | 通常の重み(非GGUF) |
| 得意な用途 | 単発リクエスト・エッジ/ローカル | 同時多重リクエストのサービング |
| 特徴技術 | CPU/GPUハイブリッド実行 | PagedAttention・連続バッチング |
| 導入の手軽さ | 単一バイナリで容易 | サーバー構築が前提 |
主な情報源
- Ollama GitHub Releases (v0.32.5)
- Dedimax Blog: Ollama v0.32 The Interactive Agent Update
- Tech Times: Mistral AI Targets Frontier Gap With Open-Weight Model
- Sean Kim Blog: Mistral Open-Weight Model Enters July Early Access
- Mistral AI: Introducing Mistral 3
- Red Hat Developer: llama.cpp vs. vLLM
各サービスは提供元の規約に従ってご利用ください。情報は各情報源の公開時点のものです。収集・要約はAI、公開判断は人。