Qwen4预演开源：最小量化仍装不下

Qwen3.8-Flash-Next 开放权重后，最抓眼的数字不是125B，而是每个 token 只激活6B。这听起来像一台大机器每次只开几盏灯，似乎终于能塞进个人电脑。

可文件 API 给出的结果很直接：131个 BF16 分片合计360,000,192,888 bytes，十进制是360.00GB，二进制是335.28GiB。

网上常见的“335GB”并非另一套权重，而是把 GiB 写成了 GB。两种口径描述的是同一批文件，差别来自十进制和二进制换算。容量单位写错，看着只差几个字母，落到硬盘上却能把部署判断带偏。

体积其实能对上参数拆分：125B主模型按 BF16 计算约250GB，51B N-gram embedding 约102GB，4B MTP 约8GB，加起来正好约360GB。这里没有玄学，只有一笔朴素的存储账。激活参数决定一次计算有多重，存储参数决定整台机器要背多少行李。

当年 LLaMA 权重外流后，量化、微调和端侧运行工具很快长成一套生态。它证明开放权重能加速能力下沉，却没有证明任何大模型都能立刻住进普通电脑。Qwen这次主动把架构摊开了，区别在于：生态可以飞快补齐，物理内存不会因为社区热情自动扩容。

这不是给旧架构简单加码，而是一台提前驶出实验室的 Qwen4 预览车。

配置中的 model_type 是 qwen4_exp，主体采用多模态 MoE：共有48层、512个 routed experts，每个 token 选择10个，另有 shared expert。它把庞大容量放在后台，只调动眼前需要的一小部分。

注意力层也不是整齐复制。每四层包含3个 linear/GDN attention 和1个 full/QSA attention。

Gated DeltaNet 负责压缩历史，Qwen Sparse Attention 再用轻量 indexer 按 micro-block 挑出重要上下文。目标很明确：长上下文不能再靠所有 token 两两照面，否则成本迟早把自己拖住。

另一处大动作是 N-gram Embedding。它根据局部 bigram 和 trigram 查询20,000,000项表，词表本身有248,320项，并被放在第2层。

官方设计允许把这张大表留在 host memory，再用异步预取覆盖部分等待时间。这个思路能减轻显存压力，却不会消除系统内存对它的容纳责任。

Gated Residual 把残差流扩成4个分支，由动态门控制读写；优化侧则让 Muon 与 AdamW 分工，并重新拟合 scaling law。

原生上下文达到262,144 tokens，模型卡还给出扩展到1,000,000 tokens的路径。方向非常清楚：它瞄准的是长程智能体、办公流程与多模态交互，不只是聊天框里多答几道题。Qwen4预演的重点，是重新分配计算，不是缩小存储。

当前最小 GGUF 是 UD-IQ1_S，分成3个文件：10,946,624 bytes、49,990,818,368 bytes 和22,544,696,352 bytes。

合计72,546,461,344 bytes，也就是72.55GB或67.56GiB。它已经是现有最小档，普通 IQ2、Q2、Q3、Q4只会更大。

按约180B存储参数计算，这个版本平均只有约3.22 bit/参数，仍然没能压进64GB。原因并不神秘：Dynamic quant 会给敏感张量保留更高精度，51B N-gram表、24.8万词表和非均匀量化张量也都要占地方。IQ1_S 是量化档位名称，不等于整包所有参数都使用同一位宽。

※ 容量边界来自当前文件体积与运行指南；速度尚无本机结果。

这张表真正想拦住的是一种常见误判：文件能被 mmap，不等于它适合日常运行。64GB机器即便在框架完善后通过磁盘 offload 启动，SSD仍可能持续换页；512个专家的访问又会放大等待。能亮起启动界面，和能稳定干活，是两件完全不同的事。

把大模型塞进个人电脑，本来就是量化技术与推理框架共同推动的结果。几十亿参数级别从极客玩具变成日常选项后，云端订阅的定价权才开始松动。可这条曲线并非只会向下：模型一旦把更多容量换成专家、长上下文和多模态，个人设备又会重新撞上内存墙。64GB不是不能折腾，而是不值得把折腾当生产力。

文件已经上传，运行链路却出现了明显的时间差。Qwen README 写着 llama.cpp 已支持文本与视觉；同一天，llama.cpp 上游的支持问题单仍保持开放，编号是#27741，评论数为0。Unsloth 的指南也标着 WIP 和 Coming very soon，并指向特定 PR。

这不等于谁说错了，更像是不同层级的“支持”被挤在同一个词里。仓库可以识别文件，实验分支可以读入架构，稳定版却未必已经合并并覆盖文本、视觉、量化和 offload。格式识别只是拿到了门票，稳定运行才算真正进场。

MLX路线同样要克制判断。当前 mlx-community 没有对应转换仓，MLX-LM main 的模型目录也没有 qwen4_exp 或 qwen4 实现。

准确说法只能是“当前尚未就绪”，不能永久判定为不支持。Transformers、SGLang、vLLM和TokenSpeed虽有启动命令，主要面向多卡或服务器，并不会让消费级内存突然够用。

早期工厂曾各自建设发电机组，统一电网成熟后，电力逐渐变成按需购买的公共能力。模型正在出现相似分工：大容量能力集中在云端，小容量能力留在个人设备。不同之处在于数据和上下文不是普通电流，有些工作一旦送上云，省下的是内存，交出去的却是控制权。

官方成绩最亮眼的是 JobBench：55.7，对照 Qwen3.8-27B 的33.4、DeepSeek-V4-Flash 的41.3和Claude Opus 4.6的36.6。

CoWorkBench 也达到73.9，高于27B的70.7、DeepSeek的45.1和Claude的68.2。长程任务与办公协作，确实是它最有含金量的区域。

但编码成绩并没有整齐排成一场碾压。DeepSWE 1.1是58.7，27B为42.2，DeepSeek为54.4；到了SWE-bench Pro，它的62.5只比27B的61.7高0.8。NL2Repo-Bench甚至只有48.1，低于DeepSeek的54.2。这些反例比“全面更强”四个字更有用。

多模态与电脑操作也呈现同样边界。OSWorld 2.0 binary 是19.4，与27B完全相同；partial 则从48.0升至52.3。Vision2Web 为64.0，对照27B的62.9，提升有限。它更像把能力集中投向特定工作流，而不是每个维度都突然跌落凡间一个神仙。

古德哈特定律提醒得很准：指标一旦变成目标，人们就会优化指标，而不再专注它原本衡量的东西。这里不能只盯最高分，更要看优势是否跨任务稳定。落回实际选择，JobBench的大幅领先值得重视，NL2Repo的落后同样不能藏到脚注里。榜单最诚实的部分，往往是那些没有一起上涨的分数。

64GB Mac用户现在最省时间的选择，是继续使用Qwen3.8-27B。需要更大能力时先走QwenCloud或QwenWork，本地端等待正式运行支持和真实速度数据。眼下下载72.55GB最小量化，只会先消耗硬盘、带宽和排错时间，得到的未必是能长期工作的工具。

96GB是当前指南给出的推荐起点，但只适合最小量化，还要主动限制上下文，为KV cache和系统预留空间。128GB更从容，可以考虑更高精度或更大上下文，仍然不能提前承诺速度。12GB显卡也别只看显存判死刑：如果Linux主机拥有80GB以上系统内存，仍可评估部分offload。

谁会从这种架构中受益？云端服务可以承接本地装不下的大容量能力，硬件厂商则迎来更强的内存需求。谁承担代价？抢首发的用户要付出下载、调试、换页和等待成本。沉默的一方恰恰是现有订阅服务：它们没有动机主动提醒你，哪些任务其实留在27B上已经够用。

短期内，普通GGUF量化很难扭转64GB结论，因为IQ1_S已经是现有最小档。真正可能改变边界的，是官方QAT或三值版本、专门处理N-gram表的低比特方案、经过校准的专家剪枝、同架构小杯，以及更成熟的异步预取和专家调度。每一条都需要真实结果，不能先把愿望写成兼容性。

本地运行从极客玩具变成日常选项后，服务方的定价权确实会松动；但这次更像一道重新划线的题。小模型留在个人电脑，大容量能力按需调用，隐私敏感任务尽量不出门。开源把选择权交回来了，却没有承诺每台机器都能免费吞下全部野心。真正省钱的部署，不是勉强启动，而是每天都愿意用。