第 15 节 · 本地模型升级实录：Qwen3.8-27B 当日常主力¶
前面讲过把 284B 塞进 48GB Mac——那是"本地最多能跑多大"的上限验证：2-bit 量化对中文指令遵循有明显损伤，几 token/s 的速度也离"流畅干活"还有距离。
所以"本地能不能跑"和"本地能不能天天用"是两个问题。这一节解决的，是后者。
答案是 Qwen3.8-27B。这不是评测，是"我真的把日常模型换了"的过程记录——含三档路由升级、量化档位取舍，以及带口径的实测数据。所有数字都是这台 M4 Max 上真实跑的，口径一个个标清楚。
先说升级前的痛点¶
我之前本地主力是 Qwen3.5 的 2B/4B 小档。快是真快，省电是真省电，但一到复杂推理和写代码就开始露怯——要么想半天答不到点上，要么干脆答不上来。
痛点很明确：想要"够聪明"的本地主力，小档不够用；而当时路由层还是纯文本，接不了多模态，换 27B 得先打通这层。
三档架构：按用途分，不搞一锅炖¶
现在我的本地是四件套（OCR 是独立服务）：
- fast 档：Qwen3.8-9B Q4_K_M，文件约 5.5GB，纯文本，负责快速响应、简单推理
- reason 档：Qwen3.8-27B，文件约 12GB，纯文本，负责复杂推理、写代码
- vision 档：Qwen3.8-27B（MLX 引擎），文件约 17.3GB、默认 context 下约 18GB，带视觉，负责看图
- OCR：RapidOCR（PaddleOCR-ONNX），单独服务，读教材、题页
三档同驻的规划账本约 24GB（前提：reason 档把 context 压到 8192），48GB 富余一半——实际吃多少看下面的实测表，关键变量是 context 窗口。
量化档位怎么选？reason 档用 Q3_K_XL（文件约 12GB）：27B 的 Q4 文件会到 15GB 以上（这是文件大小，不是运行时内存），三档同驻就紧张；Q3 的推理损失比 Q2 小得多，是"够用且好用"的平衡点。vision 档带视觉、走 MLX 引擎，用 nvfp4（默认 context 下约 18GB）——三档最贵，但只有它看得见图。
图 B-15-1（待出）：三档同驻的本地模型——快答、推理、看图各一档，外加一个独立的 OCR 服务
升级实录：最反直觉的一个发现¶
这次升级的核心是路由层：原来只做纯文本转发的 router，要升级成三档路由 + 视觉透传 + 剥思考段。
先说"剥思考段"是什么。这三个档位都是"思考型"变体，模型回答前会先吐一大段内心戏（thinking），然后才给正答。对用户来说，这些思考过程不该被展示，得剥掉。
我原以为这很麻烦：流式传输时，得先把思考段攒着，等它结束才能把后面的正文透传出去——这会拖慢首字响应。
结果实测发现完全不是这样：ollama 的 OpenAI 兼容接口，原生就把思考段单独放进了一个独立字段，正文本身是干净的。 router 要做的，只是把那个字段删掉。
翻译成人话：我预期要"等它把话说完再传"，实际上它早就把"心里话"和"说出口的话"分开了，我直接丢掉心里话就行。不用缓冲，首字速度零影响。
这个发现，让整个升级从"要动流式架构"，变成了"改几行配置"。
代码审查修掉两个 P1 级问题（日志崩溃路径、流式死锁），P0 是零。路由脚本净增 239 行、删 76 行，本地三档全部验证通过；旧配置不改也不会挂，未知模型自动退化成快档。
实测：内存、速度，都带口径说¶
内存（必须带 context 口径）：很多人看本地模型内存只看模型文件大小，其实 context 窗口才是大头。
| 档位 | ctx 8192 | ctx 262144（默认） |
|---|---|---|
| fast 9B | 6.2GB | 15GB |
| reason 27B | 13GB | 31GB |
| vision 27B | — | 18GB |
看 reason 档：默认 context 下要 31GB，把窗口调到 8192 只要 13GB。所以写内存数字必须带 context，否则就是误导。
速度（warm 解码）：fast 69.5 token/s，reason 17.7，vision 53.8。有意思的是，vision 档和 reason 档同为 27B，但 vision 走 MLX 引擎，解码速度是 reason 档 GGUF 的 3 倍——引擎差异比档位差异还大。
冷启动（含加载）：fast 1.7 秒，reason 4.5 秒，vision 1.5 秒。
图 B-15-2（待出）：同一个 27B，为什么内存差这么多——context 窗口调到 8192 和放到默认，内存从 13GB 涨到 31GB
9B 和 27B 差在哪：只留结论，不留数字¶
我们还做过一组对照：同一组任务，9B 和 27B 各跑一遍，比端到端谁更快。
这里必须坦白一件事：这一组对照当时没有留下原始记录。 它是手工看着交互界面一项项记下来的，没有落成可复核的数据文件，所以这一节不把那套逐项数字再抄一遍——只写当时确认下来的结论：
- 27B 的解码速度大约只有 9B 的四分之一。这一条和上面的 warm 解码表对得上（9B 69.5、27B 17.7 token/s），是有据可查的。
- 但硬任务上，把"干活的总时间"一起算，27B 反而更利索。原因不难理解：9B 把大量时间烧在"想"上，27B 想得短、给得直接。这一条只是当时的观察，没留下可复核的原始数据，请当结论看、不要当数字看。
- 9B 的"快"只在一类任务上成立：结构化短任务（比如按格式吐一段 JSON）确实快。换成开放式任务，它可能把预算全烧在思考里、正文出不来——这是一次实测里真出现过的翻车，不是假设。
- 两个档位给出的答案，正确性上没有差别；差别在"话多话少"和端到端延迟，不在对错。
一句话：9B 适合快问快答，27B 才适合真干活。
日常结论¶
现在的分工：快问快答、简单结构化任务走 fast 档；写代码、复杂推理、需要动脑的都走 reason 档；看图走 vision 档。
27B 当复杂推理/代码主力，答案质量和 9B 一样对，但话少、端到端快，体验反而更好。
"能力核心可以住进本地"这条路已经通了。但天天干活，我选 27B——27B 是给今天的，够用就是好用。
这套升级本身也是可复制的：三档路由 + 视觉透传 + 剥思考段，没有一步依赖特殊硬件。它落在这本书讲的"基座层"上——地基铺稳了，上面那些交给 AI 干的活才接得住。