A.X-K2-DSpark：SK Telecom 的推測解碼草稿模型悄然登場

A.X-K2-DSpark 是一個你大概永遠不會直接呼叫的模型——而這正是它值得一讀的原因。SK Telecom 悄悄地將它發布在 Hugging Face 上，背後沒有發布文章，也沒有新聞稿；模型卡開頭只簡單表示，這個 checkpoint「目前正在進行最終驗證，預計在未來幾天內公開釋出」。它是一個僅供草擬（drafter-only）的 checkpoint，專為推測解碼（speculative decoding）而設計，只有一個任務：透過提出候選 token 讓 A.X K2 驗證，使 SK Telecom 擁有 688B 參數的旗艦模型 A.X K2 在服務部署時變得更快、更便宜。以下整理這個 repository 實際告訴了我們什麼、哪些資訊尚未證實，以及為什麼像這樣的小型輔助模型，正是下一波 LLM 部署成本削減的關鍵所在。

A.X-K2-DSpark 實際上是什麼

A.X-K2-DSpark 在任何實質意義上都不是一個獨立模型。模型卡（model card）在其預期用途說明中已明確指出：它是一個「僅供草稿的檢查點」（drafter-only checkpoint），「不具獨立用途」（no standalone use）；由 vLLM 與其目標模型 A.X K2 一同載入，於推測解碼（speculative decoding）迴圈中運行。它是兩階段生成器中的草稿階段——由小型模型快速提出候選 token，再由目標模型加以驗證，確認無誤後，才會將任何 token 提交至輸出。

這裡的目標，就背景而言，是現存最大的開放權重模型之一。A.X K2 是 SK Telecom 的 688B 總參數、33B 活躍參數的混合專家（Mixture-of-Experts）模型，於 2026 年 7 月底以 Apache 2.0 授權在 Hugging Face 上發布。其基礎架構結合了 Multi-head Latent Attention 與 DeepSeek Sparse Attention，並加入 SK Telecom 自家的 Sparse Gate Attention 長上下文改進。A.X-K2-DSpark 以 A.X K2 的隱藏狀態為條件，並在候選位置之間加入輕量級局部依賴建模，因此可以並行提出多個 token，而非嚴格自迴歸式地逐字起草。每個候選 token 在提交前都會由 A.X K2 驗證——這就是為什麼模型卡稱其結果為「本質上無損」（lossless by construction）：輸出分佈不受起草模型影響，改變的只有服務速度。

推測解碼的運作方式，以及為何 688B 的 MoE 需要它

推測式解碼之所以存在，是因為自迴歸生成是序列化且受記憶體頻寬限制的。生成每個 token 都要從記憶體讀取模型權重；對 688B 的模型來說，每次生成一個 token 都意味著要搬移極為龐大的位元組數——即使每次前向傳播只有 33B 個參數處於活躍狀態。這個技巧在於：把少量額外的運算花在一個小型草稿模型上，讓它一次猜出接下來的數個 token，再由大模型以單次前向傳播驗證所有猜測，並保留與其自身分佈相符的最長前綴。當草稿模型夠好時，大模型每進行一次前向傳播就能拿到兩三個 token，而非只有一個，且最終輸出完全不變。

整個遊戲的成敗就在於接受率。一個猜測表現不佳的草稿模型，其提案會被拒絕，而驗證階段仍舊耗費相同的記憶體頻寬，因此加速效果便蕩然無存。正因如此，草稿模型本身已成為一個嚴肅的研究課題：以 A.X K2 這般規模的模型而言，1.5 倍與 3 倍加速之間的差異，等同於一支由十張 GPU 組成的推理集群與五張 GPU 組成的推理集群之間的差別。這類效率層面的優化，正是下一波託管 LLM API 降價的來源——並非來自基礎模型的品質數字，而是來自圍繞其構建的服務堆疊。

DSpark 就是這個方法——它來自 DeepSeek 團隊。

模型名稱中的「DSpark」是一項特定技術，並非SK Telecom的發明。模型卡引用了論文〈DSpark：以半自迴歸生成進行信心排程的推測性解碼〉（arXiv 2607.05147），該論文是2026年7月6日發布的預印本，出自DeepSeek的33人作者團隊；該團隊在自身V4時代服務系統的實際流量下部署了此方法。SK Telecom已將相同技術改編應用於自身的目標模型。

本文的兩項貢獻直接對應於 A.X-K2-DSpark 卡所描述的內容。首先，半自迴歸草稿生成：平行主幹在視窗內提出候選 token，同時輕量級序列模組對候選位置之間的依賴關係進行建模，克服了平行草稿生成器在提議序列中接受率急遽衰減的經典問題。其次，信心排程驗證：系統不再總是驗證固定數量的草稿 token，而是估計每個前綴存活的機率，並依請求設定驗證長度，且配合引擎的吞吐量輪廓進行調整——因此驗證工作量是負載感知的，而非均勻固定的。

根據論文自身的數據——這些是作者自己的測量結果，未經獨立驗證——DSpark 在相同吞吐量下，每個使用者的生成速度比生產環境的 MTP-1 基準快 60–85%，並且在嚴格的互動性限制下防止了嚴重的吞吐量下降。閱讀這份發布內容時，有兩點需要注意。那些結果是在作者自己的技術棧和目標上測量的，而非在 A.X K2 上；且 A.X-K2-DSpark 模型卡明確表示其自身評估仍在進行中。該論文證明了該方法在生產環境中有效。但它並未證明 SK Telecom 的檢查點能重現那些成果——這正是尚未確認的部分。

Repo 說了什麼——以及它沒說的

以下是目前可從儲存庫得知的內容，全部來自模型卡片：

• 用途 — 供 A.X K2 使用的草稿專用檢查點；不可單獨使用；未與其他任何目標驗證，且「與不相關模型不相容」。

• 目標 — A.X K2，總參數 688B / 活躍參數 33B 的混合專家模型。

• 上下文長度 — 262,144 tokens (256K)，與 A.X K2 的原生配置相符。

• 授權——Apache 2.0。

• 機制 — DSpark 半自回歸草擬；每個候選項在提交前皆由 A.X K2 驗證（無損）。

• 狀態——「目前正在進行最終驗證」；預計「未來幾天內」發布。

而以下是尚未明確確認的內容：

• 檢查點精度與大小 — 兩者皆在模型卡上列為待定（TBD）。

• 吞吐量、TPOT 和平均接受長度——這三個數字能告訴你草稿器是否真的有效，全部待定，並附上「評估正在進行中」。

• 各領域結果 — 卡片承諾韓語、數學、科學和程式碼的細項說明會「稍後」提供，但沒有日期。

• 正式公告 — 我們找不到 SK Telecom 在任何地方宣布 A.X-K2-DSpark 的資訊；該儲存庫本身就是公告。

• 獨立評分——並不存在。卡片上的所有內容都是 SK Telecom 自己的說法，且大部分仍只是承諾。

最重要的未確認數字是平均接受長度——即 A.X K2 在每次驗證回合中平均接受的草稿 token 數量。這單一數字決定了此草稿器是 1.2 倍的錦上添花，還是 2.5 倍的服務升級；同時，一旦發布正式上線，它也是最可能在沒有出處的情況下廣為流傳的數字。當它出現時，請抱持懷疑：DSpark 論文中的 60–85% 數據是在不同模型的服務堆疊上測得的，而 A.X K2 有其自身的草稿接受特性。

你實際上會如何執行它

運行草稿模型意味著從 SK Telecom 的 vLLM 分支提供 A.X K2 服務。模型卡的示例經輕微刪減後如下：

vllm serve skt/A.X-K2 --tensor-parallel-size 8 --tool-call-parser hermes --reasoning-parser deepseek_v3 --speculative-config '{"method": "dspark", "model": "skt/A.X-K2-DSpark", "num_speculative_tokens": N}'

使用取自 SKT-AI vLLM 儲存庫 axk2-v0.23.0 分支的 fork。該卡開宗明義地點出幾個注意事項：此設定針對 A.X K2 的原生 256K 上下文配置，而且加速效果取決於工作負載——並發數、輸出長度、接受率，以及草稿生成與驗證的相對成本，都會影響最終結果。換言之，這是服務基礎設施，而不是一個下載即跑的腳本。你需要 A.X K2 的權重、一個足以進行張量並行 8 的叢集，以及耐心調整num_speculative_tokens以配合你自己的流量。對於一個已經在服務 A.X K2 的團隊來說，這是一個有意義的專案；但這不是從零搭建的理由。

經濟學：效率層勝過質量宣稱

688B 模型的草稿模型之所以值得關注，是因為基礎模型的基準測試競賽已大致飽和，而服務成本競賽則尚未結束。SK Telecom 自身的發表早已倚重效率——據稱 Sparse Gate Attention 的變更在 120K token 輸入下，使總 token 吞吐量較前一代提升了 67.7%——而草稿模型正是將同樣的思路應用於解碼階段。每個被接受的草稿 token，都是一次你不必付費的大模型前向傳遞。

對於任何透過 API 使用這些模型、而非自行託管的人來說，草稿模型是隱形的——而這正是重點所在。當供應商在其推論服務堆疊中加入推測解碼時，你看到的不是一個新模型，而是同一個模型在每個 token 上變得更快、更便宜。定價層之所以重要，也是基於同樣的原因：在 OrcaRouter，我們以 0% 加價直接轉傳供應商的牌價，所以當某家廠商的服務效率優化反映為降價時，我們這邊當天就會同步生效——不需要重新議價，也不需要變更合約。而對於一個尚未證明自己、可能成功也可能失敗的模型來說，具備自動故障轉移的路由機制，正是讓你在不把生產路徑押注在它身上的前提下試用它的方式：只要一組 API 金鑰，如果第一家供應商效能下降，請求就會自動轉移到另一家供應商。

針對此版本的一則誠實說明：A.X-K2-DSpark 僅是草稿模型（drafter）專用的檢查點，因此任何託管模型 API 都無法路由到它——包括我們自己的。草稿模型是服務端元件，而非可呼叫的產品。當草稿模型正式發布、評測數字出爐時，出現在價目表上的會是更快、更便宜的 A.X K2——而不是名為「DSpark」的新端點。

幾個值得回答的問題

我可以单独使用 A.X-K2-DSpark 嗎？不——這就是本次發布的關鍵事實。它是一個僅作為草稿模型使用的檢查點，沒有獨立用途，也沒有公開 API；它只存在於 vLLM 推測解碼循環中，作為服務 A.X K2 的輔助角色，而且模型卡註明它尚未與任何其他目標進行過驗證。

A.X-K2-DSpark 是 A.X K2 的競爭對手嗎？ 恰恰相反。它是 A.X K2 的加速器——同一個模型變得更快，且輸出分佈保持不變。把它想像成一個附加的效率組件，而不是產品線中的新成員。

它到底什麼時候會正式發布？ 模型卡上寫著目前處於最終驗證階段，計畫在「接下來幾天內」公開發布。目前確認的資訊就只有這些。值得關注的日子，就是那些 TBD（待定）數值——吞吐量、TPOT 和平均接受長度——被填上的那一天，因為屆時發布不再只是承諾，而是變成你可以實際評估的東西了。

如果我透過 API 使用 A.X K2，我需要考慮這件事嗎？可能不需要直接考慮。API 背後的服務堆疊決定草稿器是否參與其中；你看到的結果是價格和延遲，而不是旗標。這對自行託管 A.X K2 的團隊最為重要，因為選擇啟用是他們可控制的 vLLM 配置變更。

這個故事的重點不在於草稿模型本身，而在於它所傳遞的訊號。效率工作正悄悄成為一個獨立的發布類別，而今年最有趣的新模型，愈來愈多是讓大模型變便宜的小幫手，而不是更大的模型。A.X-K2-DSpark 是目前最清楚的例子：一個沒有獨立用途的檢查點，在公告前發布，且大部分自身證據都標記為 TBD。等它落地時，請留意 accepted-length 數字；把 DSpark 論文的成果視為該方法的來源證明，而非此檢查點的承諾；如果你自己部署 A.X K2，請為 benchmark 預留資源——那是唯一能判斷這個悄悄發布的草稿模型是 1.2 倍的小確幸，還是真材實料的方式。