ハクソク

世界を動かす技術を、日本語で。

Nvidia GPUでの「GPT-OSS-120B」を1秒間に500トークンで実行する

292日前原文(baseten.co)

概要

  • OpenAIの新しいオープンソースLLM「gpt-oss-120b」 のリリース当日に最高性能を目指した最適化事例
  • NVIDIA GPU上でのレイテンシ・スループット で業界リーダーとなった実績
  • TensorRT-LLM、vLLM、SGLang など複数のフレームワークを活用したベンチマークと互換性確保
  • バグ修正・パフォーマンス改善 を迅速に繰り返し、オープンソースコミュニティにも貢献
  • 今後の最適化方針と採用情報 についても言及

OpenAI GPT-OSS-120Bパフォーマンス最適化事例

  • OpenAIのgpt-oss-120b リリース直後から顧客向けに最適なパフォーマンスを追求
  • OpenRouterの実データ によると、NVIDIA GPU上でレイテンシ・スループット共に業界トップ
  • 柔軟な推論スタック とモデルパフォーマンスエンジニアリングチームによる迅速な改善体制
  • 数時間単位でトークン生成速度を向上 し、稼働率100%を維持
  • TensorRT-LLM、vLLM、SGLang など複数の推論フレームワークでベンチマーク実施
  • HopperおよびBlackwellアーキテクチャ との互換性を確保し、幅広いGPUサポートを実現
  • NVIDIA DynamoやKVキャッシュ対応ルーティング、Eagleによる推測デコーディング など独自最適化も導入

モデル推論最適化のステップ

  • Step 1: ベースライン推論の実行

    • 新モデル対応の推論フレームワーク・ハードウェア・サーバーの準備
    • 複数エンジニアが並列でvLLM、SGLang、TensorRT-LLM を検証
    • TensorRT-LLMの開発版 を活用し、Hopper/B200両方のGPUで稼働
    • 柔軟性の高いBaseten Inference Runtime により、新アーキテクチャにも素早く対応

  • Step 2: 互換性バグの修正

    • 新アーキテクチャやHarmony形式 対応で発生するバグの修正
    • 速度・正確性を重視した反復的なテストと修正
    • オープンソースコミュニティへバグフィックスを還元
    • 多様なOSS推論フレームワークの急速な改善 により安定稼働を実現

  • Step 3: モデル設定の最適化

    • GPT-OSS-120Bは単一H100でも稼働可能 だが、4～8枚GPUの並列化で性能向上
    • Tensor ParallelismとExpert Parallelism の比較検証
      • Tensor Parallelismは低レイテンシ
      • Expert Parallelismは高スループット
      • レイテンシ重視のため Tensor Parallelismを選択
    • TensorRT-LLM MoE Backend の採用でCUDAカーネル最適化（Blackwell対応、Hopper非対応）
    • モデルライブラリに最適化済み設定をパッケージ化 し、API提供も実施

今後のパフォーマンス最適化と展望

  • 現状でもSOTAのレイテンシ・スループット を達成
  • Speculative Decoding（推測デコーディング） の導入を検討
    • Eagle 3 など10種類以上のアルゴリズムに対応
    • ドラフトモデルで先読みし、ターゲットモデルで検証 することで推論速度を大幅向上
  • モデルパフォーマンスエンジニアを積極採用中
  • AIエンジニアリングチーム向けに最適化支援サービス も提供
    • GPT-OSS-120Bや他のオープンソース・カスタムモデルの最適化 相談受付

まとめ

  • gpt-oss-120bのリリース初日からSOTA性能を実現
  • 柔軟な推論基盤・積極的なバグ修正・最適化ノウハウ が鍵
  • 今後もさらなる最適化と技術革新 を推進

Hackerたちの意見

すごく興味深い記事だね。モデルがうまく動くようにするために、どれだけマッサージが必要か全然気づかなかったよ。てっきり、そのまま使えるもんだと思ってた。

└

個人的には、大きな企業はもっと積極的に動いて、人気のある推論エンジンの開発者たちと協力して、リリース前に特別なLLMを動かすべきだと思う。結局のところ、すべてが実験的な感じだしね。あの開発者たちは、私たちが予算に優しいハードウェアで使えるように神の仕事をしてくれてるんだ。

今朝は特に頭が回ってないのかもしれないけど、投機的デコーディングの意味がわからない。ターゲットモデルは、通常通り推論を行わずにドラフトトークンをどうやって検証するの？ もしそれをやってるなら、ドラフトトークンが検証される前は信頼できないから、結局ターゲットモデルを待つことになるじゃん。

└

確かに推論は行うけど、ドラフトされたトークンのバッチに対して、プレフィルフェーズに似た形で行うんだ。だから、ドラフトモデルがN個の新しいトークンをデコードした後、実際のモデルがそのN個の新しいドラフトトークンをスコアリングするために1回の推論を行うんだ。プレフィルは計算に依存していて、デコードは帯域幅に依存してるから、実際にはN個のトークンに対して1回のプレフィルを行う方が、N回のデコードを行うよりも安上がりなんだ。

└

専門家じゃないけど、私の理解はこんな感じ。入力トークンが出力トークンより安いって知ってる？それに関係してるんだ。例えば、モデルが「フランスの首都は」と言ってるとするよ。小さいモデルが「パリです。」を生成するんだけど、これが5トークンだとしよう。大きいモデルには「フランスの首都はパリです。」を渡して、5つのトークンを一度のフォワードパスで検証するんだ。

└

私の簡単な理解では、ターゲットモデルはドラフトトークンを一度のフォワードパスで一気に検証できるんだ。そのフォワードパスの出力は、各ドラフトトークンの確率リストで、それがドラフトモデルが出した確率と比較される。もしターゲットモデルの確率がドラフトモデルと同じかそれ以上なら、そのトークンは受け入れられる。最悪の場合、ドラフトトークンが一つも受け入れられず、ターゲットモデルが通常通り次のトークンを選ぶことになる。

└

あなたの誤解の核心は、1トークンを生成するのにK回呼び出すのが、Kトークンを生成するのに1回呼び出すのと同じくらい高いと思ってることだと思う。実際には、シリアルで生成する方が小さなバッチで生成するよりもずっと高コストなんだ。

└

例えば、f2(f1(x))を実行したいとするよ。f1とf2はどちらもGPT4を1回通過するものだと仮定して、これには2秒かかる。1回の通過に1秒かかるとしたらね。代わりに、f1(x)を別のスレッドで起動して、g1はGPT-nanoを1回通過するものとしてf2(g1(x))を実行することにする。これには1 + 0.1秒かかる、gpt nanoが1回の通過に0.1秒かかると仮定してね。この1.1秒の間に、2番目のスレッドで起動したf1(x)が終わってるはず（1秒かかるから）。だから、1.1秒でf1(x)とf2(g1(x))が利用できるし、中間のg1(x)も保存しておく。g1(x)とf1(x)を比較する。もし等しいなら、つまりg1(x) = f1(x)なら、答えはf2(g1(x))で、たった1.1秒で出る。もし等しくなければ、2番目のスレッドからのf1(x)の出力に対してf2を計算することになり、さらに1秒かかるから合計で2.1秒になる。小さいモデルが大きいモデルと2/3のケースで等しいなら、この計算には平均で2/3 * 1.1 + 1/3 * 2.1 = 1.433秒かかる。投機的デコーディングがない場合は、常に2秒だね。

└

ターゲットモデルは、通常通り推論を実行せずにドラフトトークンをどうやって検証するの？ ちゃんと通常通り推論を実行してるよ、他の推論と並行してね。 > それをやってるなら、何がポイントなのか分からないな。 並行して推論を実行することで、N回の並行推論のためにモデルの重みをメモリから一度だけ読み出せるんだ。これに対して、N回の直列推論のためにはN回もメモリから読み出さなきゃいけない。推論はメモリ帯域幅に大きく制約されるから、計算に比べて1桁か2桁も遅くなることがあるんだよ。だから、これがすごく助けになるんだ。

└

ちょっと提案したいんだけど、LLMに聞いてみて！ o3みたいな推論モデルにアクセスできるなら、すごく役立つよ。今までのスレッドの中で人間が生成した回答と同じくらい良いと思うけど、実際の力はフォローアップの質問ができるところだね。 https://chatgpt.com/share/6894504f-4458-8008-a8c9-f371588259...

これを読んで、GPT-OSS 20Bのセットアップがどれだけ簡単かに気づいたよ。Llamaのおかげで、5分でMacで動かせたんだ。

└

リソースがあれば、CPUで120Bを動かすのも簡単だよ。GGUFをダウンロードして、git pullして、llama-serverを再構築するのにかかった時間と同じくらいで、家のLLM CPU推論ボックスで120Bを動かせた。特に努力せずに40t/sで動かせて、ちょっと調整したら50t/sにもなった。残念なのは、120Bですら他のモデルに比べてあまり価値がないってことだね。ggerganovとllama.cppチームが、巨大なGPUファームを持てない個人のためにLLMを民主化したのは本当にすごいことだよ。

└

LLMのセットアップが難しいのはなぜ？LLMにやってもらえばいいんじゃない？この比較的簡単なタスクがLLMには無理なら、何の役に立つの？

└

昨日使ってみたけど、毎回事実と違う情報を提供された。スピードや使いやすさも大事だけど、正確さを犠牲にしちゃいけないよね。

└

120Bも十分にメモリがあれば簡単に動かせるよ。

「オープンソースとオープンウェイトのAIを奨励する」ってのは、「フロンティアAIが自由な言論とアメリカの価値を守ることを確保する」って部分のすぐ後にあるアメリカのAIアクションプランの一部だよ。これが合理的じゃないのは分かってるけど、OpenAIのOSSモデルを見てると、プランを並行して読むとちょっとゾクゾクするんだ。とにかく、OSSモデルの提供者がハードウェアについて語るのを見るのは好きだな。これが、あまりこのレイヤーに詳しくない開発者にとっての制約ポイントだから。

└

フロンティアAIが自由な言論とアメリカの価値を守ることを確保する まだこのトピックについて考えをまとめてる段階だから、ちょっと待ってね。これって悪いことなのかな？ AIモデルは世界観を持つことになるよね。西洋の世界観を持ってる方がいいと思う。だってそれが現代社会を築いてきたし、人々の生活を良くするのに最も成功してるから。最低限、モデルには自分の世界観を文書化してほしいし、それに沿った形で私を社会的にエンジニアリングして、私の世界観を密かに変えようとしないでほしいな。

GPUに触発されて、複数のエンジニアでこの作業を並行して進めたんだ。一人のエンジニアはvLLMを試し、別の人はSGLang、もう一人はTensorRT-LLMに取り組んだ。TensorRT-LLMをすぐに動かせたのは幸運だったよ。通常、LLMにとって最もパフォーマンスが良い推論フレームワークだからね。 > TensorRT-LLMは、正しくセットアップするのが一番難しいし、関連するアーキテクチャに関してはしばしば古くなってることが多い。プロダクション環境と同じハードウェア・ドライバー・ライブラリのスタックでモデルをコンパイルする必要があるから、これは本当に面倒くさい。マルチモーダルのセットアップも、少なくともしばらくは災難だったよ。主流のモデル、例えばマルチモーダルラマを動かすのがほぼ不可能だったからね。大きな疑問は、それが本当に価値があるのかってこと。vLLMを使ってH100でGPT-OSS-120Bを動かすのは完璧だし、スループットは単一のH100で130-140 t/sを維持してるから。 （これはちょっと釣りタイトルでもあるね。単一GPUで500t/sを期待してたけど、実際にはただのテンソル並列セットアップだった） TRT-LLMの別リリースをして、gpt-ossが正しく動くことを確認するために行ったのも面白いよ。TRT-LLMは本当にゴチャゴチャしてるから。

└

TRT-LLMはDXの観点からいろいろ課題があるけど、マルチモーダルではまだvLLMをよく使ってるよ。でも、私たちが扱おうとしているトラフィック、つまり高ボリュームでレイテンシに敏感なものに関しては、ベンチマークで常に頭一つ抜けてるし、その周りのツールにかなりの開発リソースを投資してるんだ。

最近、アトランティック横断のフライト中にMacBook Pro（M4、128GB RAM）でGPT-OSS-120Bを使ったんだけど、いくつか気づいたことがあるよ： - 小さいコンテキストウィンドウとトークンの総数が少ない時だけ速い。10kトークンを超えると、基本的にすべてを長時間キューイングしてる感じ。 - MCPsやウェブ検索、URLフェッチは、LLMとのインタラクションにおいて非常に重要な部分になってる。これが使えないと、LLMのユーティリティが大幅に減少する。 - 多くのCLI/TUIコーディングツール（例：opencode）は、オフラインの状態ではモデルと一緒に信頼性よく動作しなかった。これは他の人がOSSモデルについて指摘している他の quirks に加えてのことだね。

└

M2 Maxプロセッサー。短い会話では60トーク以上出たけど、会話が長くなるにつれて30トークに落ちちゃった。これって何が原因なのか知ってる？熱制限じゃないと思うんだけど。

└

Ollama使ってる？それともLMStudio/llama.cpp？ https://x.com/ggerganov/status/1953088008816619637

└

ウィキペディアのダウンロード版があったのは知ってるよ（そんなに大きくないやつ）。近いうちに、たくさんのデータをローカルに保存してMCP経由で公開できるようになるかもね。そしたらAIがローカルで「ウェブ検索」できるようになるし。ウェブ検索の99%は同じ100～1000のウェブサイトに行き着くと思うんだ。だから、それらをローカルにコピーするのは数GB程度だろうし、著作権の問題が出てくるよね。

└

ここにM3 Max 128GBがあって、めっちゃすごいよ。512GBのRAMを搭載したMac Studioを検討中なんだけど、ウィンドウショッピングしてるだけで、ローカルのLLMのトレンドがすごく良くなってきてると思う。OpenAIがこれをリリースした理由って知ってる？

└

低電力モードを使わない限り、火を吹くってことも言ってなかったね。M4が出てからずっと知られてることだけど。メモリ帯域幅が低すぎるんだ。クラインやオープンコードのような実際のタスクで使ってみると、コンテキストの長さが長すぎて実用的じゃないし、遅すぎるよ。

└

バッテリーはどれくらい持ったの？！

広く出回っているH100 GPU 家のパーツ引き出しを見てみたけど、なぜか$25,000のGPUが見当たらないんだよね。

└

使えることと安いことは違うよね。

└

そもそも「GPU」って呼ぶの、意味あるのかな？（H100のNVIDIAの製品ページを見たら、確かにそうなってるけど。）「主にゲーム用の消費者向けハードウェアで、限られた形でLLMの推論もできる」ものと、「AIトレーニングやLLMの推論を行うためのビジネス向けハードウェア」を区別する方法がもっと簡単にあればいいのに。

└

たくさんの場所で、$2/h以下でレンタルできるよ（引き出しの中では無理かもしれないけど）。

└

Ollamaで20Bモデルを8枚のTitanXカード（2015年製）で動かしてるよ。Ollamaはモデルを配布して、必要な15GBのVRAMを8枚のカードに均等に分けたんだ。トークン/秒は読み込み速度よりも速かったよ。

└

このコメントでめっちゃ元気出た！ありがとう！データセンターの視点から言うと、パーツ引き出しの中で一番速いハードウェアは多分、古いiPhone 8だね。

└

レンタルは広く利用できるよ。もし24/7で数年運用するわけじゃなければ、GPUを買うよりホスティングされたものを借りる方がコスト的にはお得だね。個人用だと最近のデータセンター用カードは手に入らないし、Mac StudioとかStrix Haloみたいなものを使って、遅い速度に対処することになるよ。

└

でも、1時間使うのに2.50ドルくらいの小銭が見つかるかもね。

我々は、OpenRouterの実際の使用に基づく公開データで、レイテンシとスループットの両方でNVIDIA GPUを使った明確なリーダーだった。 Baseten: 592.6 tps Groq: 784.6 tps Cerebras: 4,245 tps まだまだ素晴らしい仕事だね。

└

カスタムハードウェアの提供者はTPSがすごく得意だよね。彼らのチームには本当に感謝だし、瞬時の推論のデモはめちゃくちゃ印象的だよ。ただ、私たちは131Kのコンテキストウィンドウでモデルを提供してるけど、彼らは最大33Kだから、いくつかのエッジケースのプロンプトには影響があるかもね。それに、NVIDIAのハードウェアは高トラフィックアプリケーションをスケールするのにもっと広く利用できるし。

ここにいるついでに… どのOSのLLMモデルが特定のGPU（セットアップ）で動くかを明確に示しているウェブサイト知ってる？ 必要なVRAMのためのベストなヒューリスティックは「パラメータ数 × (精度 / 8) × 1.2」だと思うんだけど、ここから見つけたよ [0]。

└

もしかしたらいいインターネット接続に甘えてるのかもしれないけど、通常はウェイトをダウンロードして、いろんなツール（llama.cpp、LM Studio、vLLM、SGLangなど）で動かしてみて、何がうまくいくか試してるんだ。ランナーやアーキテクチャ、実装、ハードウェアなど、いろんな変数が関わってるから、今まで試した計算機はどれも正確じゃなかったよ。オーバーエスティメートもアンダーエスティメートもあったし。結局、実際に動かしてみるのが一番確実な方法だと思う :)

└

huggingfaceにはこれが組み込まれてるから、ソフトウェアとハードウェアのプロフィールをここで埋めてみてね: https://huggingface.co/settings/local-apps それからモデルのページで、使えるかどうかが表示されるよ。

└

そうだね、以前に計算機を作ろうとしたことがあるけど、結構依存するんだよね。君の式は大体合ってるけど、私は1.2じゃなくて2倍にすることが多いかな。高い同時トラフィックに対応するためにね。

└

返答ありがとう！計算するのは難しそうだけど、特定のセットアップ（モデル、正確なバリアント/量子化、ランナー、ハードウェア）を追跡するデータベースサイトを作るのもいいかもね。ユーザーがどの組み合わせで動かせたか（または動かなかったか）を報告できるようにして、トークン/sみたいなメトリクスも含めて。訪問者は自分のランナーとハードウェアを指定して、その条件で動くモデルのリストをフィルタリングできるようにすればいいんじゃないかな。

完全にローカルなエージェントコーディングを試してみたいな。今って実現可能なのかな？3050のノートパソコンがあるけど、VRAMが全然足りない気がする。でも、今の一般的なハードウェアで何ができるのか知りたいな。