8月14日深夜，千问官方宣布「今天，我们正式开源Qwen3.8系列模型，所有开发者、科研机构和企业均可自由下载、部署和使用Qwen3.8模型」。小红书Mac圈几乎是连夜开跑。
有Mac mini用户直呼「17GB显存就能本地部署——翻译一下：你不用再给云厂商交token税了」。小红书有人在M4上实测nvfp4 4bit量化、Ollama的MLX后端加MTP。哔哩哔哩64GB的M2 Max用户用Ollama里的qwen3.8:27b-mlx跑通，模型文件大约18GB。知乎从8月15日那个周末开始，各平台的实测帖一直刷屏到今天。
这波冲得不无理由，社区实测对这批分给得很高：「实测这波qwen3.8-27b难得没有刷分，确实担当得起opus4.6水平」。知乎官方放出的基准表里，Qwen3.8-27B被直接拉去和Qwen3.6-27B、Qwen3.7-Plus、Muse Glimmer-30B、Opus 4.6 Max同场对比Coding、Agent和通用能力。
工程党已经卷到下一层：有人用MLX加FastAPI搭了一整套含KV Cache和RAG的本地服务，开始讨论「混合注意力架构下为什么不能直接套传统KVCache公式」。知乎
而就在大家忙着往Mac里塞模型的这周，8月18日，MLX团队推送了v0.32.1，8月19日mlx-lm主分支紧跟着把依赖升到0.32.1。GitHub我把四十多条changelog逐条翻了一遍，其中差不多一半，直接冲着这周在Mac上部署大模型的人来的。帮你分好类：哪些必须关心，哪些和你没关系，哪些功能先别指望。
和你最相关的一件事：nvfp4的正确性bug修了
这周部署Qwen3.8-27B的人，十有八九用的是4bit量化，nvfp4正是这波的主流格式，Ollama模型库里qwen3.8:27b-nvfp4、qwen3.8:27b-mlx这些标签一字排开。Ollama0.32.1修掉了一个正确性bug：nvfp4的quantized_matmul在split-K路径下计算结果有误。GitHub正确性bug和性能问题不是一回事，不是跑得慢，而是结果可能不对。如果你这几天跑nvfp4量化模型觉得输出哪里怪，升级后值得重跑一遍。
还有两个nvfp4的性能项，都是给M5的：NVFP4 scales改成每16个lane一组计算，以及M5 Max上的大规模NVFP4 QMV专项优化。GitHub看这名字，基本是把「M5 Max跑4bit大模型」这个用例写在了脸上。
M5用户：NAX内核路径终于补起来了
MLX里有一批面向M5代芯片的内核路径叫NAX，相关PR的标题里常常直接标着M5。这条路径8月上旬在集中补课：NAX GEMM空输出组的问题8月11日修掉。GitHub非转置的NAX qmm在8月12日修复并启用。GitHub0.32.1又带了两条：NAX attention的Q@K.T循环展开优化，以及配置编译时如果禁用了NAX内核会给出警告。GitHub翻译一下：你手里是M5、M5 Pro或者M5 Max，这次更新基本就是为你准备的。
两个能感觉到的小提升
一个是新增的gemv_wide内核，优化fp16/bf16的少行矩阵乘。GitHub推理解码本质上就是连续的少行矩阵乘，这种底层内核的改进，攒起来就是能感觉到的提速。
另一个是零拷贝CPU导入：mx.array(host_buffer, copy=False)在统一内存上直接生效，不再搬一次数据。GitHub在本地做RAG、做数据预处理的人，这才叫真吃上了统一内存的红利。
mlx-lm那边：修了个安静的bug，还有两个坏消息
先说好消息：8月18日mlx-lm合入修复，解决了Qwen3.6转换模型RMSNorm被双重shift的问题。GitHub对应PR的标题说得更直白：「Fix silent Qwen3.5/3.6 corruption from double RMSNorm shift」——安静的损坏。GitHub不报错、不崩溃，就是输出质量悄悄变差。如果你前阵子自己转换过Qwen模型，觉得输出有点不对劲，多半就是它。
坏消息之一：PyPI上mlx-lm的最新版本还停在4月22日的0.31.3。PyPI换句话说，pip install mlx-lm装到的是四个月前的版本，这周的修复一个都不包含。想吃上修复，得从GitHub主分支安装。
坏消息之二：MTP。Qwen3.8-27B自带MTP（多token预测）头，Ollama连qwen3.8:27b-mtp-q4、mtp-q8标签都上架了。Ollama但mlx-lm这边，原生MTP的参考实现还是个open状态的issue。GitHub后续几个实现PR也都没合，还有一个DeltaNet投机解码PR在8月14日直接关闭未合并。所以要是有人跟你说「MLX已经支持MTP、速度翻倍」，记得把这句话打个折：Ollama那边可以先尝鲜，mlx-lm原生还得再等等。
所以，该不该升级
我的判断：
正在跑nvfp4、4bit的27B：升，正确性修复永远排第一；
M5、M5 Pro、M5 Max用户：升，NAX修复和NVFP4优化都是冲着你来的；
M1到M4的老机型：顺手升就行，不急，收益主要是小修小补；
等MTP的：别靠升级等它，等不到；急用先上Ollama的mtp标签；
安装方式：pip版本停在0.31.3，想吃修复就从GitHub主分支装。
还有两个提醒
其一，这周社区爆火的Qwen3.8-27B无审查版，属于社区衍生转换——「Qwen3.8才刚开源，社区已经开始整活了」，生态活力是真足。小红书但衍生版本的出处和质量要自己判断，别看见热就无脑冲。
其二，用mlx-lm的server模式长期跑服务的，注意目前有两个open的issue：一个是换模型时buffer pool内存不释放。GitHub另一个是批量服务时线程卡死、HTTP层还活着的隐形故障。GitHub定时重启是眼下的务实方案。
三个值得继续盯的信号
MTP相关PR什么时候合并，这决定下一轮「Mac跑27B速度纪录」能刷到哪；
mlx-lm什么时候发下一个PyPI版本，多数人不从源码装，版本号才是修复普及到大众的分水岭；
Ollama下一版把MLX引擎同步到哪，多数人是通过Ollama跑模型的，引擎同步速度决定这波改进实际落地多少。
Qwen3.8-27B给了MLX一个舞台，0.32.1是官方团队对这波热度的回应。对Mac本地推理玩家来说，本周最务实的动作就一个：升级，然后重新跑一遍你的速度测试，看看评论区里那些晒出来的数字，你能追上多少。
