企业官网建设流程全解析

Qwen3.5-35B-A3B_gpuep_1.0_gpu_128 是一套面向 AMD Ryzen AI 硬件优化的 ONNX 模型仓库,它采用INT4 RTN 量化 + Group 32 分组策略,把 35B 参数的 MoE 多模态模型压缩到约19GB,同时几乎不损失精度。本文将用尽量通俗的方式,拆解这套量化策略的原理、19GB 体积是怎么算出来的,以及部署时的关键配置。

一、先认识这个项目:一个"即插即用"的 ONNX 模型包 📦

这个仓库不是源码项目,而是一份可直接加载的推理模型文件集。它由 Olive 和 OGA Model Builder 构建,将基座模型 Qwen/Qwen3.5-35B-A3B 转换并量化为 ONNX 格式,优化后用于 AMD Ryzen AI 硬件部署。

仓库结构非常清晰:

💡 注意:.onnx与.onnx.data文件在仓库中是 Git LFS 指针,clone 后需通过 Git LFS 拉取实际模型数据。

二、量化策略一览:RTN + Group 32 + INT4 权重 ⚡

项目的 README.md 明确写明了量化方案:

下面逐个解释这些名词,不需要数学基础也能看懂。

RTN 量化是什么?

RTN(Round-To-Nearest,最近舍入)是最经典的权重量化算法:把每个 FP16 权重就近取整到 4 比特能表示的离散值上。

打个比方:FP16 权重像一把"无限刻度"的尺子,INT4 只保留 16 个刻度(2⁴ = 16 个可表示值)。RTN 做的事,就是让每个权重"站到离它最近的那个刻度上"。它的优点是简单、快速、无需训练,适合离线批量构建模型文件。

Group 32 分组:为什么这是"几乎不损失精度"的关键? 🔑

如果整层 10 万个权重共享一个缩放因子(scaler),层内少数几个"大值"权重会把量化范围拉得极大,普通权重的精度就会严重受损。

Group 32 的做法是:每 32 个权重为一组,每组独立计算缩放因子。就像把全班共用一个满分标准,改成每 32 人一组各自定满分——分数立刻贴合每个人的实际水平。

• 组越小,缩放越精细,精度越高;
• 但组越小,存储缩放因子的开销越大。

32 是一个被广泛验证的甜蜜点:精度接近 FP16,额外开销仅约几个百分点。本仓库对 MoE 专家权重同样采用 32 的分组大小(README.md),确保 256 个专家量化后依然稳定。

为什么 Vision 和 Embedding 不量化?

这是"选择性量化"的实用技巧:

• Embedding 层(词表 248320 × 隐藏维度 2048)直接决定每个词的"语义坐标",对精度极其敏感,量化后极易产生"答非所问";
• Vision 编码器参数量相对较小,保持 FP16 对总包体影响有限,却能保住图像理解能力。

把精度预算集中花在"最不怕压缩"的 MoE 主干上,是整体精度几乎不掉的核心工程决策。

三、19GB 是怎么算出来的?🧮

模型名义上是 35B 参数,但A3B 表示每次前向只激活约 3B 参数(MoE 结构,256 个专家中每 token 只选 8 个,见 config.json 的num_experts与num_experts_per_tok)。压缩体积按"全部参数都要存"来估算:

也就是说,相比 FP16 原版(约 70GB),这套 INT4 方案把体积压缩了约 3/4,轻松装进 32GB 内存 + 显存共享的 AI PC,还能留出空间放 KV Cache 和图像缓冲区。

四、为什么精度"几乎不损失"?🎯

1. MoE 稀疏激活天然抗量化:A3B 架构下每次推理只激活约 3B 参数,单 token 计算路径短、误差传播少,即使 INT4 引入微小舍入误差,也难以累积成明显的质量下降。
2. Group 32 精细缩放:如上所述,量化误差被限制在每组 32 个权重的小范围内。
3. FP16 激活:只有权重被压成 4 比特,前向计算的激活值仍是 FP16,避免了"权重、激活双重取整"带来的误差叠加。
4. 敏感层免压缩:Embedding 与 Vision 保留 FP16,保住了输入端的语义质量。

五、模型结构与部署配置解读 🚀

主干结构:线性注意力 + 全注意力混合

从 config.json 可以看到,文本主干共40 层(num_hidden_layers),其中每 4 层出现一次全注意力(full_attention_interval: 4,对应 config.json 与layer_types字段),其余使用线性注意力。配合 262144 的max_position_embeddings,长上下文推理的算力开销显著低于传统 Transformer——这也是它适合端侧硬件的重要原因之一。

两套推理配置,按需选择

部署到 AMD Ryzen AI 设备时,引擎会读取.dml版本,通过 DirectML 驱动走 GPU 加速;context_length设为 4096 是为了控制 KV Cache 内存占用,与端侧 16GB~32GB 内存匹配。

采样参数

generation_config.json 给出官方推荐采样参数:temperature: 1.0、top_k: 20、top_p: 0.95,适合日常对话与生成任务直接启用。

六、如何获取并使用模型文件?

在任意目录下执行:

git lfs install git clone https://gitcode.com/hf_mirrors/amd/Qwen3.5-35B-A3B_gpuep_1.0_gpu_128.git

拉取后,使用支持 onnxruntime-genai 的推理引擎(如 AMD 提供的 Ollama/DirectML 部署栈)指向该目录即可,无需任何训练或二次转换。

七、常见问题 FAQ ❓

Q1:为什么不是 17.5GB 而是约 19GB?INT4 只压了 35B 文本权重(17.5GB),但缩放因子、FP16 的 Embedding 与 Vision 部分仍要计入体积,合计约 19GB。

Q2:INT4 会不会让模型"变笨"?RTN + Group 32 是端侧部署中被验证最稳的组合之一;配合 MoE 稀疏激活与 FP16 激活,本方案在常规对话、代码、视觉问答任务上精度损失通常不可感知。若你的任务对数字计算或长文本推理极度敏感,可关注上游 FP8 版本。

Q3:能在 NVIDIA 显卡上跑吗?ONNX 模型与后端解耦,理论可用 CUDA EP 加载genai_config.json;但本仓库是AMD 优化构建(DML 配置、Ryzen AI 调优),在 AMD 平台上体验最佳。

Q4:Group size 能自己改成 64 或 128 吗?可以,组越大体积越小、速度越快,但精度风险上升。仓库当前以 32 作为精度/体积平衡点,不建议新手随意改动。

总结

🎯 Qwen3.5-35B-A3B_gpuep_1.0_gpu_128 的核心价值,是展示了一套教科书级的端侧量化工程实践:

• 用RTN以零训练成本完成 INT4 权重压缩;
• 用Group 32分组缩放把误差锁死在小范围内;
• 对MoE 稀疏结构做"精准压缩",对 Embedding/Vision "保护性不压";
• 最终35B 模型 → 约 19GB,FP16 原版体积的不到 30%,并直接给出 AMD 硬件的 DirectML 部署配置。

对于希望在 AI PC 上本地运行多模态大模型的新手,这份仓库既是一个开箱即用的模型包,也是一份理解"INT4 量化到底怎么做"的绝佳实例。