Raon-1 mini：KRAFTON 的 28.8B MoE，以及那個僅維持 184 秒的 vLLM PR

10 月 28 日 06:34:19 UTC，有人向 vllm-project/vllm 提出了一個標題為「[Model] Add Raon-1-mini support」的拉取請求。這不是佔位內容：該請求新增了 27 個檔案、3,971 行，刪除了 22 行，還附帶了一套測試套件和一頁文件。06:37:23——三分四秒後——它被關閉、未合併，且仍標記為草稿。PUBG 背後的韓國發行商 KRAFTON 曾提出將其全新的 28.8B 開放權重模型放進全球部署最廣泛的推論引擎，隨後在任何人審查一行之前就把它撤回。

這個 pull request 背後的模型是真的，而且自 10 月 21 日起即可下載。Raon-1 mini 是混合注意力專家混合模型，每個 token 啟用約 4.3B 參數，以 Apache 2.0 發布，截至 10 月 28 日，其 Hugging Face 儲存庫在過去一個月有 2,208 次下載與 221 個讚。還不存在的是那條常規路徑：一份標準 vLLM 安裝，無需分支版 wheel 就能服務它。那個落差——介於網際網路上的檢查點與可放進部署清單的模型之間——就是整個故事，而迄今的報導多半跳過它，轉而聚焦基準測試表。

KRAFTON 實際發布了什麼

這些成品於 10 月 21 日 00:14 UTC 上傳到 Hugging Face，而這也是韓國各家貿易媒體當天所採用的日期。主儲存庫的 safetensors 索引顯示共有 28,783,218,402 個 BF16 參數；新聞稿中的「30B 級」數字是四捨五入後的結果，28.8B 才是要帶進容量規劃的數字。

• 總參數與活躍參數 — 總計 28.8B，每個 token 約 4.3B 為活躍參數。

• 授權 — 權重、設定與元件採用 Apache 2.0，允許商業使用。

• 存取權——這些儲存庫設有權限管制，但可透過勾選方塊提出請求來取得存取權，而且大多數請求似乎不會經過人工審查。

• 變體 — 基礎 MXFP8 檢查點、NVFP4 版本、GGUF 儲存庫、適用於 Apple 晶片的 MLX 檢查點，以及用於推測解碼的獨立 DFlash2 草稿模型。

• 託管 — 儲存庫側邊欄顯示該模型「未由任何 Inference Provider 部署」。卡片宣傳 KRAFTON 自家 playground 提供限時免費試用；任何地方都沒有公布每 token 的價格。

• 授權條款未涵蓋的範圍——KRAFTON 的訓練資料集、其訓練方法、未發佈的軟件，以及以另行條款運作的託管 API 與遊樂場。

這是預覽版，KRAFTON 在卡片的開頭一行也如此標示。該公司表示，完整版本預計會與一份涵蓋「訓練過程與最終效能」的技術報告一同發布。文中未提供日期，卡片中也沒有任何地方揭露訓練 token 的數量——而這是任何關於此模型訓練效率的宣稱中最大的漏洞。

KRAFTON 方面的說法聚焦於成本。首席 AI 長 Kangwook Lee 將其描述為「累積超過 5 年的 AI 研發能力」所帶來的成果，並表示公司打算採用更便宜的 LLM，以「擴大 AI 在各式產業中的應用範圍」。Raon-1 mini 是 Raon 品牌下的首個語言模型；KRAFTON 自 4 月起便以該品牌發布語音、TTS 與視覺編碼器產品。

架構才是真正的賭注所在

值得理解的重點在於線性注意力層與全注意力層之間 3:1 的比例，因為這個模型在服務經濟學上的其餘一切，都是由它衍生而來。

• 層 — 共 25 層，分為 18 個 Raon Delta Attention（RDA）層與 7 個閘控 MLA 層。

• 專家 — 總共 128 個，每個 token 有 6 個路由專家和 1 個共享啟用專家，專家中間大小為 1,088。

• 尺寸 — 隱藏大小 2,560，兩種層類型共 40 個注意力頭，RDA 頭維度 128，閘控 MLA 為 192 QK / 128 V，查詢與 KV LoRA 秩分別為 576 / 512。

• 位置編碼 — NoPE，整個堆疊中任何位置皆不使用旋轉嵌入。

• 詞彙量 — 259,840 個 token，搭配未綁定的 LM head。

• 激活與殘差 — SiTU-GLU，搭配跨四個串流的 Raon-mHC 殘差連接。

RDA 是 KRAFTON 對 Kimi Delta Attention 的修改，而它所描述的改動很具體：將抹除閘與寫入閘解耦，並在卷積後套用獨立的寫入閘縮放，使原始卷積歷史得以保留，而非被覆寫。Raon-mHC 則被描述為 DeepSeek 的 mHC 的成本較低實作。兩者都不是從零發明的，而這並非批評——模型卡中的「從零訓練」指的是 KRAFTON 以自家資料設計並預訓練該模型，而非重新發明其中的每一個區塊。該模型三項主打技術中有兩項是已發表技術的重新工程化版本，第三項則是其他實驗室也同樣收斂到的 3:1 混合排程。

真正的收益在於 KV 快取。因為只有 7 個閘控 MLA 層會保留一份 KV 快取，這張卡將成本估為在 BF16 下每個 token 約 8 KiB。在完整的 262,144-token 上下文下，每個序列約為 2 GiB——這個數字能輕鬆放進單張 32 GB 顯示卡，而如果全部 25 層都進行快取，就完全放不下。這才是藏在基準測試表底下的真正產品主張：不是 Raon-1 mini 比同類更聰明，而是它的長上下文推論便宜到足以在你可能已經擁有的硬體上運行。

基準表：逐項計數，而非概括

以下每一個數字都來自 KRAFTON。截至 10 月 28 日，Artificial Analysis 沒有 Raon-1 mini 的條目——該模型根本沒有出現在該網站的模型清單中——沒有競技場排名，也沒有第三方重現。該卡片的評估全程使用 gpt-5.6-luna 作為評審與使用者模擬器，這雖有揭露，但並非獨立。請將這些數字視為帶有異常詳盡附錄的廠商主張。

這張表有 18 行與五欄：Raon-1 mini preview 對比 Qwen3.6-35B-A3B 與 Gemma 4 26B-A4B 這兩款 MoE 同級模型，並以 Qwen3.8-27B 與 Muse Glimmer 30B 作為 dense 參考。KRAFTON 的紅色標示標出最佳分數（僅限 MoE 群組內），這是比「最佳」更狹窄的說法，也正是為何關於擊敗「大小相近的海外模型」的新聞說法需要謹慎處理。

正確計算下來，Raon-1 mini 在四列的全部五欄中都是絕對最佳：

• AA-Omniscience — 3.5，相較於 Qwen3.6-35B-A3B 的 −7.2、Qwen3.8-27B 的 −0.5、Muse Glimmer 30B 的 −34.7，以及 Gemma 4 26B-A4B 的 −46.6。它是該欄中唯一的正分；儘管絕對數值不大，這仍確實在某種程度上反映了校準情形。

• IFBench — 84.2，相較於 Qwen3.8-27B 的 82.4 與 Qwen3.6-35B-A3B 的 66.6。在指令遵循方面，它領先最接近的 MoE 同類模型 17.6 分，是表格中最強的單一結果。

• LiveCodeBench v6 — 81.6，領先 81.2、83.4、79.3 與 77.4。差距狹窄，僅以 0.4 分之差勝過 Qwen3.6-35B-A3B。

• 韓語聊天機器人 — 92.9，相較於 90.6、90.1、87.0 與 74.5。這是 KRAFTON 自家的內部基準，明確未公開發布，因此是頁面上最難以查證的數字，也是該模型定位所仰賴的數字。

它也在 GPQA Diamond（84.3）與 SWE-Verified（70.8，其 coding agent 最大領先幅度是對 Qwen3.6-35B-A3B 的 {{1}}7.6 分{{/1}}）上位居 MoE 組之首，但這兩項分別以 89.7 與 74.6 敗給 Qwen3.8-27B。這種模式——勝過同量級對手，卻輸給大一級的稠密模型——在整張表中反覆出現。

這些損失並非微不足道，而且都集中在一處：

• Terminal-Bench Lite — 47.0。這是其自身比較列中最差的成績，落後 Qwen3.6-35B-A3B 16.3 分，落後 Muse Glimmer 30B 23.7 分。

• MMLU Pro — 76.5，在五者中墊底，落後 Qwen3.6-35B-A3B 9.4 分。

BFCL v4 — 59.8，除了 Muse Glimmer 之外，落後於所有三個 MoE 與稠密模型對手，亦即函式呼叫並非此模型的強項。

• AutomationBench — 29.7，僅領先 Qwen3.6-35B-A3B 的 24.9，並落後 Qwen3.8-27B 29 分。

• GDP.pdf — 5.8，僅略高於 Gemma 4 26B-A4B 的 3.6。

綜合來看，誠實的總結比新聞稿範圍更窄、也更有用：Raon-1 mini 在指令遵循、韓語對話、校準與搜尋式瀏覽上具有競爭力，但在知識召回、終端機作業與工具呼叫方面較弱。如果你的工作負載是必須可靠串接函式呼叫的代理程式，這張表不支持採用它。如果是能精確遵循指令的長上下文韓語助理，這張表則支持進行測試。

vLLM 的 pull request 原本提出了什麼，後來又收回了哪些內容

這個 pull request 來自 KRAFTON 的 fork——分支 feat/raon-public-candidate 合入 vllm-project/vllm:main——而作者本人的註記比任何推測都更能說明這次關閉的原因：「我正在努力讓程式碼保持簡單又乾淨。等我準備好時，我會重新開啟這個 PR。」PR 內文也揭露，OpenAI Codex 協助了實作，且「逐行人工審查與端到端驗證確認仍待完成」。

即使它沒有落地，它包含的內容仍然重要，因為它描繪出要把這個架構上游化需要什麼：

• 模型與設定註冊，以及 18 個 RDA 與 7 個 NoPE MLA 層的檢查點載入。

• raon_1 推理與工具呼叫解析器轉接器——讓模型能在 OpenAI 相容端點後使用，而非原始補全 API 的那個環節。

• 重用上游 ModelOpt MXFP8/NVFP4 路徑、MLA、混合狀態處理與 DFlash2 介面，且不強制使用任何 MoE 後端。

• 用於 RDA 和 mHC 的選用 raon_fast 核心，以及設定與解析器測試和文件。

大約一半的工作已驗證，一半未驗證，而 PR 也直言不諱。通過的項目包括：11 項 CPU 配置與解析器測試、pre-commit 鉤子、以確切基準版本建置並安裝 wheel、原生模型、分詞器與解析器匯入、固定檢查點完整性檢查、目標/草稿配置配對，以及 NVFP4 混合精度配置解析。待辦事項，用 PR 自己的話來說：「真實 GPU 生成、數值/模型品質比較、後端/核心執行、共享 KDA 回歸、DFlash2/快取/圖正確性，以及服務基準測試。」它還補充：「並未作出任何加速或與生產環境同等的主張。」

kernel 限制是最可能讓團隊栽跟頭的細節——他們看到「支援 vLLM」就以為能擴展。可選的快速 kernel 需要 SM10x（Blackwell 等級硬體），加上張量平行度必須恰好為 1、BF16 卷積歷史、FP32 遞迴狀態，以及 CUDA/C++ 建置工具鏈。管線平行、專家平行與 RecoverSSM 皆不受支援。實務上，這表示快速路徑是單 GPU 路徑；這與模型的整體賣點一致，卻與大多數人實際服務 28.8B 模型的方式不相容。

本週你可以執行的項目

KRAFTON 推出自家的 vLLM 分支，固定於 ref raon-1-mini-preview，其文件以 NVIDIA B300 為基準撰寫，並透過支援工具呼叫的 OpenAI 相容 API 提供服務。文件中記載的啟動方式使用 --max-model-len 262144。下列每條路由都是 KRAFTON 自家的，且沒有一條是上游的：

• {{1}}vLLM{{/1}} — 從 {{2}}github.com/krafton-ai/vllm{{/2}} 以釘選的 ref 安裝，並設定 {{3}}VLLM_USE_PRECOMPILED=1{{/3}}。這是取得此分支的解析器適配器與 {{4}}DFlash2{{/4}} 支援的唯一途徑。

• Transformers — 5.16.1 搭配 accelerate 1.15.0、device_map="auto"，且 CPU 卸載在 32 GB GPU 上可行。

• RTX 5090 — NVFP4 檢查點、32,768 個 token 的上下文、2,048 個批次處理的 token、8 個序列，以及 3 GiB 的 FP8 KV 快取；它需要 CUDA Toolkit 13，且必須已安裝 nvcc。

• DGX Spark — 位於 ghcr.io/krafton-ai/raon-vllm-spark:sm121-4e09534 的 ARM64 容器，可執行 128K 上下文，序列數不超過 8。

• llama.cpp — KRAFTON 分支與 GGUF Q4_K_M 建置，上游支援列為待定。

• MLX — mlx 0.32.4 與 mlx-lm 0.32.2 對照獨立的 MLX 檢查點。

{{1}}推測性解碼的草稿模型{{/1}}值得特別一提，因為{{2}}2.18×{{/2}}正是會被引用的數字。KRAFTON 在單一 B300 上，使用 {{3}}MXFP8{{/3}} 目標模型與 vLLM 0.28.0、區塊大小 8 進行測量，並將其描述為輸出吞吐量比自迴歸解碼「最高」高出 {{4}}2.18×{{/4}}，且會隨硬體與工作負載而異。那是廠商在大多數讀者沒有的硬體上所做的基準測試。這類說法也高度取決於接受率，而接受率又取決於你的提示分布。

取樣設定並非一般的預設值，值得完全照抄：temperature 1.0、top_p 0.95、top_k 20，不設重複懲罰或頻率懲罰，而 presence penalty 在程式設計與數學為 0，其他一切則為 1.5。思考模式預設開啟，而說明卡建議不要關閉它。若把 presence penalty 設錯，你就會得出模型比實際更差的結論。

一個與品質無關的營運注意事項：把 fork 釘在特定版本是供應鏈決策。你拿到的是 KRAFTON 建置的 vLLM，而不是上游的發布列車——你的配置沒有上游 CI，除非有人重新變基，否則不會有上游安全修補，而且每次 vLLM 升級都會變成一次合併，而不是單純升版。對於正在評估的預覽模型，這是合理的取捨。對於生產環境依賴，這正是要和模型本身一起放進風險登記簿的事項。

如何在不押注的情況下測試它

Raon-1 mini 不在 OrcaRouter 的目錄中，這裡的任何內容都不應被解讀為另有主張——我們並不提供它。我們提供的是它的比較組，而這恰好是正確的對照組：Gemma 4 26B-A4B 每百萬輸入 token 為 $0.06、每百萬輸出 token 為 $0.33，Qwen3.6-35B-A3B 為 $0.248 與 $1.485，Qwen3.8-27B 為 $0.33 與 $2.40，全部皆為供應商牌價，無加價。那些是它被用來對比的模型，可透過同一把金鑰存取，這讓有用的實驗變得便宜：用 KRAFTON 自己的提示對抗託管基準，並用相同提示對抗本地預覽版，看看供應商表格能否經得起你的資料考驗。

那比更用力鑽研表格，更能好好利用一週。安裝 fork 只需一個下午；真正能告訴你的是這項比較：一個有效參數為 4.3B、在 IFBench 領先 17.6 分、在 Terminal-Bench 落後 16.3 分的模型，是否符合你的工作負載。如果某個託管基線已經在承載流量，透過具備自動容錯移轉的單一端點，讓它與預覽版一起路由，就意味著未經驗證的檢查點永遠不會獨自待在關鍵路徑上——評估能以生產環境的形態運行，卻不必承擔生產風險。

什麼會改變這項評估？

四件事，大致按後果輕重排序。

一次上游 vLLM 合併，因為它把 fork 的固定版本變成版本號，並讓模型進入每一個假設有主線支援的下游封裝、量化與服務工具。KRAFTON 表示，等程式碼準備好後會重新開啟該 PR；已關閉的 PR 中待完成的 GPU 驗證清單，是對「準備好」必須代表什麼的合理描述。

獨立評估，因為由單一模型評判十八個廠商列，不過是一名作者意見的規模化版本。AA-Omniscience 的結果是表格中最有意思的數字，正因為它正是獨立測試框架能迅速證實或推翻的那類東西。

完整發布版與技術報告，因為一個未揭露訓練 token 數量的預覽版，無法支撐任何關於訓練效率的主張，而效率正是整個論證的核心。在它正式發布之前，「從零訓練」只是關於來源的陳述，而非關於成本。

而且還有一個公開定價的託管端點，因為現在使用 Raon-1 mini 的唯一方式就是自己運行它，而唯一能為它定價的方式，就是攤銷你自己的 GPU 時數。

目前，精確的描述很短。Raon-1 mini 是一個真實、可下載、採 Apache-2.0 授權、總參數 28.8B／啟用參數 4.3B 的模型，於 10 月 21 日發布；它有著真正有趣的 KV 快取故事、一張在四行上捧它、在三行上讓它難堪的廠商基準測試表、一套只以 KRAFTON fork 形式存在的推論服務堆疊，以及一個只存活了 184 秒的上游 pull request。這比「KRAFTON 剛剛免費發布了一個前沿模型」或「在 vLLM 合併前沒什麼可看」都更有用。