8月14日，Qwen3.8-27B 正式上架 Hugging Face 和 ModelScope，这是千问第一次把 Qwen-Max 级模型开放出来，Mac 圈随即开启了一轮本地部署竞速。GitHub没几天，实测帖就刷了屏：M4 Max 48GB 跑出 28 token/s，256K 上下文直接开满，数字相当好看。小红书
但往下翻一翻，画风就开始分化。M5 Max 128GB 的用户对 8bit 版本并不满意：8bit 生成速度大概 16 token/s，5bit 也就 22 token/s，“速度还是有点慢”。小红书另一位 Mac Studio 用户开了 oMLX 的 spec prefill 跑基准，预填充 TPS 从 290 一路冲到 1172，结果拿到真实代码会话里完全不触发，只能感叹"上次说 PP 没救，这次说 bench 在骗我，两句都是真的"。小红书
模型不行吗？不是。Mac 不行吗？也不全是。问题出在大家盯着看的 tok/s 只是一个维度的数字，而本地跑 27B 的体验至少有三个维度。这周密集的实测，恰好把三堵墙都撞了一遍，我们一堵一堵拆。
先搞清楚三个数字
本地大模型的"快不快"，其实由三个数字决定：
解码速度，也就是平时说的 tok/s，决定对话时文字往外蹦的速度；
预填充速度，模型"读"你喂进去的内容的速度，只在一次性塞入长文档、长历史时出现；
首 Token 时间（TTFT），从按下回车到看见第一个字要等多久，长文档需求几乎都死在这。
如果你拿它干 Agent 活（接 Claude Code 之类的编程工具），还要多看一个隐藏维度：前缀缓存命中率。主流跑分工具一般都会把解码（TG）、预填充（PP）、峰值内存并排列出来，看懂这几个指标，后面的实测数据就不容易把人带偏。
第一堵墙：上下文一长，解码速度就塌
本周最直观的一组数据，来自 M4 Max 128G 上的上下文深度扫描：Qwen3.8-27B 用 NVFP4 4bit 量化、Ollama + MLX 后端加 MTP 投机解码，短上下文解码 63.1 tok/s，4K-16K 稳在 42 上下，31K 断崖掉到 11.3，63K 只有 12.1；预填充同样从 246.6 一路掉到 89.9 tok/s。哔哩哔哩测试者自己的结论很克制：16K 以内常规问答放心用，过了线就要有心理准备。
原因不复杂：KV 缓存随上下文增长，注意力计算跟着涨，每生成一个 token 都要把这一整套读一遍，统一内存的带宽被越吃越多。所以"能开 256K"和"好用"是两回事，把 256K 开满还说好用的，前提是用途停留在轻聊天。
第二堵墙：长文档预填充，TTFT 要命
M5 Pro 48G 上的另一组实测：128K 上下文开满，预填充速度其实不慢，有 201 tok/s，但首 Token 等了整整 10 分 51 秒；推理峰值内存 42.24GB，约占 48GB 统一内存的 88%，系统开始换页。小红书测试者给的建议很实在：日常控制在 64K 以内，偶尔读超长文档前，先把浏览器和 IDE 关掉。
更扎心的是 spec prefill 这种"跑分好看"的加速。还是那位 Mac Studio 用户的数据：基准测试里，开了 spec prefill 之后，pp32768 的 TTFT 直接降 75%，预填充 TPS 从 290 冲到 1172。小红书可一旦换到真实的 Claude Code 40K 新会话，0.8B 草稿模型对真实代码 prompt 的接受率不够，加速压根不触发，首字照样等几分钟。
这就是第二个教训：跑分跑的场景，和你日常用的场景，往往不是同一个东西。
第三堵墙：Agent 的重复上下文，命中率才是命
Agent 用模型的方式和聊天不同：每次工具调用都是一个新请求，每个请求都要把完整上下文再发一遍——系统提示词、工具定义、历史对话，一个任务里同样的几万 token 会被反复读上几十次。这个场景下的体验，和平时看到的 tok/s 关系不大，由"重复的部分能不能被缓存"决定。
看前面那台 M4 Max 的编程实测：全程 59 次 LLM 请求，前缀缓存命中率 98.8%，每轮实际新增只有约 452 token，单请求中位 3 秒——但首轮冷启动用了 49.3 秒。哔哩哔哩同场景的对比数据更直观：同一个全栈项目生成任务，oMLX 约 47 tok/s，LM Studio 约 16 tok/s；前缀缓存命中时首 token 约 1.7 秒，对照场景要 49 秒。小红书
两家引擎在解同一道题。Ollama 6 月的 MLX 引擎更新，除了 NVFP4 量化（质量损失约为传统 q4_K_M 的一半）和约 20% 的提速，重点是新增 snapshot 系统，在分支、重试、响应生成前等关键节点保存模型状态，让多 Agent 协作、思考模型、重试改写都能从缓存接着跑。Ollama 官网目前已有 1.9 万 star 的 oMLX 则把 KV 缓存直接卸到 SSD，官方定位就是带持续批处理和 SSD 缓存的本地推理服务。GitHub两条路本质一样：Agent 时代，内存有限，缓存为王。
三类人，三种玩法
结合这周的实测，大致可以这么对号入座：
聊天党（问答、翻译、写文案）：Q4/4bit 就够，别迷信 8bit。同一台 M5 Max，8bit 只有 16 tok/s，换 4bit 打开 MTP，写代码直接冲到 70 tok/s。小红书
长文档党：48GB 机器老实控制在 64K 以内。128K 不是不能跑，代价是十分钟级的首字等待和内存红线，跑之前先清后台。
Agent/编程党：选运行时先看前缀缓存支持，再看 tok/s，使用中多盯命中率指标。注意 oMLX 的格式不兼容 GGUF/Ollama，第一次切换要重拉约 16GB 模型，别当即插即用。小红书
24GB 用户：评论区已经给出答案。Q4 权重约 15GB，加上 KV 缓存和系统开销，单开就吃掉 22GB，连微信都不敢多挂；有人换 Q3 换来了稳定，但上下文也只有 4K。这不是姿势问题，是物理问题。
顺带替对面阵营说一句：有评论直言"一个月前1w2配了台台式机显存24, 27b稠密模型速度秒杀苹果"，这是事实，同预算下独显的带宽优势明摆着。小红书但 Mac 这条路的另一半价值在别处：128GB 统一内存意味着模型能装得下大、整机安静省电、数据不出本机。你买的是"能跑大"，不是"跑得快"，预期摆正，心态就平了。
值得等的信号
Qwen3.8 的 MoE 版本。这周评论区"等 a3b"出现的频率很高，稀疏模型每个 token 只激活一小部分参数，对统一内存的带宽瓶颈天然友好，是 Mac 上最理想的剧本。
更完整的 MTP 支持。Qwen3.8 的多 token 预测对解码提速立竿见影，没 MTP 三十 token/秒，开了能翻倍。小红书但它目前依赖特定转换版本，比如 ddalcu 的 MLX-Serve 4bit，还不能随便拿个模型就用。
框架本身也在进化。MLX 0.32 已在 7 月初发布，Metal 侧继续打磨量化矩阵乘，CUDA 后端的支持也在持续推进——没错，这个苹果家的框架也准备去 NVIDIA 的主场看看。GitHub
Mac 跑 27B，已经过了问"能不能跑"的阶段，进入了要搞清楚"哪里慢"的阶段。聊天看 tok/s，长文档看 TTFT，Agent 看命中率，把这三个数字记牢，实测帖里的数字就骗不到你。至于等 a3b的那些人——一点都不用不好意思，MoE 本来就是统一内存的真爱。
