A.X K2 DSpark 對比 A.X K2：僅草稿模型實際上能為你帶來什麼

A.X K2 DSpark 與 A.X K2 的比較，最奇怪的地方在於它根本不是真正的比較。A.X K2 DSpark 無法取代 A.X K2——它根本無法獨立使用。它是 SK Telecom 在八月初悄悄放上 Hugging Face、沒有任何公告的「僅供草稿的檢查點」：一個推測解碼草稿模型，唯一的工作是讓該公司 6880 億參數的開放權重混合專家旗艦模型 A.X K2 更快生成 token，同時完全不改變其回答。所以這場對決真正的問題不在於「哪個比較好」，而在於「你應該搭配 DSpark 跑 A.X K2，還是不搭配？」本文所有內容皆按來源標示，因為 repo 告訴我們的東西與實際量測結果之間的落差，才是整個故事的重點。

A.X K2 DSpark 實際上是什麼

SK Telecom 的模型卡對於這個模型的用途異常直言不諱。A.X K2 DSpark「是 A.X K2 的 DSpark 推測解碼草稿模型」，且「是僅供草稿的檢查點：它沒有獨立用途，目的是由 vLLM 透過推測解碼與 A.X K2 一起載入。」在實務上，這表示你下載它之後，將相容的 vLLM 指向它和 A.X K2，兩者便會像一個團隊般協作：DSpark 提出候選 token，A.X K2 驗證它們，只有通過驗證的 token 才會被輸出。

關於草稿機制的兩個細節可從儲存庫中得知。首先，DSpark 並行提出多個候選 token，而非一次一個 token 地寫出草稿序列，借用了 A.X K2 自身的隱藏表示，並結合輕量級局部依賴建模。其次，整個機制設計為無損：每個候選都會先由目標模型驗證才被採用，因此 A.X K2 的輸出分佈在構造上保持不變。

這項發布本身是一項預先公告。該卡片指出，該模型「目前正在進行最終驗證，並計劃於未來幾天內公開發布」，且評估「目前正在進行中」——卡片上的所有吞吐量、TPOT 和平均接受長度指標仍列為待定（TBD）。

為什麼這個「versus」其實是「有 versus 沒有」

由於 A.X K2 DSpark 沒有獨立用途，因此不存在你選擇它而非 A.X K2 的情境。選擇在於單獨的 A.X K2 與附加草稿模型的 A.X K2 之間。就輸出品質而言，這兩種配置在構造上是相同的；唯一可能變動的軸線是解碼速度。

在此記錄一下，A.X K2 是什麼：這是一個總參數量 688B、啟用參數量 33B 的混合專家（Mixture-of-Experts）解碼器，擁有 256 個專家加上 1 個共享專家（每次前向傳播啟用 8 個）、61 層、64 個注意力頭，以及 163,840 個 token 的詞彙表，於 7 月 29 日以 Apache 2.0 授權開放權重釋出。它原生以 MXFP8 格式預訓練了約 8.2 兆個 token，採用 SK Telecom 的 Sparse Gated Attention 以提升長上下文效率，並具備 262,144 個 token 的上下文長度（原生 128K 透過 YaRN 擴展至 256K）。SK Telecom 報告稱，它在 14 個基準測試中平均比 A.X K1 高出 32.2 個百分點，長上下文與代理（agent）評測分數更提升約 83.9 分——以上皆為廠商自行回報，目前尚無獨立發布的綜合評分。

DSpark 是專門為該架構設計的。卡片上說明它與 A.X K2 的 MoE 結構、注意力佈局和原生 256K 配置相匹配，並且未針對任何其他目標進行驗證。它繼承了相同的 262,144 個 token 的上下文，因此在視窗大小上對您沒有任何成本。

閱讀模型卡：可知，尚未確認

這個儲存庫能讓你清楚地了解這個模型是什麼，同時也提供一份簡短的清單，列出它沒有告訴你的事情。

今日可知：

它是一個僅供草稿用途的檢查點，無法獨立使用；由 vLLM 透過推測解碼與 A.X K2 一同載入。

• 授權條款為 Apache 2.0；權重可自由下載與使用。

• 上下文長度與 A.X K2 相同，為 262,144 個 tokens。

它透過 SK Telecom 的 vLLM 分支（SKT-AI/vllm 儲存庫，axk2-v0.23.0 分支）運行，並使用 --speculative-config 旗標。

此方法記錄於一篇論文：「DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation」（arXiv:2607.05147，提交於2026年7月6日）——該論文也是您將看到的加速數據的來源。

• 目前沒有任何推論提供者部署它，因此沒有可呼叫的託管 API。

尚未確認：

• 官方公告 — 該卡承諾在「未來幾天內」公開發布。

• 任何 A.X K2 專屬的加速數據。評估正在進行中，所有效能指標皆為待定。

• 它在負載下的實際幫助有多大，卡片將其標示為「視工作負載而定」。

• 對草稿模型的任何獨立第三方衡量。

DSpark 與一般推測性解碼有何不同

投機性解碼是一個老套的訣竅：一個小而快的草稿模型會先猜測接下來幾個 token，然後大型模型在一次前向傳播中檢查整個猜測，接受通過驗證的前綴，再採取一個修正步驟。做得好時，它能大幅降低延遲且完全不損失品質。

關鍵點正如 DSpark 論文所說，近期的並行草稿器——一次生成長序列——會遭遇「接受率快速衰減」，因為草稿中較後面的 token 與前面的 token 沒有依賴關係，所以被拒絕的頻率遠高得多。而盲目驗證長區塊會把批次容量浪費在那些很可能被拒絕的 token 上，這在高並發的服務系統中恰好會損害吞吐量。

DSpark 同時解決這兩個問題：

• 半自迴歸草稿生成。它將並行主幹與輕量級序列模組結合，加入區塊內依賴建模，使較晚的草稿 token 依賴於較早的 token — 這正是緩解後綴衰減的關鍵。

• 信心排程驗證。此方法並非驗證固定的區塊長度，而是根據估計的前綴存活機率與引擎的吞吐量特性，針對每個請求調整驗證長度。驗證因而具有負載感知能力。

論文的數字——以及它們沒告訴你的事

以下就是您會看到的引用數字：在匹配的吞吐量水平下，相較於 MTP-1 生產基線，DSpark「將每位用戶的生成速度提升 60% 至 85%」。該論文還報告，在離線基準測試中，與最先進的自迴歸和並行草稿模型相比，接受長度有顯著提升，並表示它能防止在嚴格的互動性約束下出現嚴重的吞吐量下降。

請仔細閱讀細則，因為這對這個特定對照組合很重要：那個60–85%的數字是在DeepSeek-V4的服務系統中、於真實使用者流量下測得的——而不是在A.X K2上。這是關於DSpark方法部署在另一個模型技術棧上的說法。相比之下，A.X K2的DSpark卡至今根本沒有任何加速數字。因此，這個組合的誠實記分板是：輸出在建構上相同，以及一個加速效果——該方法的論文認為其合理，但SK Telecom本身尚未在為此草稿檢查點所建構的模型上量測過。

實際運行它需要什麼

{{1}}先決條件是大部分人會卻步的部分：你必須自行託管 A.X K2。{{/1}} 目標模型沒有託管的 API——它是開放權重的，而要提供 688B/33B 活躍參數的 MoE 服務，是一項重大的基礎設施投入。{{2}}DSpark 只對已經做出這種投入的團隊才有意義。{{/2}}

如果你有的話，加入草稿模型的邊際成本很小：

• 下載 Apache 2.0 草稿檢查點，並執行 SK Telecom 的 vLLM fork（axk2-v0.23.0 分支）。

• 通過 --speculative-config 標誌啟用推測性解碼，將其指向 DSpark 檢查點。

• 為草稿權重預留額外記憶體，並接受你現在使用的是 vLLM 的供應商分支版本，而非標準版本——這是一項維護考量。

• 謹記論文自身的提醒：驗證並非毫無代價；在高並發情境下，草率的驗證會耗損批次容量，而這正是信心排程驗證（confidence-scheduled verification）旨在處理的失敗模式。

還有一件值得知道的事：Hugging Face 表示此模型的下載量「未被追蹤」，因此沒有公開訊號能顯示有多少團隊實際試用過它。

該由誰來選擇哪一個

若您符合以下任一情況，請執行 A.X K2 普通版：

• 您運行的是原版 vLLM，且不希望路徑中有第二個檢查點或廠商分支。

您的工作負載是吞吐量受限，而非延遲受限，且使用者能接受長時間生成的等待。

你寧可等待官方發布和首次獨立測量結果。

執行 A.X K2 加上 DSpark，如果這是你：

• 您自行託管 A.X K2，而生成延遲或 token 吞吐量正是瓶頸所在。

長上下文與代理型工作負載使使用者等待冗長的輸出——這正是推測解碼所適用的領域。

你可以接受運行一個預先公告元件，因為它的缺點是有限的：最壞的情況只是它沒有幫助，而且不會改變輸出品質。

{{1}}如果你根本不自行託管 688B MoE，那就兩者都不要選。{{/1}} A.X K2 的主權與韓語能力優勢，只有在你實際執行它時才會體現；許多團隊反而會透過託管目錄來接觸前沿開源模型。這正是讓你的整合保持模型無關（model-agnostic）的價值所在：OrcaRouter 的單一 OpenAI 相容端點涵蓋 200+ 模型，以供應商列表價格計費、零加價、自動故障轉移，並提供路由 DSL 將多個模型組合成單一呼叫。（A.X K2 與 A.X K2 DSpark 目前皆未在任何平台託管——包括 OrcaRouter——因此這關乎你技術棧的其餘部分，而非路由這兩個模型。）這種策略仍然適用：讓未經驗證的模型承擔一小部分流量並自動故障轉移，而不是讓生產路徑押注在它身上。

接下來要看什麼

現況很簡單：儲存庫是真的，方法有文件記載，但測量數據付之闕如。值得關注的三件事是：承諾的公開釋出（卡片上寫著「未來幾天內」）、SK Telecom 評估結束後首批 A.X K2 專屬的吞吐量或延遲數據，以及是否有推論供應商採用這組搭配——這正是讓 DSpark 對不自行架設的團隊具有相關性的關鍵。

常見問題

A.X K2 DSpark 可以取代 A.X K2 嗎？

不。它是一個僅供草稿使用的檢查點，沒有獨立用途——它的存在是為了讓 A.X K2 解碼更快，而不是作為它的替代品。你不能在沒有 A.X K2 的情況下執行 A.X K2 DSpark。

DSpark 是否會改變 A.X K2 的輸出品質？

不，這是構造使然。每個候選 token 在提交前都由 A.X K2 驗證，因此輸出分佈保持不變——該卡片將此方法描述為無損。

我需要自行託管 A.X K2 才能使用 DSpark 嗎？

是的。DSpark 由 vLLM 與 A.X K2 一同載入，因此除非您執行的是 688B 目標，否則沒有什麼可供它草擬。目前這兩種模型都沒有託管 API。

DSpark 是否與其他模型相容？

SK Telecom 針對 A.X K2 的 MoE 架構、注意力結構和 256K 上下文設計了它，且尚未針對任何其他目標進行驗證。

裁決

A.X K2 DSpark vs A.X K2 是一場{{1}}對決{{/1}}，而誠實的答案是{{2}}兩者皆是。{{/2}}如果你已經在運行 A.X K2，且使用者苦等長時間的生成結果，那麼草稿模型就是一個{{3}}免費、低風險的實驗：{{/3}}Apache 2.0 權重，{{4}}最壞的情況只是沒有加速，而且從結構上就不可能出現品質退化。{{/4}}如果你{{5}}不受延遲限制{{/5}}——或{{6}}根本沒有自行託管 688B MoE{{/6}}——你可以放心忽略它，直到{{7}}SK Telecom 的評測數據出爐，且承諾的公開版本讓這款模型正式定案。{{/7}}你不該做的，是{{8}}把論文中的 60–85% 數字誤認為是這個模型的測量結果：{{/8}}目前，{{9}}所有關於 A.X K2 的 DSpark 專屬內容仍是 TBD。{{/9}}