Day 0でのGPT-OSS

Perplexityは、正確で信頼性の高い回答とエージェント的なアクションを求める探究心あふれる人々に、最高のAIモデルを提供することに尽力しています。OpenAIは最近、オープンウェイトモデル（gpt-oss-20bおよびgpt-oss-120b）を発表しました。主要な多くのモデルと同様に、Perplexityはgpt-oss-20bおよびgpt-oss-120bをいち早く評価する組織の一つです。

本稿では、Day-0サポートを可能にした当社の社内推論スタックにおけるインフラストラクチャの決定事項について解説します。特に、NVIDIA H200 GPUでのこれらのモデルの提供に焦点を当て、カーネルの変更、デプロイメントの選択、および速度とコストのトレードオフについて詳述します。

Hopper上でのGPT-OSS

これらのオープンウェイトモデルはMXFP4量子化を使用して出荷されており、これによりコンシューマー向けハードウェアのメモリに収めたり、NVIDIA Blackwellでピークスループットを達成したりすることが可能になります。しかし、初期評価段階では、推論エンジンを最小限の変更で既存のH200 Hopperクラスター上で動作させることを目指しました。HopperにはBlackwellで導入された専用のFP4テンソルコアが搭載されていません。そのため、カスタムカーネルの必要性を最小限に抑え、利用可能なハードウェアを最大限に活用するために、FP8精度でモデルを提供することに決定しました。

大まかに言えば、トランスフォーマーLLMの構造は単純です。

入力埋め込み

トランスフォーマー層のシーケンス。各層にはアテンションブロックと、密なMLPまたは疎なMoEブロックが含まれます。

出力ロジット投影

新しいトランスフォーマーモデルを導入する際、我々は主に既存のモデルとどの程度一致しているかを把握し、必要な変更を特定することに関心があります。OpenAIは事前にモデルの概要を親切に共有してくれたため、推論セットアップを適切に調整することができました。その結果、モデルには多くの小さな変更が必要であることがわかりました。

アテンション：Attention Sinks付きGQA

各アテンションヘッドには、Softmaxに組み込まれる事前学習済みのシンクパラメータがあります。

DeepSeek-V3と同様のYaRN位置エンコーディング

Qwen 2と同様のバイアスを持つQKV投影

バイアスを持つ出力投影

MLP：疎なMixture-of-Expert (MoE)

多くのオープンウェイトモデルとは異なるSwiGLU活性化関数

専門家重みのTop-K後のSoftmax

バイアスを持つ専門家

パラメータ数が100Bから200B程度になると見込み、我々は以下の決定を行いました。

Attention SinksをサポートするためのFlashInferの拡張

DeepSeek-V3ファミリーモデル向けに既に構築済みのMoE実装を再利用する

量子化スキームとしてFP8 128x128ブロック・スケーリングを選択し、バイアス項をサポートするためにDeepGEMMカーネルを拡張する。

社内推論エンジン

当社の推論の取り組みは、社内推論エンジンであるROSEによって支えられています。私たちはROSEを、新しいモデルを迅速に導入できる柔軟なフレームワークへと発展させています。さらに、大規模なモデル提供が決定した際には、最新の技術水準に達するよう最適化し、パフォーマンスを向上させるプラットフォームを提供します。

ROSEはLLMエンジンを公開しており、モデルをロードして、投機的デコーダーやMTPデコーダーを含む複数のデコーダーを通じてデコードされたトークンを生成できます。モデル自体はカスタム層のセットで構成されており、量子化と並列化のための様々な設定ノードをサポートしています。層の下層では、個々の層によって実行される計算を効率的に実装および融合するTritonおよびCUDAカーネルの両方をバンドルしています。

ROSEは主にPythonで構築されており、モデル定義にはPyTorchに依存しています。Pythonは柔軟性があり新しいモデルへの適応を可能にする一方で、サービングやバッチスケジューリングなど、パフォーマンスの影響を受けやすいコンポーネントの大部分をRustに移行しています。

新しいモデルを導入する際、まずモデル階層を定義し、そのための重みコンバーターを構築します。すべての重みが考慮された後、最も単純なTP=1のユースケースに対してフォワードパスを定義し、エンドツーエンドで機能することを確認します。最後に、新しいコンテナをリリースして評価のためにクラスターにモデルをデプロイする前に、様々な形式の並列処理のサポートを実装およびテストします。その後、ダッシュボードとより詳細なベンチマークの両方からのフィードバックに基づいて、パフォーマンスを反復的に改善します。

ROSEは数値トークン上で動作し、統合テスト以外でのチャット形式に関する知識はほとんどありません。並行して、Harmonyトークナイザーをサポートし、リクエストを正確に入力トークンシーケンスにマッピングするために、周辺インフラストラクチャを調整する必要がありました。

GPT OSSモデルでは、デコーダー、CUDAグラフハーネス、または周辺インフラストラクチャに変更を加える必要がないことが判明したため、モデルを支えるカーネルの調整に注力することができました。

GPT-OSS用カーネル

シンクアテンション

シンクアテンションは、QとKの積で累積される、Softmaxの前の追加のバイアス係数を導入します。

ナイーブな実装はかなり簡単ですが、FlashInferのような効率的なアテンション実装は、独立したヘッド全体およびKVシーケンス長全体にわたってアテンションの計算を並列化します。さらに、数値安定性のために、最大要素を差し引きながらオンラインでSoftmaxを計算します。

オンライン実装では、-infに初期化された実行中の最大値mと、1へのスケールdを追跡しました。現在のヘッドのシンク値に最大値を初期化することで、Softmaxに正しく累積されるようにしました。シーケンス長に沿って複数のブロックにアテンションが分割された場合、この最大値が最初のチャンクのみに含まれるように注意する必要がありました。

プレフィルとデコードの両方に使用されるFlashInfer FA2カーネルテンプレートを、シンクパラメータを含むように調整しました。

MoE

モデルごとのMoE層の主な違いは、通常ルーティングスキームです。大幅な変動を予測し、ROSEはこのカーネルをTritonで実装することで、新しいモデルに簡単に適応できるようにしています。GPT-OSSの場合、全専門家間でSoftmaxを計算するDeepSeekスタイルのモデルとは異なり、Top-K選択専門家間でのみSoftmaxを実行するように重みスコアリングを調整する必要がありました。正確性のために、専門家の重みをbfloat16精度で計算することが極めて重要であると判断しました。

MoE層に関する課題は、バイアス項のサポートが欠けていた既存のDeepGEMMカーネルを再利用するという我々の決定によるものでした。幸いなことに、時間をかけてそれらと深く統合し、カスタムのオールツーオールディスパッチカーネルとより良く接続するように変更を加えました。メモリからロードされたバイアス値にWGMMAアキュムレータ・レジスタを初期化することで、DeepGEMMにバイアス・サポートを追加しました。これはMNブロックの処理中に一回限り実行されるため、コストは無視できる可能性が高く、L2キャッシュによりこれらの値への効率的なアクセスが保証されます。

これらのモデルはデータ並列処理の恩恵を十分に受けられないため、TPのみのディスパッチおよび結合カーネルを再利用しました。ディスパッチへの入力はすべてのランクで複製されるため、ディスパッチはローカルで利用可能な専門家のためのトークンを選択します。結合はNVLink全体で重み付けされた累積を実行します。

パフォーマンスの調整

モデルの立ち上げを迅速に行うことが目標でしたが、パフォーマンスが妥当であることを保証したいと考えました。OpenAIによって提供されたリファレンス実装に対して正確性を確認した後、デフォルトのPyTorchプロファイラーを使用して実装をプロファイルし、カーネル間でのブロックおよびスレッドの割り当てに注意を払いました。再利用した機能は、GPT-OSSモデルの2880よりも大幅に大きい7168というより大きな隠れ次元を持つモデル向けに構築されていました。より良いグリッド次元を選択するようにカーネルランチャーを専門化し、スループットを大幅に向上させました。

トークン化とチャンネル

Harmonyのチャット形式には、会話の構成、推論コンテンツ、および関数呼び出しを構造化するためのいくつかの重要な概念があります。この形式では、各メッセージはヘッダーとコンテンツで構成されています。

ヘッダーにはメタデータ（最も重要なのはロール（システム、開発者、ユーザー、アシスタント、ツール）、チャネル、およびツール呼び出しを呼び出す際のto=functions.<function-name>などの受信者）が含まれます。

チャネル（分析、解説、最終回答など）により、モデルの出力がより透過的かつセグメント化されます。形式によってこの分離が強制されるため、モデルは生産環境に思考の連鎖を漏らすことなく、透過的に推論（およびデバッグのために検査）できます。受信者タグ（to=ヘッダー）は、関数、モデル自体、エンドユーザーのいずれであっても、次にどの対象がペイロードを受け取るべきかをランタイムに正確に伝えます。

当社の推論エンジンROSEは、フォーマットに依存しません。入力トークンのバッチを受け取り、出力トークンをストリーミングで返します。当社の推論スタックでは、入力をトークン化されたプロンプトにフォーマットし、LLMの結果を構造化されたメッセージに解析するというタスクは、専用のJSON APIフロントエンドサービスによって処理されます。このフロントエンドに新しいプラグ可能なフォーマッタ/パーサーを追加することでHarmonyを統合し、バックエンドを変更せずにフロントエンドがチャット形式のルール、ツール呼び出し、ストリーミングをきれいに管理できるようにしました。この懸念の分離によりアーキテクチャがモジュール化され、バックエンドの変更を最小限に抑えながら、新しい形式や応答機能の迅速な採用が可能になります。

コストとパフォーマンス

GPT-OSSモデルのサイズが比較的小さいため、ノード間通信のオーバーヘッドを回避するために、レプリカのデプロイメントを単一ノードに制限しています。当社の実装は、専門家並列処理（EP）、データ並列処理（DP）、およびテンソル並列処理（TP）の柔軟な組み合わせをサポートしています。最適なデプロイメント構成を決定するために、バッチサイズ1から128までのすべてのシャーディング戦略の組み合わせをベンチマークしました。Prefill-Decode Disaggregationのおかげで、プレフィルとデコードのパフォーマンスとコストのトレードオフを個別に議論できます。

コスト見積もりのために、H200の公称市場レートを時給3.00ドルと仮定します（注：これは実際のGPU価格ではありません）。

batch_size=1およびDP=1に設定することが、最高のプレフィルパフォーマンスをもたらすことを発見しました。異なるTP構成は、最初のトークンのレイテンシとコストの間でさまざまなトレードオフを提供します。以下の表は、様々な構成と入力長に対するプレフィルレイテンシと100万入力トークンあたりのコストを示しています。

GPT-OSS 120B：

GPT-OSS 120B のパラレリズム構成と入力長ごとの、100万入力トークンあたりのプレフィル遅延とコスト。

GPT-OSS 20B：

GPT-OSS 20B のパラレリズム構成と入力長ごとの、100万入力トークンあたりのプレフィル遅延とコスト。

デコードについては、ほとんどの場合、EP4 DP1 TP4が最適な構成であることがわかりました。下の4つのプロットは、8192および32768のシーケンス長における120Bモデルと20Bモデルの両方について、デコード速度と100万出力トークンあたりのコストのトレードオフを示しています。

拡大

拡大

拡大

拡大

また、より小型の20Bモデルを、より大型の120Bモデルの投機的デコードドラフトモデルとして使用することも検討しました。しかし、アクティブ化されたパラメータ数が類似している（3B対5B）ため、得られる速度向上はわずかでした。

参考文献

分離されたプレフィルとデコード

推論によるSonarの加速​

マルチノードDeepSeekデプロイメントによる低レイテンシと高スループット

​効率的でポータブルなMixture-of-Experts通信

​pplx-kernels

DeepGEMM

FlashInfer: LLM推論サービングのための効率的でカスタマイズ可能なアテンションエンジン

Attention Sinksを用いた効率的なストリーミング言語モデル

DeepSeek-V3技術レポート​

​OpenAI Harmony応答形式 | OpenAIクックブック​

引用

@online{perplexity2025GptOssOnDay0,
  author = {{Perplexity} and Nandor Licker and Lequn Chen and Vladimir Zaytsev and Kevin Hu and Lauren Kolm and Jesse Dwyer},
  title = {{GPT-OSS on day 0}},
  date = {2025-08-08},
  url = {https://www.perplexity.ai/hub/blog/gpt-oss-on-day-0}
}