本周的本地大模型圈，被一波 Qwen3.8-27B 实测刷屏了。54.2 万粉的孤鸿泽晒出参数优化后的终端成绩：Q8_K_XL 量化版跑到 76 t/s+，还留下一句大实话——跑生产一定要用最新版的 llama.cpp，不要用 LM Studio。微博
109.8 万粉的斌叔OKmath 更进一步：在单张 24GB 显存的 RTX 4090 上做严格 A/B，用 DFlash2 把解码速度拉到 77~81 t/s，上下文窗口一分不缩。微博同一条赛道上，还有人用一张 16G 显存的 5060 Ti 跑 4 位混合权重，速度 47 t/s，上下文直接顶到 129K。微博
硬件的下限也有人摸：2018 年发布的 V100S 32GB OEM 版，输出大约 30 tok/s，跑的人自己解释——dense 模型每个 token 都要把完整权重扫一遍，绕不开内存墙。微博把这些个人实测摆在一起（它们都不是官方基准），会看到一个扎眼的规律：数字最漂亮的，全都跑在命令行工具 llama.cpp 上，没有一个出自 LM Studio 的图形界面。
先补个背景。8 月 14 日，千问官方如约开源 Qwen3.8-27B：27B 稠密架构、原生多模态、262K 原生上下文，权重以 Apache 2.0 协议开放，免费下载、部署、商用都不设限。微博
发布才一周多，知乎上已经出现了把它叫作新「模型斩杀线」的讨论——一个只有 27B 参数、可以被个人拥有并本地运行的开放权重模型，第一次真正摸到了前沿闭源模型的能力区间。知乎Artificial Analysis 的 Intelligence Index 给了它 52 分，与 GPT-5.6 Luna、DeepSeek V4 Flash 同分，只比 GLM-5.2 低一分。微博
分数够看、协议够松、一张消费级显卡就能装下——于是本周所有人都想把这 27B 塞进自己的机器，速度战就是这么打起来的。
为什么速度战绕开了 LM Studio
LM Studio 的定位，一直是本地大模型的「机顶盒」：下载模型、选量化、开服务，全在图形界面里点几下完成，让不懂命令行的人也能在自己电脑上跑起开源大模型。小红书上已经有人把它做成零基础教程，手把手教从零开始在本地跑开源大模型。小红书但机顶盒也有代价：引擎层的每一项新能力，都要等界面跟上才能用上。本周三个最要紧的提速手段——DFlash2 投机解码、MTP 多令牌预测、新一代量化与显存调优——入口全都在命令行的 llama.cpp 里。
先说最猛的 DFlash2。它的草稿模型，是社区随 Qwen3.8-27B 发布迅速推出的专用投机解码模型。小红书进入 llama.cpp 主线（PR #27342）后，斌叔在单张 RTX 4090 上做了严格 A/B：150k 上下文、Q4_0 KV 缓存下，Native MTP 解码 66.85 t/s，DFlash2 跑到 77.44 t/s，快 16%；草稿器参数调到 n-max 4，还能逼近 80 t/s，代价是上下文缩到 120k。微博
不过 DFlash2 不是免费的：预填充速度从 MTP 的约 2360 t/s 掉到约 1750 t/s；多卡张量切分和多模态目前都是坏的——用原帖的话说，目前仅适用于单 GPU 猛男。微博
那 MTP 是不是一无是处？也不是。同一位跑 V100S 的用户发现，开 MTP 能从 30 tok/s 提到 40+。微博但斌叔的建议恰恰相反：长生成、Agent 工作流，DFlash2 的解码速度绝对碾压 MTP。微博两边其实都对：MTP 是零折腾就能拿到的提速，DFlash2 是拿折腾去换上限。
第三个提速点藏在量化与参数里。新版 Unsloth 动态 v3 GGUF 发布后，相同磁盘大小下精度还能再高 10%。微博再叠加 Q8_K_XL 这类新量化、KV 缓存量化，以及直接决定上下文上限的 --spec-draft-n-max 参数——这些开关，目前都只有命令行版本。
还有一个容易被忽略的变化：llama.cpp 已经支持 Response API，能把本地模型直接配置成 Codex 的后端，有用户实测接入之后居然真的能用，还能拖图片进去识图。微博
也要说清楚一点：本周社区里没有人做过 LM Studio 与最新版 llama.cpp 的同机严格 A/B，「绕开」的判断来自机制——本周所有提速特性，都只在上游命令行工具里可用。LM Studio 跟进上游向来不慢，这个差距随时可能被下一次更新抹平。
谁留谁换
先说留。聊天、写作、翻译、偶尔多模态，仍然是 LM Studio 的舒适区，界面开箱即用。小显存用户更不必急着折腾：4 位量化后的 Qwen3.8-27B，仍能保留 FP16 原版 95.59% 的能力。知乎
再说换。两类人建议尽早转命令行：一是把本地模型接进 Codex 这类编程 Agent、要跑长上下文的；二是手握 24G 显存、想要 80 t/s 档体验的——按斌叔的说法，这是用几毫秒的预填充，换 27B 前沿模型上持续 81 t/s 的输出。微博
服务器方向也有现成方案：DFlash2 不是 llama.cpp 的专利，vLLM 和 SGLang 都有实现。知乎上已经有一场 8 卡 RTX3090 服务器上的可复跑对比：同一份 Qwen3.8-27B 权重，一侧 vLLM，一侧 SGLang+DFlash2。知乎作者把结论直接写进了标题：对 Qwen3.8-27B 的加速是 4~5 倍量级。小红书上还有一张同条件对比图：同一张 RTX PRO 6000 96GB、同一个 FP8 权重、同样 262K 上下文，三组并发负载下，SGLang 一侧的平均吞吐全部领先。小红书
最后是观望党：不想折腾的，可以等 LM Studio 跟进上游。GGUF 是通用格式，现在下载好的模型不会白下——界面哪天跟上，哪天再切回去也不迟。
最低成本路径
如果决定动手，成本可以压到很低：GGUF 格式通用，LM Studio 下载好的模型文件，llama.cpp 直接就能读取，不用重新下载几十个 GB。稳妥的做法是先装官方预编译包，让 llama-server 和 LM Studio 并行跑几天，确认命令行真的更快、自己真的用得上，再决定下一步。
确定要上 DFlash2 的，需要自己编译 llama.cpp 的 PR 分支。斌叔把 n-max 3 叫作「黄金比率」：释放的显存正好够匹配 MTP 的上下文限制，速度上又彻底压过 MTP。微博下面是他在单张 RTX 4090 上给出的 150k 上下文启动命令：
```
llama-server -m Qwen3.8-27B-UD-Q4_K_XL.gguf -md Qwen3.8-27B-DFlash2-Q4_K_M.gguf --spec-type draft-dflash --spec-draft-n-max 3 -c 150000 -ngl 99 --port 8080 -ctv q4_0 -ctk q4_0
```
最后，三条降温提醒。第一，本文引用的速度全部来自个人实测，显卡、系统、量化、上下文各不相同，照抄数字之前，先对照自己的硬件档位。第二，DFlash2 刚进主线，多卡和多模态还是坏的，上游迭代飞快，今天的参数很快可能过时，今天的坑也可能下周就被填上。第三，Qwen3.8 的官方聊天模板还在被吐槽「无法关闭思考」「工具调用导致崩溃」，社区已经流传一个 Jinja2 修复模板，接编程 Agent 之前，建议先把它找来看看。微博模型越跑越容易，但工具层的门槛，正在悄悄拉开人与人的差距——这大概是本周本地大模型圈最真实的写照。
