NVIDIA GPUでGPT-OSS-120Bを毎秒500トークン以上で実行する方法

 (baseten.co)
7 ポイント 投稿者 GN⁺ 2025-08-12 | 2件のコメント | WhatsAppで共有
  • OpenAIのオープンソースLLMであるGPT-OSS-120Bを、NVIDIA GPU環境で毎秒500トークン以上の処理性能になるよう最適化した
  • TensorRT-LLM、vLLM、SGLangなど複数の推論フレームワークを並行してテストし、HopperとBlackwellアーキテクチャの両方をサポート
  • 互換性バグを修正し、Harmonyなどの新規レスポンス形式統合、KVキャッシュ認識ルーティング、Eagleベースの推測（Speculative）デコーディングなど最適化を適用
  • テンソル並列化とエキスパート並列化を比較した結果、低レイテンシを実現するためにテンソル並列化を採用し、BlackwellではTensorRT-LLM MoEバックエンドを使用
  • 今後の性能向上には、小型ドラフトモデルを用いる推測（Speculative）デコーディングを含む追加最適化を計画

概要

  • OpenAIの最新オープンソース大規模言語モデルであるGPT-OSS-120Bが公開されると同時に、Basetenは最高性能実装へ挑戦
    • BasetenはOpenAIの公式ローンチパートナー
  • OpenRouterで公開された実ユーザーデータを通じて、NVIDIA GPUベース環境で他社製品を上回る性能を実証
  • Flexible Inference Stackとモデルエンジニアリングチームの専門性により、時間単位で最適化パッチを迅速に適用
  • ブログ記事執筆のわずか数時間の間でも毎秒100トークンを追加改善し、100%の稼働率を維持

パフォーマンス最適化の取り組み

  • TensorRT-LLM、vLLM、SGLangなどの推論フレームワークでテストおよびベンチマークを実施
  • Hopper、Blackwell GPUアーキテクチャとの互換性確保を並行
  • BasetenのFlexible Inference StackやNVIDIA Dynamoなど主要コンポーネントを統合
  • KVキャッシュ認識ルーティングと**Speculative decoding（Eagleベース）**など、継続して実績のある性能最適化手法を適用

以下は、SOTA性能とフルコンテキストウィンドウサポートを同時に実現するための主要ステップ

Step 1: 初回推論の実行

  • どの方式であっても**初回推論（ベースライン推論）**を速やかに実行することが出発点
  • GPU環境を踏まえ、複数のエンジニアが同時にvLLM、SGLang、TensorRT-LLMの実験を並行して実施
  • 最も優れた性能を示したTensorRT-LLMをいち早く起動することに成功
  • Hopper（最も多くH100 GPUがある）とBlackwell（B200 GPUで速度が高い）両方でTensorRT-LLMのサポートを確保
  • Baseten Inference Runtimeの柔軟性により、新アーキテクチャモデルへの対応やスタック内ツールの迅速な置き換えが容易だった

Step 2: 互換性バグの修正

  • 新しいモデルアーキテクチャの登場には、フレームワーク統合時の頻繁なバグが付きもの
  • GPT OSSには、Harmonyのような新しいレスポンス形式が追加され、既存フレームワークとの統合時にバグが発生
  • 速度と精度を同時に確保するため反復的に修正・テストを実施し、有効な修正はオープンソースへ貢献
  • グローバルなオープンソースコミュニティの協業により、さまざまな最適化経路やバグ修正が迅速に行われている

Step 3: モデル構成の最適化

  • OpenAIはGPT OSS 120Bが単一H100でも動作することを明記しているが、実際には4〜8GPUの並列化が性能面で有利
  • Tensor Parallelismはレイテンシ（遅延）に、Expert Parallelismはシステムスループット（throughput）に強み
    • Basetenは低レイテンシ最適化を目的にTensor Parallelismを選択
  • BlackwellではTensorRT-LLM MoE Backendを適用し、以前のTritonバックエンドよりCUDAカーネル性能が向上
  • HopperおよびBlackwell環境それぞれに最適化された設定を公開し、Model APIではBlackwellベースの設定を採用

追加のパフォーマンス最適化

  • 第1次最適化のみでSOTAレベルのスループットとレイテンシを実現したが、改善の余地は十分ある
  • 次の主要アップデートはSpeculative Decodingの導入予定
    • この方式では、より高速な小型「ドラフト」モデルが予測トークンを生成し、本モデルが検証
    • BasetenはEagle 3を推奨するが、推論スタック内で10個以上のアルゴリズムを状況に応じて柔軟に運用
  • Speculative decodingは一度に複数トークンの推論を進め、効率的な速度向上を可能にする

関連記事

2件のコメント

 
jjw951215 2025-08-12

私も、かわいい小さなH100を1台でも誰かくれてくれたらいいのに…。
 
GN⁺ 2025-08-12
Hacker Newsのコメント

  • widely-available H100 GPUs

    そのコメントを見て、自宅の部品ボックスを漁ってみたんだけど、どうしても25,000ドルのH100 GPUがどこにも見当たらないのか不思議に思った。

    • NVIDIAの製品ページで、H100が実際にGPUとして分類されていることを直接確認した。今は『ゲーム用途が中心だがLLM推論もかなり限定的に可能なコンシューマー向けハードウェア』と『AI学習やLLM推論が主目的で、ビジネス向けのプロ仕様ハードウェア』を、もっとわかりやすく区別できる呼称が必要だと思う。
    • Ollamaで20Bモデルを、2015年製のTitanXカード8枚で回してみた。Ollamaが総15GBのVRAMを8枚のカードに均等に分散してくれ、トークン速度も読み取り速度より速かった。
    • こうしたGPUは、レンタルは本当に簡単だ。24/7でずっとGPUを回すつもりがないなら、買うよりホスティングを借りる方がはるかに経済的だ。個人用途で最新のデータセンター級カードを使う機会もまずないし、その場合はMac StudioやStrix Haloなどで十分だが速度はやや遅い。
    • このコメントのおかげで今日1日がとても楽しくなった。確かにデータセンター視点での話で、私の引き出しにある最速ハードウェアはたぶん古いiPhone 8だ。
    • 「自宅に25,000ドルのGPUがない」というのは、実際にそのようなものを買えるという意味ではない。つまり、在庫があり『手に入る』というだけで、そこまでお金があって買えるという意味ではないという点だ。

  • 大西洋横断便の中でMacBook Pro（M4、128GB RAM）を使ってGPT-OSS-120Bを試してみた。
    コンテキストウィンドウが小さく、全体のトークン数が少ないときだけ速い。1万トークンを超えるとほぼすべての処理が長くなり、キューに溜まってしまう。
    MCPs、Web検索、URLパッチなどは、すでにLLMの使用体験で非常に重要になっている。これらがないとLLMのユーティリティも大きく低下する。
    オフライン環境用に事前に設定していたCLI/TUIコーディングツール（opencodeなど）が、モデルと一緒では信頼性高く動作しなかった。
    OSSモデルの他の特徴も、前のコメントでよく言及されたもの以外にこれがある。

    • 以前のWikipediaもローカル保存して使えていたから、いずれ多くのデータをMCPで公開してAIが『Web検索』のようにローカルで検索するようになると考える。Web検索の99%は同じ100〜1000サイトでしか起きていない。要するに数GB保存すればカバーできるので、著作権問題が残る。
    • Ollama、LMStudio、llama.cppのどれを使うか気になる。ggerganovのツイート
    • iogpu.wired_limit_mbの設定をどうしたのか知りたい。デフォルトならRAMの約70%、つまり約90GB程度しかGPUコアが使えない。もっと活用するには設定を変更する必要がある。
    • M2 Maxプロセッサで実施した。短い会話では1秒あたり60トークン以上を見たが、長くなると30まで落ちた。この速度低下の原因が何か気になる。サーマルの問題ではなさそうだった。
    • コンピュートバウンドのプリフィル（CPUの帯域幅対演算比が高い場合）とデコードの差だと思う。1万コンテキストでも最初のトークンまでは0.5秒未満。

  • 複数のエンジニアがvLLM、SGLang、TensorRT-LLMを並行して試している。TensorRT-LLMが最速という声が多いが、通常もっとも設定が難しく、最新アーキテクチャの反映もよくできず、プロダクション環境と同じハードウェア・ドライバ・ライブラリスタックでモデルを直接コンパイルする必要があるため、本当に面倒だ。マルチモーダルはしばらくほぼ不可能なレベルで、代表的なLlamaマルチモーダルモデルでさえまともに動かなかった。価値があるかは疑問だが、例えばGPT-OSS-120BをH100でvLLMにかけると問題なく動作し、安定して130〜140t/sを出せる。タイトルだけ見ると1枚のGPUで500t/sが出るように見えるが、実際はテンソル並列の設定だ。gpt-oss向けにTRT-LLMを別パッケージ化したのも少しおかしい。TRT-LLM自体が少しややこしいツールだ。

    • TRT-LLMを触ると、DX観点で課題が多い。マルチモーダル時もなおvLLMを多用する。とはいえ、私たちのように大規模で低遅延のトラフィックでは、ベンチマークでTRT-LLMが常に優秀だったので、この分野のツール群にかなり投資してきた。

  • GPT-OSS 20Bはインストールが本当に簡単だった。Llamaのおかげで、私のMacで5分で動かすことができた。

    • CPUリソースが十分なら120Bも難なく動かせる。自宅でLLM CPU推論サーバにGGUFファイルをダウンロードし、git pullしてllama-serverだけを再ビルドすればそのままで動き、40t/sはそのままで、50t/sは少しだけチューニングすると得られた。残念ながら120Bより良いモデルがすでにたくさん出ているので、わざわざ回す必要はない。ggerganovとllama.cppチームが、個人のコンピューティング環境でもLLMを使えるように民主化した点は本当にすごい。
    • LLMの設定が難しいと言われるけど、LLMに設定させればいいのでは？この簡単なことすらできないほどなら、LLMに何の意味があるんだろうかと思う。
    • 昨日試してみたが、全セッションで事実関係が誤った情報がずっと出ていた。速度や便利さも良いが、精度を犠牲にするなら意味がない。
    • メモリが十分なら120Bは本当に簡単に動く。
    • 読んでいて分かったのは、モデルを正しく動作させるには、膨大な前処理とチューニング作業が必要だということを知らなかった。デフォルト設定のままでうまくいくと思っていた。
    • 私は、大手企業がLLMのリリース前に主要な推論エンジン開発者と積極的に協力して、自社LLMにも対応してもらえたらいいと思う。まだすべてが実験的だからそうなのだろうが、開発者たちが低価格ハードウェアでもLLMを載せて使えるように本当に大きな努力をしている。

  • 米国のAI Action Planで「オープンソースとオープンウェイトAIの推進」が「フロンティアAIが表現の自由と米国の価値を守る」の直後に来ていた。合理的とは言いがたいが、このタイミングでOpenAIのOSSモデルを読むと少しぞっとする。とはいえ、OSSモデル開発企業がハードウェアの話をしてくれるのは良い。大半の開発者にとってハードウェアは参入障壁なので、この話があるのは嬉しい。

    • 「フロンティアAIに自由と米国的価値を守らせる」項目もあったが、まだ自分の考えを整理する段階なので、少し理解してほしい。AIモデルは世界観を持つのが当然で、私はむしろ西洋的な世界観を好む。これがより良い社会を作ってきた前例も多くある。少なくともモデルは自分の世界観を文書化してそれに沿っているので、ユーザーにこっそり社会工学的に思考を変えさせるよう誘導しないでほしい。

  • OS別、GPU別でどのLLMモデルがよく動くかを明確に示すサイトを知っている人はいないか。VRAM見積りは、パラメータ数×(Precision/8)×1.2が最も信頼できる経験式だった（参考）。

    • 同様の計算機を作ろうとしたが、実際は変数（同時接続トラフィックなど）が多すぎる。その式も大体は合っているが、同時トラフィックが多い場合は2倍で計算するのが安全。
    • huggingfaceにハードウェア／ソフトウェア仕様を入力すると、各モデルの詳細ページでそのモデルの利用可能性が表示される機能がある。huggingface設定
    • 私はインターネット速度が速いので、モデルの重みファイルをダウンロードして、llama.cpp、LM Studio、vLLM、SGLangなど複数のランナーで直接試すのが一番早い。ランナー／実装／ハードウェアなど変数が多すぎるため、どの計算機でも実体験と完全に一致することはなかった。やはり実際に動かしてみるしかない。
    • 皆さんの意見に感謝する。算出が難しいなら、各自ランナー、ハードウェア、モデル、パラメータ、量子化、作動可否、tokens/sなどの指標までコミュニティで実験して共有するDBサイトを作ればいいかと思う。ハードウェア／ランナーの組み合わせごとに絞り込んですぐ使えると本当に実用的。

  • GPT-OSS-120Bモデルの実際のアレイサイズのような正確な数値を見つけるのが意外と難しいことを言いたい。静的型言語なら配列サイズを大まかに目視で把握できるのに、実データ（重み以外）がどのように流れ、出力ストリームがどの程度広いかを把握したい。ギガビットイーサネットで「トークン出力」帯域が最大何t/sか気になって、GitHubリポジトリgpt-ossを探しているのだがなかなか見つからない。

    • 連続するトークン全体を対象に、トークンサンプリングも規約に従ってロジットをストリーム処理しようとするアプリケーションがどんなものか知りたい。さらに、通常は文法などを合わせるためにサンプリング前にロジット加工とトークン返却をしないと次の推論に入れないことを考慮しなければならない。
    • huggingfaceのモデル設定を見ると値が2880個ある（dtypeを掛けたもの）。

  • GPT-OSSはfp4サポートでBlackwellチップ上でより速く動く。Rustで学習/推論エンジンを作っているが、cudarcとcandleにfp8、fp4サポートを追加している。cudarc PR、candle PR、Mixlayerエンジンでこれらのモデルをサポートするためにこの作業を進めている。

    • RTX Pro 6000ユーザーだが、gpt-oss-120b推論が今可能か気になる。PRはすでにマージされたようだが、実際に回せるかどうかが知りたい。