ローカルLLMのエコシステムにOllamaは必要ない

 (sleepingrobots.com)
26 ポイント 投稿者 GN⁺ 13 일 전 | 3件のコメント | WhatsAppで共有
  • Ollama はローカルLLMの実行を簡素化した初期ツールだったが、その後 出典の隠蔽とクラウド中心への転換 により信頼を失った
  • 中核エンジンである llama.cppの功績を過小評価 し、独自のggmlバックエンドへ移行したことで 性能低下とバグの再導入 が発生
  • モデル名のミスリード、非公開GUIアプリの配布、非効率なModelfile構造 などをめぐってコミュニティの批判が続いている
  • モデルレジストリのボトルネック、セキュリティ脆弱性、ベンダーロックイン構造 がローカル優先の思想と衝突
  • llama.cpp、LM Studio、Jan などのオープンソース代替が、すでに より高い性能と透明性 を提供し、ローカルLLMエコシステムの中心になっている

Ollamaの問題点とローカルLLMエコシステムの代替策

  • Ollamaの起源と初期の役割

    • Ollama は、ローカルLLM実行を簡素化した最初期の llama.cppラッパー として注目を集めた
      • ユーザーはC++を直接ビルドしたりサーバー設定をしたりしなくてもモデルを実行できた
    • その後、出典を隠し、ユーザーを誤認させ、ローカル中心の思想から離れて ベンチャー資本ベースのクラウド中心構造へ移行した
    • 創業者は Jeffrey Morgan と Michael Chiang で、以前に Docker GUI の Kitematic を開発し、Docker Inc. に買収された経歴を持つ
    • Y Combinator(W21) 出身で、2023年に公開リリースされ、「Docker for LLMs」を掲げた

  • llama.cppに対する不適切なクレジット

    • Ollamaの推論機能は全面的に Georgi Gerganov の llama.cpp に依存している
    • 1年以上にわたり README、Webサイト、マーケティング資料のいずれにも llama.cpp への言及がなく、MITライセンス表記すら欠落 していた
    • コミュニティによるライセンス順守要求の Issue (#3185) には 400日以上応答がなかった
    • その後、共同創業者が README の末尾に「llama.cpp project founded by Georgi Gerganov」という1行だけを追加
    • Ollama側は「私たちは多くのパッチを行っており、徐々に独自エンジンへ移行する」と述べ、意図的にクレジットを矮小化 していた

独自バックエンド移行と性能低下

  • ggmlベースのカスタムバックエンド導入

    • 2025年半ば、Ollamaは llama.cpp の代わりに ggmlベースの独自実装 へ移行した
    • 安定性を理由に掲げていたが、結果として すでに解決済みだったバグを再導入 した
    • 構造化出力の不具合、ビジョンモデルの失敗、GGML assertion クラッシュなど多数の問題が発生
    • GPT-OSS 20B などの最新モデルが動作しなかったり、テンソル型未対応の問題が起きたりした
    • Gerganov は、Ollama が ggmlを誤ってフォークした と直接指摘している

  • 性能比較の結果

    • コミュニティベンチマークでは llama.cppがOllamaより1.8倍高速 （161 vs 89 tokens/s）
    • CPUでも 30〜50% の性能差がある
    • Qwen-3 Coder 32B のテストでは llama.cppが70%高いスループット を示した
    • 原因は Ollama の デーモン構造、非効率なGPUオフロード、旧式バックエンド にある

モデル名のミスリード

  • DeepSeek-R1の事例

    • Ollamaは DeepSeek-R1-Distill-Qwen-32B などの蒸留モデルを単に 「DeepSeek-R1」 と表記していた
    • 実際の 671B パラメータモデルではないにもかかわらず同じ名称を使用
    • ユーザーが「DeepSeek-R1をローカルで動かした」と誤解し、DeepSeekの評判を損なう 事態になった
    • 関連する GitHub Issue (#8557, #8698) はいずれも重複扱いのまま未解決
    • 現在でも ollama run deepseek-r1 は蒸留モデルを実行する

クローズドなアプリの公開

  • GUIアプリの非公開配布

    • 2025年7月、macOS・Windows向けの Ollama GUIアプリ が公開された
    • 非公開リポジトリ で開発され、ライセンス表記なしで配布され、ソースコードも非公開だった
    • オープンソースのイメージを保っていたプロジェクトとしては 急激なクローズド化 だった
    • コミュニティは AGPL-3.0 依存の可能性と ライセンス違反の懸念 を提起した
    • Webサイトは GitHub リンクの横にダウンロードボタンを配置し、オープンソースであるかのような印象 を与えていた
    • 数か月間沈黙した後、2025年11月になってようやくメインリポジトリにマージされた
    • XDA は「オープンソースをうたうプロジェクトは公開状況を明確にすべきだ」と批判した

Modelfileの非効率性

  • GGUFフォーマットとの重複

    • GGUFフォーマット は、モデル実行に必要なすべての情報を単一ファイルに含んでいる
    • Ollama はこれに Modelfile という別の設定ファイルを追加し、Dockerfile に似た構造を採っている
    • すでにGGUFに含まれている情報を重複定義し、不要な複雑さ を招いている
    • Ollama は ハードコードされたテンプレート一覧 だけを自動認識し、新しいテンプレートは無視する
    • その結果、モデルの 命令フォーマットが壊れ、ユーザーが手動変換しなければならない

  • 非効率なパラメータ変更

    • パラメータ変更時には ollama show --modelfile で抽出して修正し、ollama create で再生成する必要がある
    • この過程で 30〜60GBのモデル全体コピー が発生する
    • コミュニティはこれを「非効率で不要な複製」だと批判している
    • llama.cpp では単に コマンドライン引数 でパラメータを調整できる

  • テンプレート互換性の問題

    • Ollama は Goテンプレート構文 を使っており、モデル作者が使う Jinjaテンプレート と一致しない
    • LM Studio と llama.cpp は Jinja を直接サポートするが、Ollama では変換が必要になる
    • 変換エラーによる 会話フォーマット崩れ の問題が多数報告されている

モデルレジストリのボトルネック

  • モデル登録の遅延

    • 新しいモデルが Hugging Face に公開されても、Ollama では 直接パッケージングして登録 しなければ利用できない
    • 対応する量子化形式も Q4_K_M、Q8_0 などに限定 されている
    • その結果、モデル公開からOllamaで使えるまで遅れ が生じる
    • コミュニティでは「新モデルのテストは llama.cpp か vLLM を使うべき」という PSA 投稿が広まった

  • 量子化の制約

    • Ollama は Q5、Q6、IQ 系列 をサポートしていない
    • ユーザーが要望しても「別のツールを使ってほしい」と返答される
    • ollama run hf.co/{repo}:{quant} コマンドにより Hugging Face を直接指定できるようになったが、 依然として 内部ハッシュストレージにコピーされ共有不能 であり、テンプレート問題も続いている

クラウド移行とセキュリティ問題

  • クラウドモデルの導入

    • 2025年末、Ollama は クラウドホスティングモデル を追加した
    • ローカル中心のツールであるにもかかわらず、一部モデルでは 外部サーバーへプロンプトを送信 する
    • MiniMax などの サードパーティ製モデル を使うと、データが外部に送られる可能性がある
    • Ollama は「ログを保存しない」と明記しているが、第三者のポリシーは不明確 だ
    • Alibaba Cloud ベースのモデルでは データ保持が保証されない

  • セキュリティ脆弱性

    • CVE-2025-51471: 悪意あるレジストリサーバーが認証トークンを窃取できる脆弱性
    • 修正PRは存在したが、数か月にわたり取り込まれなかった
    • ローカルプライバシーを中核価値に掲げるツールとしては 深刻な構造的問題 だ

ベンチャー資本中心の構造

  • 繰り返されるパターン

    • オープンソースプロジェクトを ラップしてユーザー基盤を確保 → 投資を調達 → 収益化へ転換 する流れ
    • Ollamaの段階的な動き
      • オープンソースとして開始し、llama.cpp を基盤に構築
      • 出典を縮小し、独立した製品のように見せる
      • モデルレジストリとフォーマットでロックインを誘導
      • クローズドGUIを公開
      • クラウドサービス導入 によって収益化

  • ベンダーロックイン構造

    • Ollama はモデルを ハッシュ化されたファイル名 で保存するため、他ツールとの互換性が低い
    • GGUF を取り込むことはできても、書き出しは不便に設計 されている
    • ユーザーは Ollama エコシステムに 縛られる構造 になっている

代替ツール

  • llama.cpp

    • OpenAI互換APIサーバー（llama-server）、Web UI、細かなパラメータ制御、高いスループットを提供
    • 2026年2月、ggml.ai が Hugging Face に加わり、持続可能性を確保した
    • MITライセンスベースで、450人以上のコントリビューターが参加している

  • その他の代替

    • llama-swap: 複数モデルのロードとホットスワップをサポート
    • LiteLLM: 複数バックエンド間の OpenAI 互換プロキシを提供
    • LM Studio: GUIベースで llama.cpp を採用し、GGUF 完全互換
    • Jan、Msty: ローカル優先設計のオープンソースデスクトップアプリ
    • koboldcpp、Red Hat ramalama: コンテナベースのモデル実行、明確な出典表記

結論: ローカルLLMエコシステムの方向性

  • Georgi Gerganov の llama.cpp はローカルAI革新の基盤
    • コミュニティ協業により、コンシューマーハードウェアでも強力なモデル実行が可能になった
  • Ollama はこの基盤の上で成長したが、 出典隠蔽、品質低下、クローズド化、クラウド移行 によって信頼を失った
  • ローカルLLMエコシステムに必要なのは Ollamaではなくllama.cpp
    • 真のオープン性と性能は、すでにコミュニティ中心のツール群が提供している

関連記事

3件のコメント

 
shblue21 12 일 전

ある程度同意しますし、ローカルでちゃんと使うならLM Studioのほうがより良い気がします。
 
kirinonakar 12 일 전

私も最初はollamaから始めましたが、最近はかなり前にLM Studioへ乗り換えました。
 
GN⁺ 13 일 전
Hacker Newsの意見

  • ローカルLLMユーザーの大半は、OllamaのおかげでUXの問題が解決されたと考えている
    1行のコマンドでモデルを実行でき、ROCmドライバも自動で処理される
    一方でllama.cppは名前からしてC++ライブラリのように聞こえ、一般ユーザーにはとっつきにくい
    自分はただプログラムを自分でビルドしたいわけではなく、気軽に楽しく使いたいだけだ

    • 今ではllama.cppは標準でGUIを含んでいる。以前はなかったが、今は時代が変わった
    • 「LM Studio、Jan、Msty、koboldcpp…」など代替は多いが、実際にOllamaを置き換えられる本命が何なのか気になる
      Mac Miniを使っているがCLIツールでも構わない。Ollamaの強みは簡単なインストールとモデルのダウンロードだったので、代替ツールにもその程度の手軽さを期待している
    • kobold.cppやLM Studioはどうかという提案。LM Studioはオープンソースではないが、llama.cppに対して正当にクレジットを与えている
      モデル対応が壊れた状態で統合されたり、誤ったGGUFがアップロードされたりしないように、品質管理が重要だと思う
    • 同意する。これはDockerと似た状況だ
      もちろんruncを直接使うこともできるが、大半はdocker runを選ぶ
      UXは技術採用の重要な要素であり、インターフェース作りが得意でないプロジェクトなら、ラッパーを作ることに何の問題もない
    • OllamaがUXの問題を解決したからといって、ライセンス違反が免責されるわけではない

  • 同じ主張を繰り返すのに疲れたので、自分が知る時系列と出典を一度に整理した

    • この記事を書いてくれてありがとうという声。自分もllama.cppに少し関わったが、Ollama創業者たちの振る舞いには本当に失望した
      代替としてはllama-fileを勧める。Mozilla AIのllamafileは単一実行ファイルでOSを問わず動作し、完全なオープンソースだ
      Justine Tunneyが作ったCosmopolitanCベースで、llama.cppを正式に使っている
    • FOSSの精神を重視する人間として、とても勉強になる記事だったという声
    • 知らなかった事実が多かったという声
    • 要約とタイムラインが素晴らしいという評価

  • Ollamaは使いやすさの面で1000倍優れていると思う
    llama.cppは素晴らしいが、一般ユーザー向けではない
    自分はOllamaから始めたが、最新の修正を求めてllama.cppに移った
    それでもモデル管理には今もOllamaを使っている。あまりに便利なので、自分でスクリプトを作ってキャッシュディレクトリを管理している

    • ブログ記事では代替が直感的だとしていたが、実際にはそうではない
      単なるチャットアプリならともかく、OpenAI互換APIとモデル管理が必要になると、使いやすさは急激に落ちる
    • Ollamaのデフォルトのcontext sizeが小さすぎて、モデルが間抜けになるという不満が多かった
      継続的に変えるには新しいモデルファイルを作る必要があり、それがさらに複雑だった
      Docker的なアプローチはむしろ一般ユーザーには不便で、上級ユーザーにはllama.cppのほうが優れていると思う
    • ちなみに今ではllama.cppにrouterモードが追加され、モデルをリアルタイムで切り替えられる
    • 最近のバージョンはずっと強力になっている。llama.cpp tools/servで確認できる
    • LM Studioを3年前から使っているが、その頃ですらすでにOllamaよりずっと良かった

  • MITライセンスについての2つの見方を整理している

    1. 「1行のクレジットさえ付ければ何でもできる」
    2. 「法的には自由でも、共同体に対する道義的責任が伴う」
      llama.cppの創始者Georgi Gerganovは、クレジットの欠落に対してのみ不満を示していた。つまり彼は前者の解釈に近い振る舞いをしている
    • 後者の解釈は筋が通らないと思う。GPLの義務を求めるならGPLを使えばいい
      MITは法的文書であって道徳指針ではない
      個人的にはユーザー向けソフトウェアにはGPLを使うのがよいと思う
      MITを使っておいて、その後で企業がコードを持っていくと文句を言うのは矛盾している
      企業には道徳はなく、あるのは人だけだと思う
    • Georgiが望んでいればいつでもGPLに変えられた。しかしそうはしなかった
      結局のところ両プロジェクトは発展を続け、ユーザーの選択肢は増えた

  • 以前はデフォルトのモデルフォルダを変更できず不便だった
    モデルを登録するにはDockerfileのような手順を踏む必要があり、モデルはハッシュストレージにコピーされるため場所も変えられなかった
    そのためLM Studioに移った。完全なオープンソースではないが、モデルフォルダが見えていてHugging Faceとも統合されていた

    • 今では可能だ。サーバー設定ファイルの環境変数OLLAMA_MODELSでパスを指定できる
    • 自分もこの問題で苦労した。SSDアップグレードの前後でLM Studioと比較しようとしたが、モデルの保存場所を探して整理する過程があまりに複雑で不必要に苦痛だった

  • Ollamaはモデルファイルをハッシュ化されたブロブストレージにコピーする構造のため、他のツールと共有できない
    おそらく重複排除のための設計なのだろうが、その結果として他ツールを試しにくくしている
    モデルファイルは非常に大きいため、ストレージ容量とダウンロード負担が大きい

  • Arch Linuxでpacman -Ss ollamaは16件ヒットするが、llama.cppやlmstudioは0件だ
    いつか変わってほしい

    • llama.cppは更新が速すぎるため安定パッケージ化は難しいが、代わりにAURからインストールできる
      Vulkan、ROCm、CUDA版のいずれも対応している
    • 一方openSUSEではzypperでllamacppを見つけられる
      ディストリビューションごとにバージョンやサポートが異なる。結局、数多くのLinuxディストリビューションが存在する理由はここにある
    • 自分はCachyOSでyay -S llama.cppからインストールしたが、Ollamaよりはるかに速くて良かった

  • 「llama.cpp」という名前は、今となっては親しみやすく聞こえない
    以前はMetaのLlamaモデルを意味していたが、今ではもっと強力なオープンソースモデルが多い

    • だが「Ollama」も同じ問題を抱えている
      今では「Local LLaMA」という名前がローカルモデル実行の一般名詞のように使われている
    • Wikipediaの一般化した商標の一覧を見ると、こうした現象は珍しくない

  • Ollamaはワークフロー全体を支配しようとする匂いがして、最初から避けていた
    結果的に正しい判断だったと思う

  • Ollamaのハッシュ化ブロブストレージ構造が最大の罠だ
    数か月かけてモデルを集めていた場合、他ツールに移る際にすべてを再ダウンロードしなければならない
    大半のユーザーは、すでに深く投資した後になって初めてこの事実に気づき、乗り換えコストの大きさを痛感する