Raon-1 mini：KRAFTON 的 28.8B MoE，以及那个仅持续了 184 秒的 vLLM PR

10月28日 UTC 06:34:19，一份题为“[Model] Add Raon-1-mini support”的拉取请求被提交至 vllm-project/vllm。它并非占位提交：涉及 27 个文件，新增 3,971 行、删除 22 行，还附带一套测试和一篇文档页面。06:37:23——3 分 4 秒后——它被关闭，未合并，且仍被标记为草稿。PUBG 背后的韩国发行商 KRAFTON 曾提议将其新的 28.8B 开放权重模型纳入全球部署最广泛的推理引擎，随后在任何人审阅一行之前又将其撤回。

这个拉取请求背后的模型是真实存在的，并且自 10 月 21 日起就可以下载。Raon-1 mini 是一个混合注意力混合专家模型，每个 token 会激活约 43 亿个参数，以 Apache 2.0 许可发布；截至 10 月 28 日，它在过去一个月内有 2,208 次下载，其 Hugging Face 仓库获得了 221 个赞。目前尚不存在的，是那条普通路径：一个标准的 vLLM 安装就能在不使用分叉 wheel 的情况下为其提供服务。这个缺口——介于互联网上的检查点与可以放进部署清单的模型之间——才是整件事的关键，而迄今为止的报道大多跳过了它，转而关注基准测试表。

KRAFTON 实际发布了什么

这些产物于 UTC 10月21日 00:14 上线到 Hugging Face，这也是当天每家韩国行业媒体统一采用的日期。主仓库的 safetensors 索引显示，BF16 下有 28,783,218,402 个参数——新闻稿中的“30B 级”数字是四舍五入的结果，容量规划应采用的数字是 28.8B。

• 总参数与激活参数——总计 28.8B，每 token 约 4.3B 激活参数。

• 许可证 — 权重、配置和组件均采用 Apache 2.0，允许商业使用。

• 访问权限——这些仓库设有访问限制，但通过复选框提出请求即可获得访问权限，而且对于大多数请求，似乎并未经过人工审核。

• 变体 — 基础 MXFP8 检查点、NVFP4 构建、GGUF 仓库、适用于 Apple silicon 的 MLX 检查点，以及用于推测解码的独立 DFlash2 草稿模型。

• 托管 — 仓库侧边栏显示该模型“未由任何推理提供商部署”。模型卡片宣传在 KRAFTON 自有试验场中提供限时免费试用；任何地方都没有公布每 token 价格。

• 许可证不涵盖的内容——KRAFTON 的训练数据集、其训练方法、未分发的软件，以及托管 API 和 playground，这些均适用单独条款。

这是一个预览版，KRAFTON 在卡片开头就是这样标注的。该公司表示，计划在正式完整发布的同时发布一份技术报告，内容涵盖“训练过程和最终性能”。但没有给出日期，卡片中也未在任何地方披露训练 token 数量——而这正是任何关于该模型训练效率的说法中最大的漏洞。

KRAFTON 方面的说法是成本。首席人工智能官 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 层保留一份缓存，产品卡将成本定在 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 行 5 列：将 Raon-1 mini preview 与作为 MoE 同级竞品的 Qwen3.6-35B-A3B 和 Gemma 4 26B-A4B 进行对比，同时列出 Qwen3.8-27B 和 Muse Glimmer 30B 作为稠密模型参照。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，这是其相对 Qwen3.6-35B-A3B 最大的编码智能体领先幅度，达到 7.6 分）上位居 MoE 组第一，但在这两项上均不敌 Qwen3.8-27B（89.7 和 74.6）。这种模式——能击败同量级选手，却输给大一档的稠密模型——在整张表中反复出现。

损失并非微不足道，而且集中在一处：

• 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。

综合来看，这份诚实的总结比新闻稿更聚焦、也更有用：{{1}}Raon-1 mini{{/1}} 在指令遵循、韩语对话、校准和搜索式浏览方面有竞争力，在知识回忆、终端工作和工具调用方面较弱。如果你的工作负载是一个必须可靠地串联函数调用的代理，这张表支持不选它。如果它是一个需要精确遵循指令的长上下文韩语助手，这张表支持测试它。

vLLM 的拉取请求提议了什么，又撤回了什么

这个拉取请求来自 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/缓存/图正确性，以及服务基准测试。”它还补充道：“未作出任何加速或生产环境同等水平的声明。”

内核约束是最可能让团队栽跟头的细节——他们看到“vLLM 支持”就以为它能扩展。可选的快速内核需要 SM10x——Blackwell 级硬件——并且张量并行度必须恰好为一、BF16 卷积历史、FP32 循环状态以及 CUDA/C++ 构建工具链。不支持流水线并行、专家并行和 RecoverSSM。实践中，这意味着快速路径是一条单 GPU 路径，这与该模型的整体卖点一致，但与大多数人实际服务 28.8B 模型的方式不兼容。

本周你可以运行的内容

KRAFTON 发布了其自有的 vLLM 分支，固定于 ref raon-1-mini-preview，文档针对 NVIDIA B300 编写，并通过兼容 OpenAI 的 API 提供服务，支持工具调用。文档中的启动命令使用 --max-model-len 262144。以下每条路由均为 KRAFTON 自有，均非上游：

• vLLM — 使用 VLLM_USE_PRECOMPILED=1，从 github.com/krafton-ai/vllm 的固定 ref 安装。这是获取该 fork 的解析器适配器与 DFlash2 支持的唯一途径。

• Transformers — 5.16.1 搭配 accelerate 1.15.0、device_map="auto"，并且 CPU offload 在 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 容器，以不超过 8 个序列运行 128K 上下文。

• llama.cpp — 一个 KRAFTON 分支和一个 GGUF Q4_K_M 构建版本，上游支持被列为待定。

• MLX — mlx 0.32.4 和 mlx-lm 0.32.2，针对单独的 MLX checkpoint 进行测试。

投机解码的草稿模型值得提一句，因为 2.18× 这个数字会被引用。KRAFTON 在单块 B300 上、使用 MXFP8 目标模型和 vLLM 0.28.0、block size 为 8 的条件下进行了测量，并将其描述为输出吞吐量比自回归解码“最高”高 2.18×，具体会因硬件和工作负载而异。这是厂商在大多数读者并不拥有的硬件上做的基准测试。这也是一种高度依赖接受率的说法，而接受率又取决于你的提示分布。

采样设置并非通常的默认值，值得原样照搬：temperature 1.0、top_p 0.95、top_k 20，不设重复惩罚或频率惩罚；编码和数学任务的存在惩罚为 0，其他所有任务为 1.5。思考模式默认开启，说明卡建议不要关闭它。如果把存在惩罚设错，你就会得出模型比实际更差的结论。

有一条与质量无关的运维注意事项：固定到某个 fork 是一项供应链决策。你得到的是 KRAFTON 构建的 vLLM，而不是上游的发布节奏——你的配置没有上游 CI；除非有人执行 rebase，否则不会有上游安全补丁；而且每次 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 安装只需一个下午；真正能说明一个在 IFBench 上领先 17.6 个百分点、在 Terminal-Bench 上落后 16.3 个百分点的 4.3B 激活参数模型是否适合你的工作负载的，正是这项对比。如果托管基线已经在承载流量，那么将它和预览版通过一个带自动故障转移的端点一起路由，就意味着未经证实的检查点绝不会独自处在关键路径上——评估可以按生产形态运行，而不承担生产风险。

什么会改变这一评估？

四件事，大致按后果的严重程度排序。

一次上游 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-cache 故事，一张厂商基准测试表在其中四行上让它显得出色、在三行上让它难堪，一个仅以 KRAFTON 分支形式存在的服务栈，以及一个仅持续了 184 秒的上游拉取请求。这比“KRAFTON 刚刚免费发布了一个前沿模型”或“在 vLLM 合并之前没什么可看的”都更有用。