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 精準度來提供模型服務，以將自訂核心的需求降到最低，並充分利用可用硬體。

從高層次來看，Transformer LLM 的結構很簡單：

輸入嵌入

一系列 Transformer 層。每一層包含一個注意力區塊，以及一個密集 MLP 或稀疏 MoE 區塊。

輸出對數機率投影

當推出新的 Transformer 模型時，我們主要有興趣了解它們與現有模型的契合程度，以識別所需的變更。OpenAI 提前親切地分享了其模型的概覽，讓我們能夠據此調整推論設定。我們發現該模型確實需要相當多的微小變更。

注意力：帶注意力槽的 GQA

每個注意力頭都有一個預先訓練的槽參數，該參數會納入 Softmax 計算中

YaRN 位置編碼，類似於 DeepSeek-V3

QKV 投影具備偏差，類似於 Qwen 2

輸出投影具備偏差

MLP：稀疏混合專家模型 (MoE)

SwiGLU 激活函數，與大多數開源權重模型不同

專家權重的 Top-K 後 Softmax

專家具備偏差

預期參數數量約在 100B-200B 之間，我們決定：

擴展 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 的核心

槽注意力

槽注意力在 softmax 之前引入了一個額外的偏差因子，與 Q 和 K 的乘積進行累積：

雖然簡單的實作相當微不足道，但高效的注意力實作（例如 FlashInfer）在獨立頭以及 KV 序列長度上並行化注意力的計算。此外，為了數值穩定性，Softmax 是線上計算的，同時扣除最大元素以確保數值穩定性：

線上實作追蹤了初始化為 -inf 的執行最大值 m，以及初始化為 1 的縮放 d。透過將最大值初始化為當前頭的槽值，我們可以確保它正確累積到 Softmax 中。我們必須小心確保只有在注意力沿著序列長度分割成多個區塊時，此最大值才會被包含在第一個區塊中。

我們已調整了用於預填和解碼的 FlashInfer FA2 核心範本，以納入槽參數。

MoE

不同模型的 MoE 層之間的主要區別通常是路由方案。由於預期會有顯著的可變性，ROSE 在 Triton 中實作了此核心，讓我們能夠輕鬆地將其調整為新模型。以 GPT-OSS 為例，我們必須調整權重評分，僅在 Top-K 選擇的專家上執行 softmax，這與某些計算所有專家 softmax 的 DeepSeek 風格模型不同。我們發現為了準確性，在 bfloat16 精準度下計算專家權重至關重要。

MoE 層面臨的挑戰是由於我們決定重複使用現有的 DeepGEMM 核心，這些核心缺乏對偏差項的支援。幸運的是，隨著時間的推移，我們與它們進行了深入整合，進行了更改以更好地將它們與我們的自訂全對全調度核心連接起來。我們透過將 WGMMA 累積器暫存器初始化為從記憶體載入的偏差值，為 DeepGEMM 新增了偏差支援。這是處理 MN 區塊期間的一次性操作，因此成本可能微不足道，且 L2 快取確保了對這些值的有效存取。

由於這些模型無法輕易從資料並行性中受益，我們重複使用了僅限 TP 的調度與組合核心。調度的輸入在所有等級中複製，因此調度會為本地可用的專家選擇標記。組合透過 NVLink 執行加權累積。

效能微調

儘管我們的目標是快速推出模型，但我們確實希望確保效能仍然合理。在確保與 OpenAI 提供的參考實作正確之後，我們使用預設的 PyTorch 分析器對我們的實作進行了效能分析，注意核心之間的區塊和執行緒配置。我們重複使用的功能是為具有 7168 較大隱藏維度的模型建構的，這明顯大於 GPT-OSS 模型的 2880。我們專門化了核心啟動器以選擇更好的網格維度，從而顯著提升了吞吐量。

標記化與通道

Harmony 的聊天格式有幾個用於建構對話、推理內容和函式呼叫的重要概念。在此格式中，每個訊息由標頭和內容組成：

標頭承載了後設資料 —— 最重要的是角色（系統、開發人員、使用者、助理、工具）、通道，以及在叫用工具呼叫時的接收者，例如 to=functions.<function-name>。

通道（例如分析、評論和最終答案）使模型的輸出更加透明和分段。由於該格式強制執行這種分離，模型可以進行透明推理（並接受除錯檢查），而不會將思維鏈洩漏到生產環境中。接收者標籤（to= 標頭）確切地告訴執行階段哪個參與者應該接收下一個有效負荷——無論那是函式、模型本身還是終端使用者。

我們的推論引擎 ROSE 是無格式限制的。它接收一批輸入標記並串流返回輸出標記。在我們的推論堆疊中，將輸入格式化為代幣化提示並將 LLM 結果解析回結構化訊息的任務是由專用的 JSON API 前端服務處理的。我們透過在此前端新增一個新的可插入格式化程式/解析器來整合 Harmony，從而允許後端保持不變，而前端則整潔地管理聊天格式規則、工具呼叫和串流。這種關注點分離保持了架構的模組化，能夠以最小的後端變更快速採用新格式和回應功能。

成本與效能

由於 GPT-OSS 模型相對較小，我們將副本的部署限制在單一節點上，以避免節點間通訊開銷。我們的實作支援專家平行（EP）、資料平行（DP）和張量平行（TP）的靈活組合。為了找出最佳的部署設定，我們在批次大小從 1 到 128 的範圍內，對所有分片策略組合進行了基準測試。得益於 Prefill-Decode Disaggregation，我們得以分別討論 prefill 與 decode 的效能與成本取捨。

對於成本估算，我們假設名義 H200 市場費率為 $3.00/小時（注意：這並非我們的實際 GPU 價格）。

我們發現設定 batch_size=1 和 DP=1 可產生最佳的預填效能。然後，不同的 TP 組態在首個標記延遲和成本之間提供不同的權衡。下表顯示了各種組態和輸入長度的預填延遲以及每百萬個輸入標記的成本。

GPT-OSS 120B：

GPT-OSS 120B 在不同平行化配置與輸入長度下的預填充延遲及每百萬個輸入 token 成本。

GPT-OSS 20B：

GPT-OSS 20B 在不同平行化配置與輸入長度下的預填充延遲及每百萬個輸入 token 成本。

對於解碼，我們發現 EP4 DP1 TP4 是大多數情況下的最佳組態。以下四個圖表說明了 120B 和 20B 模型在 8192 和 32768 序列長度下解碼速度與每百萬個輸出標記成本之間的權衡。

放大

放大

放大

放大

我們還考慮將較小的 20B 模型用作較大 120B 模型的推測解碼草稿模型。然而，由於啟動的參數數量相似（3B 對比 5B），因此帶來的速度提升微乎其微。

參考資料

分離式預填與解碼

透過推測加速 Sonar​

使用多節點 DeepSeek 部署降低延遲並提高吞吐量

​高效且可攜的混合專家通訊

​pplx-kernels

DeepGEMM

FlashInfer：用於 LLM 推論服務的高效且可自訂的注意力引擎

帶注意力槽的高效串流語言模型

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}
}