【免费下载链接】Qwen3.5-35B-A3B_gpuep_1.0_gpu_128项目地址https://ai.gitcode.com/hf_mirrors/amd/Qwen3.5-35B-A3B_gpuep_1.0_gpu_128点击查看免费下载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 硬件部署。仓库结构非常清晰:文件作用text.onnx text.onnx.data文本主干(Decoder),INT4 量化后的核心权重vision.onnx vision.onnx.data视觉编码器,保持FP16embedding.onnx embedding.onnx.data词嵌入层,保持FP16config.json模型结构配置(层数、专家数、上下文长度等)genai_config.jsononnxruntime-genai 推理配置(完整 262144 上下文)genai_config.json.dmlDirectML 专用配置(AMD 硬件部署用,上下文 4096)generation_config.json采样参数(temperature 1.0、top_k 20、top_p 0.95)chat_template.jinja对话模板(支持图像/视频占位符)processor_config.json图像预处理参数(patch_size 16、归一化等)tokenizer.json分词器(248320 词表) 注意:.onnx与.onnx.data文件在仓库中是 Git LFS 指针,clone 后需通过 Git LFS 拉取实际模型数据。二、量化策略一览:RTN Group 32 INT4 权重 ⚡项目的 README.md 明确写明了量化方案:组成部分量化方案说明文本权重(含 MoE 专家)INT4 权重 FP16 激活RTN 量化,分组大小 32MoE 专家权重INT4,group size 32256 个专家全部参与量化视觉编码器 VisionFP16不量化,保证图像理解精度词嵌入 EmbeddingFP16不量化,保护词表语义下面逐个解释这些名词,不需要数学基础也能看懂。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)。压缩体积按全部参数都要存来估算:组成部分估算说明35B 文本权重(INT4)≈ 17.5 GB4 bit 0.5 字节/参数,35B × 0.5B分组缩放因子(Group 32)≈ 1~2 GB每 32 个权重 1 个 scalerEmbedding(FP16)≈ 1.0 GB248320 × 2048 × 2 字节Vision 编码器(FP16)≈ 0.5 GB27 层视觉 Transformer合计≈ 19 GB对比 FP16 全精度约需 70 GB也就是说,相比 FP16 原版(约 70GB),这套 INT4 方案把体积压缩了约 3/4,轻松装进 32GB 内存 显存共享的 AI PC,还能留出空间放 KV Cache 和图像缓冲区。四、为什么精度几乎不损失?MoE 稀疏激活天然抗量化:A3B 架构下每次推理只激活约 3B 参数,单 token 计算路径短、误差传播少,即使 INT4 引入微小舍入误差,也难以累积成明显的质量下降。Group 32 精细缩放:如上所述,量化误差被限制在每组 32 个权重的小范围内。FP16 激活:只有权重被压成 4 比特,前向计算的激活值仍是 FP16,避免了权重、激活双重取整带来的误差叠加。敏感层免压缩:Embedding 与 Vision 保留 FP16,保住了输入端的语义质量。五、模型结构与部署配置解读 主干结构:线性注意力 全注意力混合从 config.json 可以看到,文本主干共40 层(num_hidden_layers),其中每 4 层出现一次全注意力(full_attention_interval: 4,对应 config.json 与layer_types字段),其余使用线性注意力。配合 262144 的max_position_embeddings,长上下文推理的算力开销显著低于传统 Transformer——这也是它适合端侧硬件的重要原因之一。两套推理配置,按需选择配置项genai_config.jsongenai_config.json.dml上下文长度2621444096推理后端通用(如 CUDA)DirectML(dml: {}),面向 AMD 硬件部署到 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 量化到底怎么做的绝佳实例。赞分享【免费下载链接】Qwen3.5-35B-A3B_gpuep_1.0_gpu_128项目地址https://ai.gitcode.com/hf_mirrors/amd/Qwen3.5-35B-A3B_gpuep_1.0_gpu_128点击查看免费下载相关推荐W8A8量化策略详解MiniMax-M2.7-w8a8-QuaRot如何将权重与激活压缩到int8且近乎无损W8A8量化策略详解MiniMax M2.7 w8a8 QuaRot如何将权重与激活压缩到int8且近乎无损 MiniMax M2.7 w8a8 QuaRo大模型基础模型模型量化AutoGPTQ模型压缩技巧如何将大模型缩小4倍而不损失精度想要在普通硬件上运行大语言模型AutoGPTQ正是你需要的解决方案 这个基于GPTQ算法的开源工具包能够将大模型压缩4倍同时保持原始精度让每个人都模型量化大模型模型优化VibeVoice-ASR-Streaming-7B-bf16 的 MLX 4-bit 量化完全指南:16.6GB 模型如何压到 5.7GB 且精度几乎无损VibeVoice ASR Streaming 7B bf16 的 MLX 4 bit 量化完全指南:16.6GB 模型如何压到 5.7GB 且精度几乎无损 V上一篇终极文档下载指南如何用kill-doc脚本轻松下载各大文库内容下一篇express-validator checkExact() 完全指南精确校验请求字段杜绝未知字段注入创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
【免费下载链接】Qwen3.5-35B-A3B_gpuep_1.0_gpu_128项目地址https://ai.gitcode.com/hf_mirrors/amd/Qwen3.5-35B-A3B_gpuep_1.0_gpu_128点击查看免费下载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 硬件部署。仓库结构非常清晰:文件作用text.onnx text.onnx.data文本主干(Decoder),INT4 量化后的核心权重vision.onnx vision.onnx.data视觉编码器,保持FP16embedding.onnx embedding.onnx.data词嵌入层,保持FP16config.json模型结构配置(层数、专家数、上下文长度等)genai_config.jsononnxruntime-genai 推理配置(完整 262144 上下文)genai_config.json.dmlDirectML 专用配置(AMD 硬件部署用,上下文 4096)generation_config.json采样参数(temperature 1.0、top_k 20、top_p 0.95)chat_template.jinja对话模板(支持图像/视频占位符)processor_config.json图像预处理参数(patch_size 16、归一化等)tokenizer.json分词器(248320 词表) 注意:.onnx与.onnx.data文件在仓库中是 Git LFS 指针,clone 后需通过 Git LFS 拉取实际模型数据。二、量化策略一览:RTN Group 32 INT4 权重 ⚡项目的 README.md 明确写明了量化方案:组成部分量化方案说明文本权重(含 MoE 专家)INT4 权重 FP16 激活RTN 量化,分组大小 32MoE 专家权重INT4,group size 32256 个专家全部参与量化视觉编码器 VisionFP16不量化,保证图像理解精度词嵌入 EmbeddingFP16不量化,保护词表语义下面逐个解释这些名词,不需要数学基础也能看懂。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)。压缩体积按全部参数都要存来估算:组成部分估算说明35B 文本权重(INT4)≈ 17.5 GB4 bit 0.5 字节/参数,35B × 0.5B分组缩放因子(Group 32)≈ 1~2 GB每 32 个权重 1 个 scalerEmbedding(FP16)≈ 1.0 GB248320 × 2048 × 2 字节Vision 编码器(FP16)≈ 0.5 GB27 层视觉 Transformer合计≈ 19 GB对比 FP16 全精度约需 70 GB也就是说,相比 FP16 原版(约 70GB),这套 INT4 方案把体积压缩了约 3/4,轻松装进 32GB 内存 显存共享的 AI PC,还能留出空间放 KV Cache 和图像缓冲区。四、为什么精度几乎不损失?MoE 稀疏激活天然抗量化:A3B 架构下每次推理只激活约 3B 参数,单 token 计算路径短、误差传播少,即使 INT4 引入微小舍入误差,也难以累积成明显的质量下降。Group 32 精细缩放:如上所述,量化误差被限制在每组 32 个权重的小范围内。FP16 激活:只有权重被压成 4 比特,前向计算的激活值仍是 FP16,避免了权重、激活双重取整带来的误差叠加。敏感层免压缩:Embedding 与 Vision 保留 FP16,保住了输入端的语义质量。五、模型结构与部署配置解读 主干结构:线性注意力 全注意力混合从 config.json 可以看到,文本主干共40 层(num_hidden_layers),其中每 4 层出现一次全注意力(full_attention_interval: 4,对应 config.json 与layer_types字段),其余使用线性注意力。配合 262144 的max_position_embeddings,长上下文推理的算力开销显著低于传统 Transformer——这也是它适合端侧硬件的重要原因之一。两套推理配置,按需选择配置项genai_config.jsongenai_config.json.dml上下文长度2621444096推理后端通用(如 CUDA)DirectML(dml: {}),面向 AMD 硬件部署到 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 量化到底怎么做的绝佳实例。赞分享【免费下载链接】Qwen3.5-35B-A3B_gpuep_1.0_gpu_128项目地址https://ai.gitcode.com/hf_mirrors/amd/Qwen3.5-35B-A3B_gpuep_1.0_gpu_128点击查看免费下载相关推荐W8A8量化策略详解MiniMax-M2.7-w8a8-QuaRot如何将权重与激活压缩到int8且近乎无损W8A8量化策略详解MiniMax M2.7 w8a8 QuaRot如何将权重与激活压缩到int8且近乎无损 MiniMax M2.7 w8a8 QuaRo大模型基础模型模型量化AutoGPTQ模型压缩技巧如何将大模型缩小4倍而不损失精度想要在普通硬件上运行大语言模型AutoGPTQ正是你需要的解决方案 这个基于GPTQ算法的开源工具包能够将大模型压缩4倍同时保持原始精度让每个人都模型量化大模型模型优化VibeVoice-ASR-Streaming-7B-bf16 的 MLX 4-bit 量化完全指南:16.6GB 模型如何压到 5.7GB 且精度几乎无损VibeVoice ASR Streaming 7B bf16 的 MLX 4 bit 量化完全指南:16.6GB 模型如何压到 5.7GB 且精度几乎无损 V上一篇终极文档下载指南如何用kill-doc脚本轻松下载各大文库内容下一篇express-validator checkExact() 完全指南精确校验请求字段杜绝未知字段注入创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
