世界を動かす技術を、日本語で。

Ollamaの使用をやめましょう

概要

  • Ollama はローカルLLM運用で最も有名なツールだが、問題点が多い
  • llama.cpp へのクレジット不足やライセンス違反が指摘されている
  • パフォーマンスやモデル管理の面で llama.cpp より劣る点が多い
  • Modelfile など独自仕様がユーザー体験を複雑化
  • クラウド志向 への転換やオープンソース精神の形骸化が懸念されている

Ollamaの問題点と背景

  • Ollama はローカルLLM運用の先駆けとして人気を獲得

    • llama.cppのC++ビルドやサーバー設定の煩雑さを解消
    • 「Docker for LLMs」としてワンコマンド運用を提供
  • llama.cpp へのクレジット不備

    • READMEや配布バイナリにMITライセンス表記が長期間未記載
    • GitHub issue #3185で指摘されるも400日以上放置
    • 2024年4月に渋々「llama.cpp project founded by Georgi Gerganov.」と1行追記
  • Ollamaチームの姿勢

    • llama.cppへの依存を過小評価、独自エンジン開発へシフトを示唆
    • コミュニティからは「正当なクレジットを与えよ」と批判多数

独自バックエンド移行の失敗

  • 2025年中頃、llama.cppから ggml ベースの独自実装へ移行

    • 安定性向上を狙うが、既知バグや非対応モデルが増加
    • GPT-OSS 20Bなど新規モデルで動作不良、テンソル型未対応
    • llama.cppより1.8倍遅いなどパフォーマンス低下(例:161 vs 89 token/s)
  • パフォーマンス劣化の要因

    • Ollama独自デーモン層によるオーバーヘッド
    • GPUオフロードの非効率化
    • Upstreamとの差分による最適化不足

モデル名の誤表記と混乱

  • DeepSeek R1ファミリーの取り扱いで誤解を誘発
    • Distillモデル(8B)を「DeepSeek-R1」と表記し本来の671Bモデルと誤認させる
    • SNSで「DeepSeek-R1がローカルで動いた」と誤情報が拡散
    • GitHub issue #8557, #8698も未解決

クローズドソース化への傾斜

  • 2025年7月、GUIアプリをクローズドソースで公開
    • ライセンス未付与、ソース非公開、MITライセンスと誤認させるUI
    • AGPL依存疑惑も指摘される
    • 数ヶ月後にメインリポジトリへ統合されたが、運営方針に疑問の声

Modelfileによるユーザー体験の悪化

  • GGUF の「単一ファイルで完結」を無視し、Modelfileを追加

    • チャットテンプレートやパラメータがGGUF内にあるのに別ファイル必須
    • テンプレート自動認識はOllama既知のもののみ、未知テンプレは破損
    • Goテンプレート形式への手動変換が必要、Jinjaと非互換
  • パラメータ変更の煩雑さ

    • 1パラメータ変更のために30-60GBのモデルコピーが発生
    • llama.cppはCLIフラグで即時変更可能、Ollamaは手間とストレージ負担大

モデル登録・配布のボトルネック

  • 新モデル登場時、Hugging FaceのGGUFは即時利用可能(llama.cpp)

  • Ollamaは内部レジストリでのパッケージング待ちが必要

    • 限られた量子化形式(Q4_K_M, Q8_0等)のみサポート
    • ユーザーの要望には「他ツールを使え」と案内
  • huggingface直pull機能 も後付け対応

    • それでも独自ストレージやテンプレ破損問題は解決せず

クラウド志向・ローカルファーストの崩壊

  • 2025年後半、Ollamaはクラウド推進を開始
    • ローカルプライバシー重視の理念から逸脱
    • コミュニティの信頼低下

まとめ:なぜOllamaを使うべきではないか

  • オープンソース精神の形骸化 とクレジット軽視
  • パフォーマンス・互換性・柔軟性 でllama.cpp等に劣後
  • ユーザー体験の複雑化 と独自仕様によるロックイン
  • クラウド志向 への転換でローカル志向ユーザーの期待を裏切る
  • コミュニティでは「 Friends don’t let friends use ollama」という声が定着

結論 最新・高性能なローカルLLM運用には llama.cppLM StudiovLLM など、よりオープンかつ柔軟なツールの利用を推奨

Hackerたちの意見

同じポイントを繰り返すのに疲れたし、毎回ソースを掘り起こすのも面倒だったから、ここにタイムライン(私が知っている限り)をまとめておくよ。

ありがとう、これ知らなかった。

素晴らしい文章だね、まとめとタイムラインありがとう。

これを書いてくれてありがとう。ここにいる人たちが実際に読んで、根拠のない攻撃記事だと決めつけないことを願ってる。私はちょっとだけllama.cppに関わっていて、君が書いたことのほとんどを知ってるけど、ollamaの創設者たちの行動は本当にひどいよ!代替案を探している人には、llama-fileをおすすめするよ。これは、選んだモデルを含むどのOSでも動く1ファイルの実行可能ファイルなんだ: https://github.com/mozilla-ai/llamafile?tab=readme-ov-file 本当にオープンソースで、Mozillaが支援していて、llama.cppをオープンに使ってるし、CosmopolitanCの有名な魔法使いジャスティン・タニーが作ったんだ。

すごくいいね。こんなこと全然知らなかったよ。

まだデフォルトのモデルフォルダを変更できないの? 無駄なdockerfileみたいなものでモデルを手動登録するために、いろいろ面倒なことをしなきゃいけなかったよね。それで元のモデルをハッシュストレージにコピーするみたいな感じだったし(そのストレージの場所も変更できなかったし)。その時、LMStudioに切り替えたんだけど、正直そっちも完全にオープンソースではなかったけど、少なくともモデルフォルダを見せてくれたし、HFと統合されてたから、無駄なプロプライエタリモデルガーデンよりはマシだった。

これもすごくイライラした。SSDストレージをアップグレードする前に使ってたんだけど、LM Studioと比較したくて。両方のインターフェースでHFからダウンロードした同じモデルを使えたらいいなと思ったんだ。どこに何があるのか、どう整理されてるのかを探すのに同じような苦労をしなきゃいけなかった。ほんとに無駄に痛い思いをしたよ。

まだデフォルトのモデルフォルダを変更できないの? 実はできるよ。サーバーの設定ファイルにオプションがあるから。

Ollamaが使いやすさで約1000倍優れていることには触れられてないね。Llama.cppは素晴らしいプロジェクトだけど、使い勝手が悪いソフトウェアの中でも最もユーザーフレンドリーじゃないと思う。プロジェクトの誰も普通のユーザーのことを気にしてないんじゃないかな。最初はOllamaを使ってて、すごく良かった。でも、もっと最新の修正を得るためにllama.cppに移った。モデルを引っ張ったりリストしたりするのはOllamaが簡単だから、今でも使ってるよ。それから、llama-swapがggufをllama.cppに読み込めるように、ハードリンクの別のキャッシュディレクトリを埋めるためのスクリプトを自分で作った。

その通り。ブログ記事には、挙げられた代替案が同じくらい直感的だと書いてあるけど、全然そうじゃない。チャットアプリが必要なら、確かに選択肢はたくさんある。でも、OpenAI互換のAPIとモデル管理が欲しいなら、アクセスの面で問題がすぐに出てくる。提案にはオープンだけど、ブログ記事に書かれている代替案はダメだね。

Ollamaが使いやすいことには触れられていない。何と比べて?私は3年前にこの投稿で言及されているLM Studioに出会ったけど、その時点でOllamaが何かも知らなかった。あれはその時からずっと良かったよ。

ollamaでVulkanアクセラレーションを動かそうと2時間もかけたけど、全然ダメだった(半分のモデルがサポートされてなくて、クラッシュしちゃう)。llama.cppのポッドマンコンテナは、5分で起動して動くよ。

Hacker Newsで議論の続きを見る