Baseten VibeQwenベンチマーク、vLLMを最大90%上回る。ただし条件付き
Basetenは、Claude Codeが厳密に定義された1つのデプロイメントを1週間かけて最適化した結果、VibeQwenエンジンがvLLMを最大90%上回ったと述べている。Baseten VibeQwenベンチマークでは、Qwen-3.6-35B-A3BとNVFP4の重み、NVIDIA B200 GPU 1基を組み合わせた。
この結果は、最も定着したオープンな推論エンジンを直接打ち破ったようにも聞こえる。しかし実際には、それらの設計上の優先順位に対する挑戦として捉えるほうが適切だ。VibeQwenは1つのモデル、アクセラレータ、精度形式、ワークロードに特化している一方、vLLMは幅広く変化し続けるデプロイメント環境をサポートしている。
この実験は、コーディングエージェントの役割も変える。Claude Codeは単発のCUDAカーネルを提案しただけではない。Basetenによれば、動作する推論エンジンを組み立て、候補をデプロイし、本番エンドポイントを計測し、精度を確認しながら、およそ1週間にわたり反復を続けた。
見出しの数値は依然としてBaseten自身のベンチマーク結果である。VibeQwenは広範な独立検証を受けておらず、報告された90%の優位性は、投機的デコードに有利な反復的かつ構造化されたテキストで示された。より重要な問いは、この特化型でエージェント主導のプロセスが、印象的な実験室の成果にとどまらず、再現可能なエンジニアリングになり得るかどうかだ。
Baseten VibeQwenベンチマークが実際に測定したもの
Basetenの最も強い結果は、汎用的なvLLMの代替ではなく、狭く明示的に最適化された構成から得られた。
Basetenのエンジニア、Shawn Rushefskyは2026年10月2日にこの実験を公開した。彼の推論ベンチマークでは、Qwen-3.6-35B-A3B向けに生成されたエンジンを、B200アクセラレータ1基上でNVFP4精度により使用したと説明している。
NVFP4は、対応するNVIDIAハードウェア上でメモリトラフィックを削減し、計算を高速化するよう設計された4ビット浮動小数点形式だ。この精度の選択は重要である。推論速度は、モデル、量子化形式、GPUアーキテクチャ、利用可能なカーネルに大きく左右されるためだ。
Basetenは、生成されたエンジンをVibeQwenと名付けた。同社はこれを、同一のB200 1基のハードウェアで動作する、調整済みのvLLM 0.25.1デプロイメントと比較した。
単一ストリームで、スペキュレーターに適したテキストを用いた場合、VibeQwenは毎秒1,792出力トークンを生成したと報告されている。同じ報告上のテスト条件では、vLLMデプロイメントは毎秒943トークンだった。
この差が、90%改善という見出しの数値につながった。「スペキュレーターに適している」とは、投機的デコーダが並列検証に向けて複数の可能性の高いトークンを提案できる、反復的または構造化された出力を指す。
最初のトークンが返るまでの時間、すなわちTTFTは、vLLMの28ミリ秒からVibeQwenでは12ミリ秒へ低下した。TTFTは、リクエスト送信から最初の生成トークンを受け取るまでの遅延を測定する。
Basetenはこの変化を2.33倍の改善と位置付けた。ユーザーは最初の間をすぐに意識するため、この低遅延は対話型アシスタント、コード補完、音声インターフェースで重要になる。
VibeQwenは、より高いトラフィック下でも優位だったと報告されている。並行実行数32では、1つのレプリカが毎秒10,307出力トークンを生成し、vLLMの6,030を上回った。
これは総出力スループットで71%高いことを意味する。この結果は、エンジンの優位性が単独ユーザーの孤立したテストに限られない可能性を示すが、対象となったのは報告された1つの並行実行レベルのみだ。
比較には、Basetenが実験開始時点で最新としたvLLM 0.25.1が使われた。プロジェクトのリリース履歴によると、このバージョンは2件の限定的なバグ修正を含むパッチリリースだった。
Basetenは、すべてのモデル、プロンプト分布、GPUで同じ差が出るとは主張していない。公開された結果は、この特定のモデル、ハードウェア、ワークロードの組み合わせに関するものだ。
この区別は、購入者が数値をどう解釈すべきかを左右する。選択されたテキストで90%先行したことは、最適化の余地を示す有意義な証拠だが、一般的なAIサービング全体で90%改善したことを意味するわけではない。
したがって、このベンチマークは競争上の問いを変える。チームは、安定した高ボリュームのワークロードにとって、幅広い互換性を持つランタイムが依然として最適な到達点なのかを問う必要がある。
コーディングエージェントがこれほど大きな余地を見つけられた理由
推論最適化は、速度、出力品質、ハードウェアの挙動をすべて測定可能なフィードバックによって検証できるため、コーディングエージェントに適している。
Basetenは、LLMを推論ソフトウェア向けコンパイラのように扱う実験的システム、MetaInferの考え方を取り入れた。あらゆる環境向けに1つのエンジンを維持する代わりに、このシステムは明示されたランタイム制約に合わせてコンパクトなソフトウェアを生成する。
MetaInferプロジェクトは、コーディングエージェントと契約型ナレッジベースを組み合わせている。このナレッジベースには、制約、テスト、機能したパターン、失敗した試みからの学びが記録される。
エージェントは実装を提案し、コンパイルし、正確性テストスイートを実行し、性能を測定して、コードを改訂できる。各ループは、多くの一般的なソフトウェアタスクよりも明確なシグナルを返す。
たとえばビジュアルデザインの刷新は、部分的に人間の判断へ依存する。一方、推論エンジンには、レイテンシー、スループット、GPU使用率、メモリ消費量、出力精度といった明確な測定値がある。
この明瞭さにより、長時間にわたる最適化が現実的になる。エージェントは、候補がより高速に感じられるとレビュー担当者を説得する必要はない。事前定義された正確性ゲートを満たしながら、数値的なベースラインを上回らなければならない。
Basetenは、Claude CodeにMetaInferの資料、モデルの重み、SSH経由のB200ワークステーションへのアクセスを与えた。また、出力品質を確認するための信頼できる参照、すなわち精度オラクルとしてフル精度モデルも提供した。
初期目標は厳しいものだった。Basetenは、NVFP4ベースラインに対する精度を損なうことなく、性能指標全体でvLLMを20%上回るようエージェントに求めた。
Claude CodeはBaseten上に候補をデプロイし、各エンドポイントに対してAIPerfを実行できた。AIPerfは、孤立したカーネルのタイミングだけでなく、デプロイ済みのモデルサービングの挙動を測定するワークロードジェネレーターだ。
Rushefskyによれば、このプロセスは約1週間続いた。消費したトークンは約17億で、その大半はキャッシュ済み入力であり、B200の使用時間は約200時間だった。
エンジンは最初の数日でvLLMと同等に達したと報告されている。Basetenはシステムに探索の継続を許可し、それが最終的により大きな差につながった。
人間の監督がなくなったわけではない。Rushefskyは、システムが特定のトラフィック形状に過度に集中した際、時折その方向を修正した。
Claude Codeは、提案された変更が数値出力を変化させた場合にも停止した。Basetenは最終的に、BF16モデルに対する総合精度が少なくとも同等に強い場合、NVFP4参照との微妙な差異を受け入れた。
BF16、すなわちbfloat16は、4ビット形式よりも広い数値範囲と高い精度を保持する。BF16実装との比較は、量子化やカーネルの変更がモデル品質を損なっていないかを明らかにできる。
こうした制御が、この取り組みが単なる長時間のコード生成プロンプト以上であった理由を説明する。Basetenは、エージェントが行動し、結果を観察し、有用な知識を保持し、リスクのある変更を受け入れる前にゲートに遭遇できる環境を構築した。
この実験はオープン実装からも借用している。Basetenは、適切な場合には事前最適化済みカーネルを含め、エージェントがvLLMとTensorRT-LLMを調査することを許可した。
この選択により、プロジェクトは本番エンジニアリングとの関連性を増す一方、支援なしのアルゴリズム発明の証拠としては有用性が下がる。VibeQwenは、既存および新規作成されたコンポーネントをまたぐ、エージェント主導の統合と特化を表している。
それでも、この結果は注目に値する。エンジニアは長年、プロファイラー、ベンチマーク、自動チューニングシステムを使ってきた。ここでは、LLMがカーネル、エンジンロジック、サービングの挙動、デプロイメント、検証にまたがる判断を調整したと報告されている。
特化型エンジンが汎用ランタイムにかける圧力
主要な対決は、製品としてのVibeQwen対vLLMではない。エンジニアリング戦略としての特化対汎用性である。
vLLM、SGLang、TensorRT-LLMは、広範な互換性という問題を解決する。多くのアーキテクチャ、量子化形式、アクセラレータ、バッチ処理パターン、API、運用要件をサポートしなければならない。
この広さは、非常に大きな実用価値を生む。チームは、個々の特殊なレイヤー、カーネル、サービングパターンごとにランタイムを構築せずに、新しいモデルをデプロイできる。
一方で、それは抽象化も生む。スケジューラー、モデルランナー、互換性レイヤー、フォールバックパス、構成可能なカーネルは、単目的エンジンなら取り除ける分岐を追加する。
MetaInferの主張は、こうした抽象化が性能を取りこぼすというものだ。デプロイメントが安定すると、エージェントはその正確な制約に合わせてエンジンを特化できる。
VibeQwenは、B200上のNVFP4によるQwen-3.6-35B-A3Bを対象とした。無関係なモデルや旧世代のアクセラレータに向けた洗練された経路を維持する必要はなかった。
特化型エンジンは、常に連続して発生する処理を融合できる。選択されたワークロードに寄与しない変換、メモリ転送、実行時チェック、汎用インターフェースを除去できる。
Basetenの以前のカーネル最適化に関する取り組みは、利用可能な探索空間を示している。同社のエージェントは、拡散モデルと言語モデルをまたいで、モデルレベルのプロファイリングとカーネル単位の実験を組み合わせたと報告されている。
これらのプロジェクトでは、定数スケールの事前パッキング、正規化と量子化の融合、中間メモリ操作の削除などが有用な変更に含まれた。こうした手法は、モデルが意図する計算を変えることなく作業量を削減する。
VibeQwenの実験は、この考え方をサービングスタック全体へ拡張した。本番エンドポイントには、高速な行列乗算以上の要素が関わる。
リクエストはAPIから入り、スケジューリングとバッチ処理を通過し、モデルカーネルを実行し、トークンをストリーミングし、限られたGPUメモリを共有する。1つのカーネルだけを最適化しても、支配的なボトルネックが残る可能性がある。
コーディングエージェントは、これらのレイヤー間の相互作用を調査できる。また、疲れたり、手作業で設計した1つの実装に執着したりすることなく、複数の実験を実行できる。
この圧力が、汎用エンジンを時代遅れにするわけではない。むしろ、デプロイメントのライフサイクルにおける位置付けを変える可能性がある。
チームは、互換性、活発なメンテナンス、慣れ親しんだサービングインターフェースを提供するvLLMから始めるかもしれない。トラフィックが予測可能になれば、エージェントはその本番プロファイル向けの特化ブランチを生成できる。
汎用エンジンは参照実装とフォールバックとして残る。カスタムエンジンは、削減されるレイテンシーや増加するスループットが保守負担を正当化するワークロードを処理する。
これはプロファイルガイド最適化コンパイルに似ているが、最適化対象にはアプリケーションの挙動とサービングインフラも含まれる。エージェントは、ソースコード、カーネル、ランタイム構成、デプロイメント判断をまたいで探索している。
このアプローチは、既存エンジンに対し、より多くの特化用フックを公開する圧力も高め得る。モジュール型ランタイムなら、サービングシステム全体を置き換えずに、エージェントが選択した経路を最適化できる可能性がある。
vLLMも立ち止まってはいない。そのリリースでは、モデルランナー、投機的デコード、量子化サポート、ハードウェア経路が定期的に変更されている。
したがって、Baseten VibeQwenベンチマークは、動き続ける競争の一時点として読むべきだ。ベースラインは改善し得る一方、VibeQwenから得られた再利用可能な発見は、いずれより広範なランタイムに取り込まれる可能性がある。
持続的な変化は戦略的なものだ。汎用的な性能が、価値の高いワークロードにとって必ずしも最終的な最適化段階ではなくなっている。
90%という主張には重要な境界条件がある
このベンチマークは調査に値するだけの信頼性を備えているが、普遍的な性能結論を裏付けるには対象が狭く、自己申告に依存しすぎている。
最大の懸念はワークロードの選定だ。Basetenによれば、90%という結果は、同社のspeculatorに適した反復的かつ構造化されたテキストから得られたという。
Speculative decodingは、複数の将来トークンを提案し、それらをまとめて検証することで生成を高速化する。その有効性は、提案がターゲットモデルの生成内容とどれほど頻繁に一致するかに左右される。
構造化されたコード、テンプレート、反復的なデータでは、高い受理率が得られる可能性がある。一方、自由形式の文章、珍しい言語、創作文章、急速に変化するコンテキストでは、異なる挙動を示す可能性がある。
Basetenは、テストしたすべてのトラフィックパターンでVibeQwenが首位だったと報告している。ただし公開された要約には、各プロンプト分布や受理率を再現できるほど詳細なデータはない。
このベンチマークは、エンジンを開発・ホスティングする企業自身によるものでもある。独立した第三者は、同一のハードウェアとモデル重みでVibeQwenの結果を再現していない。
だからといって測定結果が無効になるわけではない。コード、テストフィクスチャ、または第三者の結果によって直接再現できるようになるまでは、主張を「Basetenによれば」に限定する必要がある。
精度の基準にも同様の慎重さが求められる。Basetenはまず、NVFP4の参照値と比べて精度低下を許容しない方針を掲げた。
最適化の過程では、BF16ベースラインに対する総合精度が少なくとも同等に保たれる場合、小さな数値差を許容した。これは妥当なエンジニアリング上の妥協だが、タスクレベルでの詳細な評価が必要になる。
平均スコアは、特定領域での性能低下を覆い隠し得る。企業には、自社のプロンプト、ツール呼び出し、構造化出力、安全性の挙動、長コンテキストのワークロードを網羅するテストが必要だ。
運用上の信頼性も未解決の問題だ。ベンチマークの実行では、数カ月にわたる本番アップグレード、不正なリクエスト、tokenizerの変更、ドライバー更新、まれなシーケンス長までは測定できない。
汎用エンジンは、広範な利用を通じても信頼を得る。より大きなコントリビューターおよび顧客基盤によって、エッジケースが発見・修正されるからだ。
カスタムエンジンでは、責任が集中する。オーバーヘッドを取り除く同じ専門化が、形状、バッチ、精度、ハードウェアの挙動に関する脆弱な前提を生む可能性もある。
開発コストも重要であり、公表価格を付けなくてもその点は変わらない。VibeQwenは、約200 B200時間と17億モデルトークンを消費したとされる。
これらの投入は、大規模かつ継続的なワークロードであれば正当化できるかもしれない。モデルが毎週変わる場合や、トラフィックがエンジニアリング投資を回収できないほど小さい場合には魅力が薄れる。
実験の反復予算も、直接比較を複雑にする。vLLMは、多数のユーザー、モデル、デバイスにまたがって開発作業を配分しなければならない。
Claude Codeは、1つのターゲットの最適化に1週間を費やした。したがってVibeQwenの優位性は、エージェントが書いたソフトウェアの優秀さだけでなく、集中的な努力の価値も示している。
Basetenの第2の実験は、再利用に関する有望だが不完全な証拠を示している。同社は、拡張したナレッジベースをSAM 3.1の画像セグメンテーションサーバーに適用した。
Sammieと呼ばれるこのシステムは、1基のH100で毎秒91枚の画像を処理したと報告されている。Basetenによれば、数日間と約2億トークンを費やした後、これはMetaの参照サーバーを50%上回ったという。
モデル、GPU、アーキテクチャ、ベースラインはいずれもVibeQwenとは異なっていた。Baseten自身も、対照実験が存在しないことを認めている。
したがってSammieは、蓄積された知識が役立ったことを示唆するものの、ナレッジベースの寄与を切り分けてはいない。より迅速な完成は、より簡単なワークロードや別の手続き上の違いによるものだった可能性もある。
最も安全な読み方は、否定でも称賛でもない。VibeQwenは、コーディングエージェントが深いシステム最適化を協調して進められるという本格的なシグナルを示している。
ただし、企業が信頼性の高いカスタムエンジンを必要に応じて生成し、モデル更新をまたいで維持し、専門家が保守するランタイムを一貫して上回れることまでは、まだ示していない。
1つのQwenデプロイメントを超えて、この結果が重要な理由
より大きな可能性は、モデル、ハードウェア、トラフィックパターンが判明した後に最適化を始めるデプロイメントプロセスにある。
従来の推論フレームワークは、各ユーザーの正確なワークロードをすべて把握する前に設計判断を下さなければならない。エージェントが構築するエンジンは、その順序を逆転させる。
まずデプロイメントの事実から始める。これには、選択したモデル、想定プロンプト長、出力分布、並行処理の目標、精度要件、アクセラレーターの種類などが含まれる。
企業向けコードアシスタントは有用な例だ。その出力には、構文、インデント、一般的なライブラリ呼び出し、繰り返し現れるプロジェクト慣行が含まれることが多い。
こうした規則性はspeculative decodingを支援できる。低いTTFTは、インラインコード補完の対話的な感覚も改善する。
音声システムの優先順位は異なる。最初のトークンが素早く到着し、自然な会話に十分な安定性で生成が続くなら、総スループットが低くても受け入れられる場合がある。
バッチ要約サービスは、代わりに総スループットを優先できる。何千もの文書で予測可能な入力・出力範囲が共有される場合、最初のトークンが遅くても許容されることがある。
汎用ランタイムは、この3つすべてに対応しなければならない。専用エンジンは、そのうち1つだけを最適化できる。
このアプローチは、モデル選択をより柔軟にする可能性がある。かつてレイテンシ目標を満たせなかったモデルでも、ワークロード固有の最適化後には実用的になるかもしれない。
この可能性は、インフラ購入者とアプリケーションチームに影響する。モデル品質の比較では、サービングソフトウェアが利用可能な性能の大半をすでに引き出していることが前提とされる場合が多い。
VibeQwenはその前提に異議を唱える。ランタイムの選択は、固定されたハードウェア上で、どのモデルが最高の品質、応答性、容量を提供するかを大きく変える可能性がある。
これは特にmixture-of-expertsモデルで重要だ。Qwen-3.6-35B-A3Bは各トークンで総パラメータの一部だけを活性化し、独特のルーティングとメモリ挙動を生み出す。
正確なexpertレイアウトと量子化方式を把握するランタイムは、こうしたパターンを狙い撃ちできる。汎用エンジンは、他のアーキテクチャ向けのパスも保持しなければならない。
Basetenはすでに、speculative decodingを通じた別の道を探っている。同社のDFlash implementationは、複数トークンを並列に予測することでQwen3-8Bの性能を改善したと報告されている。
この先行研究には、モデル固有のトレーニングと実装が必要だった。これに対しVibeQwenは、既存モデルと量子化済み重みを中心に最適化を調整するエージェントを強調している。
両アプローチは収束し得る。最適化エージェントは、ドラフトモデル、カーネル融合、キャッシュ、バッチ処理、メモリレイアウトの変更から選択できる。
この幅広い探索には価値がある。なぜなら、ボトルネックはワークロードによって変わるためだ。デコード速度を改善すると、スケジューラーのオーバーヘッド、ネットワークレイテンシ、前処理が次の制約として浮かび上がる可能性がある。
再利用可能なナレッジベースは、最も重要な資産になるかもしれない。成功したカーネルは重要だが、記録された失敗は、将来のエージェントが高価な実験を繰り返すことを防げる。
ハードウェア契約と検証ルールのライブラリが拡大すれば、新しいエンジンごとに必要な作業を減らせる可能性がある。BasetenのSammieテストは、その効果を観察する初期の試みだった。
再利用性が向上すれば、最適化はカスタムコンサルティングプロジェクトではなくなる。プロダクションAIサービス向けの自動化されたコンパイル工程に近づいていく。
その変革には、慎重な記録が必要だ。チームは、ベンチマーク入力、コンパイラのバージョン、ドライバー、カーネル、モデルハッシュ、精度スイート、デプロイメント構成を保存しなければならない。
そうしなければ、高速な結果は再現不能な成果物になる。エージェントはそのスコアに至った方法を把握していても、組織は安全に再現・監査できない。
ここで人間のエンジニアリングは依然として中心的な役割を担う。開発者は有用な目標を定義し、ベンチマークの不正最適化を防ぎ、検証データを選び、受け入れ可能な性能と品質のトレードオフを決める。
VibeQwenはその責任を取り除くものではない。エンジニアが境界を定義した後、コーディングエージェントがより広い実装空間を探索できるようにする。
エージェント構築エンジンが定着するかを決める3つのシグナル
次の試金石は、別の孤立した記録ではなく、ワークロード、ライフサイクルの変化、独立した環境をまたぐ再現性だ。
第1のシグナルは、再現可能なVibeQwenパッケージである。独立したチームが比較を再実行するには、十分なコード、構成、プロンプトデータ、評価ロジックが必要になる。
再現では、通常の文章、コード、構造化出力、複数言語、長いコンテキスト、異なる並行処理レベルを扱うべきだ。speculative acceptance rateも報告すべきである。
幅広い結果が得られれば、専門化によって持続的な余地を引き出したというBasetenの主張は強まる。優位性が大幅に縮小すれば、見出しの成果は有利なトラフィックに限定される。
第2のシグナルは、変化をまたいだ持続性だ。モデルプロバイダーは、重み、tokenizer、量子化レシピ、サービング要件を更新する。
NVIDIAも、コンパイラ、ドライバー、ライブラリ、GPU世代を更新する。有用なカスタムエンジンは、脆弱な再構築にさらに1週間を要することなく、こうした変化を吸収しなければならない。
エージェントがVibeQwenを別のQwenリリースや異なるアクセラレーターへどれほど迅速に移植できるかに注目したい。比較には、人間によるレビュー時間、計算予算、デプロイ後に発見された回帰も含めるべきだ。
高速かつ信頼性の高い移行は、ナレッジベースが複利的に価値を生むという考えを支える。繰り返し人手による救済が必要なら、カスタムエンジンが依然として高価な専門家向けプロジェクトであることを示唆する。
第3のシグナルは、汎用ランタイムからの反応だ。vLLM、SGLang、TensorRT-LLMは、新しいカーネル、専門化インターフェース、自動チューニング技術を導入できる。
メンテナーが関連するパスを理解すれば、VibeQwenの利得の一部は共有エンジンに取り込まれる可能性がある。それにより直接的なベンチマーク差は縮小するが、基礎となる最適化作業の価値は裏付けられる。
より深い反応としては、保守されたランタイム内で、ユーザーが専用の実行計画を生成できるようになることが考えられる。このハイブリッドモデルは、固定されたデプロイメントのオーバーヘッドを取り除きつつ、互換性を維持できる。
勝者は、完全に生成されたエンジンでも、完全に汎用的なエンジンでもないかもしれない。エージェントが制御する専門化の境界と堅牢なフォールバックパスを備えた汎用フレームワークになる可能性がある。
開発者にとって、目先の教訓は実践的だ。推論ソフトウェアを、モデル重みの交換可能なラッパーではなく、測定可能なコンポーネントとして扱うべきである。
最適化対象を選ぶ前に、プロンプトと出力の分布を記録する。本番に近いリクエストを使って、TTFT、出力トークンレイテンシ、スループット、メモリ、精度、テール挙動をテストする。
企業の購入担当者は、ベンダーに対し、ベンチマークで何を最適化し、何を除外したのかを尋ねるべきだ。単一のピークスループット値から分かるのは、対話的レイテンシ、品質、移植性、運用努力についてはほとんどない。
報告された利得が多様なデータでも維持されるかも尋ねるべきだ。Baseten VibeQwenベンチマークは、慎重な評価を終わらせるものではなく、始めるきっかけとなるときに最も有用である。
この実験は、自律的なシステムエンジニアリングの説得力ある一端を示している。同時に、エージェントには綿密に設計されたテストと、人間が定める制約が必要であることも示している。
今後1〜3カ月で、VibeQwenが再現可能で、移植可能で、保守可能なものになるかが明らかになるはずだ。あなたのデプロイメント計画を最も変える結果はどれだろうか――独立した再現、迅速なモデル移行、それともvLLM内での同様の専門化だろうか？
