vLLM設定の推測はやめよう：RunPodでのLLMベンチマーク - クリス・ヴェラ（RunPod）

하이라이트

• RunPodのB300ノードをプラットフォーム上で運用する場合、月額4万ドルのコストがかかる。

• Kimi K3モデルの実行にはCUDA 12.8ではなくCUDA 13.0が必要である。

• バッチトークンの数を増やすと、長時間のジョブにおけるトークン間レイテンシが大幅に減少する。

• BenchPodはVLLMベースのDockerイメージとFastAPIアプリケーションを自動作成するテンプレートである。

타임라인

1. 00:00 - 03:47

   VLLM運用の現状と直面する課題

   RunPodのフォワードデプロイエンジニアであるクリス・ヴェラが、VLMやLLMの新しいモデルがリリースされた際に顧客や社内で直面する苦労について解説する。GPUを手軽に実行できるネオクラウドとしてのRunPodの背景を紹介しつつ、多くの人が正しいバージョンや設定を把握しないまま手探りで開発を進めている現状を指摘する。コーディングエージェントの構築や要約タスクといった具体的な目的や、ユーザー数に応じた細かい最適化の調整項目を事前に把握することの重要性を説いている。

   • 最新モデルの導入時に多くの開発者が設定を推測頼みで適当に決めている。
   • ナイトリービルド版や誤ったコンテキストウィンドウサイズを使用することでエラーや手戻りが発生する。
   • 開発環境から本番環境への移行時にはKVキャッシュの活用や同時接続ユーザー数を考慮する必要がある。
2. 03:47 - 06:07

   BenchPodによる包括的なベンチマークと自動修復

   設定変更のたびにイメージを再起動しコールドスタートを待つ時間のロスを解消するため、開発されたテンプレートであるBenchPodの概要が示される。OpenAI互換のDockerイメージをベースにしており、エージェント用としても活用できる。サービング機能やウォッチドッグによる自動修復が組み込まれているため、本番稼働のレベルに近づける段階での懸念を軽減し、開発プロセスをシンプルにする。

   • BenchPodはVLLMをベースにした包括的なメトリックシステムとテンプレートである。
   • ウォッチドッグ機能による自動修復機能を備え、先週末のGPU障害時も社内ユーザーに不具合を感じさせずに稼働した。
   • ストレージボリュームを設定しボタンを数回クリックするだけでデプロイが完了する。
3. 06:07 - 10:03

   Kimi K3モデルの検証とライブメトリクスの活用

   頻繁に使用されているKimi K3を取り上げ、コーディングエージェントにおける優れたKVキャッシュの活用効率や高速なTTFT（最初のトークン出力速度）について言及する。ダッシュボードに表示される多数のメトリクスを通じて、CUDA 13.0などの正しい動作環境を把握できる仕組みを紹介する。さらに、先週末に発生したGPU障害からの自動修復実績や、APIコールを介してAIエージェントがすべてのデータを容易に呼び出せる利便性が説明される。

   • Kimi K3は100万トークンのコンテキストを持つが、B300ではその半分程度を使用するのが現実的である。
   • ダッシュボードではGPUメトリクスやCUDAの動作バージョンをリアルタイムで確認できる。
   • Kimi K3インスタンスで発生したコールドスタートの時間は9分であった。
4. 10:03 - 16:20

   バッチトークンの最適化とモデル選択の基準

   処理されるバッチトークンの最大数を変更して並行実行したベンチマーク結果を公開し、バッチ数を増やすことで長時間のジョブを高速に完了させられる検証データを提示する。最先端のフロンティアモデルが常に最適とは限らず、DeepSeekなどを複数のH200で運用する選択肢も含めてコストとパフォーマンスのバランスを考える重要性を説く。最後に、AIガバナンスやツール導入の必要性に触れ、月末に公開されるテンプレートの活用を促して締めくくられる。

   • バッチトークンの数を増やしても1秒あたりの生成時間は変わらないが、トークン間のレイテンシは大幅に減少する。
   • B300ノードは非常に強力であるが月額4万ドルというコストがかかるため、用途に応じたモデル選択が必要である。
   • 月末にはBenchPodのテンプレートが一般公開される予定である。