在 Day Zero 提供 Beam 1.0 服務：SGLang 配方實際上鎖定了什麼

你可以下載的檢查點，並不是你可以部署的模型，而這兩者之間的距離，通常得由某個夠不耐煩的人花上數週的框架工程來衡量。Reflection Beam 1.0 是罕見的例外：那些工程隨著權重一起到位。Reflection 於 2026 年 10 月 5 日發表該模型；到了 2026 年 10 月 16 日，權重、Apache 2.0 授權、第一方端點，以及橫跨七個推論堆疊的零日支援全數一起到位，而其中一個堆疊——SGLang，其專案帳號在 16 日表示它在 Reflection 的生產環境中為 Beam 提供服務——更發布了一份詳細到足以讓人爭論的配方。

那份配方才是真正有意思的產物，比基準測試表更有意思。一篇發布貼文告訴你某個模型很好。一份部署矩陣則告訴你，要弄清楚這件事得付出什麼代價，以及你所做的選擇會在哪些地方悄悄決定你的延遲。Reflection Beam 1.0 的 SGLang 文件是一個產生器：你挑一個硬體平台和一種策略，它就會吐出一個固定版本的 Docker 指令。對任何打算實際跑這個東西、而不是呼叫它的人來說，它逼你逐一經歷的那些選項才是真正的新聞。

配方拒絕隱藏的三個軸

這個頁面會要求你提供硬體平台、策略與量化方式，然後組出指令。這比大多數模型發布所承認的決策空間還要小，而每個軸向都有實際後果：

• 硬體平台 — B300、GB300 或 H200。Blackwell 機型原生採用 NVFP4 組建；H200 則是 FP8 與 BF16 路徑。這與 Reflection 版本說明所述的下限相同，只是改以下拉式選單重新表述。

• 策略 — 低延遲或高吞吐量，而這是大多數部署預設會弄錯的軸線。低延遲會啟用 DFlash2 草擬器，並以區塊大小 8 執行張量平行處理。高吞吐量則完全停用 DFlash2。

• 量化 — NVFP4、FP8 或 BF16，這些必須與平台和策略相互配合，而非可自由組合。

這兩個策略預設不是效能調整鈕，而是演算法的改變。推測性解碼是以解碼延遲換取每一步額外的草稿模型工作量；在區塊大小為 8、搭配 1.93B 參數草稿模型的情況下，當你一次只服務一位使用者時，這個取捨值得做，但當你積極進行批次處理時，就值得拒絕。在高吞吐量配方中關閉 DFlash2 並不是降級，而是對另一個問題給出的正確答案。

食譜不再能互換之處

別只停在預設集，繼續往下讀——頁面記載了幾項因具體硬體因素而存在的組態拆分，在你複製看到的第一個 Docker 指令之前，這些都值得先了解：

• H200 BF16 以自動靜態記憶體比例執行 TP8。933.81 GiB 的 BF16 檢查點無法容納於更少的裝置上，而記憶體比例是計算得出的，並非公開暴露的——這意味著這是唯一一個你無法在不離開支援路徑的情況下手動調整的配方。

• 其他每個配方都使用張量平行加上 DPA。這裡的 DPA 是資料平行注意力配置，能將注意力與專家平行拆分解耦，而這就是為什麼非 BF16 配方能容忍 BF16 配方所無法容忍的裝置數量。

• Blackwell NVFP4 額外啟用了專家平行化與 FlashInfer MegaMoE。這正是 Reflection 自家指南所指向的組合，而且唯有在檢查點是 273 GiB 的封裝 4 位元版本、而非 468.72 GiB 的 FP8 版本時，這個組合才會變得可用。

實際結論是：「我們在 SGLang 上跑 Beam 1.0」並不是一句關於硬體的話。兩個團隊都可以這麼說，卻各自執行不同的精度、不同的平行化配置和不同的解碼演算法，而唯一能相互對照的方式，就是把這三者全都講清楚。

「零日」有何價值，以及它不是什麼

在權重發布當天就獲得框架支援是一個明確的訊號，而且是一種特定類型的訊號。SGLang 對 Beam 1.0 的支援之所以存在，是因為 Reflection 的工程師在發布前就與 SGLang 社群合作——這是 SGLang 專案在 10 月 16 日公開發表的說法，也與 Reflection 將 SGLang 列為其零日合作夥伴之一相符，其他夥伴還包括 Transformers、vLLM、Unsloth、Axolotl、TokenSpeed 和 N​VIDIA Dynamo，並提供了 SGLang、vLLM 和 TokenSpeed 的書面操作指南，以及 Kubernetes 的 Helm chart。

• 它所確立的是——一條有文件記錄、持續維護的路徑，從已發布的檢查點通往提供服務的端點，運行於具名硬體上，並將各種量化變體納入考量。這在第一週就確實超越大多數開源發布所能做到的程度。

• 它無法證明的是——該配置是最佳的，或者你會得到的吞吐量數字會與其他人的相符。在 Reflection 投入生產環境的說法，是供應商與框架方的說法，並由實際提供服務的人員所回報。我們尚未見到對其的獨立重現，也尚未有任何針對自行託管 Beam 部署的第三方基準測試公開發表。

這個區別在這裡比平常更重要，因為這是一個 5013 億參數的稀疏專家混合模型，每個 token 有 234 億個參數處於啟用狀態，而這個架構的全部價值在於你的服務成本只是模型名稱的幾分之一。框架支援才是把那項聲稱從架構圖轉變成記憶體預算的關鍵。它並不會把它轉變成實測的吞吐量數字，而我們能找到的第一方資料中，沒有任何一份公布推論的吞吐量——發布內容中唯一具體的每秒 token 數，描述的是在單一節點、8 張 B300 GPU 上進行的 LoRA 監督式微調，那是訓練步驟，不是服務速率。

自架零日堆疊真正會有的失效模式

有一種特定的出錯方式，而問題不在模型，而是在第二週。一個為單一量化與單一平行化配置所建構的固定版本 Docker 映像檔，並不是它自身的備援：如果草稿模型與你的流量模式產生不良互動、如果驅動程式更新改變了記憶體比例所分配到的數量，或者你的容量被排在另一個租戶後面，你就沒有剩下的配置可以退回——你面對的是一次停機，而一個能力極強的模型就困在其中。

Beam 1.0 並非我們的路由之一，因此我們無法為你提供，而此處的任何內容都不應被解讀為我們對可用性的聲明。我們能做的是，把備援方案放在有用的地方。OrcaRouter 以單一 OpenAI 相容金鑰串接 200 多個模型，依供應商標價原價轉嫁、不加收任何費用，並支援跨供應商的自動容錯移轉，因此一個停止回應的自架 Beam 試行部署，只是一次路由變更，而非一起事故。Beam 部署最常取代、且可透過該方式觸及的模型，都附有公開的價目表：

• GLM-5.2 — 每百萬輸入詞元 $1.40、每百萬輸出詞元 $4.40，並具備 1,000,000 個詞元的上下文。 Reflection 自身效率主張所衡量的對象，也是 Beam 長上下文程式設計工作最直接的替代方案。

• Kimi K3 — 每百萬輸入 $3.00、快取 $0.30、輸出 $15.00，並具備 1,048,576 個詞元的上下文視窗。Reflection 的發表文章承認，K3 在原始能力上仍保持領先。

• Qwen3.8-Max — 每百萬輸入 $2.00、輸出 $6.00，並提供 1,000,000 個詞元的上下文視窗，是為想要這項能力卻不想自建機櫃的團隊打造的旗艦級專有選項。

這份食譜仍然沒有告訴你的事

有三個缺口值得點名，因為每一個都是你最終會在資訊不如你所願充足的情況下所做的決定。

首先是價格。Reflection 的端點已有文件說明，且與 OpenAI 相容，提供 max、xhigh、high、medium 和 low 的推理強度，強制推理並以 max 為預設，而每個組織的限制會在所有金鑰之間共用。它沒有公布每百萬 token 的費率，因此 Beam 1.0 的效率論證無法只靠算術推演完成。一個總是進行推理且預設為最大強度的模型，會因輸出 token 的定價是一美元還是十美元，而成為截然不同的商業提案。

第二點是獨立測量。Artificial Analysis 將該模型列出，Intelligence Index 為 30，沒有速度數據，也沒有價格，且記錄顯示它沒有公開可用的 API——這是第三方的陳述，意味著託管介面尚未為從事這類測量的人員所見。它唯一一個獨立計算出的效率數據點是真實的：Beam 在 AA 的 Intelligence Index 上產生了 7,900 萬個輸出 token，而對照組的中位數為 1.3 億。這支持了「推理 token 更少」的說法，但無法告訴你這些 token 產出的速度有多快。

第三個是版本漂移。已發布的配方是針對特定檢查點與特定 SGLang 建置所撰寫，而草稿模型本身是獨立的儲存庫。當其中任一者變動時，你在十月鎖定的配方，到了十一月就成了沒人測試過的配置。請把 Docker 指令視為帶有有效期限的起點，而不是部署。

現在誰應該對此採取行動，而誰應該等待？

如果你已經擁有 Blackwell 算力，SGLang 方案確實足以起步：四張 B300 是參考的 NVFP4 配置，記憶體計算公式已經公開，合規測試套件也已存在，而且下檔風險僅限於工程時間。如果你沒有這些硬體，這筆帳仍然算不攏，因為託管選項沒有價目表可以拿來跟資本購置相比——而首日框架支援再怎麼好，也無法取代價格。

值得關注的不是又一個宣布支援的框架。而是第一個並非來自 Reflection 或某個框架專案、而是公開發表的數字：在具名配置上的獨立吞吐量量測，或是第一方端點上的價目表。任一個都會讓這件事從一份記錄詳盡的實驗，變成一個明細項目。在那之前，對 10 月 16 日的正確解讀是：艱難的工程已如期交付——而商業案例仍是還在建構中的那部分。

這些都不是假設：像這次發布這類版本背後那些有紀錄的 AI 失效與代理事件，全都收錄在OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。