【免费下载链接】Qwen3-4B_rai_1.8.0_npu_4K项目地址https://ai.gitcode.com/hf_mirrors/amd/Qwen3-4B_rai_1.8.0_npu_4K点击查看免费下载在 AMD Ryzen AI 笔记本上本地跑大模型Qwen3-4B_rai_1.8.0_npu_4K 是一个值得研究的项目它是基于 Qwen3-4B 经 Quark 量化 OGA Model Builder 构建、并完成 NPU 部署后处理Full Fusion 4K context的 ONNX 模型最大亮点就是对4K 长上下文的原生支持。翻开仓库目录你会看到一堆dd_metastate_*文件文件名里的sequence_length_padded_128到sequence_length_padded_4096正是 4K 长上下文设计背后最核心的工程机制——padded 长度桶长度分桶。本文带你拆解这些桶是怎么来的、每个桶里装了什么以及为什么这是 NPU 部署的必修课。先认识这个模型4K 上下文的身份证在下钻之前先看看模型自己申报的参数配置项值说明模型架构Qwen3ForCausalLM36 层见 config.json隐藏层维度2560 / 32 头 / 8 个 KV 头标准 GQA 注意力配置最大输出长度4096见 genai_config.json上下文长度40960词表内能力见 genai_config.json量化方案AWQ / Group 128 / UINT4 权重 BFP16 激活见 README.md推理后端RyzenAINPUhybrid_opt_token_backend: npu权重体积model.onnx model.onnx.data约 950MBUINT4 量化后的结果其中最能说明4K身份的是两份配置rai_config.json 记录了随 Ryzen AI 软件版本演进的最大提示词长度1.5.1: 2048, 1.6.0: 4096, 1.7.1: 4096也就是说从 1.6.0 版本起这个模型把 prompt 上限从 2048 直接翻倍到了 4096——这正是项目名中_4K的由来。genai_config.json 中max_length: 4096则限制了单次生成的输出上限两者共同框定了模型在 NPU 上能吃多长、能吐多长。什么是 padded 长度桶为什么 NPU 模型非要分桶普通 GPU 推理框架如 PyTorch习惯动态 shape来多长的 prompt 就按多长算。但 NPU 不同——它本质上是一张编译好的硬件流水线对输入形状往往要求静态、固定。如果每次输入长度都不一样都要重新编译延迟根本无法接受。工程上的标准解法就是长度分桶bucketing / padding预先选定一组桶长度如 128、256、512……4096每个桶分别编译一份 NPU 执行计划并持久化到文件运行时把实际输入padding填充到 ≥ 实际长度的最小桶按该桶的执行计划推理。这样 NPU 永远只面对它见过的固定形状既保证了硬件吞吐又通过多桶覆盖了不同长度的请求。Qwen3-4B_rai_1.8.0_npu_4K 目录下的dd_metastate文件就是这套机制的编译产物。逐一拆解10 个 Prefill 长度桶长什么样在 README.md 中可以看到模型经历了量化 → OGA 构建 → NPU 部署后处理三个环节。仓库中 10 个sequence_length_padded_*文件组就来自最后一个环节覆盖128 → 4096步长 128128, 256, 512, 768, 1024, 1536, 2048, 2304, 3072, 4096注意步长并非均匀——前半段细粒度256/512/768后半段跳跃更大1536 之后直接 2048、2304、3072这是典型的按使用频率分配桶的设计短 prompt 更常见桶更密以减少 padding 浪费长 prompt 相对少桶可以稀疏。每个桶其实是一组三元组文件以 128 桶为例完整 10 桶见仓库根目录dd_metastate_Llm_Prefill_modellayers.0input_layernormMLADFRMSNORM_sequence_length_padded_128_.meta该长度桶下 NPU 编译出的引擎元数据/执行计划体积最大是桶的本体dd_metastate_Llm_Prefill_modellayers.0input_layernormMLADFRMSNORM_sequence_length_padded_128_.ctrlpkt控制包control packet描述该桶如何被调度执行dd_metastate_Llm_Prefill_modellayers.0input_layernormMLADFRMSNORM_sequence_length_padded_128_.supersuper 指令NPU 侧的底层执行指令集。文件名前缀Llm_Prefill_modellayers.0input_layernormMLADFRMSNORM也很有信息量这是Prefill预填充阶段、从model.layers[0]的input_layernorm开始、经过MLA多 latent 注意力/ DFR / MS NORM 融合后的算子段——Full FusionREADME 中提到的全融合就体现在这类跨算子的融合命名上。各桶 .meta 体积长度翻倍体积近似线性增长这些文件在仓库中以 LFS 指针形式存在从指针里就能读出真实大小padded 长度桶.meta 实际体积相对 128 桶12834.0 MB1.0x25642.1 MB1.2x51265.3 MB1.9x76890.3 MB2.6x102499.9 MB2.9x1536146.8 MB4.3x2048167.4 MB4.9x2304197.3 MB5.8x3072234.6 MB6.9x4096259.7 MB7.6x这张表揭示了一个朴素的工程事实NPU 执行计划的体积随序列长度近似线性膨胀因为注意力相关的中间张量、常量与调度信息都要按长度展开。4096 桶是最大的单文件但相对整个模型约 1GB 权重 2.2GB 常量仍只是零头——AMD 选择为 128 到 4096 全段预编译 10 个桶本质是用仓库体积换取任意长度 prompt 零等待的即开即跑。Decode 阶段的另一半Llm_Token 桶推理分两个阶段Prefill 一次读完整个 prompt之后逐 Token 生成Decode。仓库里同样有一组 Decode 侧的文件只是桶的数量和命名不同dd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM_attention_mask_padded_256_.metadd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM_attention_mask_padded_512_.metadd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM_attention_mask_padded_1024_.metadd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM_attention_mask_padded_2048_.metadd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM_attention_mask_padded_3072_.metadd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM_attention_mask_padded_4096_.meta三个细节值得注意按attention_mask分桶而非sequence_lengthDecode 阶段每步只生成 1 个 token真正随历史增长的是注意力掩码/KV 历史长度所以桶键用的是 mask 长度只有 6 个桶且间隔 256 起跳Decode 是逐 token 的稳态循环桶可以更粗256/512/1024/2048/3072/4096 已足够覆盖各桶 .meta 体积惊人地一致约 3.23 MBDecode 每步计算量恒定1 个 token 对 N 个 KV执行计划主要由结构决定对长度的敏感度远低于 Prefill。两相对照Prefill 是一次大计算、Decode 是无数小计算桶策略的差异完全是性能模型差异的直接映射——这就是 NPU 4K 部署里最隐蔽也最值得学习的工程权衡。全局常量与状态两套 dd_metastate 之外还有它们除了按长度分桶的文件仓库还有 4 个全局元数据文件它们与桶无关、只有一份文件真实体积作用dd_metastate_Llm_Prefill_modellayers.0input_layernormMLADFRMSNORM.fconst约 2.0 GBPrefill 阶段浮点常量预计算好的张量数据dd_metastate_Llm_Prefill_modellayers.0input_layernormMLADFRMSNORM.state839 BPrefill 侧小型状态/校验数据dd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM.fconst约 2.2 GBDecode 阶段浮点常量dd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM.state796 BDecode 侧状态数据Prefill 与 Decode 各持有一套约 2GB 的 fconst 常量说明 AMD 把两个阶段视为独立的优化目标分别融合编译——Prefill 追求一次读完 4096 token 的大矩阵吞吐Decode 追求单 token 的低延迟二者硬件路径并不共享。普通用户视角4K 长度桶带来什么体验回到最初的问题这些工程细节对用户意味着什么直接支持 4096 token 的长 prompt对照 rai_config.json1.6.0 的 Ryzen AI 环境可一次性输入最多 4096 token约等于一篇 2000 多字的长文或大段代码适合文档摘要、长文问答任何长度都是编译好的无论你的 prompt 是 100 token 还是 4000 token运行时都不需要现场编译 NPU 计划只是选择对应的桶做一次 padding首 token 延迟稳定短 prompt 不吃亏128/256 等细粒度小桶保证短对话的 padding 浪费被压到最低日常问答不为长上下文买单注意输入预算prompt 上限 4096 生成上限 4096genai_config.json若 prompt 已接近 4096剩余可生成空间会相应缩减长文档场景建议先做分段摘要。小结Qwen3-4B_rai_1.8.0_npu_4K 目录里看似杂乱的dd_metastate文件其实是一套完整、克制的 4K 长上下文工程方案10 个 Prefill 桶128→40966 个 Decode 桶256→4096把动态长度问题转化为静态形状集合每个桶 .meta执行计划.ctrlpkt控制包.superNPU 指令三件套配合两套约 2GB 的 fconst 常量完成全融合部署桶粒度按短密长疏分配在 padding 浪费与编译产物体积之间取得平衡。对于想深入 NPU 大模型部署的读者这个仓库本身就是一份活的教材从 config.json 的 AWQ 量化配置到 README.md 描述的Quark 量化 → OGA 构建 → NPU 后处理流水线再到这批分桶编译产物完整展示了一份 Hugging Face 模型如何变成 Ryzen AI 笔记本上即开即用的 4K 长上下文模型的全过程。赞分享【免费下载链接】Qwen3-4B_rai_1.8.0_npu_4K项目地址https://ai.gitcode.com/hf_mirrors/amd/Qwen3-4B_rai_1.8.0_npu_4K点击查看免费下载相关推荐Qwen3-235B-A22B-quantized.w4a8 推理引擎揭秘GQA注意力与40K长上下文性能优化内幕Qwen3 235B A22B quantized.w4a8 推理引擎揭秘GQA注意力与40K长上下文性能优化内幕 Qwen3 235B A22B quantLlama-3.1-8B_rai_1.8.0_npu_16K 深度揭秘16K 长上下文 Token Fusion 是如何实现的Llama 3.1 8B_rai_1.8.0_npu_16K 深度揭秘16K 长上下文 Token Fusion 是如何实现的 Llama 3.1 8B_ra揭秘131k超长上下文如何用Muse-Glimmer-30B-5bit读懂图文长文档揭秘131k超长上下文如何用Muse Glimmer 30B 5bit读懂图文长文档 Muse Glimmer 30B 5bit 是一款专为苹果芯片打造的 5上一篇10分钟上手PHP-VCR让你的测试用例告别网络依赖下一篇ACE-Step UI完整指南免费开源的AI音乐生成神器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 揭秘Qwen3-4B_rai_1.8.0_npu_4K的4K长上下文设计：128到4096的padded长度桶工程内幕
【免费下载链接】Qwen3-4B_rai_1.8.0_npu_4K项目地址https://ai.gitcode.com/hf_mirrors/amd/Qwen3-4B_rai_1.8.0_npu_4K点击查看免费下载在 AMD Ryzen AI 笔记本上本地跑大模型Qwen3-4B_rai_1.8.0_npu_4K 是一个值得研究的项目它是基于 Qwen3-4B 经 Quark 量化 OGA Model Builder 构建、并完成 NPU 部署后处理Full Fusion 4K context的 ONNX 模型最大亮点就是对4K 长上下文的原生支持。翻开仓库目录你会看到一堆dd_metastate_*文件文件名里的sequence_length_padded_128到sequence_length_padded_4096正是 4K 长上下文设计背后最核心的工程机制——padded 长度桶长度分桶。本文带你拆解这些桶是怎么来的、每个桶里装了什么以及为什么这是 NPU 部署的必修课。先认识这个模型4K 上下文的身份证在下钻之前先看看模型自己申报的参数配置项值说明模型架构Qwen3ForCausalLM36 层见 config.json隐藏层维度2560 / 32 头 / 8 个 KV 头标准 GQA 注意力配置最大输出长度4096见 genai_config.json上下文长度40960词表内能力见 genai_config.json量化方案AWQ / Group 128 / UINT4 权重 BFP16 激活见 README.md推理后端RyzenAINPUhybrid_opt_token_backend: npu权重体积model.onnx model.onnx.data约 950MBUINT4 量化后的结果其中最能说明4K身份的是两份配置rai_config.json 记录了随 Ryzen AI 软件版本演进的最大提示词长度1.5.1: 2048, 1.6.0: 4096, 1.7.1: 4096也就是说从 1.6.0 版本起这个模型把 prompt 上限从 2048 直接翻倍到了 4096——这正是项目名中_4K的由来。genai_config.json 中max_length: 4096则限制了单次生成的输出上限两者共同框定了模型在 NPU 上能吃多长、能吐多长。什么是 padded 长度桶为什么 NPU 模型非要分桶普通 GPU 推理框架如 PyTorch习惯动态 shape来多长的 prompt 就按多长算。但 NPU 不同——它本质上是一张编译好的硬件流水线对输入形状往往要求静态、固定。如果每次输入长度都不一样都要重新编译延迟根本无法接受。工程上的标准解法就是长度分桶bucketing / padding预先选定一组桶长度如 128、256、512……4096每个桶分别编译一份 NPU 执行计划并持久化到文件运行时把实际输入padding填充到 ≥ 实际长度的最小桶按该桶的执行计划推理。这样 NPU 永远只面对它见过的固定形状既保证了硬件吞吐又通过多桶覆盖了不同长度的请求。Qwen3-4B_rai_1.8.0_npu_4K 目录下的dd_metastate文件就是这套机制的编译产物。逐一拆解10 个 Prefill 长度桶长什么样在 README.md 中可以看到模型经历了量化 → OGA 构建 → NPU 部署后处理三个环节。仓库中 10 个sequence_length_padded_*文件组就来自最后一个环节覆盖128 → 4096步长 128128, 256, 512, 768, 1024, 1536, 2048, 2304, 3072, 4096注意步长并非均匀——前半段细粒度256/512/768后半段跳跃更大1536 之后直接 2048、2304、3072这是典型的按使用频率分配桶的设计短 prompt 更常见桶更密以减少 padding 浪费长 prompt 相对少桶可以稀疏。每个桶其实是一组三元组文件以 128 桶为例完整 10 桶见仓库根目录dd_metastate_Llm_Prefill_modellayers.0input_layernormMLADFRMSNORM_sequence_length_padded_128_.meta该长度桶下 NPU 编译出的引擎元数据/执行计划体积最大是桶的本体dd_metastate_Llm_Prefill_modellayers.0input_layernormMLADFRMSNORM_sequence_length_padded_128_.ctrlpkt控制包control packet描述该桶如何被调度执行dd_metastate_Llm_Prefill_modellayers.0input_layernormMLADFRMSNORM_sequence_length_padded_128_.supersuper 指令NPU 侧的底层执行指令集。文件名前缀Llm_Prefill_modellayers.0input_layernormMLADFRMSNORM也很有信息量这是Prefill预填充阶段、从model.layers[0]的input_layernorm开始、经过MLA多 latent 注意力/ DFR / MS NORM 融合后的算子段——Full FusionREADME 中提到的全融合就体现在这类跨算子的融合命名上。各桶 .meta 体积长度翻倍体积近似线性增长这些文件在仓库中以 LFS 指针形式存在从指针里就能读出真实大小padded 长度桶.meta 实际体积相对 128 桶12834.0 MB1.0x25642.1 MB1.2x51265.3 MB1.9x76890.3 MB2.6x102499.9 MB2.9x1536146.8 MB4.3x2048167.4 MB4.9x2304197.3 MB5.8x3072234.6 MB6.9x4096259.7 MB7.6x这张表揭示了一个朴素的工程事实NPU 执行计划的体积随序列长度近似线性膨胀因为注意力相关的中间张量、常量与调度信息都要按长度展开。4096 桶是最大的单文件但相对整个模型约 1GB 权重 2.2GB 常量仍只是零头——AMD 选择为 128 到 4096 全段预编译 10 个桶本质是用仓库体积换取任意长度 prompt 零等待的即开即跑。Decode 阶段的另一半Llm_Token 桶推理分两个阶段Prefill 一次读完整个 prompt之后逐 Token 生成Decode。仓库里同样有一组 Decode 侧的文件只是桶的数量和命名不同dd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM_attention_mask_padded_256_.metadd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM_attention_mask_padded_512_.metadd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM_attention_mask_padded_1024_.metadd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM_attention_mask_padded_2048_.metadd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM_attention_mask_padded_3072_.metadd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM_attention_mask_padded_4096_.meta三个细节值得注意按attention_mask分桶而非sequence_lengthDecode 阶段每步只生成 1 个 token真正随历史增长的是注意力掩码/KV 历史长度所以桶键用的是 mask 长度只有 6 个桶且间隔 256 起跳Decode 是逐 token 的稳态循环桶可以更粗256/512/1024/2048/3072/4096 已足够覆盖各桶 .meta 体积惊人地一致约 3.23 MBDecode 每步计算量恒定1 个 token 对 N 个 KV执行计划主要由结构决定对长度的敏感度远低于 Prefill。两相对照Prefill 是一次大计算、Decode 是无数小计算桶策略的差异完全是性能模型差异的直接映射——这就是 NPU 4K 部署里最隐蔽也最值得学习的工程权衡。全局常量与状态两套 dd_metastate 之外还有它们除了按长度分桶的文件仓库还有 4 个全局元数据文件它们与桶无关、只有一份文件真实体积作用dd_metastate_Llm_Prefill_modellayers.0input_layernormMLADFRMSNORM.fconst约 2.0 GBPrefill 阶段浮点常量预计算好的张量数据dd_metastate_Llm_Prefill_modellayers.0input_layernormMLADFRMSNORM.state839 BPrefill 侧小型状态/校验数据dd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM.fconst约 2.2 GBDecode 阶段浮点常量dd_metastate_Llm_Token_Token_modellayers.0input_layernormMLADFRMSNORM.state796 BDecode 侧状态数据Prefill 与 Decode 各持有一套约 2GB 的 fconst 常量说明 AMD 把两个阶段视为独立的优化目标分别融合编译——Prefill 追求一次读完 4096 token 的大矩阵吞吐Decode 追求单 token 的低延迟二者硬件路径并不共享。普通用户视角4K 长度桶带来什么体验回到最初的问题这些工程细节对用户意味着什么直接支持 4096 token 的长 prompt对照 rai_config.json1.6.0 的 Ryzen AI 环境可一次性输入最多 4096 token约等于一篇 2000 多字的长文或大段代码适合文档摘要、长文问答任何长度都是编译好的无论你的 prompt 是 100 token 还是 4000 token运行时都不需要现场编译 NPU 计划只是选择对应的桶做一次 padding首 token 延迟稳定短 prompt 不吃亏128/256 等细粒度小桶保证短对话的 padding 浪费被压到最低日常问答不为长上下文买单注意输入预算prompt 上限 4096 生成上限 4096genai_config.json若 prompt 已接近 4096剩余可生成空间会相应缩减长文档场景建议先做分段摘要。小结Qwen3-4B_rai_1.8.0_npu_4K 目录里看似杂乱的dd_metastate文件其实是一套完整、克制的 4K 长上下文工程方案10 个 Prefill 桶128→40966 个 Decode 桶256→4096把动态长度问题转化为静态形状集合每个桶 .meta执行计划.ctrlpkt控制包.superNPU 指令三件套配合两套约 2GB 的 fconst 常量完成全融合部署桶粒度按短密长疏分配在 padding 浪费与编译产物体积之间取得平衡。对于想深入 NPU 大模型部署的读者这个仓库本身就是一份活的教材从 config.json 的 AWQ 量化配置到 README.md 描述的Quark 量化 → OGA 构建 → NPU 后处理流水线再到这批分桶编译产物完整展示了一份 Hugging Face 模型如何变成 Ryzen AI 笔记本上即开即用的 4K 长上下文模型的全过程。赞分享【免费下载链接】Qwen3-4B_rai_1.8.0_npu_4K项目地址https://ai.gitcode.com/hf_mirrors/amd/Qwen3-4B_rai_1.8.0_npu_4K点击查看免费下载相关推荐Qwen3-235B-A22B-quantized.w4a8 推理引擎揭秘GQA注意力与40K长上下文性能优化内幕Qwen3 235B A22B quantized.w4a8 推理引擎揭秘GQA注意力与40K长上下文性能优化内幕 Qwen3 235B A22B quantLlama-3.1-8B_rai_1.8.0_npu_16K 深度揭秘16K 长上下文 Token Fusion 是如何实现的Llama 3.1 8B_rai_1.8.0_npu_16K 深度揭秘16K 长上下文 Token Fusion 是如何实现的 Llama 3.1 8B_ra揭秘131k超长上下文如何用Muse-Glimmer-30B-5bit读懂图文长文档揭秘131k超长上下文如何用Muse Glimmer 30B 5bit读懂图文长文档 Muse Glimmer 30B 5bit 是一款专为苹果芯片打造的 5上一篇10分钟上手PHP-VCR让你的测试用例告别网络依赖下一篇ACE-Step UI完整指南免费开源的AI音乐生成神器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考