--- title: "LLM Servingとは？vLLM・SGLang・Ollamaの比較と推論サーバーの構築・性能指標" url: "https://www.issoh.co.jp/tech/details/7838/" published: 2025-07-23 updated: 2026-10-31 categories: ["LLM・RAG"] publisher: "株式会社一創" --- # LLM Servingとは？vLLM・SGLang・Ollamaの比較と推論サーバーの構築・性能指標 LLM Serving（LLMサービング）は、学習済みの大規模言語モデルを推論エンジンに載せ、APIとして多数のリクエストに応答し続ける仕組みです。モデルを手元で1回動かすことと、同時に届くリクエストを決められた待ち時間内でさばき続けることは別の問題で、その差を埋めるのがサービング層です。本記事では、推論との違い、GPUメモリを使い切るPagedAttentionと連続バッチ、vLLM・SGLang・Ollamaなど推論エンジンの選び方、TTFTやITLといった性能指標の測り方、GPUメモリの見積もりと起動コマンド、本番で見落としやすい認証の範囲までを、2026年10月時点の一次情報で整理します。 ## まとめ：LLM Servingの要点と推論エンジンの選び方 - LLM Servingは推論の計算そのものではなく、APIの受付・バッチ化・スケジューリング・スケーリング・監視までを含む本番の仕組みを指します。 - 速さを決めるのはKVキャッシュの管理（PagedAttention）とリクエストの差し込み（連続バッチ）です。vLLM 0.32.0では、対応する生成モデルならプレフィックスキャッシュとチャンク化プレフィルも既定で有効です。 - 本番GPUで多数の同時接続をさばくならvLLMが標準、共通の接頭辞が多いエージェントやRAGはSGLang、手元の検証はOllamaかllama.cppです。Hugging FaceのTGIは2025年12月に保守モードへ移りました。 - 性能は「1トークン目までの時間（TTFT）」と「トークン間の時間（ITL・TPOT）」に分けて測ります。平均だけでなくP99と、目標を満たしたリクエストの単位時間あたりの処理件数（goodput）で判断します。 - GPUメモリは「重み＋KVキャッシュ＋実行時の作業領域」で見積もります。Qwen3-8Bのbf16は重みだけで約16.4GB、KVキャッシュは1トークンあたり144KiBです。 ## LLM Servingの意味と推論との違い サービング（serving）は、モデルを「呼べば答えが返る本番サービス」に変える工程全体を指す言葉です。推論（inference）はその中心にある計算で、両者は包含関係にあります。推論そのものの仕組みは[LLM推論とは？仕組みと高速化の手法・推論基盤の選び方を実装視点で解説【2026年】](/tech/details/15363/)、LLMに限らない機械学習モデル全般の配備は[モデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準を解説【2026年版】](/tech/details/16073/)で扱っています。本記事はLLM固有のサービングに絞ります。 ### 推論とサービングの役割分担 推論は、入力に対してモデルが出力トークンを1つずつ生成する計算です。サービングは、その推論を中心に、受付API（多くはOpenAI互換のREST）、リクエストの待ち行列とバッチ化、GPUへの割り当て、認証とレート制限、ログと監視、モデルの入れ替えまでを束ねたシステムです。推論が速くても、リクエストが1件ずつ直列に流れるとGPUは空き時間だらけになるため、実サービスの速さと単価はサービング層の設計で決まります。 ### prefillとdecodeの処理特性とGPU配置 LLMの1リクエストは2段階で進みます。prefillは入力プロンプト全体を並列に処理してKVキャッシュ（各トークンのKeyとValue）を作る段階で、演算量が多く、1トークン目が返るまでの時間を決めます。decodeは1トークンずつ生成する段階で、毎回KVキャッシュ全体を読むためメモリ帯域に縛られます。DistServe（[arXiv:2401.09670](https://arxiv.org/abs/2401.09670)）は、同じGPUで2段階を混ぜると互いに待たせ合うことを示し、prefillとdecodeを別GPUに分ける設計で、待ち時間の制約内でさばけるリクエスト数を最大7.4倍にしたと報告しています。この「分離するかどうか」が、後で触れる大規模構成の分かれ目になります。 ## GPUを使い切る基盤技術：PagedAttention・連続バッチ・プレフィックスキャッシュ 主要な推論エンジンは、次の技術を共通して実装しています。 ### PagedAttentionによるKVキャッシュの固定長ブロック管理 PagedAttentionは、vLLMの論文（Kwonら、SOSP 2023、[arXiv:2309.06180](https://arxiv.org/abs/2309.06180)）で提案されたKVキャッシュの管理方式です。OSの仮想メモリのページングと同じ発想で、KVキャッシュを固定長ブロックに分け、GPUメモリ上の空いている物理ブロックへ非連続に配置し、論理ブロックから物理ブロックへの対応表で引きます。必要になった分だけブロックを確保するので、最大長を前もって確保する方式で起きていた断片化と重複がほぼ消え、論文ではFasterTransformerやOrcaと同じ待ち時間で2〜4倍のスループットを示しました。vLLMのブロック長の既定値は16トークンで、v0.32.0では注意機構のバックエンドに合わせて自動で選ばれます。 PagedAttentionは、KVキャッシュをGPUとCPUに分けて退避する技術ではありません。要点はGPUメモリ内での非連続配置で、CPUへのオフロードは別の機能です。vLLMでの具体的な挙動は[vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説](/tech/details/15786/)で詳しく扱っています。 ### 連続バッチによる反復単位のリクエスト入れ替え 連続バッチ（continuous batching、in-flight batching）は、Orca（OSDI 2022）が示した反復単位のスケジューリングです。従来のバッチ処理は、バッチ内の全リクエストが生成を終えるまで次を入れません。連続バッチは1トークン生成するたびに、終わったリクエストを抜いて待機中のリクエストを空いた枠に差し込みます。応答の長さがまちまちなチャットでは、短い応答が長い応答を待つ無駄がなくなります。vLLM・SGLang・TensorRT-LLMはいずれも標準で備えています。 ### プレフィックスキャッシュとチャンク化プレフィル：既定設定と適用条件 プレフィックスキャッシュは、システムプロンプトやRAGの共通部分など、前のリクエストと同じ接頭辞のKVキャッシュを再利用してprefillを省く機能です。チャンク化プレフィルは、長いプロンプトのprefillを小分けにしてdecodeと同じステップに混ぜ、長文の入力が他のユーザーの生成を止めないようにします。vLLM v0.32.0のソースでは`enable_prefix_caching`と`enable_chunked_prefill`がどちらも既定で`True`です（[vllm/config/cache.py](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/config/cache.py)・[vllm/config/scheduler.py](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/config/scheduler.py)）。ただし、プレフィックスキャッシュを公式に対応していないモデルや一部のCPU環境では、起動時に自動で無効になります。SGLangはこの再利用を基数木で管理するRadixAttentionを中核に据え、論文（[arXiv:2312.07104](https://arxiv.org/abs/2312.07104)）ではエージェント制御やマルチターン会話などで最大6.4倍のスループットを示しています。共通の接頭辞がない用途では、接頭辞キャッシュの再利用による効果は期待できません。ただし、構造化出力など他の最適化によるエンジン間の性能差は残ります。 ## 推論エンジンの比較と選び方（2026年10月時点） 推論エンジンは「本番GPUで同時接続をさばくもの」と「手元で手軽に動かすもの」に分かれます。版と公開日はGitHubのリリースから取得した2026年10月31日時点の値です。 | エンジン | 開発元 | 最新版（公開日） | 既定ポート | 強み | | ------------ | ------------ | -------------------- | ----- | ---------------------- | | vLLM | vLLMプロジェクト | 0.32.0（10/18） | 8000 | PagedAttention・対応モデル数 | | SGLang | SGLangプロジェクト | 0.5.22（10/19） | 30000 | RadixAttention・構造化出力 | | TensorRT-LLM | NVIDIA | 1.2.1（4/20）・1.4.0rc2 | 8000 | NVIDIA GPU向けの最適化 | | TGI | Hugging Face | 3.3.7（2025/12/19） | – | 保守モード | | Ollama | Ollama | 0.40.13（10/28） | 11434 | 1コマンドで導入 | | llama.cpp | ggml-org | b12015（10/30） | 9931 | CPU・Apple Silicon・GGUF | llama.cppの`llama-server`は、2026年10月15日のビルドb11662から既定ポートが8080から9931に変わりました（[tools/server/README.md](https://github.com/ggml-org/llama.cpp/blob/master/tools/server/README.md)）。8080を前提にした古い手順やリバースプロキシの設定は、`--port 8080`を明示しないとつながりません。 ### 本番GPU向け：vLLM・SGLang・TensorRT-LLM vLLMは多様なモデルとハードウェアに対応しており、OpenAI互換APIで既存のクライアントからそのまま呼べるため、迷ったときの起点になります。2026年8月の実証研究（[arXiv:2608.03036](https://arxiv.org/abs/2608.03036)）でも、OSSでの採用が最も多いエンジンはvLLMでした。SGLangは、同じシステムプロンプトや会話履歴を繰り返し送るエージェント・RAG・マルチターン会話で有利です。TensorRT-LLMはモデルをNVIDIA GPU向けに最適化して高い性能を出しますが、NVIDIA GPUに固定され、正式版（1.2.1）とリリース候補（1.4.0rc2）の間が半年ほど空いている点は運用上の確認事項です。仕組みと採用判断は[TensorRT-LLMとは？NVIDIA GPUでのLLM推論高速化の仕組みと採用判断を解説【2026年版】](/tech/details/16075/)にまとめています。 ### ローカル・検証向け：Ollama・llama.cpp・MLX Ollamaは`ollama run`1つでモデルの取得から対話までが済み、既定で127.0.0.1の11434番にAPIサーバーが立ちます。llama.cppはGGUF形式の量子化モデルをCPUやApple Siliconで動かす用途に強く、エッジや組み込みに向きます。Apple Siliconに絞るなら[MLXとは？mlx-lmの使い方｜生成・量子化・サーバ・LoRAの手順とApple Siliconでの採用判断【2026年10月】](/tech/details/17956/)も候補です。いずれもPoCや社内検証には十分ですが、数十〜数百の同時接続を受ける本番では、連続バッチとKVキャッシュ管理を作り込んだvLLMやSGLangに分があります。 ### TGIの保守モード移行とリポジトリのアーカイブ Hugging FaceのText Generation Inference（TGI）は、2025年12月11日にREADMEへ保守モード（maintenance mode）の告知を加え、当時は小さなバグ修正やドキュメント改善などを受け付ける方針を示しました。その後リポジトリはアーカイブされ、2026年10月時点では読み取り専用です（最後の更新は2026年3月21日）。同じREADMEで、新規の利用先としてvLLM・SGLang、ローカル向けにllama.cppとMLXを推奨しています（[huggingface/text-generation-inference](https://github.com/huggingface/text-generation-inference)）。最後のリリースは2025年12月19日の3.3.7です。既存のTGI環境を動かし続けることはできますが、新規に選ぶ理由はありません。移行の判断は[Text Generation Inference（TGI）とは？メンテナンスモード後の採用判断とvLLM移行【2026年版】](/tech/details/15937/)で扱っています。 ### 条件別の推奨と、選んではいけない組み合わせ | 条件 | 推奨 | | ------------------------ | --------------------------- | | 本番GPU・多数の同時接続・モデル入れ替えが多い | vLLM | | 共通の接頭辞が長いエージェント・RAG | SGLang | | NVIDIA固定でモデルを長期間固定 | TensorRT-LLM | | GPUなしPC・個人の検証 | Ollama / llama.cpp | | Mac（Apple Silicon）中心 | MLX / llama.cpp | | Kubernetesで複数ノードに分散 | llm-d / NVIDIA Dynamo＋vLLM等 | 避けるべきなのは、Ollamaをそのまま社外向けの本番APIにする構成と、検証もしていないのにTensorRT-LLMを最初に選ぶ構成です。前者は認証や負荷制御を別途設計する必要があり、後者は対象モデル・GPU・バックエンドの対応確認が必要です。TensorRT-LLMのPyTorchバックエンドでは、対応モデルをTensorRTエンジンの事前構築なしで読み込めます。まずvLLMで基準値を測り、足りない指標がはっきりしてから他のエンジンを試すのが手戻りの少ない順番です。 ## 性能指標の読み方：TTFT・ITL・TPOT・goodput サービングの性能は、ユーザーが体感する待ち時間と、GPU1枚あたりの処理量に分けて測ります。1つの数字で比べると、エンジン選定もチューニングも外れます。 ### TTFT・ITL・TPOT・goodputの定義と応答体感との関係 | 指標 | 測るもの | 主に効く段階 | | ------- | ---------------------- | ------------ | | TTFT | 送信から1つ目の出力までの時間 | prefill・待ち行列 | | ITL | 連続する出力の間隔 | decode | | TPOT | 1トークン目を除く出力1トークンあたりの時間 | decode | | goodput | 目標の待ち時間を満たしたリクエストの毎秒件数 | 全体 | vLLMのベンチマーク文書は、TPOTを「（全体の待ち時間−TTFT）÷（出力トークン数−1）」で定義し、通常のデコードではITLとTPOTはほぼ同じ値になると説明しています（[docs/benchmarking/cli.md](https://github.com/vllm-project/vllm/blob/v0.32.0/docs/benchmarking/cli.md)）。投機的デコーディングを使うと1回の出力に複数トークンが入るため、ITLは大きく、TPOTは小さく出ます。チャットの体感はTTFTとITLで、バッチ処理の単価はスループットで決まります。目標値は平均ではなくP99で置いてください。平均だけでは一部のリクエストに生じる長い待ち時間を見落とすため、P99も測り、用途に応じた許容時間と照合してください。 ### vllm bench serveによる負荷試験と遅延計測 vLLMには負荷試験のコマンドが付属しています。サーバーを起動した状態で、別のターミナルから次のように実行すると、TTFT・TPOT・ITLの平均・中央値・P99が表で出ます。`--goodput`にTTFTとTPOTの目標をミリ秒で渡すと、目標内に収まったリクエストの毎秒件数（Request goodput）も出ます。サーバーを`--api-key`付きで起動した場合は、ベンチ側の環境変数`OPENAI_API_KEY`に同じ値を入れます。 ``` # サーバー側（別ターミナルで起動済みとする） # vllm serve Qwen/Qwen3-8B --max-model-len 8192 vllm bench serve \ --backend vllm \ --model Qwen/Qwen3-8B \ --dataset-name random \ --random-input-len 1024 \ --random-output-len 256 \ --num-prompts 200 \ --max-concurrency 32 \ --goodput ttft:500 tpot:50 ``` `--max-concurrency`を8・16・32・64と上げながら同じ測定を繰り返し、TTFTとTPOTのP99・goodput・エラー率がすべての目標を満たす同時接続数を探します。200件の試行は初期確認とし、運用上限は試行件数を増やして複数回測定した結果から決めてください。同じサーバーに同じプロンプトを繰り返し流すと、プレフィックスキャッシュが効いてスループットが実際より高く出る、と公式文書が注意しています。測定ごとに`--seed`を変えるか、サーバーを再起動してください。本番に近いデータで測るなら、vLLMプロジェクトが推奨するGuideLLMも選択肢です。 ## 自前でLLMサーバーを立てる：GPUメモリの見積もりと起動手順 ローカルや社内でLLMサーバーを立てるときは、まずGPUメモリに収まるかを計算し、次にvLLMかOllamaで起動します。 ### 必要なGPUメモリ＝重み＋KVキャッシュ 重みは「パラメータ数×精度のバイト数」で、bf16・fp16は2バイト、int4量子化は約0.5バイトです。KVキャッシュは1トークンあたり「2（KとV）×層数×KVヘッド数×ヘッド次元×バイト数」で、これに同時に保持するトークン数を掛けます。Hugging Faceのconfig.jsonで、Qwen3-8Bは36層・KVヘッド8・ヘッド次元128なので、bf16で1トークンあたり2×36×8×128×2＝147,456バイト（144KiB）です。8,192トークンの会話を1本保持すると約1.1GiB、32本同時なら約36GiBになり、重みより大きくなります。同じ8BでもLlama 3.1 8Bは32層なので128KiB/トークンです。 | モデル規模 | bf16の重み | int4の重み | 構成の目安 | | ------ | ------- | ------- | -------------------- | | 7〜8B | 約16GB | 約5GB | 24GB GPU 1枚 | | 13〜14B | 約28GB | 約8GB | bf16は48GB級・int4は24GB | | 70B | 約140GB | 約40GB | 80GB GPU 2枚以上 | 表は重みだけの概算で、KVキャッシュと実行時の作業領域が別に要ります。同時接続数と最大コンテキスト長を決めてから、上の式でKVキャッシュを足して判断してください。GPUがない場合はint4のGGUFをllama.cppやOllamaでCPU実行できますが、生成速度は大きく落ちます。 ### vLLMのOpenAI互換サーバー起動手順 vLLMは`vllm serve`にモデル名を渡すと、既定で8000番にOpenAI互換のエンドポイントが立ちます。Qwen3-8BはApache 2.0で、Hugging Faceのアクセス申請なしで取得できます。 ``` pip install 'vllm[bench]==0.32.0' # 両ターミナルで同じ十分に長い秘密値をVLLM_API_KEYに設定してから実行 : "${VLLM_API_KEY:?VLLM_API_KEYに秘密値を設定してください}" # OpenAI互換サーバーを起動（既定ポート8000） vllm serve Qwen/Qwen3-8B \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --api-key "$VLLM_API_KEY" # 別ターミナルからリクエスト curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $VLLM_API_KEY" \ -d '{"model":"Qwen/Qwen3-8B","messages":[{"role":"user","content":"こんにちは"}]}' ``` チューニングで最初に触る引数は次の4つです。既定値はv0.32.0のソースで確認したものです。 | 引数 | 既定値 | 効き方 | | ----------------------- | --------- | ---------------------- | | –gpu-memory-utilization | 0.92 | 重みとKVキャッシュに使うGPUメモリの割合 | | –max-model-len | モデルの最大長 | 下げるとKVキャッシュに余裕 | | –max-num-seqs | GPUと用途で自動 | 同時に処理する系列数の上限 | | –tensor-parallel-size | 1 | 1台内の複数GPUに重みを分割 | 同じGPUで別のプロセスも動かすなら`--gpu-memory-utilization`を下げます。メモリ不足で起動しないときは、まず`--max-model-len`を実際に必要な長さまで絞るのが効きます。複数GPUを使うときは`--tensor-parallel-size`にGPU数を、ノードをまたぐ場合は`--pipeline-parallel-size`も指定します（[vLLM Parallelism and Scaling](https://docs.vllm.ai/en/latest/serving/parallelism%5Fscaling/)）。 ### Ollamaのローカルサーバー起動手順 Ollamaはアプリかサービスとして常駐させ、`ollama pull`でモデルを取得すると11434番のAPIから呼べます（端末で対話するだけなら`ollama run`で足ります）。`/v1/chat/completions`のOpenAI互換エンドポイントもあるため、アプリ側はvLLMとほぼ同じ形で呼べます。 ``` # Ollamaをインストールし、アプリまたはサービスを起動しておく # サーバーが停止中なら、先に別ターミナルでollama serveを実行 # APIで使用するモデルを取得 ollama pull qwen3:8b # APIサーバーは別ターミナルまたはアプリ・サービスで起動済みとする # 既定の接続先は127.0.0.1:11434 # OpenAI互換エンドポイントへリクエスト curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen3:8b","messages":[{"role":"user","content":"こんにちは"}]}' ``` Ollamaは既定で127.0.0.1にだけ待ち受けるので、他の端末から使うには環境変数`OLLAMA_HOST=0.0.0.0:11434`が要ります。公式文書のとおり`localhost:11434`のローカルAPIは認証を求めないため（[Ollama Authentication](https://docs.ollama.com/api/authentication)）、社内ネットワークに出す前にリバースプロキシで認証を挟んでください。開発ツールから手元のモデルを呼ぶ構成は[OllamaでCodexをローカルLLM実行する方法｜ollama launch codex・chatgpt（旧codex-app）の設定【2026年10月】](/tech/details/12264/)が具体例です。 ## 本番運用：分散構成・監視・認証の範囲 ### 1台に収まらないときの分散構成：llm-dとNVIDIA Dynamo 1台のGPUサーバーに収まらない規模や、prefillとdecodeを別々に増減したい場合は、推論エンジンの上に分散の仕組みを重ねます。llm-dはKubernetes向けの分散推論スタックで、2026年10月20日に1.0.0が出ました。READMEでは、prefillとdecodeの分離で標準のvLLMより最大70%高いトークン毎秒を出した事例（NVIDIA B200・AWS）を挙げています（[llm-d/llm-d](https://github.com/llm-d/llm-d)）。NVIDIA Dynamo（1.6.1、2026年10月27日）は、vLLM・SGLang・TensorRT-LLMを置き換えるのではなく、それらを複数ノードで協調させるオーケストレーション層で、分離サービング・KVキャッシュを意識したルーティング・自動スケーリングを備えます（[ai-dynamo/dynamo](https://github.com/ai-dynamo/dynamo)）。単一サーバーで性能目標を満たし、複数レプリカへのルーティングや自動スケーリングも不要なら、まず推論エンジン単体から始める方針です。llm-dの構成と導入は[llm-dとは？1.0の新機能とKubernetes分散推論の仕組み・導入手順と採用判断【2026年10月】](/tech/details/16392/)で解説しています。 ### /metricsで見るべき指標 vLLMは`/metrics`でPrometheus形式の指標を出します。運用で最初に監視するのは次の指標です。 - `vllm:time_to_first_token_seconds`と`vllm:inter_token_latency_seconds`：体感の待ち時間。P99で警告を出します。 - `vllm:num_requests_waiting`：待ち行列の長さ。増え続ける場合は、流入量に処理能力が追いついていない可能性があります。GPU使用率、入出力長、スケジューラ設定、エラーを併せて確認します。 - `vllm:kv_cache_usage_perc`：KVキャッシュの使用率。高止まりとプリエンプション回数の増加が重なる場合は、処理中のリクエストに必要なKVキャッシュが不足していないか確認します。 - `vllm:num_preemptions`：追い出しの回数。増えたら`--max-num-seqs`か`--max-model-len`を下げます。 複数のモデルや外部APIを1つの入口にまとめ、予算や失敗時の切り替えを管理するなら、vLLMの前段にLiteLLMを置く構成が定番です（[LiteLLMとは？複数LLMを1つのAPIで呼ぶProxyの構築手順とフォールバック・予算設定【2026年10月】](/tech/details/18663/)）。 ### –api-keyで守られる範囲と守られない範囲 自社でLLMを動かす大きな理由は、プロンプトや社内文書を外部の生成AIサービスに送らずに済むことです。ただし、サーバー自体を外から叩ける状態にすると、別の漏洩経路ができます。vLLMのセキュリティ文書によると、`--api-key`が認証をかけるのは`/v1`・`/v2`・`/inference`・`/cohere`で始まるパスだけです。SageMaker互換の`/invocations`や、生成を止める`/pause`、重みを書き換える`/update_weights`などは、`--api-key`を付けても認証なしで呼べます（[docs/usage/security.md](https://github.com/vllm-project/vllm/blob/v0.32.0/docs/usage/security.md)）。本番では、vLLMを外部に直接公開せず、許可したパスだけを通すリバースプロキシの内側に置いてください。プロンプトインジェクションへの入出力フィルタや、個人情報のマスキング、監査ログはその上に重ねる対策です。閉域で生成AIを業務に組み込む設計から相談したい場合は、[生成AI導入支援](https://www.issoh.co.jp/service/ai/genai/)でも対応しています。 ## よくある質問 ### LLM Servingの「サービング」とはどういう意味ですか？ 学習済みのモデルを、外部から呼び出せるAPIとして提供し続けることです。推論の計算に加えて、リクエストの受付・バッチ化・GPUの割り当て・監視までを含みます。 ### LLMサービングのフレームワークはどれを選べばよいですか？ 本番GPUで多数の同時接続を受けるならvLLM、共通の接頭辞が長いエージェントやRAGはSGLang、手元の検証はOllamaかllama.cppです。TGIは保守モードのため新規には選びません。 ### vLLMとは何ですか？Ollamaとどう違いますか？ vLLMはPagedAttentionと連続バッチで同時接続のスループットを高めた推論エンジンで、2026年10月時点の最新は0.32.0です。Ollamaは導入の手軽さを優先したローカル向けのツールで、同時接続の多い本番はvLLMが向きます。 ### ローカルでLLMサーバーを立てるのに必要なGPUは？ 8Bクラスをbf16で動かすなら24GBのGPU1枚が目安で、重みが約16GB、残りをKVキャッシュに使います。int4量子化なら重みは約5GBまで下がります。70Bはint4でも約40GBが要ります。 ### LLMサーバーの速さは何で比べればよいですか？ 1つ目の出力までの時間（TTFT）と、トークン間の時間（ITL・TPOT）を、平均ではなくP99で比べます。同じモデル・同じGPU・同じ入出力長で`vllm bench serve`などを使い、同時接続数を変えながら測ります。 ## 関連記事 - [vLLMとは？PagedAttentionの仕組み・使い方とOllama・TensorRT-LLMとの違いを実装者目線で解説](/tech/details/15786/) - [LLM推論とは？仕組みと高速化の手法・推論基盤の選び方を実装視点で解説【2026年】](/tech/details/15363/) - [モデルサービングとは？推論APIの構成とKServe・Triton・BentoMLの選定基準を解説【2026年版】](/tech/details/16073/) - [TensorRT-LLMとは？NVIDIA GPUでのLLM推論高速化の仕組みと採用判断を解説【2026年版】](/tech/details/16075/) - [llm-dとは？1.0の新機能とKubernetes分散推論の仕組み・導入手順と採用判断【2026年10月】](/tech/details/16392/) --- 出典: [LLM Servingとは？vLLM・SGLang・Ollamaの比較と推論サーバーの構築・性能指標]()（株式会社一創）