GPT-OSS 的 Day-0 支援

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 在結構上相當簡單：

輸入嵌入 (Input embedding)

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

輸出 Logit 投影 (Output logit projection)

在引進新的 Transformer 模型時，我們主要關注其與既有模型的匹配程度，以釐清所需的變更。OpenAI 在模型發布前友善地分享了概覽，使我們能據此調整推論設定。我們發現該模型確實需要進行相當數量的細微調整。

注意力機制：具備注意力匯聚 (Attention Sinks) 的 GQA

每個注意力頭皆有一個預訓練的匯聚參數 (Sink parameter)，該參數會納入 Softmax 計算中

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

QKV 投影包含偏差項 (Bias)，類似於 Qwen 2

輸出投影包含偏差項

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

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

專家權重在 Top-K 選擇後進行 Softmax

專家模型包含偏差項

預期參數數量約在 100B 至 200B 之間，我們決定採取以下行動：

擴展 FlashInfer 以支援注意力匯聚

重複使用已為 DeepSeek-V3 模型系列建立的 MoE 實作

選擇 FP8 128x128 區塊縮放 (Block scaling) 作為量化方案，並擴展 DeepGEMM 核心以支援偏差項。

內部推論引擎

我們的推論工作由內部推論引擎 ROSE 支撐。我們正將 ROSE 建構為一個靈活的框架，以便快速引進新模型。此外，當我們決定大規模部署某個模型時，它也提供了優化與提升效能以達到業界頂尖水準的平台。

ROSE 公開了一個 LLM 引擎，可以載入模型並透過多個解碼器（包括推測解碼與 MTP 解碼器）為其產生解碼後的 Token。模型本身由一組自訂層組成，這些層支援各種關於量化與並行處理的配置節點。在這些層之下，它整合了 Triton 與 CUDA 核心，能高效實作並融合各層執行的計算。

ROSE 主要由 Python 構建，並依賴 PyTorch 進行模型定義。雖然 Python 賦予我們靈活性以適應新模型，但我們正將大多數對效能敏感的組件（例如服務與批次調度）遷移至 Rust。

為引進新模型，我們首先定義模型層級結構並為其建構權重轉換器。在確認所有權重後，我們為最簡單的 TP=1 使用案例定義前向傳遞 (Forward pass)，並確保其端到端運作正常。最後，在發布新容器並將模型部署到叢集進行評估之前，我們實作並測試對各種並行形式的支援。隨後，我們根據儀表板與更細緻的基準測試回饋，反覆優化效能。

ROSE 在數值 Token 上運作，除了整合測試外，對聊天格式幾乎沒有認知。同時，我們必須著手調整周邊基礎設施，以支援 Harmony Tokenizer 並正確地將請求對應至輸入 Token 序列。

在使用 GPT OSS 模型時，我們發現解碼器、CUDA 圖形掛鉤 (Harness) 或周邊基礎設施無需進行任何更動，這使我們能將精力集中在調整支撐模型的運算核心上。

GPT-OSS 的運算核心

匯聚注意力 (Sink Attention)

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

雖然簡單的實作相對容易，但高效的注意力實作（如 FlashInfer）會在獨立的注意力頭以及 KV 序列長度上對計算進行並行化。此外，為確保數值穩定性，Softmax 會在線上 (Online) 計算，同時扣除最大元素：

線上實作會追蹤一個運行中的最大值 m（初始化為 -inf）以及一個縮放比例 d（初始化為 1）。透過將最大值初始化為當前注意力頭的匯聚值，我們能確保它正確地累積到 Softmax 中。我們必須謹慎確保，若注意力沿序列長度被分割成多個區塊，此最大值僅包含在第一個區塊中。

我們調整了用於預填 (Prefill) 與解碼 (Decode) 的 FlashInfer FA2 核心範本，以納入匯聚參數。

MoE

不同模型 MoE 層的主要差異通常在於路由方案。預期會有顯著的變異性，ROSE 以 Triton 實作此核心，讓我們能輕鬆適應新模型。以 GPT-OSS 為例，我們必須調整權重評分，僅對 Top-K 選擇的專家進行 Softmax，這與某些對所有專家進行 Softmax 的 DeepSeek 風格模型不同。我們發現，以 bfloat16 精度計算專家權重對於準確性至關重要。

MoE 層的挑戰源於我們決定重複使用既有的 DeepGEMM 核心，該核心缺乏對偏差項的支援。幸運的是，隨著時間推移，我們與其進行了深入整合，並進行了相關變更，以更好地連接自訂的全對全 (All-to-all) 調度核心。我們透過將 WGMMA 累積器暫存器初始化為從記憶體載入的偏差值，為 DeepGEMM 增加了偏差支援。這是在處理 MN 區塊期間執行的一次性操作，因此其成本可能微乎其微，且 L2 快取確保了對這些值的高效存取。

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

效能調整

儘管我們的目標是快速引進模型，但我們仍希望確保效能合理。在確保符合 OpenAI 提供的參考實作後，我們使用預設的 PyTorch Profiler 對我們的實作進行了分析，密切關注核心間的區塊與討論串分配。我們重複使用的功能是為隱藏維度為 7168 的模型構建的，這比 GPT-OSS 模型的 2880 大得多。我們專門針對核心啟動器進行了優化，以選擇更好的網格維度，進而顯著提升了輸送量。

符號化與頻道

Harmony 的聊天格式在結構化對話、推理內容與函式呼叫方面有幾個重要概念。在此格式中，每則訊息由標頭與內容組成：

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

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

我們的推論引擎 ROSE 是格式不可知的。它接收一批輸入 Token 並串流回傳輸出 Token。在我們的推論堆疊中，將輸入格式化為 Tokenized Prompt，並將 LLM 結果解析回結構化訊息的任務，是由專門的 JSON API 前端服務處理。我們透過在該前端添加新的可插入式格式化器/解析器來整合 Harmony，這使後端保持不變，同時前端能乾淨地管理聊天格式規則、工具呼叫與串流。這種關注點分離保持了架構的模組化，能以最小的後端變更快速採用新格式與回應功能。

成本與效能

鑑於 GPT-OSS 模型相對較小，我們將每個副本的部署限制在單一節點，以避免節點間的通訊開銷。我們的實作支援專家並行 (EP)、資料並行 (DP) 與張量並行 (TP) 的靈活組合。為確定最佳部署設定，我們針對 1 到 128 的批次大小，對所有分片策略的組合進行了基準測試。多虧了 預填與解碼分離 (Prefill-Decode Disaggregation)，我們能夠分別討論預填與解碼的效能與成本權衡。

關於成本估算，我們假設 H200 的名義市場價格為每小時 3.00 美元（註：這並非我們的實際 GPU 價格）。

我們發現，設定 batch_size=1 與 DP=1 可獲得最佳的預填效能。不同的 TP 配置隨後在首個 Token 延遲與成本之間提供了不同的權衡。下表列出了各種配置與輸入長度下，每百萬個輸入 Token 的預填延遲與成本。

GPT-OSS 120B：

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

GPT-OSS 20B：

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

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

放大

放大

放大

放大

我們也考慮過將較小的 20B 模型用作大型 120B 模型的 推測解碼 (Speculative decoding) 草稿模型。然而，由於激活參數的數量相似（3B 對 5B），導致速度提升微乎其微。

參考資料

預填與解碼分離

透過推測加速 Sonar​

透過多節點 DeepSeek 部署降低延遲並提高輸送量

​高效且可移植的專家混合模型通訊

​pplx-kernels

DeepGEMM

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

具備注意力匯聚的高效串流語言模型

DeepSeek-V3 技術報告​

​OpenAI Harmony 回應格式 | OpenAI Cookbook​

引用

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