北京
当每个组件都健康、每个版本都是最新的，但系统仍然无法工作时，你会遇到一种特殊的死胡同。谷歌发布的Gemma 4 E2B QAT量化检查点，在vLLM TPU服务栈上就是这种情况——检查点和加载器对文件内容的理解不一致。
两个变体以不同方式拒绝加载：-qat-w4a16-ct报错称压缩张量方案在JAX路径中不受支持；-qat-q4_0-unquantized则因权重未从检查点初始化而失败，具体是上层KV共享层的k_norm权重缺失。这不是配置问题，没有额外的标志位可以解决。
QAT不是压缩，后缀也不是装饰
量化感知训练（QAT）是在训练过程中模拟量化，而非事后压缩成品模型。int4权重不是bf16模型的事后近似——模型在训练时就已知晓将以这种方式存储。这就是为什么QAT int4检查点能保持质量，而简单四舍五入到int4则不能。
后缀不可互换。-q4_0-unquantized是已反量化的QAT检查点，以10.21 GB bf16而非3.52 GB int4形式分发，携带QAT训练值。在这款硬件上它更快——10.1对8.1 tok/s——因为无需实时解包int4。
32 GB内存的适配问题
128K token的fp8 KV缓存占用2.40 GB。在v6e芯片上，两个变体都轻松容纳，应选择更快的那个；-q4_0-unquantized仍留有约七个128K上下文的余量。但在16 GB的v5e芯片上，情况反转：bf16变体仅剩约3.0 GB，勉强容纳一个128K上下文且无批处理空间，int4变体成为唯一合理选择。
作者最终选择自行编写加载路径。这个死胡同的教训是：当供应商的检查点和加载器互相矛盾时，等待上游修复、改用未量化模型，或自己动手写加载代码——没有第四条路。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
