AREX Feed Article
阿里官宣 Qwen3.8-27B 新部署配方：NVFP4 + DFlash2 上线 SGLang cookbook
8 月 21 日，阿里 Qwen 官方账号 @Alibaba_Qwen 宣布，Qwen3.8-27B 的 NVFP4 与 DFlash2 部署配方已上线 SGLang cookbook，并在推文中致谢 SGLang 项目："Fresh recipes just dropped! NVFP4 + DFlash2 for Qwen3.8-27B now in the SGLang cookbook. Thanks for the support!"（）。这是 Qwen3.8-27B 开放权重一周内，部署生态支持的最新一步。
背景：Qwen3.8-27B 是阿里 8 月 14 日（周五）以 Apache 2.0 许可在 Hugging Face 与 ModelScope 开放的 27B 稠密多模态模型（据 ），262,144 token 原生上下文、可经 YaRN 扩展至 1M，推理强度可调；称其针对软件工程、推理与长程任务优化，设计用于在笔记本上本地运行。开放一周内，Unsloth 的 GGUF 量化版升至 Hugging Face 热门榜第二、累计下载 270 万次（）；独立开发者 Simon Willison 的本地实测则把痛点摆上台面：LM Studio 默认配置只有 15–30 tok/s，"唯一阻碍它成为日常主力的是性能"（）。
SGLang 先推配方，Qwen 官宣致谢
把配方放进 cookbook 的是 SGLang 团队自己。8 月 20 日 23:51（UTC），SGLang 官方账号宣布"刚把 DFlash2（@inco_ai）配方推入 Qwen3.8-27B cookbook"，理由是"社区已经看到 NVFP4 + DFlash2 的出色结果，这些配方是很好的起点"，并预告"更多 Qwen3.8-27B 更新在路上"（）。约 8 小时后，@Alibaba_Qwen 跟进官宣并致谢。
SGLang cookbook 的 目前提供该模型的 BF16/FP8/NVFP4（W4A4）checkpoint 与内置 MTP 的部署配置，单卡目标硬件为 H200、RTX PRO 6000、RTX 5090 与 DGX Spark，并附启动命令与配置建议。论坛用户 kosta 在 8 月 20 日发布了配套的完整可复现配方（），写明 DFlash2 是"块扩散投机解码"（block-diffusion speculative decoding），已于 8 月 19 日合入 SGLang 上游（commit c14312a66）。
DFlash2 是什么：宣称 3 倍自回归速度
DFlash2 来自 inco.ai，SGLang 推文直接标注了归属。inco.ai 在 NVIDIA 开发者论坛发布的介绍称，DFlash 2 是其"广泛部署的并行草稿模型"的继任者，"接近自回归解码 3 倍的速度，输出相同"，并同时放出了 Qwen3.8-27B 与 Meta Muse Glimmer 的草稿模型（）。配方作者 kosta 称 DFlash2 是无损投机解码，贪心输出与目标模型一致，即加速不改变生成内容。
投机解码由草稿模型生成候选 token、主模型快速校验，绕开逐 token 生成的瓶颈；DFlash2 走的是并行草稿路线。配合 NVFP4 4-bit 量化把权重压到约 16.5GB（DFlash2 草稿模型约 2.6GB），这套组合的目标是把 Qwen3.8-27B 塞进 DGX Spark（GB10，128GB 统一内存）这类本地设备。
DGX Spark 实测：代码生成 52–61 tok/s
kosta 的帖子给出实测数字：2026-08-19 在真实硬件上验证，单台 DGX Spark 上代码生成 52–61 tok/s、散文 26 tok/s、思考对话 34–49 tok/s，HumanEval pass@1 为 159/164（97.0%），prefill 约 10K tok/s，短提示首 token 时延约 0.16 秒；两台 Spark 用 RoCE 互联做张量并行（TP=2）后，代码生成升到 87 tok/s。帖子还附带一组补丁，让 SGLang 的 /v1/responses 端点真正兼容 OpenAI SDK（修掉 7 类问题，外加一处基准工具的修复），并提醒 NVFP4 配置下显存占用参数应设 0.90 而非 0.95，否则 GB10 可能硬重启。
其他 Spark 用户报出相近数字：danilo.luvizotto 为 40–42 tok/s；jbourny 的对比表显示，DFlash2 配置下数学题 47.2 tok/s、代码 40.0 tok/s，而此前最佳 MTP/Dspark 配置分别为 38.8 与 31.0 tok/s。
把数字放回 Simon Willison 的实测里看：他抱怨 LM Studio 默认只有 15–30 tok/s，换用 llama.cpp 的 MTP 草稿解码后提速约 72%；新配方要解决的正是解码速度。需要说明的是，这些性能数字全部来自开发方与社区成员的实测自报。
社区分歧：DFlash2 与 MTP 谁更快
配方上线前，社区已经就"DFlash2 能否快过 MTP"吵过一轮。Qwen3.8-27B 模型卡下的 里，有用户以 Muse Glimmer 为例提问"DFlash 草稿模型会不会比 MTP 更快"；实测派给出相反结论："DFlash 并不比 MTP 好，MTP 在 token 摄入上快 2 到 3 倍。"有用户贴出的对比：原生 Q4 配置 23.73 tok/s，Qwen3.6 草稿转 Qwen3.8 的 DFlash 配置 31.94 tok/s（+34.6%，草稿接受率 34.04%），原生 MTP 50.70 tok/s（+113.7%，接受率 71.65%）。
也有用户认为 DFlash"在算力充足、代码类场景下理论上更快"。还有人报告，16GB 显存机器上 Qwen3.8-27B 配 DFlash 只有 5–6 tok/s，而 Muse Glimmer 同一配置跑到 50–60 tok/s，"Qwen 3.8 27B 真的很好，但那个速度在 16GB 显存上没法用"。同一套配方，在 NVIDIA 论坛的 Spark 用户手里是明确的提速，在部分消费级显存配置上结论相反。DFlash2 与 MTP 谁更快，两边的实测各执一词。
尚未解决的边界：DFlash2 与 1M 上下文二选一
配方帖列出的已知限制很具体：当前构建中 DFlash2/DSpark 与 YaRN 上下文扩展（超过 262K）不兼容，要 1M 上下文只能退回基础仓库的 MTP 模式，更慢。也就是说，模型卡上"262K 原生上下文、YaRN 扩至 1M"的能力与 DFlash2 加速目前不能同时拿到。
数字的可靠性同样存疑。eWeek 在报道模型发布时就提醒，发布材料缺少同口径的基准对比（MLQ.ai 的观察），阿里的性能声明应视为厂商自报；新配方的 tok/s 数字同样出自开发方与社区实测。对本地用户来说，眼下要在两件事里选：262K 上下文内用 DFlash2 提速，或放弃加速换 1M 上下文。SGLang 的预告只说"更多 Qwen3.8-27B 更新在路上"。