尧图网页设计 
KTransformers 部署 Qwen3-Next-80B-A3B 全指南balance_serve 异质推理、优化规则与线性注意力解析【免费下载链接】ktransformersA Flexible Framework for Experiencing Heterogeneous LLM Inference/Fine-tune Optimizations项目地址: https://gitcode.com/GitHub_Trending/ktr/ktransformers导读本文基于 doc/en/Qwen3-Next.md完整讲解如何在 KTransformers 框架中以异构CPU GPU方式部署运行 Qwen3-Next-80B-A3B-Thinking / Instruct 两个官方模型。读完本文你将掌握从 GGUF 模型下载、KTransformers 安装到以balance_serve后端启动推理服务并通过 OpenAI 兼容接口发起请求的完整实操链路同时结合仓库源码与Qwen3Next-serve.yaml优化规则理解线性注意力Gated DeltaNet与 512 路 MoE 专家在 KTransformers 中如何被注入替换、如何分布到 CPU/GPU以及为何该模型暂不支持 CUDA Graph 优化。一、背景Qwen3-Next 的架构特点与 KTransformers 支持范围KTransformers 现已官方支持两个 Qwen3-Next 系列模型Qwen3-Next-80B-A3B-Thinking推理增强版本Qwen3-Next-80B-A3B-Instruct指令微调版本Qwen3-Next 是一个典型的 80B 总参数、A3B 活跃参数 的稀疏 MoE 模型其架构与 Qwen3-MoE 有显著差异这也是它在 KTransformers 中需要专门适配的原因。从仓库中 archive/ktransformers/models/configuration_qwen3_next.py 的Qwen3NextConfig默认值可以看出其核心结构参数参数默认值含义hidden_size2048隐藏层维度num_hidden_layers48Transformer 层数num_attention_heads16注意力头数head_dim256多头注意力的投影维度num_experts512路由专家routed experts总数num_experts_per_tok10每个 token 激活的专家数moe_intermediate_size512路由专家中间维度shared_expert_intermediate_size512共享专家中间维度decoder_sparse_step1MoE 层频率每层均为 MoElinear_conv_kernel_dim4线性注意力卷积核大小linear_key_head_dim128线性注意力 K 头维度linear_value_head_dim128线性注意力 V 头维度linear_num_key_heads16线性注意力 K 头数linear_num_value_heads32线性注意力 V 头数max_position_embeddings32768最大序列长度partial_rotary_factor0.25施加 RoPE 的 Q/K 维度比例其中两个最值得关注的设计混合注意力48 层中约每 4 层出现 1 层标准全注意力full attention其余 3 层为线性注意力linear attention。这一层类型序列在配置类中按layer_types自动生成linear_attention if bool((i 1) % 4) else full_attention。超大专家池512 个路由专家、每 token 激活 10 个加上 48 层全 MoEdecoder_sparse_step1权重总量约 80B但单次推理仅计算约 3B 活跃参数。这两点分别决定了 KTransformers 适配时的两条主线为线性注意力编写专用的 Gated DeltaNet 算子见后文第五节以及把绝大多数专家权重卸载到 CPU 内存以换取低 GPU 显存占用。二、资源需求为什么 512 专家只需 6 GB 显存文档明确给出官方资源预估以 512 个专家运行该模型需要约320 GB 内存和6 GB GPU 显存。这一数字背后正是 KTransformers 异构推理的核心思想MoE 专家权重体量巨大占据模型总参数的大部分但每个 token 仅激活其中一小部分。KTransformers 将专家层experts默认放在 CPU 上对应优化规则中generate_device: cpu按需把被路由命中的专家搬运到 GPU 计算同时让注意力、RoPE、归一化、lm_head 等算子驻留 GPUgenerate_device/prefill_device: cuda。因此部署前请务必确认主机具备充足的内存条容量约 320 GB 以上并至少保留 6 GB 空闲 GPU 显存。显存需求还与--cache_lens相关——在 archive/ktransformers/server/args.py 中gpu_memory_size会按cache_lens与 KV cache 结构估算用于调度器的显存预算计算。三、安装 KTransformers 与准备模型3.1 下载 GGUF 模型使用huggingface-cli下载官方发布的 Qwen3-Next 模型GGUF 格式huggingface-cli download --resume-download Qwen/Qwen3-Next-80B-A3B-Instruct如需部署推理增强版本则下载Qwen/Qwen3-Next-80B-A3B-Thinking。--resume-download支持断点续传适合大体积权重下载。下载完成后将模型目录路径分别记录为下述启动命令中的--model_path与--gguf_path。说明文档中的模型链接指向官方发布页模型本体请通过上述官方仓库获取KTransformers 仓库内不包含模型权重。3.2 安装 KTransformers参照仓库自带的官方安装指南完成环境安装安装指南。安装过程会构建 Python 扩展包括 CUDA 侧的 Marlin 量化算子与 CPU 侧的 experts 内核并安装推理服务所需的依赖。本仓库当前将完整 Python 实现归档在archive/ktransformers/目录下运行入口为ktransformers/server/main.py安装后以ktransformers包形式导入。四、启动 Qwen3-Next 推理服务balance_serve 后端4.1 完整启动命令文档给出的服务启动命令如下python ktransformers/server/main.py \ --port 10021 \ --model_path path-to-Qwen3-Next-80B-A3B-Thinking \ --gguf_path path-to-Qwen3-Next-80B-A3B-Thinking \ --model_name Qwen3NextForCausalLM \ --optimize_config_path local_path/ktransformers/optimize/optimize_rules/Qwen3Next-serve.yaml \ --max_new_tokens 1024 \ --cache_lens 32768 \ --chunk_size 256 \ --max_batch_size 4 \ --no-use_cuda_graph \ --backend_type balance_serve对应仓库中的优化规则文件为 archive/ktransformers/optimize/optimize_rules/Qwen3Next-serve.yaml请将其中的local_path替换为仓库实际所在路径。4.2 核心参数说明结合 archive/ktransformers/server/args.py 中的参数解析逻辑各参数含义如下参数示例值说明--port10021服务监听端口用于后续 HTTP 请求--model_path模型目录HuggingFace 格式模型config 与 tokenizer所在路径--gguf_path模型目录GGUF 权重文件所在路径用于GGUFLoader加载量化权重--model_nameQwen3NextForCausalLM指定模型架构类名必须与仓库 models 中注册的类一致--optimize_config_pathQwen3Next-serve.yaml算子注入规则文件决定哪些模块被替换为 KTransformers 优化实现--max_new_tokens1024单次生成的最大新 token 数--cache_lens32768KV cache 长度预算直接影响显存估算与分页调度--chunk_size256Prefill 阶段的分块大小控制长输入按块调度--max_batch_size4服务可同时处理的最大请求批大小--no-use_cuda_graph—显式关闭 CUDA GraphQwen3-Next 必需见第六节--backend_typebalance_serve选择 balance_serve 调度后端这是 Qwen3-Next 的推荐/必需后端其中--backend_type balance_serve尤为关键balance_serve 是 KTransformers 面向并发推理优化的调度后端支持分页 KV cache、批处理 prefill/decode并与下文提到的 FlashInfer MLA 注意力包装器配合使用。五、源码级剖析Qwen3Next-serve.yaml 优化规则KTransformers 通过 YAML 规则文件描述模块匹配—算子替换关系服务启动时据此把原生 HF 模块注入为优化实现。下面逐条解读 Qwen3Next-serve.yaml它共包含 10 条规则#匹配对象原生类/正则名替换为KTransformers 算子设备分配设计意图1Qwen3NextRotaryEmbeddingKQwen3MoeRotaryEmbeddingRoPE.pycuda / cuda复用 Qwen3-MoE 的 RoPE 优化实现2lm_headtorch.nn.LinearKTransformersLineargenerateVLinearMarlinprefillKLinearTorchcuda / cuda输出投影走 GPU Marlin 量化内核3model.layers.*中的普通Linear正则排除mlp.shared_expert_gateKTransformersLineargenerateKLinearMarlinprefillKLinearTorchcuda / cuda各层 QKV/O 投影等线性层量化加速4model.layers.*.mlpQwen3NextSparseMoeBlockKQwen3NextSparseMoeBlockV2experts.pycuda / cuda自定义 MoE 前向流程含路由与调度5model.layers.*.mlp.expertsKTransformersExpertsV2prefillKExpertsTorchgenerateKExpertsCPUout_device: cudacpu / cuda专家权重驻留 CPU按需搬运计算后输出回 GPU6Qwen3NextGatedDeltaNetKQwen3NextGatedDeltaNetbalance_serve_attention.pycuda / cuda线性注意力专用实现7Qwen3NextAttentionKQwen3NextAttentionbalance_serve_attention.pycuda / cuda全注意力走 FlashInfer MLA 包装8model.embed_tokensdefaultcpu / cpuEmbedding 放 CPU减小显存占用9Qwen3NextRMSNormKQwen3NextRMSNormlayernorm.pycuda / cuda归一化层 GPU 化10Qwen3NextMLP共享专家/稠密 MLP 层KQwen2MoeMLPmlp.pycuda / cuda复用 Qwen2-MoE 的 MLP 实现两条正则规则值得注意规则 3 使用负向前瞻^model\.layers\.(?!.*mlp\.shared_expert_gate).*$把各层 Linear 全部替换但排除共享专家门控层避免与规则 4/5 的专家处理冲突。规则 5 显式声明recursive: False防止KTransformersExpertsV2内部子模块被后续规则再次递归注入。设备分配上prefill_device/generate_device分别控制 prefill 与 decode 两个阶段的计算设备专家层在 decode 阶段使用 CPU 内核KExpertsCPU而 prefill 阶段使用 GPU 内核KExpertsTorch这与 512 专家、10 路 Top-K 路由的稀疏特性高度契合——decode 阶段每步仅激活少量专家CPU 上按需计算即可维持高吞吐。5.1 注意力算子的底层实现规则 6、7 替换后的注意力算子位于 balance_serve_attention.py。该文件同时实现了基于 FlashInfer 的BatchMLAPagedAttentionWrapper包装逻辑flashinfer_attn将压缩 KV、q_absorb/out_absorb吸收矩阵乘法等 MLA 相关步骤交由 FlashInfer 分页注意力完成KQwen3NextAttention/KQwen3NextGatedDeltaNet即在此基础上针对 Qwen3-Next 的层类型全注意力 / 线性注意力分别提供前向实现。在 balance_serve 调度层面自定义模型类 custom_modeling_qwen3_next.py 中的KQwen3NextForCausalLM.forward按config.layer_types[i]区分全注意力层调用decode_layer.self_attn配合 FlashInfer 包装器与分页 KV cache线性注意力层则调用decode_layer.linear_attn并通过conv_states、recurrent_states维护 Gated DeltaNet 的卷积与循环状态——这正是线性注意力状态形状与序列长度无关特性的体现。5.2 动态 Cache 结构原生模型文件 modeling_qwen3_next.py 中的Qwen3NextDynamicCache同时维护两套缓存全注意力层的key_cache/value_cache形状随 seq_len 增长以及线性注意力层的conv_states形状(batch, d_inner, d_conv)与recurrent_states形状(batch, d_inner, d_state)恒定不变。该设计解释了为何 KV cache 管理与传统模型不同也是--cache_lens预算需要单独配置的原因之一。六、访问服务OpenAI 兼容接口调用服务启动后即可用标准 OpenAI Chat Completions 协议发起请求。文档给出的 curl 示例curl -X POST http://localhost:10021/v1/chat/completions \ -H accept: application/json \ -H Content-Type: application/json \ -d { messages: [ {role: user, content: hello} ], model: Qwen3-Next-80B-A3B-Instruct, temperature: 0.3, top_p: 1.0, stream: true }关键点端口必须与启动时的--port 10021一致model字段填模型名与下载的模型对应Instruct 或 Thinking支持temperature、top_p采样参数stream: true启用流式返回该接口与 OpenAI SDK 兼容可直接用openaiPython 客户端接入便于集成到现有应用。七、为什么 Qwen3-Next 暂不支持 CUDA Graph文档在 Notes 中明确指出由于 Qwen3-Next 使用线性注意力CUDA Graph 优化暂不支持——即将到来。结合源码可以给出技术层面的解释动态状态与分支线性注意力层依赖随时间变化的conv_states/recurrent_statesQwen3NextDynamicCache每步生成时状态持续更新且每层还需依据layer_types走不同的前向分支attention vs linear_attnCUDA Graph 要求静态的算子图与固定形状难以直接捕获这类动态执行流。代码层面的显式关闭在 custom_modeling_qwen3_next.py 中KQwen3NextForCausalLM类属性显式声明use_cuda_graph False因此启动命令必须携带--no-use_cuda_graph关闭 CUDA Graph 路径避免调度后端误入不兼容的图捕获流程。FlashInfer 包装器按需 planprefill 阶段的flashInferAttn.plan()依据每个 batch 的 q/kv 索引动态规划分页注意力属于运行时确定的行为与 CUDA Graph 的静态化思路冲突。因此当前 Qwen3-Next 部署以--no-use_cuda_graph为准文档表示官方正在推进 CUDA Graph 支持后续版本可能放开该限制。八、部署注意事项小结严格使用--backend_type balance_serveQwen3-Next 的优化算子尤其注意力依赖 balance_serve 的调度与 cache 结构--optimize_config_path必须指向仓库内真实的Qwen3Next-serve.yaml仓库归档路径为 archive/ktransformers/optimize/optimize_rules/Qwen3Next-serve.yaml否则算子注入规则缺失会导致回退到原生实现丧失异构加速效果机器内存需满足约 320 GB 预算512 专家场景GPU 显存 6 GB 起步实际占用随--cache_lens、--max_batch_size增大而上升Thinking 与 Instruct 两个版本架构一致仅需在下载模型、--model_path/--gguf_path与请求体model字段中保持一致即可切换若需深入了解算子注入框架本身可参阅 doc/en/kt-kernel_intro.md 与 优化规则解析掌握规则语法后可自行扩展其他模型的注入配置。【免费下载链接】ktransformersA Flexible Framework for Experiencing Heterogeneous LLM Inference/Fine-tune Optimizations项目地址: https://gitcode.com/GitHub_Trending/ktr/ktransformers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 KTransformers 部署 Qwen3-Next-80B-A3B 全指南：balance_serve 异质推理、优化规则与线性注意力解析
KTransformers 部署 Qwen3-Next-80B-A3B 全指南balance_serve 异质推理、优化规则与线性注意力解析【免费下载链接】ktransformersA Flexible Framework for Experiencing Heterogeneous LLM Inference/Fine-tune Optimizations项目地址: https://gitcode.com/GitHub_Trending/ktr/ktransformers导读本文基于 doc/en/Qwen3-Next.md完整讲解如何在 KTransformers 框架中以异构CPU GPU方式部署运行 Qwen3-Next-80B-A3B-Thinking / Instruct 两个官方模型。读完本文你将掌握从 GGUF 模型下载、KTransformers 安装到以balance_serve后端启动推理服务并通过 OpenAI 兼容接口发起请求的完整实操链路同时结合仓库源码与Qwen3Next-serve.yaml优化规则理解线性注意力Gated DeltaNet与 512 路 MoE 专家在 KTransformers 中如何被注入替换、如何分布到 CPU/GPU以及为何该模型暂不支持 CUDA Graph 优化。一、背景Qwen3-Next 的架构特点与 KTransformers 支持范围KTransformers 现已官方支持两个 Qwen3-Next 系列模型Qwen3-Next-80B-A3B-Thinking推理增强版本Qwen3-Next-80B-A3B-Instruct指令微调版本Qwen3-Next 是一个典型的 80B 总参数、A3B 活跃参数 的稀疏 MoE 模型其架构与 Qwen3-MoE 有显著差异这也是它在 KTransformers 中需要专门适配的原因。从仓库中 archive/ktransformers/models/configuration_qwen3_next.py 的Qwen3NextConfig默认值可以看出其核心结构参数参数默认值含义hidden_size2048隐藏层维度num_hidden_layers48Transformer 层数num_attention_heads16注意力头数head_dim256多头注意力的投影维度num_experts512路由专家routed experts总数num_experts_per_tok10每个 token 激活的专家数moe_intermediate_size512路由专家中间维度shared_expert_intermediate_size512共享专家中间维度decoder_sparse_step1MoE 层频率每层均为 MoElinear_conv_kernel_dim4线性注意力卷积核大小linear_key_head_dim128线性注意力 K 头维度linear_value_head_dim128线性注意力 V 头维度linear_num_key_heads16线性注意力 K 头数linear_num_value_heads32线性注意力 V 头数max_position_embeddings32768最大序列长度partial_rotary_factor0.25施加 RoPE 的 Q/K 维度比例其中两个最值得关注的设计混合注意力48 层中约每 4 层出现 1 层标准全注意力full attention其余 3 层为线性注意力linear attention。这一层类型序列在配置类中按layer_types自动生成linear_attention if bool((i 1) % 4) else full_attention。超大专家池512 个路由专家、每 token 激活 10 个加上 48 层全 MoEdecoder_sparse_step1权重总量约 80B但单次推理仅计算约 3B 活跃参数。这两点分别决定了 KTransformers 适配时的两条主线为线性注意力编写专用的 Gated DeltaNet 算子见后文第五节以及把绝大多数专家权重卸载到 CPU 内存以换取低 GPU 显存占用。二、资源需求为什么 512 专家只需 6 GB 显存文档明确给出官方资源预估以 512 个专家运行该模型需要约320 GB 内存和6 GB GPU 显存。这一数字背后正是 KTransformers 异构推理的核心思想MoE 专家权重体量巨大占据模型总参数的大部分但每个 token 仅激活其中一小部分。KTransformers 将专家层experts默认放在 CPU 上对应优化规则中generate_device: cpu按需把被路由命中的专家搬运到 GPU 计算同时让注意力、RoPE、归一化、lm_head 等算子驻留 GPUgenerate_device/prefill_device: cuda。因此部署前请务必确认主机具备充足的内存条容量约 320 GB 以上并至少保留 6 GB 空闲 GPU 显存。显存需求还与--cache_lens相关——在 archive/ktransformers/server/args.py 中gpu_memory_size会按cache_lens与 KV cache 结构估算用于调度器的显存预算计算。三、安装 KTransformers 与准备模型3.1 下载 GGUF 模型使用huggingface-cli下载官方发布的 Qwen3-Next 模型GGUF 格式huggingface-cli download --resume-download Qwen/Qwen3-Next-80B-A3B-Instruct如需部署推理增强版本则下载Qwen/Qwen3-Next-80B-A3B-Thinking。--resume-download支持断点续传适合大体积权重下载。下载完成后将模型目录路径分别记录为下述启动命令中的--model_path与--gguf_path。说明文档中的模型链接指向官方发布页模型本体请通过上述官方仓库获取KTransformers 仓库内不包含模型权重。3.2 安装 KTransformers参照仓库自带的官方安装指南完成环境安装安装指南。安装过程会构建 Python 扩展包括 CUDA 侧的 Marlin 量化算子与 CPU 侧的 experts 内核并安装推理服务所需的依赖。本仓库当前将完整 Python 实现归档在archive/ktransformers/目录下运行入口为ktransformers/server/main.py安装后以ktransformers包形式导入。四、启动 Qwen3-Next 推理服务balance_serve 后端4.1 完整启动命令文档给出的服务启动命令如下python ktransformers/server/main.py \ --port 10021 \ --model_path path-to-Qwen3-Next-80B-A3B-Thinking \ --gguf_path path-to-Qwen3-Next-80B-A3B-Thinking \ --model_name Qwen3NextForCausalLM \ --optimize_config_path local_path/ktransformers/optimize/optimize_rules/Qwen3Next-serve.yaml \ --max_new_tokens 1024 \ --cache_lens 32768 \ --chunk_size 256 \ --max_batch_size 4 \ --no-use_cuda_graph \ --backend_type balance_serve对应仓库中的优化规则文件为 archive/ktransformers/optimize/optimize_rules/Qwen3Next-serve.yaml请将其中的local_path替换为仓库实际所在路径。4.2 核心参数说明结合 archive/ktransformers/server/args.py 中的参数解析逻辑各参数含义如下参数示例值说明--port10021服务监听端口用于后续 HTTP 请求--model_path模型目录HuggingFace 格式模型config 与 tokenizer所在路径--gguf_path模型目录GGUF 权重文件所在路径用于GGUFLoader加载量化权重--model_nameQwen3NextForCausalLM指定模型架构类名必须与仓库 models 中注册的类一致--optimize_config_pathQwen3Next-serve.yaml算子注入规则文件决定哪些模块被替换为 KTransformers 优化实现--max_new_tokens1024单次生成的最大新 token 数--cache_lens32768KV cache 长度预算直接影响显存估算与分页调度--chunk_size256Prefill 阶段的分块大小控制长输入按块调度--max_batch_size4服务可同时处理的最大请求批大小--no-use_cuda_graph—显式关闭 CUDA GraphQwen3-Next 必需见第六节--backend_typebalance_serve选择 balance_serve 调度后端这是 Qwen3-Next 的推荐/必需后端其中--backend_type balance_serve尤为关键balance_serve 是 KTransformers 面向并发推理优化的调度后端支持分页 KV cache、批处理 prefill/decode并与下文提到的 FlashInfer MLA 注意力包装器配合使用。五、源码级剖析Qwen3Next-serve.yaml 优化规则KTransformers 通过 YAML 规则文件描述模块匹配—算子替换关系服务启动时据此把原生 HF 模块注入为优化实现。下面逐条解读 Qwen3Next-serve.yaml它共包含 10 条规则#匹配对象原生类/正则名替换为KTransformers 算子设备分配设计意图1Qwen3NextRotaryEmbeddingKQwen3MoeRotaryEmbeddingRoPE.pycuda / cuda复用 Qwen3-MoE 的 RoPE 优化实现2lm_headtorch.nn.LinearKTransformersLineargenerateVLinearMarlinprefillKLinearTorchcuda / cuda输出投影走 GPU Marlin 量化内核3model.layers.*中的普通Linear正则排除mlp.shared_expert_gateKTransformersLineargenerateKLinearMarlinprefillKLinearTorchcuda / cuda各层 QKV/O 投影等线性层量化加速4model.layers.*.mlpQwen3NextSparseMoeBlockKQwen3NextSparseMoeBlockV2experts.pycuda / cuda自定义 MoE 前向流程含路由与调度5model.layers.*.mlp.expertsKTransformersExpertsV2prefillKExpertsTorchgenerateKExpertsCPUout_device: cudacpu / cuda专家权重驻留 CPU按需搬运计算后输出回 GPU6Qwen3NextGatedDeltaNetKQwen3NextGatedDeltaNetbalance_serve_attention.pycuda / cuda线性注意力专用实现7Qwen3NextAttentionKQwen3NextAttentionbalance_serve_attention.pycuda / cuda全注意力走 FlashInfer MLA 包装8model.embed_tokensdefaultcpu / cpuEmbedding 放 CPU减小显存占用9Qwen3NextRMSNormKQwen3NextRMSNormlayernorm.pycuda / cuda归一化层 GPU 化10Qwen3NextMLP共享专家/稠密 MLP 层KQwen2MoeMLPmlp.pycuda / cuda复用 Qwen2-MoE 的 MLP 实现两条正则规则值得注意规则 3 使用负向前瞻^model\.layers\.(?!.*mlp\.shared_expert_gate).*$把各层 Linear 全部替换但排除共享专家门控层避免与规则 4/5 的专家处理冲突。规则 5 显式声明recursive: False防止KTransformersExpertsV2内部子模块被后续规则再次递归注入。设备分配上prefill_device/generate_device分别控制 prefill 与 decode 两个阶段的计算设备专家层在 decode 阶段使用 CPU 内核KExpertsCPU而 prefill 阶段使用 GPU 内核KExpertsTorch这与 512 专家、10 路 Top-K 路由的稀疏特性高度契合——decode 阶段每步仅激活少量专家CPU 上按需计算即可维持高吞吐。5.1 注意力算子的底层实现规则 6、7 替换后的注意力算子位于 balance_serve_attention.py。该文件同时实现了基于 FlashInfer 的BatchMLAPagedAttentionWrapper包装逻辑flashinfer_attn将压缩 KV、q_absorb/out_absorb吸收矩阵乘法等 MLA 相关步骤交由 FlashInfer 分页注意力完成KQwen3NextAttention/KQwen3NextGatedDeltaNet即在此基础上针对 Qwen3-Next 的层类型全注意力 / 线性注意力分别提供前向实现。在 balance_serve 调度层面自定义模型类 custom_modeling_qwen3_next.py 中的KQwen3NextForCausalLM.forward按config.layer_types[i]区分全注意力层调用decode_layer.self_attn配合 FlashInfer 包装器与分页 KV cache线性注意力层则调用decode_layer.linear_attn并通过conv_states、recurrent_states维护 Gated DeltaNet 的卷积与循环状态——这正是线性注意力状态形状与序列长度无关特性的体现。5.2 动态 Cache 结构原生模型文件 modeling_qwen3_next.py 中的Qwen3NextDynamicCache同时维护两套缓存全注意力层的key_cache/value_cache形状随 seq_len 增长以及线性注意力层的conv_states形状(batch, d_inner, d_conv)与recurrent_states形状(batch, d_inner, d_state)恒定不变。该设计解释了为何 KV cache 管理与传统模型不同也是--cache_lens预算需要单独配置的原因之一。六、访问服务OpenAI 兼容接口调用服务启动后即可用标准 OpenAI Chat Completions 协议发起请求。文档给出的 curl 示例curl -X POST http://localhost:10021/v1/chat/completions \ -H accept: application/json \ -H Content-Type: application/json \ -d { messages: [ {role: user, content: hello} ], model: Qwen3-Next-80B-A3B-Instruct, temperature: 0.3, top_p: 1.0, stream: true }关键点端口必须与启动时的--port 10021一致model字段填模型名与下载的模型对应Instruct 或 Thinking支持temperature、top_p采样参数stream: true启用流式返回该接口与 OpenAI SDK 兼容可直接用openaiPython 客户端接入便于集成到现有应用。七、为什么 Qwen3-Next 暂不支持 CUDA Graph文档在 Notes 中明确指出由于 Qwen3-Next 使用线性注意力CUDA Graph 优化暂不支持——即将到来。结合源码可以给出技术层面的解释动态状态与分支线性注意力层依赖随时间变化的conv_states/recurrent_statesQwen3NextDynamicCache每步生成时状态持续更新且每层还需依据layer_types走不同的前向分支attention vs linear_attnCUDA Graph 要求静态的算子图与固定形状难以直接捕获这类动态执行流。代码层面的显式关闭在 custom_modeling_qwen3_next.py 中KQwen3NextForCausalLM类属性显式声明use_cuda_graph False因此启动命令必须携带--no-use_cuda_graph关闭 CUDA Graph 路径避免调度后端误入不兼容的图捕获流程。FlashInfer 包装器按需 planprefill 阶段的flashInferAttn.plan()依据每个 batch 的 q/kv 索引动态规划分页注意力属于运行时确定的行为与 CUDA Graph 的静态化思路冲突。因此当前 Qwen3-Next 部署以--no-use_cuda_graph为准文档表示官方正在推进 CUDA Graph 支持后续版本可能放开该限制。八、部署注意事项小结严格使用--backend_type balance_serveQwen3-Next 的优化算子尤其注意力依赖 balance_serve 的调度与 cache 结构--optimize_config_path必须指向仓库内真实的Qwen3Next-serve.yaml仓库归档路径为 archive/ktransformers/optimize/optimize_rules/Qwen3Next-serve.yaml否则算子注入规则缺失会导致回退到原生实现丧失异构加速效果机器内存需满足约 320 GB 预算512 专家场景GPU 显存 6 GB 起步实际占用随--cache_lens、--max_batch_size增大而上升Thinking 与 Instruct 两个版本架构一致仅需在下载模型、--model_path/--gguf_path与请求体model字段中保持一致即可切换若需深入了解算子注入框架本身可参阅 doc/en/kt-kernel_intro.md 与 优化规则解析掌握规则语法后可自行扩展其他模型的注入配置。【免费下载链接】ktransformersA Flexible Framework for Experiencing Heterogeneous LLM Inference/Fine-tune Optimizations项目地址: https://gitcode.com/GitHub_Trending/ktr/ktransformers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考