Ollamaの使用をやめましょう

24日前原文(sleepingrobots.com)

概要

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.cpp や LM Studio、 vLLM など、よりオープンかつ柔軟なツールの利用を推奨

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分で起動して動くよ。

歴史の一部が欠けてる気がする… OllamaがLlama.cppがリリースされる3年前に設立されたなら、その時はどのエンジンを使ってたの？いつ移行したの？

└

彼らは数年間ステルスモードで過ごしていたけど、最初のリリースはllama.cppだった。Ollama v0.0.1「Goで書かれた高速推論サーバー、llama.cppによって動かされている」 https://github.com/ollama/ollama/tree/v0.0.1

└

それは違うと思う。llama.cppは、Metaが特定の研究者にllamaをリリースしてから数週間で登場したんだよ（その後、一般にも公開された）。その3年前には、誰もllamaって名前を知らなかった。llama.cppが先に存在してたはずだよ。

パフォーマンスの問題がすごいね。シェアしてくれてありがとう。

パフォーマンスの問題に気づいたよ。最近Janを使い始めて、llama.cppとローカルのollamaで同じモデルを実行してみたけど、llama.cppの方が明らかに速かった。

ローカルでLLMを動かしたいユーザーにとって、ollamaはUXの問題を解決してくれた。一つのコマンドで、rocmドライバーがあっても知らずにモデルを動かせるんだ。もしllamaがそんなUXを提供しているなら、コミュニケーションがひどく失敗してるね。名前からしてそうだし。Llama.cpp：それはcppライブラリだ！ollamaはラッパーだよ。それがメンタルモデル。自分のプログラムを作りたくない！ただ楽しみたいだけなんだ :-P

└

llama.cppは今やデフォルトでGUIがインストールされてるよ。以前はこれがなかったんだ。時代は変わったね。

└

でも、ollamaがめっちゃ遅いなら、楽しさが半減しちゃうよね。もっと速いGUIの方が楽しいと思うよ。

└

ラマを叩け！あ、待って、それは別のプログラムだ。

└

UXの問題を解決した。 >一つのコマンドそれに、ollama run model-nameとllama-cpp -hf model-nameの違いはほとんどゼロだし、ターミナルでの操作自体が巨大なUXの障害になってるのに（Ollamaが人気なのはGUIがあるからだよね）、なんでオープンソースプロジェクトに責任を押し付けるの？コミュニケーションなんてほぼゼロなのに。

うーん… pacman -Ss ollama | wc -l で16 pacman -Ss llama.cpp | wc -l で0 pacman -Ss lmstudio | wc -l で0 いつかはどうにかなるかな。

俺はollamaに結構期待してたんだけど、デフォルトの解決策としては素晴らしいと思ってた。最初はあの組織がゴミだってことに気づいてたけど、torchをインストールしなくても信頼できる推論バックエンドがあるのが好きだったから無視してたんだ。6ヶ月くらい前に、ollama（その組織）とのやり取りが本当にイライラしたから、全部llama.cppに切り替えた。無視してたみんなに謝りたい。ollamaは文化にとって吸血鬼みたいなもので、彼らの終わりは早く来てほしい。ちなみに、llama.cppはモデル管理を除けば、ollamaがやることをほぼ全部、ollamaよりも上手くやってるよ。でも、現実的に考えて、好みの形のAPIを書いてくれって頼めば、qwenが問題なく処理してくれるからね。

「llama.cpp」って名前、最近はあんまり親しみが持てないよね… 昔は「llama」って言ったらFacebookのモデルのことを指してたと思うけど、今はそのLlamaシリーズのモデルはもう最強のオープンソースモデルを表せないよね…

└

「ollama」の「llama」って、まさに同じ問題じゃないの？

ハクソク