■ 1. Ollamaの概要と問題の本質
- OllamaはローカルLLM実行ツールとして最も普及しているが普及に値しない
- 普及の理由は先行者優位であり技術的優位性ではない
- llama.cppをラップしたツールでありながらその依存関係を長期間隠蔽してきた
- VC資金を受け取りながらオープンソースコミュニティの信頼を裏切ってきた
■ 2. llama.cppへの帰属問題
- Ollamaの推論機能はすべてGeorgi Gerganov作のllama.cpp(2023年3月)に依存している
- llama.cppはGitHub上で10万以上のスターと450名以上のコントリビューターを持つ
- Ollamaは1年以上にわたってREADMEにllama.cppへの言及を記載しなかった
- MITライセンスの唯一の要件である著作権表示を配布バイナリに含めなかった
- コミュニティからの指摘(Issue #3185)が400日以上放置された
- 最終的に追加されたのはREADME末尾の一行のみであり共同創業者のコメントは距離を置く意図を示唆した
■ 3. llama.cppからのフォークと性能劣化
- 2025年中頃にllama.cppを離れてggmlを直接ベースとしたカスタム実装へ移行した
- 移行理由として安定性を挙げたが実際にはllama.cppが解決済みのバグが再発した
- 主な問題:
- 構造化出力サポートの破損
- ビジョンモデルの失敗
- GGMLアサーションクラッシュ
- ベンチマーク結果:
- 同一ハードウェア・同一モデルでllama.cppはOllamaの1.8倍高速(161 vs 89 tokens/sec)
- CPU使用時のギャップは30〜50%
- Qwen-3 Coder 32Bではllama.cppがOllamaより約70%高スループット
- Georgi Gerganov自身がOllamaのGGMLフォークに問題のある変更があることを指摘した
■ 4. モデル名の誤表示
- DeepSeek R1リリース時に671Bパラメータの本体ではなく小規模蒸留モデルを「DeepSeek-R1」として表示した
- DeepSeek自身は「R1-Distill」プレフィックスで正しく命名しておりHugging Faceも正確に表示していた
ollama run deepseek-r1は8Bの蒸留モデルを起動する- Issue #8557と#8698は修正なしにクローズされた
- この誤表示によりDeepSeekの評判に悪影響を与えた
■ 5. クローズドソースアプリのリリース
- 2025年7月にmacOS/Windows向けGUIデスクトップアプリをプライベートリポジトリで開発しライセンスなしで公開した
- コミュニティからAGPL-3.0依存の可能性が指摘された
- WebサイトではGitHubリンクの隣にダウンロードボタンを配置しオープンソースアプリと誤認させる構造だった
- メンテナーは数ヶ月間沈黙し2025年11月にメインリポジトリへのマージが行われた
■ 6. Modelfileの問題
- GGUFはシングルファイルデプロイを原則とし必要な情報がすべてファイル内に含まれているが Ollamaはその上にModelfileという別設定ファイルを追加した
- Ollamaはハードコードされたリストに存在しないチャットテンプレートを自動検出できず
{{ .Prompt }}にサイレントフォールバックする- パラメータ変更のワークフロー:
- Modelfileのエクスポート→編集→
ollama createで新モデルエントリ作成という手順が必要- この過程でモデルファイル全体(30〜60GB)がコピーされる場合がある
- Jinja形式ではなくGoテンプレート構文を採用しており独自形式への変換が必要
- llama.cppではtemperatureや system promptはコマンドラインフラグで変更可能
■ 7. レジストリのボトルネック
- 新モデルのGGUFはHugging Face上で数時間以内に公開されるがOllamaレジストリへの追加は遅延する
- Ollamaが提供する量子化形式はQ4_K_SQ4_K_MQ8_0F16F32のみでQ5_K_MQ6_KIQクォントは非対応
- 新モデルリリース時にOllamaでテストした結果としてモデル自体ではなくOllamaのバックエンドに起因する問題がモデルの評判を損なう事例が複数発生している
- Hugging Faceが
ollama run hf.co/{repo}:{quant}形式をサポートしたが根本的な問題は解決されていない■ 8. クラウドへの転換
- 2025年後半にクラウドホストモデルをローカルライブラリと並列で提供開始した
- MiniMaxなどのプロプライエタリモデルを選択した場合データが外部に送信されることの明確な開示がない
- Ollamaのドキュメントはプロンプトを保存・ログ記録しないと述べているが第三者プロバイダの扱いは不明
- Alibaba Cloudホストモデルにはゼロデータリテンション保証が存在しない
- CVE-2025-51471:悪意あるレジストリサーバーが通常のモデルpull中に認証トークンを奪取できる脆弱性が存在しPRが作成されるまで数ヶ月を要した
■ 9. VCバックドプロジェクトのパターン
- OllamaはY Combinator(W21)出資のスタートアップでKitematic(Docker GUIをDocker Incに売却)の創業者によって設立された
- 典型的な段階:
- OSSをラップしてコミュニティの信頼を獲得
- 帰属表示を最小化してプロダクトを自立しているように見せる
- プロプライエタリなモデルレジストリ形式でロックインを作る
- クローズドソースコンポーネントを追加
- 収益化のためにクラウドサービスを導入
- モデルはハッシュ化されたファイル名でOllama独自形式で保存されており他ツールへの移行が困難
■ 10. 代替ツール
- llama.cpp:
- OpenAI互換APIサーバー(llama-server)と組み込みWeb UIを提供
- スループットはOllamaより一貫して高い
- 2026年2月にggml.aiがHugging Faceと統合し長期持続性を確保
- Mozilla llamafile:
- モデルとランタイムを1つの実行ファイルにパッケージ化し6つのOSで動作
- llama-swap:
- 単一APIエンドポイント後ろでのマルチモデルオーケストレーション
- GUIオープンソース選択肢:
- Jan(AGPLv3):ローカルファーストチャットアプリ
- koboldcpp(AGPL):組み込みWeb UIを持つllama.cppフォーク
- クローズドソースラッパー:
- LM Studio:llama.cppへの適切な帰属表示を維持し善意ある姿勢を示すプロプライエタリGUI
- Msty:マルチモデルサポートと組み込みRAGを持つクローズドソースGUI
- Red Hat ramalama:依存関係を明示的にクレジットするコンテナネイティブなモデルランナー
■ 11. 結論
- llama.cppはGeorgi Gerganovが2023年3月に一夜で作成しローカル推論革命の基盤となった
- Ollamaはそのllama.cppをラップしVC資金を調達したが帰属を拒否しフォークを失敗させクローズドソースアプリを出荷しクラウドサービスへ転換した
- あらゆる判断ポイントでOSSエコシステムへの貢献よりも投資家向けの自立性アピールを優先した
- ローカルLLMエコシステムに必要なのはllama.cppであり Ollamaの代替ツールはすでに十分存在する