• 大模型
• 代码模型
• 模型量化
• 本地部署
• 模型优化
• Qwen

Qwen2.5-Coder-14B-Instruct_gpuep_1.0_gpu_128是基于 Qwen2.5-Coder-14B-Instruct 转换而来的 AI 编程大模型，采用 ONNX 格式并在 AMD GPU 上推理加速（GPUEP + INT4 分组量化）。本文带你用几分钟读懂它的底层架构：48 层 Transformer、GQA 分组注意力机制与 32K 上下文是怎么实现"又快又省内存"的，并附完整参数清单与部署细节。

一、这个项目是什么？📦

一句话概括：140 亿参数的代码大模型 + ONNX 部署包 + AMD GPU 专属优化。

它由 AMD 的 OGA Model Builder 将 Qwen2.5-Coder-14B-Instruct 转换为 ONNX 模型，并针对 AMD Ryzen AI 等 GPU 硬件做了 INT4 量化，目的是让 14B 级别的编程模型能在本地 GPU 上高效跑起来，用于代码生成、补全与对话。

量化策略（来自 README.md）：

• 算法：RTN（Round-To-Nearest）
• 分组：Group 128
• 激活：FP16
• 权重：INT4

名字里的gpuep指 GPU Execution Provider（ONNX Runtime 的 GPU 执行提供方），gpu_128指 Group 128 量化分组，这两个后缀直接告诉你它的"加速血统"。

二、核心架构全解析：48 层 Transformer 的"骨架"🔍

所有架构参数都记录在 config.json 中，先给出关键参数速览表：

每一层都在做什么？

48 层结构完全一致（layer_types全部为full_attention），每一层都是经典的 Decoder 单元：

1. RMSNorm归一化（rms_norm_eps= 1e-06）
2. GQA 分组注意力：40 个 Query 头 × 8 个 KV 头，128 维头
3. 残差连接
4. RMSNorm归一化
5. SwiGLU MLP：5120 → 13824 → 5120 的前馈网络
6. 残差连接

输入经过 Embedding 层（词表 152064，tie_word_embeddings为 false，不共享词嵌入）后，逐层"滚动"这 48 层，最后由 LM Head 输出下一个 token 的概率分布。

三、GQA 分组注意力：KV Cache 直接省 5 倍🚀

这是本模型最值得讲的架构点。

普通MHA（多头注意力）每个 Query 头都配独立的 Key/Value 头，40 个头就要存 40 份 KV 缓存；而GQA（Grouped Query Attention，分组查询注意力）让每 5 个 Query 头共享一组 KV 头（40 ÷ 8 = 5:1），参数不减半，但推理时的显存开销大幅下降。

按 head_size 128、FP16 存储计算：

同样跑满 32K 上下文，GQA 方案把 KV 缓存从约 30 GiB 压到约 6 GiB——这正是 14B 模型能在消费级 GPU 上长上下文推理的关键原因。

四、32K 上下文：一次能读多长的代码？📏

config.json 中max_position_embeddings = 32768，配合rope_theta = 1,000,000的旋转位置编码（RoPE）且未启用rope_scaling，意味着：

• 一次最多处理 32768 个 token，约相当于十几万汉字或数千行代码
• 未启用滑动窗口（use_sliding_window: false、sliding_window: null），32K 内全程全注意力，远距离引用不会"失忆"
• 对编程场景的意义：可以把整个工具函数、模块文件甚至一次多文件改动放进上下文，让模型"看全"再回答

需要注意：上下文越长，KV 缓存越大（线性增长），32K 满载时约需 6 GiB 额外显存，属于 GQA 带来的直接红利。

五、AMD GPU 部署细节：ONNX Runtime 是怎么加速的⚙️

部署配置集中在 genai_config.json，几个关键设定：

模型图结构保存在 text.onnx，大体积权重放在外置文件 text.onnx.data（INT4 量化后的权重），这种"图 + 外置数据"的拆分是 ONNX 大模型的常见做法，便于管理与加载。完整的模型属性快照可参考 model_config.json。

六、开箱即用的生成参数🎛️

采样参数由 generation_config.json 预设，兼顾代码生成的稳定性与多样性：

配合 chat_template.jinja 中的对话模板与 tokenizer.json 分词器，输入输出链路是完整闭环。

七、文件结构与快速上手🛠️

仓库文件一览（均在 Upload Qwen2.5 ONNX files/ 目录下）：

获取模型文件的推荐方式（需安装 ONNX Runtime 的 AMD GPU EP 运行环境）：

git clone https://gitcode.com/hf_mirrors/amd/Qwen2.5-Coder-14B-Instruct_gpuep_1.0_gpu_128

克隆后把Upload Qwen2.5 ONNX files目录作为模型路径，交给支持 ONNX GenAI API 的推理框架，按genai_config.json自动选择 AMDGPU 提供方可完成推理。

八、常见问题 FAQ❓

Q1：INT4 量化会不会明显降低代码生成质量？RTN Group 128 是当前工程实践中"质量-体积"平衡较好的方案：权重压缩到约 1/4，配合 FP16 激活，体积大幅下降而效果损失有限，适合本地部署。

Q2：为什么叫"gpuep"，和普通 ONNX 模型有何区别？它不是通用 CPU 版 ONNX 模型，而是针对 GPU 执行提供方（Execution Provider）优化的产物：禁用 CPU 回退、按 HIP profile 调度、KV 缓存共享缓冲，都是为 AMD GPU 长上下文推理做的定向优化。

Q3：32K 上下文是不是必须占满显存？不是。KV 缓存随实际输入长度线性增长，短对话占用很小；只有在真正喂入 32K token 的超长上下文时，才会接近约 6 GiB 的 KV 缓存峰值。

小结：Qwen2.5-Coder-14B-Instruct_gpuep_1.0_gpu_128 =48 层全注意力 Transformer+5:1 GQA 分组注意力（KV 缓存省 80%）+32K 全注意力上下文+INT4/Group 128 量化+ONNX Runtime AMD GPU 加速。理解这五块拼图，你就掌握了它的"底层架构"，也能为本地部署的显存规划、上下文取舍提供依据。

• 大模型
• 代码模型
• 模型量化
• 本地部署
• 模型优化
• Qwen