《关于我只有 27B，却把整个大模型圈的 buff 叠满了这档事》

把 Opus、GPT、Grok 都写进名字里，这个 Qwen 27B「缝合怪」到底强在哪？

这个模型的名字，真给我看乐了。

https://huggingface.co/nerkyor/Qwen3.8-27B-Coder390-EfficientThink-Opus5.5-GPT6Astra-Grok4.7-DSV4Pro-K3-SFT-RLOO-MTP-DFlash2

一个 27B 的本地模型，把 Qwen、Opus、GPT、Grok、DeepSeek、K3 全请来了，还不够，后面又接上 SFT、RLOO、MTP、DFlash2。完整名字长这样：

Qwen3.8-27B-Coder390-EfficientThink-Opus5.5-GPT6Astra- Grok4.7-DSV4Pro-K3-SFT-RLOO-MTP-DFlash2

好家伙，前半段是大模型点名大会，后半段是技术栈展示。难怪评论区有人说像轻小说书名，还有人已经给第二季起好了名字：经历了这么多训练，还是数不清 strawberry 里有几个 r。

玩梗归玩梗，这个配方确实挺让人好奇。这么多模型和技术放在一起，到底是在各干各的，还是纯粹把 buff 写进了名字里？

先把身份说清楚：这是开发者nerkyor做的社区后训练版本，基于 Qwen3.8-27B 继续优化，不是 Qwen 官方又发了一个新型号。这篇主要拆作者公开的配方和成绩，不是独立实测。至于它有没有把名字里的老师们打下来，咱们先别急着下结论。

01｜先纠正一个事：390，真不是 390 万条数据

看到 Coder390，再看到其他文章的“390 万条代码数据”，很容易就对上了：哦，拿几百万条代码把这个 27B 又练了一遍。

但按模型卡的解释，还真不是这么回事。

这里的 390，指的是 GPQA、MMLU、LCB 三项成绩都到了约 90 分，而不是用了多少条训练数据。严格一点说，GPQA 是 178/198，约 89.9%，名字里取了个整。所以，“390 万条数据专项微调”这句话，不能从这个型号里推出来。

再看后面那串大模型。乍一看，像是把几家的能力全蒸馏了一遍，但作者披露的分工其实不一样：

这样看就顺了：有负责出题的，有负责写答案的，有负责筛数据的，也有负责评判的。 更像是给这个 27B 组了一个教学团队，而不是把几家模型的权重拼到一起。

尤其是K3，不是给 Qwen 换了个“内核”；Grok 也不只是被拿来蒸馏的老师。名字看着很热闹，实际说的是它们在数据和训练流程里的分工。

讲道理，请好老师当然有用，但“老师阵容豪华”和“学生已经跟老师一样强”，中间还差一张成绩单。这个区别得先留着，后面看跑分的时候很重要。

02｜真正有意思的，是它想治一治“想太多”

比起名字里那几位老师，我觉得更值得展开的是EfficientThink。

作者想解决的问题，不是简单让模型少写几个字，而是模型已经快做出来了，却还在反复检查、推翻、重新推导，最后把输出额度用完，也没交出一个有效答案。模型卡举的极端情况，是一路写到约94K token，答案还是没出来。

这就有点像考试时题已经算出来了，但总觉得哪里不对，又重算一遍；重算完还不放心，再换个方法。折腾到交卷，答题卡上反而没填答案。你说它完全不会吧，也不是；你说给它更多时间就能解决吧，还真不一定。

所以这个版本的思路是：该推理的继续推理，但别把时间都花在反复绕圈上。

具体怎么做？先用 SFT 学好的示范，再用 RLOO 根据回答质量调整生成倾向。SFT 比较好理解，就是给模型看“这类问题应该怎么答”。RLOO 则是让它对同一个问题生成几份回答，再比较哪一份更值得鼓励。

这里稍微放个公式，其实不复杂：

A i = r i − 1 G − 1 ∑ j ≠ i r j A_i = r_i - \frac{1}{G-1}\sum_{j\ne i}r_jAi​=ri​−G−11​j=i∑​rj​

G GG是同一个问题生成的回答数量，r i r_iri​是当前这份回答的奖励。后面那一项，就是其他几份回答的平均奖励。说白了，不只看你这次得了几分，还要看你比同组其他回答好多少。这是标准 RLOO 的基本比较方式，不代表这个项目的训练实现就只有这一个公式。

比较关键的是，它没有把奖励直接写成“越短越好”。按作者披露的设计，短且正确的回答给+1.05，长但正确的也有+1.0，没有交出答案则是−1.0。

这个差别就挺重要：做对仍然是第一位，短一点只是加分项。不能为了省 token，把原本能做对的题给省错了。

根据作者公开数据重绘。对比原版 FP8 与 Coder390 静态 FP8 的思考 token 中位数 P50，非独立实测。

看作者这组数据，GPQA 的思考中位数从5,299 降到 2,966，少了约44.0%；LiveCodeBench 从8,388 降到 4,511，少了约46.2%。 这里比较的都是原版 FP8 和 Coder390 静态 FP8，也都是中位数，没有把不同版本、不同统计口径的最好结果凑到一块。

也就是说，在这些测试里，它不是简单把思考关掉，而是在保留解题过程的同时，少写了一大截。

顺带一提，前一版 EfficientThink 还披露过1,905 条 SFT 样本、110 组偏好对。这些只是特定阶段的数据，不能拿来当整个 Coder390 的训练总量。但至少说明一件事：看后训练项目，还是得看作者具体用了什么数据、怎么筛、怎么给奖励，不能看见名字里有个数字，就自动补出几百万条训练样本。

03｜代码题 83 → 90，确实涨了，但先别急着喊平替

说了这么多，最后还是得看效果。不然配方写得再长，也只是让模型名字更难复制。

先看作者给出的同协议对照：

根据作者模型卡重绘。GPQA Diamond 为 198 题，MMLU 为 500 题子集，LiveCodeBench 为 100 题子集；均为作者自测。

最显眼的是代码题。LiveCodeBench 这 100 道题，原来过 83 道，现在过 90 道。GPQA 多答对了 1 道，MMLU 多答对了 6 道。

单看这组结果，确实是个不错的信号：思考变短了，成绩没有跟着掉，代码题还多过了几道。比起单纯告诉大家“又提速了”，这种把答案质量和思考长度放在一起的对照，更有参考价值。

不过，这里有几个条件得一起看，不能只截一个 90% 就结束。

首先，这组对照使用的是两张 RTX PRO 6000、100K 上下文、最多 94,208 个输出 token，推理环境是SGLang + DFlash2。所以，它不是一张 24GB 消费卡上的实测成绩。模型能不能在 24GB 卡上跑，和这张成绩单是怎么跑出来的，是两件事。

其次，这也不是它跟 Opus、GPT 同场考试的对比。名字里有这些老师，不代表表里就有这些老师的同协议成绩。现在这张表支持的是“比原版改善了多少”，还支持不了“已经把老师打下来了”。

再就是 LiveCodeBench 的范围。这里是 100 道题的子集，不是拿到别处任何一张榜单，都能直接对着数字比。LiveCodeBench 会持续收集新题，也支持按题目发布时间划分评测窗口。你测的是哪一批题，题目和训练数据在时间上是什么关系，都会影响这个分数怎么理解。

这不是说它一定有数据污染，而是讨论泛化能力时，这些条件不能跳过去。尤其是小规模子集，多过几道题，百分比就会明显变化。

所以我觉得，这组结果可以关注，甚至值得拿自己的任务复测一轮；但要说它已经能稳定替代顶级模型做大型项目，还差对应的证据。代码题多过了几道，和能不能在一个真实仓库里跨文件改代码、跑测试、连续调用工具，不是一道题。

04｜MTP、DFlash2 也安排上了，但它们不是继续“加智商”

这个名字还有个容易让人误会的地方：训练方法和推理加速，全写到一块了。

看着像是模型练完 SFT，又练 RLOO，再练 MTP，最后加个 DFlash2，能力一路往上叠。但按仓库说明，SFT、SimPO、RLOO 是后训练过程里的方法；MTP 对应随包提供的预测头，DFlash2 对应配套的投机解码草稿模型。

所以，“SFT + RLOO + MTP 三重专项训练”这个说法，并不准确。后面这两项，重点已经转到怎么把字更快地吐出来了。

投机解码可以这么理解：主模型每次只生成一个 token，步骤比较碎。那就先让一个轻量模块猜出后面几个 token，再交给主模型批量检查。猜对的部分一起留下，没通过的部分重新处理。DFlash2 走的也是并行起草这条路线，想办法让每次验证能留下更多有用的草稿。

一个负责先写草稿，一个负责验稿。这个分工比“DFlash2 注意力加速”更接近它实际在做的事，也别因为名字里有个 Flash，就把它和 FlashAttention 当成同一类东西。

它和前面的 EfficientThink 放在一起，就能看出这套方案的主线了：

生成耗时 ≈ 生成 token 数 每秒生成 token 数 \text{生成耗时} \approx \frac{\text{生成 token 数}}{\text{每秒生成 token 数}}生成耗时≈每秒生成token数生成token数​

EfficientThink 想办法让分子小一点，少生成那些没必要的推理；投机解码想办法让分母大一点，把需要生成的部分更快写出来。

一个是少绕圈，一个是快出字。这两条路线能放在一起考虑，但也别直接把 token 的减少比例当成整个任务的提速比例。上面的式子只是粗略理解，没有把输入处理、工具调用等开销都算进去。

还有个部署时要注意的地方：按这个仓库给出的用法，MTP 和 DFlash2 选一条加速路径就行，不是两个开关一起打开，速度还能继续翻倍。

05｜24GB 显卡能不能跑？本地党最关心的来了

配方看完了，分数也看完了，最后还是那个问题：我的卡能不能装下？

传播文案里的“Q4 约 18GB”，很容易让人觉得，24GB 显存稳了，甚至还能开个超长上下文。

先别急。按 GGUF 仓库的文件信息，这个 Q4 LynnStyle-MTP 文件是19,620,406,592 字节，换算下来约19.62 GB，或者 18.27 GiB。 两种单位看着都是十几 GB，但更关键的问题是：这只是权重文件的大小，不是整个服务跑起来的显存占用。

运行时还有上下文缓存、计算缓冲等开销。上下文和并发往上加，不能只盯着模型文件还有没有塞进显存。所以，24GB 卡更合理的打开方式，是先用短上下文、单并发验证，确认能稳定跑，再一点点往上调。

顺便把精度的事也说清楚：Q4 版本列出的作者成绩是GPQA 175/198、MMLU 448/500、LCB 89/100。不是前面静态 FP8 那一行。要部署哪个版本，就看哪个版本的结果，别拿 FP8 的成绩配上 Q4 的显存需求，拼成一个“又强又省”的配置。

先把需要的文件下回来

下面以 Linux / NVIDIA 环境为例。先安装 Hugging Face CLI，然后只下这个 Q4 文件就行，没必要把整个仓库都拉下来：

pipinstall-Uhuggingface_hubREPO='nerkyor/Qwen3.8-27B-Coder390-EfficientThink-Opus5.5-GPT6Astra-Grok4.7-DSV4Pro-K3-SFT-RLOO-GGUF-NInfer'hf download"$REPO"\'GGUF/Qwen3.8-27B-Coder390-EfficientThink-Q4LynnStyle-MTP.gguf'\--local-dir ./coder390

再用支持这个模型和原生 MTP 的 llama.cpp 构建启动。这里先给8K 上下文、单并发，别一上来就把上下文拉满。

llama-server\-m./coder390/GGUF/Qwen3.8-27B-Coder390-EfficientThink-Q4LynnStyle-MTP.gguf\-c8192\-np1\-ngl99\--jinja\--host127.0.0.1\--port8080\--aliascoder390\--spec-type draft-mtp\--spec-draft-n-max4

这组参数是根据仓库示例整理的起步模板，不是我实测确认过的“24GB 显卡一定不爆显存”配置。llama.cpp 构建是否支持、运行时占用多少，还得在实际环境里验证。

几个主要参数不难理解：-c 8192是上下文设置，-np 1只开一个请求槽位，-ngl 99尝试把模型层放到 GPU。启动成功后，本机访问http://127.0.0.1:8080就能使用。

显存不够的话，先缩短上下文，再试着移除 MTP 参数，把基础推理跑通；还是不够，就减少放到 GPU 上的层数。别一开始把所有组件都开上，出了问题反而不知道是哪一块占用超了。

尤其注意，仓库的长上下文示例里有一组-c 409600 -np 4。看到这个数字很心动可以理解，但别只把409600抄出来，就当成 24GB 显卡的默认配置。示例参数和自己的硬件条件，得分开看。

需要看图的话，再下载同仓库的GGUF/mmproj-Qwen3.8-27B-Q8_0.gguf，通过--mmproj指定路径。只下主 GGUF 时，就先按纯文本模型使用；图像组件同样需要额外的资源。

最后聊两句

这个 27B 的名字确实长，但拆开看，主线并不乱：后训练减少无效思考，推理加速缩短等待。作者自测给出的结果值得继续关注，不过“请了好老师”和“已经超过老师”是两回事。先把它当成一个有意思的本地模型优化案例，比急着喊“Opus 平替”实在多了。

文中成绩均为发布者自报，本文未进行独立实测,请大家自行判断。模型卡与部署参数可能继续更新，实际部署请以仓库说明为准。

资料来源

[1] Coder390 主模型卡

[2] 前一版 EfficientThink 模型卡

[3] Hugging Face TRL：SFT Trainer

[4] Hugging Face TRL：RLOO Trainer

[5] LiveCodeBench 项目主页

[6] DFlash 2: Keep Drafting Parallel

[7] Coder390 GGUF / NInfer 仓库

[8] llama.cpp server 文档

[9] Hugging Face CLI 文档