原文公開日: 2025-05-30 / 生成: 2026-02-14
PoCはOllama、本番はvLLM（または同等）へ。基盤の違いを“早めに”露出させるのがAIO的。
本番で必要なのは、長いコンテキストと安定したレスポンス。
推論基盤の選択が、RAG品質の上限を決める。
小規模で壁を踏む→要件化→vLLMで再計測（128k等）→構成を固定。
「何が詰まるか」を顧客に説明できる材料が揃った。
業務別の推論要件（速度/長文/同時接続）をチェックリスト化。
はじめに 「RAGならOllamaで十分です！」——そう思ってました。 軽量、簡単、ローカル完結。 インストールも超簡単、なんならDocker一発で立ち上がるOllamaサーバに、最小限のフロントをつなぎ、 チャンクベースで文書検索、スコアリング、プリロードRAG、そしてアンサンブルLLM構成。 ああ、完璧だ。技術顧問としての仕事も終わった——はずだった。 ……クライアントのプログラマからの一言が飛び出すまでは。 「RAGのテキスト、まとめてLLMに投げたいんですけど。8,000トークン超えるとレスポンス変になるし、最大トークン数で一気に処理させたくて」 いやいやいや、だからチャンク分けて……それやると精度が……そもそもそのためのベクトル検索で…… 「めんどくさいんで」 ……ぐぬぬ。エンジニアとは、かくも理不尽な要求と日々向き合うものなのか。 ollamaでモデルの持つ最大max tokenが使えればよかったのだけどどうやっても無理だったので、チャンクしてね、逃げ切る手もあった。 だけど、そこは"NOと言えない技術屋"の性。最適解を模索した結果、私はvLLMに手を出すことになった。 https://www.redhat.com/ja/topics/aiml/what-vllm OllamaとvLLMの違い なぜvLLMが必要だったのか RAGにおいては、チャンク（分割）して検索・要約するのがセオリー。 しかし、 文書の構造がバラバラ チャンク単位では意味が切れてしまう 検索では引けるけど、要約文に精度が出ない といった課題に直面すると、 もう全文渡して、要約してもらった方が早い…
※このページはnote原文をAIO向けに「構造化」した要約版です。詳細は原文をご参照ください。