vLLM の品質保証プロセスを解説

imagevLLM のプルリクエストが、CI やパフォーマンス・精度評価、リリースゲートを通過する様子

イントロダクション

vLLM は現在、最も広く利用されているオープンソースの LLM 推論エンジンです。GitHub ではスター数が 8.6 万を超え、月間の pip インストール数は 560 万件、イメージプル数は 250 万件に達しています。さらに、1,000 種類以上のモデルアーキテクチャと 600 種以上のアクセラレータに対応しています。

このように多様なモデルやハードウェアをサポートできる点は vLLM の最大の強みですが、同時に安定性を維持するのが極めて困難な要因でもあります。

2026 年 6 月、vLLM はメインブランチに 1,918 コミットをマージしました。これは平均して 1 日あたり 64 コミットに相当し、PyTorch や Kubernetes といった大規模な OSS プロジェクトと同等のペースです。この期間中、CI（継続的インテグレーション）はピーク時に 1,400 の並列ランナーを稼働させ、合計で 1,300 万分のジョブ時間を消費しました。

このようなペースで vLLM をテストするのは、日々難しくなっています。H100 では問題なく動作する変更でも、AMD ではコンパイルに失敗したり、B200 でスループットが低下したり、特定のバックエンドではモデルの出力をわずかに変えてしまう可能性があります。vLLM が使われる理由となっている広範な対応範囲こそが、コミットごとに守らなければならない領域そのものです。

この記事では、このペースで vLLM のリリースを安定させるために私たちが行っていること、成功した施策や得た教訓、そしてまだ課題が残る部分について共有します。ここでは技術的な詳細よりも、高レベルなプロセスに焦点を当てます。技術の詳細については別の記事で取り上げます。

vLLM におけるプルリクエストから新バージョンへのリリースに至るまでの道のりは、以下の 3 つの層を経由する必要があります：

• CI — PR ごとに何が壊れているかを即座に検出する仕組み
• パフォーマンスベンチマークと精度評価 — CI では捉えきれない、静かに壊れる現象を検出する方法
• リリースプロセス — シグナルを評価し、判断を下した上で、ユーザーへ安全にアーティファクトを届ける手順

レイヤー 1: CI

コードベースの全コンポーネントに対する広範なユニットテスト

すべての PR（プルリクエスト）には、まず軽量な GitHub Actions のチェックが走ります。コードの静的解析（linting）やフォーマット確認など、基本的なガードレールです。

コミッターが「マージ可能」と判断すると、CI プラットフォームである Buildkite で本格的なユニットテストの実行が始まります。

imageGitHub Actions のチェックから、動的に選択された Buildkite ジョブへと至る vLLM の CI フロー

Buildkite は各 PR に対してテストパイプラインを動的に構築します。まずブートストラップステップでジョブ定義を読み込み、差分（diff）を検証して関連するグループのみをスケジュールします。

ドキュメントのみの変更であれば、実行されるのは数個のジョブだけです。しかし、重要なカーネルに触れた場合は、100 以上のジョブが並列で起動することになります。

全体として、vLLM の CI スイートは 37 のテストグループと 266 のジョブから構成され、異なるカーネルやスペキュレティブ・ディコーディング（speculative decoding）、LoRA など主要なコンポーネントと機能すべてを網羅しています。各グループに含まれるジョブ数は数個から数十個まで様々で、多くのテストでは複数のコンポーネントが同時に検証されます。以下はその一部です：

imagevLLM の CI テストグループとジョブの例

テスト環境の一貫性を担保する

テストが意味を持つのは、毎回同じ条件で実行される場合に限られます。 障害となるのは主に 2 つの「ドリフト（ズレ）」です。一つは CI ランナー間で環境が異なること、もう一つは時間が経つにつれて依存関係が変わってしまうことです。前者は共有コンテナイメージで、後者は固定された依存関係グラフによって解決します。

どのマシンでも同じコンテナイメージを使用。 266 のジョブが数十種類のマシンに分散して実行される中で、不安定で信頼性の低い結果を招く最速の方法は、各ジョブが独自に微妙に異なる環境を設定させてしまうことです。これを防ぐため、vLLM では主要なジョブのほとんどが共通のコンテナイメージ内で実行されます。このイメージは各ランの実行開始時に一度だけビルドされ、すべての場所で再利用されます。

imagevLLM の CI およびリリースに共通するコンテナのビルドステージ

Dockerfile は多段階で構築されます。各ステージは下位のステージをベースに、必要な要素を追加していく形になっています。

具体的には、ベースステージで CUDA ツールチェーンを用意し、ビルドステージでその上にホイール（wheel）をコンパイルします。そしてランタイムステージで、これらのホイールと実行時の依存関係をインストールして完了です。

そこからビルドは分岐します。一方のイメージにはサービングのエントリーポイントを追加してリリース用とし、別のイメージにはテスト依存関係を追加して CI ジョブが引き出す用にします。この共通の祖先を持つことで、テスト環境と本番環境を常に近い状態に保つことができます。

同じイメージを利用するジョブでは、B200 上のカーネルテストと L4 上のエントリーポイントテストが、全く同じコンテナイメージをバイト単位で引き出しながら、異なるハードウェア上で実行されます。一度ビルドして共有することで、大きな変動要因を排除できます。つまり、各ジョブごとの設定のズレに起因する失敗は大幅に減ります。

毎回同じバージョン。依存関係は時間とともに変化します——これは私たちが痛い目を見て学んだ教訓です。

バージョンが固定されていない依存関係があると、失敗の原因を追跡するのが非常に難しくなります。あるテストが月曜日は成功しても、水曜日にはクラッシュすることがあります。その間のコード変更を一つずつ確認しますが、どれも関連していそうには見えません。数時間後になってようやく気づくのです。「あ、FlashInfer が水曜日に新しいバージョンをリリースして、ビルドが静かにそれを取り込んでいたんだ」と。FlashInfer だけが問題だったわけではありません。nixl や transformers、そしてその転送依存関係も同様に私たちを苦しめました。それぞれの無通告のアップグレードは CI を壊す新たな機会となり、原因は依存関係の層の奥深くに埋もれてしまうのです。

そこで vLLM の CI は依存関係を固定します。トップレベルの依存関係すべてを pip-compile に通してロックファイルを生成し、転送依存関係を含むすべてのパッケージのバージョンを固定しています。

image 上位依存関係をすべて固定した完全なパッケージグラフ

ロックファイルは定期的に更新され、その都度 CI システム全体を再実行しています。このように依存関係のバージョンを完全に固定して以来、依存関係に起因する不具合が頻発するという頭痛の種は解消されました。

多様なハードウェアと複数プロバイダによる CI 計算リソースのスケーリング

各ジョブは Buildkite のランナーキューに送信されます。Buildkite は特定のハードウェア構成を持つマシン群からなるプールです。例えば、gpu_1 キューは L4 GPU を搭載した個別の VM で支えられており、b200 キューは B200 GPU を内蔵した Kubernetes クラスターによって運用されています。ランナーが利用可能になると、キュー内の次のジョブを引き受けて実行し、その結果を Buildkite に報告します。

執筆時点での vLLM の CI システムでは、58 種類のランナーキューが存在し、多様なアクセラレータに対応しています。これらのハードウェアは複数のパートナー組織から提供されています。

image アクセラレータベンダーとハードウェア種別ごとの vLLM CI ランナーキュー

計算リソースへの支出には限度があります。仮に予算が許すとしても、これほど多様なマシンを自社で管理するのは非常に困難な作業です。このように多様性に富んだ CI カバレッジを実現できているのは、多くの素晴らしいパートナーからの寛大な支援と協力のおかげです。

しかし、統合には大きな課題があります。パートナーごとに要件は異なります。すべてにアクセス権限を任せるケースもあれば、自社のハードウェアを管理したいという要望を持つところもあります。また、セキュリティの制約が非常に厳しい環境もあるのです。

では、これら多様な環境を一つの CI パイプラインにどう組み込むのでしょうか？

ここで活躍するのがBuildkite agentです。このエージェントはプロバイダーの環境内で動作し、HTTPS を介して Buildkite へアウトバウンド接続を行います。これにより、Buildkite からエージェントへの接続要求が必要なくなるため、プロバイダー側ではインバウンドポートの開放や VPN の設定、ネットワークへのアクセス権限付与といった手間が不要になります。

エージェントがジョブを受け付けると、指定されたコマンドを実行し、ログをストリーミングで返送した上で最終的な終了ステータスを報告します。永続型（persistent）のエージェントは待機状態に戻り次のジョブを待ちますが、一時的（ephemeral）なエージェントはジョブ完了後に即座に終了します。

このエージェントの運用方法には複数の選択肢があり、プロバイダーは自社の環境に合わせて最適な方式を選んでいます。

最もシンプルな形態はスタンドアロンのマシンです。8 基の A100 を搭載したサーバーや Arm サーバーがこれに該当します。プロバイダー側でエージェントをインストールし、ランナーキューを指定するだけで、このループが継続して実行されます。

imageスタンドアロンの Buildkite エージェントがランナーキューをポーリングし、結果を報告する様子

Kubernetes クラスター内のマシンでは、同じモデルが Buildkite Agent Stack for Kubernetes を通じて機能します。コントローラーは一致するジョブごとに 1 つの Pod を持つ Kubernetes Job を作成し、そこでテストを実行して結果を報告します。私たちは常にこの方法を推奨しています。なぜなら非常にスケーラブルだからです。すべてのノードに Buildkite エージェントをインストールする必要はなく、クラスターに追加するだけで済みます。

imageBuildkite Agent Stack for Kubernetes が CI ジョブごとに 1 つの Pod を作成する様子

どちらの方法でも、導入は私たちが行う側で簡単です。キューを作成しトークンを提供すれば、プロバイダー側がエージェントを起動します。マシンへのアクセス権限は不要です。これこそが、vLLM が所有できる以上のハードウェア、つまり年間数百万ドル相当の寄付されたファームウェア上でテストを行える理由なのです。

ハードウェアの有効活用は容易ではない

需要が高く計算リソースには明確な限界があるため、無駄をなくす必要があります。

大規模 GPU を MIG スライスで分割する

imageH200 GPU 8 枚を分割し、56 のマルチインスタンス GPU（MIG）スライスを作成

CI ジョブの多くは小規模なモデルで実行されるため、GPU 1 台全体を使う必要はありません。NVIDIA の MIG 機能を使えば、1 枚の GPU を複数の独立したスライスに分割できます。例えば H200 は 7 つの 18GB パーティションに分けられるため、同時に 7 つのジョブを 1 台で処理可能です。計算してみると、大規模な GPU を分割して使う方が、同様の負荷をこなすために小規模な GPU を個別に借りるよりもはるかにコストが安いことがわかりました。

ゼロから自動スケール：マシン 1 台あたり 1 ジョブ

時間課金のマシンを利用する場合、稼働させておくだけで無駄遣いになります。そのため各キューは自律的にスケールします。ジョブが待機していればマシンの数を増やし、実行すべきものがなくなればゼロまで減らします。各マシンは 1 つのジョブを引き受け、コンテナ内で実行して終了後にシャットダウンします。この仕組みにはもう一つのメリットがあります。すべてのジョブが新鮮なマシンで実行されるため、過去の処理名残りがテスト結果に影響を与えることがないのです。

再利用可能なものは再構築しない

CI において最も時間がかかり、反復的でコストの高い作業は以下の通りです：

• CI パイプライン全体で使用される標準 Docker イメージのビルド
• CUDA カーネルのコンパイル
• すべての依存関係のインストール
• Hugging Face からのモデル重みデータのダウンロード

そのため私たちは以下を避けるように努めています：

• Docker レイヤー：レジストリのキャッシュを活用し、再構築せずにキャッシュされたレイヤーを再利用します。これには依存関係も含まれます。

• ビルダー用 AMI のウォームキャッシュ：ビルダーマシンに最新のレイヤーを事前に読み込んでおくための AMI を、毎晩ビルドするジョブを用意しています。これにより、ビルダーマシンは本番環境に近い状態から起動できます。

• コンパイラーキャッシュ：sccache を活用し、コンパイルされた C++/CUDA の出力結果を S3 バケットにキャッシュして再利用します。すべてのビルダーマシンはこのバケットから読み込み可能ですが、メインブランチ用のビルダーマシンのみが書き込み権限を持ちます。

• モデル重み：テスト対象のモデルは非常に巨大なため、各クラスターごとに一度だけ共有ストレージへダウンロードし、ジョブ側からはその場所から読み込むようにしています。毎回ギガバイト単位のデータをプルする必要はありません。

CI の健全性を可視化する

1 日に数百回の CI ランが実行され、それぞれが異なるハードウェア上で数百のジョブを走らせています。そのため、システム自体が健全に動作しているかどうかを確認する必要があります。

キューに数時間分の待ち時間が溜まっていたり、テストが 20 回に 1 回の割合で不安定になったり、先月よりジョブの実行時間が 10 分遅延したりする事態が発生しても、それを追跡するのは容易ではありません。

私たちは PyTorch チーム（PyTorch の素晴らしい友人たち）が構築した「PyTorch CI HUD」(hud.pytorch.org) に着想を得て、独自のダッシュボード ci.vllm.ai を作成しました。

15 分ごとに Buildkite パイプラインのデータが Databricks と ClickHouse に取り込まれます。

利用可能なすべてのデータとダッシュボードへの完全な制御権を持つことで、観測スタックを構築する際に非常に高い柔軟性が得られます。これにより、以下のような典型的な質問に迅速かつ容易に回答できるようになりました：

CI の健全性シグナル

01 of 04

メインブランチは現在健全か？

ダッシュボードが示すもの

過去 3 日間、答えは「いいえ」でした。なぜジョブの実行に 10 時間もかかったのでしょうか？

これらは、私たちのダッシュボードが果たせる役割の一部に過ぎません。現代のコーディングエージェントのおかげで、深いフロントエンドの専門知識がなくても、こうしたツールを誰でも使いこなせるようになりました。

失敗の検出と対応の自動化

ダッシュボードは問題を可視化してくれます。次のステップは、検知から診断までの時間を短縮することです。もちろん、そのためには強力な AI エージェントを活用する必要があります。

毎晩、CI アナライザーボットがテストスイート全体を実行し、前日の結果と比較します。新たに失敗した箇所があれば、エラーログを読み込んで失敗の種類を分類し、直近のコミット履歴を追跡して原因となる変更を見つけ出します。そして、修正済みの自動リバージョン PR を作成して Slack に報告し、メンテナーがレビューとマージを行えるようにします。

このボットは、1 日あたり平均 1.5 件の自動リバージョン PR を生成しています。失敗の種類と原因となったコミットを正しく特定できる確率は約 70% です。つまり、オンコール担当者が対応を開始する際、真っ白な状態からではなく、すでに正しい診断結果に基づいて作業を始められるのです。

このボットは、問題発生時の迅速な検出に不可欠な存在となっています。また、コミュニティ全体で問題が発生したその場で修正に取り組む取り組みとも相まって、vLLM の品質を支えています。特に、Red Hat のオンコールローテーションに参加してくださる皆様に感謝いたします！

imageCI アナライザー・ボットが回帰を検知し、リバージョンを提案している様子

グリーンチェックでは見えないもの

これらすべてを組み合わせることで、PR に対する「グリーンチェック（合格）」を信頼できるようになります。広範な単体テストのカバレッジ、多様なアクセラレータでの実行、一貫した環境、そして綿密なモニタリングです。CI をパスすれば、マージに伴うリスクは大幅に低減できると確信できます。

しかし、CI だけでは全体像は見えません。すべてのテストを通過しても、モデルの処理速度が低下したり、出力結果が誤ったりする可能性があります。CI の高速化とコスト削減のため、私たちは多くの E2E テストを省略しがちです。それ以上に重要なのは、vLLM ユーザーが日常直面する状況を十分にシミュレートできていない点です。次の層は、まさにその課題を解決するために存在します。

レイヤー 2：パフォーマンスベンチマークと精度評価

5 月に v0.20.0 をリリースした直後、わずか数日で緊急パッチである v0.20.1 と v0.20.2 を公開せざるを得ない事態になりました。2 つの重大な問題がすり抜けていたのです。1 つは Blackwell アーキテクチャ上で gpt-oss が複数 GPU にまたがる（テンソル並列度が 1 より大きい）場合に動作しなくなったというもので、もう 1 つは GB200 上での DeepSeek V4 のスループットが急激に低下したというものです。

当時、私たちはベンチマークパイプラインを持っていませんでした。つまり、リリース前にこれらのモデルがそのハードウェア上で正しく動作し、高速で実行されることを確認する E2E テストが何一つ走っていなかったのです。そのため、両方の問題が CI を潜り抜け、ユーザーに届いてしまいました。

パフォーマンスの低下は、サーバーが起動しリクエストも成功する限り、すぐにクラッシュすることはありません。ユーザーが体感するのは、1 秒あたりに生成されるトークン数の減少や、最初のトークンを待つ時間の延長です。同様に、精度の低下も目立たないものです。モデルは有効な回答を返しますが、その内容は誤っています。

私たちは、パフォーマンスベンチマークと精度チェックを両方実施してモデルをエンドツーエンドで検証することの重要性に気づきました。そこで、この検証層を構築するために多くの時間を費やしました。

現在、このシステムはリリースプロセスにおいて重要な指標を提供しており、すでにいくつかの重大な回帰問題を検出しています。v0.20.0 のリリース前に発生していた問題も、今回構築したシステムであれば確実に捕捉できたはずです。

毎夜実行するモデルとアクセラレーターの組み合わせテスト

私たちは、https://github.com/vllm-project/perf-eval でパイプラインを維持しています。各設定ファイルは、vLLM サーバーの起動方法や引数、提供するモデル、使用するアクセラレータ、実行するタスクなど、ワークロードの詳細を記述します。

各ワークロードでは、通常以下の 3 つのタスクが実行されます：

• パフォーマンスベンチマーク — vllm-bench を使用して、最初のトークンまでの時間（TTFT）や出力トークンあたりの時間（TPOT）、その他多くの指標を測定します。
• 数学的推論モデルの精度評価 — lm-eval を用いて、GSM8K、GPQA、AIME などのベンチマークでモデルの精度を検証します。
• 関数呼び出しの精度検証 — Berkeley Function-Calling Leaderboard（BFCL）を通じて確認します。

image 毎夜、vLLM ではワークロードの性能評価に加え、精度や関数呼び出しのテストを自動実行しています。

毎晩、そしてリリース候補版が出るたびに、DeepSeek V4 Pro/Flash、gpt-oss、Kimi K2.5、MiniMax M2.5 と M3、Qwen3.5、GLM 5.1、Gemma 4、Nemotron 3 Super など主要モデルを対象に、H200、B200、MI300X、MI355X の各ハードウェア上でフルスイートの実行を行います。現在では合計 17 種類のモデルとハードウェアの組み合わせ（レシピ）があり、さらに増えつつあります。今後は GB200/GB300 や PD 非同期化（disaggregation）への対応も追加予定で、対象モデルも拡大していく方針です。

常に高速なのか？

各実行が完了すると、結果はデータベースに格納されます。以前ご紹介した CI ダッシュボードにも、この性能データが表示されています。

毎晩の測定値をグラフ化し、経時的なパフォーマンスの低下（リグレッション）を容易に検出できるようにしています。

例えば、Performance dashboard の画面は以下の通りです：

image H200 上での gpt-oss 120B の性能履歴

*テンソル並列度を 8 に設定し、同時実行数ごとに分割した gpt-oss 120B の性能履歴*

Compare view を使えば、2 つの vLLM イメージを直接比較できます。例えば、リリース候補版と直前のリリース版を並べて検証するといった使い方が可能です。

imageパフォーマンスダッシュボードで 2 つの vLLM イメージを比較

常に正しいのか？

vLLM インスタンスが驚異的な速度を発揮していても、出力内容がゴミであればその速さは無意味です。パフォーマンスだけでなく、モデルからの回答が信頼できるかどうかも厳しくチェックしています。

Evaluation ダッシュボード には集計スコアと誤差範囲が表示され、そこから特定のランを実行して詳細を確認できます。ここでは、質問文、正解となる参照回答、生のモデル応答、抽出された回答、そして正誤判定結果を一つずつ inspect 可能です。単なる集計値からデバッグするよりも、こうしたサンプルレベルのエビデンスの方がはるかに有用です。

image誤った評価サンプルの調査

*GSM8K の不正解サンプルでは、正確な質問文、期待される回答、モデルの応答、そして抽出結果が明確に示されます。

レイヤー 3：リリースプロセス

高速なペースでの提供

2025 年 11 月以降、vLLM のリリースは 2 週間ごとのサイクルを維持しています。同規模のプロジェクトでは通常、これよりも遥かに長い期間をかけてリリースを行うのが一般的です。なぜ私たちはこのペースを堅持しているのか。

• ユーザーへの変更が迅速に届きます。新しいリリースは常にメインブランチからすぐ後に公開されます。
• 予測可能性が高いです。ユーザーや下流のプロジェクトは、次のリリース時期を推測するのではなく、安定したスケジュールに基づいて計画を立てられます。
• 機能管理と回帰バグの特定が容易になります。500 コミット程度であればバイセクション（二分探索）による調査も可能ですが、数千コミットに及ぶ場合はその負担が大きくなります。

デッドラインのプレッシャーも軽減されます。コントリビューターは、列車（リリース）が出発する前に慌てて変更を提出する必要がなくなり、次回の 2 週間後の列車に乗せるだけで済みます。

チェリーピックもクリーンに保たれます。数日前の修正であれば、通常は単純なピックアップで済み、マージ競合による混乱にはなりません。

隔週の月曜日にリリース週が始まります。その様子を見てみましょう。

image vLLM のリリース候補のテストと公開ループ

最も安全なコミットから始める

月曜日、リリースマネージャーはメインブランチにおける最新の完全 CI 実行結果を確認し、最も健全な状態にあるコミットを選択します。これにより、リリース固有の変更を加える前に、リリースブランチに利用可能な中で最も健康な出発点を与えます。

その特定のコミットで releases/vX.Y.Z ブランチを切り出し、ブランチ名とリリース期間を発表します。

リリース候補ごとの厳重なテスト

ブランチ作成から水曜日にかけて、チェリーピックの依頼を確認し、それらをバッチ処理でリリースブランチに取り込み、結果を次のリリース候補としてタグ付けします。

すべての候補は、以下の 3 つのゲートを通過する必要があります。

• 完全 CI スイート
• パフォーマンスベンチマークスイート
• モデル精度評価スイート

各結果は特定のリリース候補に紐付きます。後続の候補で CI の健全性やパフォーマンス、評価品質に変化が生じた場合、どの候補がその違いをもたらしたのかを特定できます。対象となる候補は、わずか数十コミット先のものです。

水曜日に cherry-pick の期間を閉じます。その後、リリース候補版に対しては既存の課題に対する修正のみが cherry-pick 対象となり、新しい候補版タグが付与され、3 つのゲートを通るまで再テストされます。最終的に基準を満たす候補版が出るまでこのプロセスを繰り返します。

バージョン品質への妥協はない

候補版が合格するのは、3 つのゲートをすべて通過した場合のみです。

週末になっても合格する候補版が出ない場合もありますが、それは問題ありません。私たちは期限通りにリリースできるよう最善を尽くしますが、そのために基準を下げることは決してありません。新しいバージョンについては、Rockstar が GTA 6 を扱う姿勢と同じように、「完成した時が完成」と考えます。ただし、10 年かかるわけではありませんが…

すべてのプラットフォームに対応してリリース

候補版が合格すると、そのコミットを基にさまざまなハードウェアプラットフォームや CUDA バージョン向けのビルド成果物を作成し始めます。これにより、誰もが vLLM をネイティブで利用できるようになります。そして、何よりも先に、ビルドされた成果物自体に対して smoke test（簡易動作確認）を実施します。

執筆時点では、すべてのリリースで以下の成果物を提供しています：

• Python wheel 7 種類:
• CUDA 12.9 (x86_64/arm64)
• CUDA 13.0 (x86_64/arm64)
• CPU (x86_64/arm64)
• ROCm
• Docker イメージ 11 種類:
• CUDA 12.9, x86_64/arm64, Ubuntu 22.04/24.04
• CUDA 13.0, x86_64/arm64, Ubuntu 22.04/24.04
• ROCm
• CPU (x86_64/arm64)

次のステップ

これまでの取り組みについて自慢話が多くなりましたが、正直に言えば、ロードマップ上にはまだ多くの課題が残っています。主なものは以下の通りです：

• テストの自動選定。現在は各 PR でどのテストを実行するかを手動で管理したマッピングに基づいて選択していますが、この情報はすぐに陳腐化してしまいます。これを自動化したいと考えており、LLM を活用した選定、静的解析、動的解析、ソースパスにラベルを付けて対応するテストと紐付ける手法など、いくつかのアプローチを試しています。

• 結果までの時間短縮。現在の CI は平均して 1〜2 時間かかりますが、これを 30 分以内に抑えたいと考えています。

• ユニットテストの効率化。多くの「ユニットテスト」は実際には vLLM サーバーを起動し、実際のリクエストを送信しているため、CI の速度が大きく低下しています。

• 終了コードの扱い改善。一部のジョブでは失敗時に誤った終了コードを返すケースがあり、例えばインフラの問題をテスト失敗として報告してしまい、障害の切り分けやアラート・再試行処理が困難になっています。

• フラキー（不安定）なテストの検出と隔離の高速化。インフラや上位パッケージに起因するもの、あるいは安全に記述されていないテストなど、多くのフラキーテストが存在します。これらを自動的に検出して隔離できるようにしたいと考えています。

• インフラ問題の自動検出。不良マシンの兆候を早期に察知し、多数のジョブが失敗する前に CI フリートから自動的に除外できるようにしたいです。

• アラート機能の強化。ランナーキューの混雑や回帰現象に対する基本的なアラートはありますが、さらに充実させたいと考えています。具体的には、CI ランナーでのディスク使用圧力の検知、通常より急激にジョブが失敗する状況の検出、依存パッケージのインストール失敗などが挙げられます。

• コードカバレッジレポートの改善。カバレッジ範囲は広くなっていますが、コードベースの隅々まで実際にテストされていることを確信できる状態にはまだ至っていません。

CI の開発は、多くの人が思っている以上に面白いものです。この記事では vLLM のリリースを安定させるための高レベルなプロセスについてのみ取り上げましたが、もっと楽しい技術的な詳細もたくさんあります。これらは別の投稿で扱えるかもしれません。

これらの問題があなたの興味に合致している場合や、私たちが何か間違っていると感じる場合は、vLLM の Slack で #sig-ci チャンネルまでお気軽にご連絡ください。また、この分野を専門としてフルタイムで働きたいとお考えの方は、Inferact 社で採用を行っていますので、ぜひご応募ください。

謝辞

これらは決して一人の努力ではありません。vLLM の CI はコミュニティ全体によって構築され、維持されています。

CI の開発に貢献してくださったすべての皆様に心から感謝いたします（アルファベット順）：

• Amazon: Junpu Fan, Liangfu Chen, Omri Shiv,
• AMD: Alexei Ivanov, Andreas Karatzas, Kenny Roche, Micah Williamson
• Arm: Fadi Arafeh, Ioana Ghiban
• EmbeddedLLM: Tun Jian Tan
• Google: Brittany Rockwell, Jincheng Chen, Ming Huang, Qiliang Cui, Yarong Mu, Yiwei Wang
• HuggingFace: Harry Mellor
• Inferact: Harry Chen, Jiangyun Zhu, Kaichao You, Nick Hill, Roger Wang, Simon Mo, Zhewen Li
• Intel: Chendi Xue, Jiang Li, Kunshang Ji, Wenjun Liu
• Meta: Andrey Talman, Charlotte Qi, Eli Uriegas, Huamin Li, Huy Do, Orion Reblitz-Richardson, Reza Barazesh
• NVIDIA: Alec Flowers, Benjamin Chislett, Mathew Wicks, Pen Chung Li, Stefano Castagnetta, Vadim Gimpelson, Xin Li

• Red Hat: アンディ・リンフート、アビナシュ・シン、ドグ・スミス、エドワード・クワーム、フローラ・フォン、ルーカス・ウィルキンソン、ルカ・ゴベディッチ、マイケル・ゴイン、ニコロ・ルッチェージ、ロバート・ショー、ラッセル・ブライアント、タルン・クマール、タイラー・マイケル・スミス、ウェントァオ・イェ

• Reflection AI: アムル・マフディ（メタ在籍時の貢献）

• 個人貢献者：サイラス・レオン（DarkLight1337）、ユーチー・ワン（noooop）、haosdent、モハメド・アンガード

素晴らしいパートナーの方々:

• AWS、Crusoe、LambdaLabs、Nebius、NVIDIA、Roblox、RunPod：計算リソースのクレジットを提供してくださりありがとうございます。

• Buildkite：プラットフォーム上で CI を無償で実行できる環境を提供してくださり、本当に感謝しています <3

そして最後に、Anyscale（Ray）在籍中に CI について多くのことを教えてくれた二人のメンター：Lonnie Liu（現 OpenAI）、Cuong Nguyen（現 NVIDIA）。