• 大模型
• 模型量化
• 本地部署

🚀Qwen3.6-35B-A3B-w4a16-llmcompressor是 AMD 官方发布的Qwen3.6-35B-A3B 4-bit 权重量化模型（W4A16），基于 LLM Compressor（GPTQ 算法）完成量化，专为AMD EPYC CPU 推理优化。本篇生产部署指南帮你快速搞定版本依赖、vLLM 推理启动、局限性避坑，并给出一条可落地的量化模型优化路线图。

一、5 分钟读懂：这个量化模型是什么

它是对开源模型 Qwen3.6-35B-A3B（MoE 架构，35B 总参数、激活 3B）做的INT4 Weight-Only 量化版本，核心收益一目了然：

一句话理解W4A16：权重（Weight）用 4-bit 整数存储，激活（Activation）保持 16-bit（BF16）计算。内存占用大幅下降，计算精度损失极小——这正是"以约 0.4% 的基准分换取近 3 倍内存压缩"的性价比方案。

二、版本依赖清单：先对齐这 5 个组件再动手

⚠️ 这个模型有硬性版本锁，生产环境必须按 README.md 中的清单逐项对齐，任何一个版本漂移都可能导致模型加载失败：

推荐用固定版本的依赖文件一次性安装：

torch==2.13.0.0 zentorch==2.13.0.0 vllm==0.28.0 llmcompressor==0.12.0

两个性能关键设置（新手最常漏掉）：

1. OpenMP 预加载：启动 vLLM 前先设置LD_PRELOAD指向 LLVM OpenMP 的libomp.so或 Intel 的libiomp5.so：

export LD_PRELOAD=$(find /path/to/env -name "libomp.so" | head -1)

2. NUMA 绑核：大内存带宽是 CPU 推理的命脉，参考 README 中的做法用numactl将进程绑定到指定 NUMA 节点（如numactl --physcpubind=0-95），避免跨节点访存拖慢吞吐。

三、生产部署三步走：从下载到第一行输出

第 1 步：获取模型仓库

git clone https://gitcode.com/hf_mirrors/amd/Qwen3.6-35B-A3B-w4a16-llmcompressor

核心权重文件是 model.safetensors（约 18.1 GiB），下载请预留充足磁盘与带宽。

第 2 步：安装上述锁定版本的依赖（见第二节清单）。

第 3 步：用 vLLM 加载，几行代码出结果

from vllm import LLM, SamplingParams model = LLM(model="<本地模型路径>", dtype="bfloat16") params = SamplingParams(temperature=0.7, max_tokens=256) print(model.generate(["你好，介绍一下你自己"], params)[0].outputs[0].text)

✅ 生产建议：dtype保持bfloat16；用 vLLM 的 OpenAI 兼容服务方式对外暴露 API，配合max_model_len按业务实际上下文长度调优（模型理论支持 262144 上下文，但 CPU 场景下 KV cache 内存要按实际长度核算）。

四、量化参数速览：config.json 里藏着什么

打开 config.json 中的quantization_config字段，可以读懂这份模型的"量化身份证"：

• 量化格式：compressed-tensors，quant_method标记为 compressed，状态compressed
• 权重：INT4、对称量化（symmetric=true）、group_size=128、actorder=static、存储格式pack-quantized
• 激活：BF16，不做激活量化（即 input/output activations 均为 null）

哪些模块被刻意"免量化"保留为 BF16？这是本模型精度几乎无损的关键设计（完整 ignore 列表见 config.json 与量化配方 recipe.yaml）：

而 256 个路由专家、共享专家与线性注意力投影全部量化，因此整体压缩率接近 INT4 理论上限的 75%。量化配方本身非常精简——GPTQModifier、targets 为 Linear、scheme 为 W4A16、block_size 128、dampening_frac 0.01，可直接参考 recipe.yaml。

五、局限性详解：这 5 个坑先知道再上线

📌 来自 README.md 的官方限制，逐条对照你的业务场景：

1. 版本锁（Version Lock）：仅兼容 ZenDNN v6.1.0 / ZenTorch v2.13.0.0 / PyTorch v2.13.0.0 组合，其他版本可能无法正确加载。升级框架前必须重新验证。
2. CPU Only：专为 AMD EPYC 通过 ZenDNN 优化，不适用于 GPU 推理。如果你的集群是 GPU 为主，请改用原版 BF16 模型或 GPU 向的量化格式。
3. 视觉路径未量化：视觉塔保持 BF16，图像预处理开销不变，内存节省完全来自语言模型部分。官方评测也以language_model_only=True方式进行。
4. 推理（Reasoning）模型行为：Qwen3.6 默认会输出 thinking 思考链，评测或严格控时长的业务场景建议关闭思考模式（enable_thinking=False）并放宽max_gen_toks，否则答案抽取会与基线不可比。采样默认参数见 generation_config.json（temperature=1.0、top_k=20、top_p=0.95）。
5. 精度权衡：4-bit 比 INT8 更激进，用少量精度换取约 73% 的内存压缩。对精度极其敏感的业务（医疗、金融合规）建议做内部基准回归测试后再上线。

六、量化模型优化路线图：从 W4A16 到下一站

结合本仓库的配方与配置文件，给出一条可执行的演进路线：

阶段 1：稳定上线（当前模型直接部署）

• 按第二、三节完成部署与压测，记录基线：吞吐、TTFT、显存/内存占用、GSM8K 分数。

阶段 2：校准数据与配方调优

• 本模型用 128 条 ultrachat_200k 样本、最大 2048 长度校准。若你的业务语料分布特殊（如代码、长文档），可参考 README 中的量化脚本，用自己的数据重跑 GPTQ 校准，通常能进一步收窄精度差距。
• 调参入口就是 recipe.yaml：block_size（分组大小）、dampening_frac（阻尼系数）、actorder是最值得实验的三个旋钮。

阶段 3：混合精度策略

• 学习本模型"路由器/视觉塔免量化"的思路：对自己模型做逐层敏感度分析，把最敏感的少数层保留 BF16 或升为 INT8，其余层维持 INT4，在内存与精度间再挤一点空间。

阶段 4：KV Cache 量化

• 当前kv_cache_scheme为 null（见 config.json），KV cache 仍以 BF16 存储——CPU 场景下长上下文的内存大头。关注 LLM Compressor 对 KV cache 量化的支持进度，是下一轮内存优化的最大增量。

阶段 5：持续评测闭环

• 用 lm-evaluation-harness（vLLM 引擎）固化评测流水线（README 中给出了完整lm_eval命令模板），每次版本升级或配方改动后回归 GSM8K 等任务，保证优化"看得见、可回滚"。

七、仓库文件导读

结语

Qwen3.6-35B-A3B-w4a16-llmcompressor证明了在 AMD EPYC 纯 CPU 环境下，35B 级 MoE 模型借助W4A16 量化 + ZenDNN也能以 18.1 GiB 的内存代价跑出 99.61% 的基准恢复率。只要守住版本锁、避开 GPU 误用、理解免量化设计，你就能把它稳稳地跑进生产；而沿着校准调优 → 混合精度 → KV cache 量化的路线图，还有明确的下一站可以走。

• 大模型
• 模型量化
• 本地部署