Step 5 Preview 第零天即可自行託管：vLLM 與 SGLang 雙雙為 StepFun 的 600B MoE 開通服務路徑

Step 5 Preview 在 2026 年 10 月 15 日早上並不是新消息。StepFun 的 6000 億參數旗艦模型自 2026 年 9 月 20 日起即可透過供應商自家 API 呼叫，而獨立評測機構 Artificial Analysis 則自 9 月 18 日起持續對其評分。那天早上真正新的是範圍更窄、也實用得多的事：兩個主流推論堆疊各自發布了在自己擁有或租用的硬體上執行它的途徑。vLLM 開了一份草稿 pull request，加入 Step 5 Preview——共 129 個檔案、+16,996 行——並附上配套 recipe 與專用的 vllm/vllm-openai:step-5-preview 映像檔，該映像檔於 UTC 00:51 上架 Docker Hub。SGLang 合併了一頁 cookbook，內含 Blackwell 與 Hopper 部署 recipe，其背後的模型支援 pull request 也在同一小時開啟。直到那天早上之前，要讓 Step 5 Preview 跑上自己的 GPU，唯一方法是用社群重新上傳的 checkpoint，而沒有人授權你可再散布它。

所以，誠實的標題不是「StepFun 推出了一款模型」。它是在九月推出這一款，而模型本身的日期，理應放在任何相關文章的第一句。真正的標題是：截至 2026 年 10 月 15 日，服務這個問題的答案裡已經有指令了。

10月15日實際上改變了什麼？

四件文物全都標註為同一天，值得將它們分開來看，因為它們代表著不同程度的承諾。

• vLLM 模型支援 — Pull Request #61727，標題為「新增 Step-5 Preview 支援」，由 jeejeelee 於 01:18 UTC 開啟，並帶有 草稿標記。它是單一 squash 提交，涉及 129 個檔案，且尚未合併。草稿 PR 是作者請求審查，而非維護者的承諾。

• vLLM 配方 — vllm-project/recipes 中的拉取請求 #1122，於 01:16 UTC 提前兩分鐘開啟，並且也處於開啟狀態，新增了 models/stepfun-ai/Step-5-Preview.yaml，其中包含一個 FP8 預設變體和一個 NVFP4 變體。這是含有相關數字的文件，也是本文大部分內容所依據的文件。

• 容器映像檔——vllm/vllm-openai:step-5-preview，於 2026-10-15 00:51 UTC 推送，形式為雙架構 manifest：linux/amd64 壓縮後為 8.56 GB，linux/arm64 為 9.58 GB，並有 step-5-preview-x86_64-cu130 與 step-5-preview-arm64-cu130 與它們並列。已發布的映像檔比開放中的 PR 是更強烈的訊號：這代表有人已建置並推送了它，無論審查何時完成。

• SGLang cookbook——提取要求 #44357「Add Step 5 Preview cookbook」，經審查後於 UTC 01:21 合併進 main，新增了一個部署頁面，SGLang 文件現在於 docs.sglang.ai/cookbook/autoregressive/StepFun/Step-5-Preview 提供該頁面，並標記為 NEW。其配套的支援 PR #44356 仍處於開啟狀態。該 cookbook 頁面直白指出：「Step 5 Preview 支援尚未在任何 SGLang 發行版本中推出，因此單純透過 pip install sglang 安裝的版本無法提供其服務」——這是整頁最重要的一句話。

把這四者放在一起讀，就會得到一幅連貫的圖像：StepFun 正在為一個 API 已經上線近一個月的模型，建立開放式推論服務。這裡沒有任何發布公告，也沒有任何基準測試。它是決定這個模型究竟是不是你能實際運行起來的底層管線。

Step 5 Preview 是什麼，用服務工程師最先問到的說法來說明

StepFun 自家的英文文件對架構的著墨相當薄弱——它公布了模型 ID、100 萬 token 的上下文視窗、文字／圖像／影片輸入、純文字輸出、64k token 的最大輸出、JSON Schema 支援、提示快取，以及具備低、中、高三種設定的 reasoning_effort 控制項。它並未公布參數量。下方的架構數據來自今天發布的兩份第一方服務文件；這兩份文件必須讀取檢查點才能撰寫載入器，而它們彼此相符。

• 規模 — 總參數 600B，每個 token 啟用 27B，採用稀疏混合專家設計。vLLM recipe 獨立指出 604B，「依 checkpoint 張量形狀計算而來」，而這兩個數字其實是同一個數字以不同方式四捨五入。

• 深度與路由 — 92 層。每個 MoE 層會將一個 token 路由至 352 個專家中的 8 個，外加一個共享專家。這個專家數量正是 vLLM PR 帶有 router-GEMM 核心變更的原因：它新增了 (4096, 352) 作為支援的 (hidden_dim, num_experts) 配對，與現有的 (3072, 256) 和 (6144, 128) 並列。

• 注意力 — 四層重複模式：三層滑動視窗層關注最近的 512 個 token，接著是一層稀疏注意力層。稀疏層將 KV 歷史切分為 8-token 區域，用輕量級索引器為每個區域的摘要評分，並選取最多 512 個歷史區域，在 token 層級進行關注。SGLang 稱之為區域稀疏注意力；實際結果是，1M token 的上下文在記憶體上仍可負擔。

• 推測解碼 —— 三層 MTP。SGLang 的「三層 MTP」與 vLLM 配方中的 --spec-method mtp --spec-tokens 3，是從兩個方向提出的同一主張。

• 精度 — 路由專家權重為 FP8（E4M3，128×128 區塊縮放係數），但最後三個 MoE 層例外，維持 BF16。vLLM recipe 另以變體形式引用一份獨立的 NVFP4 檢查點：stepfun-ai/Step-5-Preview-NVFP4。兩套技術堆疊都保留混合精度層的拆分不變，而非將其向上轉型。

• 推理行為 — 模型總是先思考再回答。reasoning_effort 設定深度，且預設為 high（未設定時），這是在延遲預算下最可能讓你感到意外的設定。StepFun 建議的取樣參數是 temperature=1.0、top_p=0.95、top_k=0，而 SGLang 的 cookbook 將這些標示為僅供參考，而非應寫死的內容。

硬體門檻是決定這對你來說是否重要的部分。

這正是 vLLM 配方展現價值之處，因為沒有其他人發表過硬性最低需求。

• FP8 下限 — 773 GB 的 VRAM，最少需要 4 張 GPU，預設硬體目標為 B300。已驗證的配置分別列於 H200、B300 與 GB300。在四張 B300 上，此配方提供 TP4、TEP4 或 DEP4 佈局；FP8 權重無法放入四張 H200，因此 Hopper 路徑為八張 GPU。

• NVFP4 下限 — 量化檢查點需要 473 GB 的 VRAM，比 FP8 少了 300 GB。代價在於上下文：NVFP4 變體以 --max-model-len 320000 執行，因此你得從官方標示的 1,048,576 個 token 中捨棄約 724,000 個，才能塞進更小的佔用空間。

• 專家平行 — 在 Blackwell 上，TEP 與 DEP 佈局會透過 MegaMoE 路由，並使用 --moe-backend deep_gemm_mega_moe；純張量平行佈局則刻意不這麼做，因為 MegaMoE 需要專家平行才能有東西可分割。在 H200 上，此配方對每個專家層都退回使用 Triton MoE，包括那三個 BF16 層，因為 TRT-LLM MoE 核心僅限 Blackwell 使用。

• 啟動成本 — SGLang cookbook 指出，在 B300 上首次啟動約需 15 分鐘的 FlashInfer 編譯時間，後續啟動則降至約 6 分鐘，並建議你在重新啟動之間保留 FLASHINFER_WORKSPACE_BASE 與 ~/.cache/sglang。如果你要從零開始自動擴縮，那是冷啟動的下限，而非可忽略的捨入誤差。

• 目前尚未支援的部分 —— vLLM 配方將 Simple 與 LMCache KV 卸載皆標示為此模型不支援。SGLang 的 HiCache 路徑在 cookbook 中記載為可用，這是兩套技術堆疊在當前狀態下的一項實質能力差異。

實務上的解讀：Step 5 Preview 是四到八顆加速器的部署，不是單節點的玩票專案。如果那句話就讓你失去興趣，下方的 API 章節就是本文其餘的部分。

呼叫它，以及每個 token 的成本

StepFun 自家的定價頁面列出 step-5-preview，快取未命中時每百萬輸入 token 為 $1.00，快取命中時為 $0.10，每百萬輸出 token 為 $2.70——這些數字來自供應商，而非轉售商。有兩個細節會改變這筆計算。首先，快取未命中的輸入計價包含了將新內容寫入快取的過程，因此對長文件進行第一次處理時會按一次計價，第二次處理時就便宜了。其次，輸出 token 同時包含模型的推理過程與答案，這點在這裡比在直接作答的模型上更為重要。

Artificial Analysis，唯一有公開發表測試結果的中立評估機構，給 Step 5 Preview 的 Intelligence Index 分數為 43.7——顯示為 44——輸出速度中位數為每秒 88.5 個 token，而首個答案 token 的時間為 24.7 秒，對比每次回應約 2,000 個推理 token。速度數字還算體面，但答案 token 延遲則不然：一個總是先思考的模型不適合互動式自動完成，卻很適合批次與代理式工作，而這正是 StepFun 對它的定位。這些是第三方測試框架上的獨立數字，也是唯一可得的數字——StepFun 完全沒有為這個模型發布任何基準測試表。

在故事仍顯柔軟之處，而且它並非全以同樣的方式柔軟。

有三件事值得點出來，而不是粉飾帶過，因為每一件都有不同的保存期限。

首先，供應商檢查點是否真的可下載。兩份第一方服務文件都將 stepfun-ai/Step-5-Preview 和 stepfun-ai/Step-5-Preview-NVFP4 列為標準檢查點，而 SGLang 的 cookbook 則連結了 StepFun Model License 1.0 底下的 LICENSE.txt。本頁無法做到的是，從 Hugging Face 確認這些儲存庫今日可公開讀取：Hugging Face API 對 stepfun-ai/Step-5-Preview 傳回的 401 Invalid username or password，與對一個從未存在過的儲存庫 ID 所傳回的完全相同，因此該回應無法區分受閘控的模型與不存在的模型。該 recipe 本身的指引——「若檢查點需要驗證，請使用 hf auth login」——是唯一關於存取權的說明，而且是有條件的。請將該下載視為由撰寫載入器的人所提及，並在你圍繞它規劃推出之前，自行確認存取權。

第二個是發布日期，三個來源給出三種說法：StepFun 的公告資料把推出時間訂在 2026 年 9 月 20 日；Artificial Analysis 在其自身的中繼資料中將該模型標為 2026 年 9 月 18 日，並顯示「2026 年 9 月發布」；而大多數工具所讀取的模型中繼資料聚合器則記載為 2026 年 9 月 16 日。這三者都沒有解釋這個落差。本文在需要日期時採用供應商的 9 月 20 日，而值得知道的是，你正在閱讀的工具拿到的是哪個數字。

第三點是成熟度，而在這一點上，這兩套堆疊並不等價。SGLang 的 cookbook 已合併、且已併入 main，但 SGLang 自家的文字卻說支援尚未在任何正式版本中出貨，因此 Python 路徑只是一個預覽版 Docker 映像，除此之外別無其他。vLLM 的 recipe 是公開的，其模型 PR 是一份尚未合併的草稿，GitHub 目前回報它存在合併衝突且需要 rebase，而它自家的審閱者也已針對這份 recipe 提出三項未結事項——一道 FP8 硬體閘門、一份預設 B300 設定檔（在四 GPU 的指南中卻產生八 GPU 的指令），以及一項未編入變體參數中的 NVFP4 上下文上限。這些都不構成淘汰的理由。但這一切都說明，本週進行首次自架部署應視為一次評估，而非一次遷移。

這個，這週該怎麼處理

如果你已經擁有四張 B300 或八張 H200，而且工作負載看起來像是長文件分析、多輪工具呼叫或整夜執行的代理程式運行，那麼 vLLM 的配方幾乎就是一本操作手冊：拉取 vllm/vllm-openai:step-5-preview，複製 TP4 或 TEP4 指令，並在你向任何人承諾百萬 token 之前，先檢查 --max-model-len 1048576 是否能挺過你實際的 KV 預算。如果你用的是 Hopper 而非 Blackwell，就先從 NVFP4 檢查點開始，並接受 320k 上下文，或者編列八張 H200 的預算。無論哪種方式，都要在每個請求上明確設定 reasoning_effort，而不是沿用偏高的預設值，並且在你從每秒 88.5 個 token 這個數字得出任何結論之前，先在你自己的流量上測量 24.7 秒的 answer token 時間。

如果你沒有那樣的硬體，API 並不是安慰獎——它是一樣的權重，按 token 計費，輸入每百萬 token $1.00、輸出 $2.70，重複出現的上下文還可享 90% 快取折扣。而這一頁最該誠實交代我們自身定位的地方就在這裡：截至今日，Step 5 Preview 並不在 OrcaRouter 的現行模型清單上。我們的目錄涵蓋 13 家供應商的 207 個模型，目前完全沒有收錄任何 StepFun 模型，因此就這個特定模型而言，供應商自家的 API 是唯一可呼叫的路徑，本頁任何內容都不應被解讀為我們提供該模型的聲明。我們真正負責路由的是周邊的決策：當你在挑選要用哪個前沿模型承載生產工作負載時，主張透過單一端點存取它的理由是：供應商定價以 0% 加價原樣傳遞，因此供應商調價當天就是你的價格，而且跨供應商的自動容錯移轉意味著單一模型狀況不佳的一個下午不會變成你的服務中斷。這是關於我們確實有收錄的模型的陳述，而且是刻意不針對這一個模型的陳述。

接下來要關注的事情範圍很窄，而且可以查核。stepfun-ai/Step-5-Preview 是否會落實為一個可讀取的儲存庫，且帶有你能拿給法務團隊看的授權檔案；vLLM 的 #61727 是否脫離草稿狀態並清掉它的合併衝突；SGLang 的支援 PR #44356 是否進入某個帶標籤的發行版本，也就是這個 recipe 不再只是預覽映像、而變成你的 CI 可以鎖定的東西的那一刻。這三項中任何一項成真，都會把本週的「你大概可以跑它」變成直接了當的「可以」，而在那之前，唯一值得提出的主張，就是證據所支持的那一個：在 2026 年 10 月 15 日，兩套 serving 堆疊各自發布了通往一個自 2026 年 9 月 20 日起即可呼叫的模型的路徑。

選擇在自己的硬體上執行一個 6,000 億參數的模型，也屬於那種必須看歷史紀錄的決定：這一類模型有紀錄的 AI 事故與代理失效，都收錄在OrcaRouter AI Incident Archive，其中每筆條目都附有自己的來源、嚴重程度、信心等級與爭議標記。