HNはOllama批判をlocal LLMツールの信頼テストとして読んだ

“Stop Using Ollama”をめぐる HN thread は450点を超えた。火種は、local AIでよくある「どのruntimeが好きか」ではない。Sleeping Robotsの記事は、Ollamaがllama.cppを使いやすくした功績を認めつつ、attribution、model packaging、cloud機能、storage設計がユーザーのcontrolを弱めていると批判した。

論点は「llama.cppを直接使え」という単純な話ではない。記事は、Ollamaが一行コマンドの便利さで広がった一方、registry、Modelfile、template変換、hashed blob cacheを通して、modelとruntimeの間に強い中間層を作ったと見る。Hugging Faceの最新GGUFをすぐ試したい人、quantizationを細かく選びたい人、llama.cpp flagsを直接管理したい人、複数toolで同じmodel fileを共有したい人には、その中間層が便利さではなく摩擦になる。

HNのコメントは一枚岩ではなかった。llama.cppがrouter mode、hot-swapping、web UI、MCP supportなどでかなり使いやすくなったという声がある一方で、普通のユーザーはC++ projectではなくappを求めていた、というOllama擁護も目立った。さらに実務的な指摘として、Ollamaのblob storageに大きなmodelをため込むと、別runtimeへ移るときに同じGGUF cacheをそのまま指しにくい、という離脱コストも話題になった。

このthreadがAI/IT読者に刺さる理由は、local AIの価値がprivacyという言葉だけで決まらないからだ。modelがどこに保存されるか、GGUF metadataをどう扱うか、cloud-hosted modelとlocal modelをどう区別するか、upstream projectへのcreditが見えるか。こうした地味な設計が、実際の自由度を決める。

結論は単純な不買ではない。Ollamaは今でも、すぐlocal modelを動かしたい人に低い入口を提供する。だが最新model、特殊なquant、明示的なserving flags、他toolとの互換性を重視するなら、llama.cpp、LM Studio、KoboldCpp、llama-swap、直接GGUF workflowを比べる意味がある。HNが盛り上がったのは、便利なtoolがいつ自分のworkflowのownerになるのかを問う議論だった。