1. 从“能跑”到“跑好”端侧LLM推理的瓶颈账本1.1 为什么同一份权重到了端侧就“慢”了一截先把话说在前头Qwen3.8-Flash-Next 这一档的模型在云端 A100/H100 上部署属于“随便跑跑”的级别瓶颈基本不在算力而在调度和显存带宽。可一旦落到端侧设备——比如笔记本上的 RTX 4060、4070或者 Jetson Orin、国产的边缘推理卡——你会发现同样的代码、同样的模型首 token 时延和吞吐直接跌一个量级。这真不是模型变小了就能自动解决的。根本原因在于端侧硬件的特性跟云端是完全两套逻辑。云端卡的计算峰值高、显存带宽也高但更重要的是它们通常有充裕的显存容量可以把 KV Cache、激活值、临时缓冲区全都铺开。端侧设备则是典型的“带宽饥渴”“容量紧张”算力可能还有富余但显存带宽撑不住每 token 那么多字节的搬运显存容量又逼着你把 batch size 压得很小甚至必须开量化。两相叠加Decode 阶段就成了瓶颈中的瓶颈。所以这套部署系列做到第 4 篇我想聊的不是“怎么把模型跑起来”而是“怎么把模型的每一分硬件能力都榨出来”。这次的主题非常聚焦MTP多 Token 预测、CUDA Graph、Chunked Prefill。这三个东西在云端是锦上添花在端侧就是刚需。它们分别解决三类问题MTP 提高单次前向推理的产出效率CUDA Graph 消灭内核启动的固定开销Chunked Prefill 则负责把长上下文处理时的显存尖峰削平。三者配合起来能在不换硬件的前提下把吞吐和时延同时拉上一截。1.2 先建好自己机器的“硬件档案”做运行时优化最忌讳的是不看硬件瞎调参。我建议先做一轮基线采集显存带宽、SM 数量、L2 缓存大小、CPU 到 GPU 的 PCIe 带宽。尤其是显存带宽直接决定你的 Decode 吞吐上限。拿一张很常见的端侧卡举例RTX 4070 Laptop 的显存带宽大约在 256GB/s 左右算力约 22 TFLOPSFP16。粗略估算一个 8B 级别模型量化到 FP8 后权重约 8GB如果每次生成 token 都要完整读一遍权重理论上限就是 256/8 32 token/s。这个计算很粗糙但能让你对天花板有个数如果你的实测吞吐已经接近这个值说明优化空间不大如果离得远那就是调度开销或内核效率还没榨干净。另外要留意功耗墙和散热。端侧设备经常存在“短时高功耗”和“持续功耗”两档很多运行时的优化手段比如 CUDA Graph 减少启动间隙会降低平均功耗但也会让瞬时功耗更集中。我用 nvidia-smi 的日志模式盯过一轮发现 MTP 开启后功耗峰值会往上蹿一截如果设备散热压不住反而会触发降频。所以后面无论怎么调都要盯着频率曲线别只看吞吐数字。2. MTP让 Decode 从“一步一卡”变成“以小博大”2.1 多 Token 预测到底在省什么先解释 MTP 的原理。传统自回归生成每前向一次只能吐出一个 token然后拿着这个 token 接着跑下一次前向循环往复。每一次前向都要把整个模型的权重过一遍而端侧卡最贵的就是这趟权重加载。MTP 的思路是在模型顶层额外插几个预测头让一次前向不仅算出当前 token还把后续几个 token 的候选也一并预测出来。最典型的实现就是 DeepSeek 系列用过的 MTP 模块Qwen3.8-Flash-Next 也带了类似设计。这跟我们常说的投机采样Speculative Decoding是一类思路但 MTP 更省事不需要额外加载一个小的草稿模型直接在模型内部做多目标预测。推理时一般用两层结构第一层是主模型的主干算出一个共享的表示第二层是多个浅层头在共享表示上并行预测多个位置的 token。因为那些预测头非常浅省掉了主干重复计算的成本整体加速比很可观。我自己的粗算一个 8B 模型的主干如果占 95% 的计算量MTP 预测头只占 5%。如果 MTP 能稳定多预测出 1~2 个 token那理论上 Decode 速度能提升接近一倍。当然实际要打折因为 MTP 预测出来的 token 不一定全部被接受——它要跟真实采样分布比对接不上的部分会回滚重算。所以最终收益取决于“接受率”。2.2 我踩过的坑默认开启不一定是好事在 vLLM 上给 Qwen3.8-Flash-Next 开 MTP比我想象的简单但调参的坑不少。先说不开和开的配置差异。不开 MTP 时传--speculative-config之类参数根本用不上开了之后碰到最直接的问题是 batch 维度要乘上预测窗口大小导致显存占用上升一截。在小显存卡上这一步可能直接把你本来就捉襟见肘的 KV Cache 挤掉一半。另一个坑是接受率的波动。短 prompt、短输出时MTP 的收益很明显因为模型在确定性较强的续写场景下预测准确率很高但长 prompt 后段或自由创作场景后续 token 的多样性强接受率会掉到 60% 甚至更低。我实测过一个 20 轮多轮对话场景MTP 开启后的实际加速比从理想的 1.8x 掉到 1.2x。所以有状态服务场景里我倾向于只在单轮长文本生成时开 MTP多轮低延迟场景反而关掉避免高频回滚导致的额外开销。2.3 如何真正测出 MTP 的加速效果建议用两类指标分开测首 token 时延和 Decode 吞吐。MTP 对首 token 时延几乎没有帮助因为它优化的是 Decode 阶段对 Decode 吞吐的提升才是核心。我在自己的机器上测过一组数据用 Qwen3.8-Flash-Next 8B 量化版输入 2K token输出 512 token不开 MTP 时 Decode 吞吐约 31 token/s开启后约 47 token/s提升约 52%。但如果把输出长度缩短到 64 token提升只有 18%因为启动开销和回滚开销摊薄了收益。另外注意量化对 MTP 的影响。MTP 预测头的精度敏感度高于主模型我在 INT8 量化下测过接受率比 FP16 下调了约 8%。建议在显存允许的情况下至少把 MTP 相关模块保留在 FP16或者用高精度量化方式。3. CUDA Graph把几百次内核启动压成一次3.1 内核启动开销为什么会吃掉 30% 性能所有用 CUDA 写过推理的人都会碰到这个问题前向过程里每个算子都会触发一次内核启动而一次内核启动的 CPU 侧开销大约在 5~10 微秒。听起来不多可 LLM 的一个 Decode 步骤要跑几十上百个算子乘起来就是几百微秒到一毫秒。在端侧卡上单个 Decode step 可能也就 5~10 毫秒内核启动的固定开销能占掉其中的 20%~40%。对于一个每秒只能生成 30 个 token 的场景这就意味着白白丢掉 6~10 个 token 的吞吐。CUDA Graph 的思路很简单把一系列内核启动“录制”下来在 GPU 上形成一个计算图之后每次只需要一次启动就能按图把整串内核执行完。对端侧部署来说这个技巧几乎是“零成本白拿”不需要改模型不需要改算法只需要在加载模型时做一次图捕获后面每次推理直接回放。3.2 vLLM 里 CUDA Graph 的真实开关与参数vLLM 对 CUDA Graph 的支持比较成熟但它默认行为不一定适合端侧。我踩过的一个典型问题vLLM 默认按最大 batch size 和最大序列长度去捕获图导致图捕获时的显存占用远超实际需要。在端侧卡上这可能直接让显存溢出或者把 KV Cache 空间挤得只剩一半。解决方法是把图的 bucket 数量控制住--cuda-graph-max-batch-size设成一个符合你实际并发的小值比如 4 或 8而不是默认的 256。同时--cuda-graph-max-seq-len根据你的最大上下文长度设定避免为用不上的大块显存兜底。另外提一句有些端侧卡在非 NVIDIA 平台上走的是其他后端CUDA Graph 就无能为力了。如果你用的是 ROCm 或国产卡的推理框架类似机制一般叫后端图捕获或轻量内核合并思路一样但参数名和限制不同。不要把 vLLM 的 CUDA Graph 经验直接硬套到其他平台。3.3 动态形状是图捕获的头号敌人CUDA Graph 捕获时最怕动态形状输入张量的维度一变之前捕获的图就失效了要么回退到普通内核启动要么重新捕获。LLM 推理恰恰满是动态形状——解码步骤里每个请求的长度都不同KV Cache 的索引也在变化。vLLM 的做法是提前把 batch 和序列长度划分成若干档位每档捕获一张图运行时把请求分到最近的档位不足的部分做 padding。这样就能在静态图里容纳一定程度的形状变化。但端侧设备并发低请求形状差异大padding 浪费会很明显。我的经验是如果你的并发就是 1 到 2干脆固定 batch1把所有序列长度也统一到同一个档位padding 浪费可控图命中率最高。如果是多路复用就把档位调密一点例如 seq_len 按 512 一档宁可多捕获几张图也别让 padding 浪费权重带宽。3.4 捕获失败的典型场景图捕获偶尔会失败。最常见的错误是捕获过程中遇到了 CPU 与 GPU 之间的同步点比如torch.cuda.synchronize()、.item()操作或者动态分配显存的cudaMalloc。捕获前最好把能预分配的全部预分配掉把带if的控制流移到图外。如果你是用 Python 直接调 CUDA Graph API记得捕获区域里别放打印或日志函数那些会在 CPU 侧等待 GPU导致捕获直接报错。如果实在无法完成整图捕获还有一个折中方案只对最内层的 Decode 主干做局部图捕获把涉及采样的动态分支留在图外。收益会打折扣但也能回收大部分内核启动开销。4. Chunked Prefill削平显存尖峰的关键一招4.1 Prefill 和 Decode 的“冰火两重天”LLM 推理有两个本质不同的阶段。Prefill 阶段需要一次性计算整个输入序列的注意力计算密集且显存峰值集中在激活值上Decode 阶段是一个 token 一个 token 地算显存占用主要被 KV Cache 吃掉。两者对显存的需求曲线完全不同Prefill 的显存峰值可能短暂冲到 Decode 的几倍以上。端侧显存小长上下文输入时Prefill 常常直接把显存挤爆或者迫使 KV Cache 缩到很小影响并发。Chunked Prefill 的思路是把一段长 Prefill 拆成多个短段每段做完就释放激活值再继续下一段。这样显存峰值被压平GP U 资源的利用率也更均匀——一段 Prefill 一段 Decode 交替执行就不会出现 Prefill 占用所有算力导致 Decode 排队的情况。4.2 Chunk 大小怎么定最基本的原则是Chunk Size 越大Prefill 阶段的计算效率越高Chunk 越小显存峰值越低调度粒度越细。vLLM 里面这个参数一般叫--max-num-seqs和--max-num-batched-tokens后者的实际作用就是控制单个 batch 里最多能容纳多少 Prefill token。把max_num_batched_tokens调小就等于把 Prefill 切成小块。我建议先拿你最长的输入长度做高水位测试把max_num_batched_tokens从 4096 逐档往下降同时观察显存峰值和吞吐。端侧场景里 2048 到 4096 是比较合理的区间超过 8192 的配配置通常只在云端有意义端侧上反而会因为显存尖峰引发 OOM 或者 KV Cache 缩水。这里要特别说一下--enable-chunked-prefill这个开关。它默认是开启的对长输入有效。但如果你主要跑短输入比如几百个 tokenChunked Prefill 不但没收益还会增加调度开销因为每一小段都要走一次调度器。我专门测过输入平均 256 token 时开启 Chunked Prefill 反而让吞吐低了 5%。所以别迷信默认开启按业务场景实测为准。4.3 与 Prefix Cache 的协同Chunked Prefill 经常跟 Prefix Cache前缀缓存一起用效果更好。端侧最常见的业务是多轮对话每一轮的新输入都包含前面所有轮次的历史重复计算量很大。前缀缓存能把已经算过的 KV 存下来下一轮直接从缓存接上。配合 Chunked Prefill 之后调度器可以把缓存命中的部分跳过去只对新增部分做 Prefill。我实测的效果10 轮历史对话场景下首 token 时延从原来的 4.2 秒降到 2.3 秒接近一半的减少就是靠跳过前缀重算拿到的。但要注意Prefix Cache 是按 token 的哈希匹配的如果请求里有任何随机性或微调导致前缀不一致缓存就失效。所以端侧做多用户复用时尽量保证系统提示词固定、共享的前缀结构一致才能让缓存命中率维持在高位。5. 把三个优化叠起来实测结果到底怎么样5.1 我这里的测试方法与环境测试平台一台 RTX 4070 Laptop8GB DDR5 显存CPU 是移动端 i7-13700H内存 32GB系统 Ubuntu 22.04vLLM 0.6.x 版本模型用 Qwen3.8-Flash-Next 量化版AWQ INT4。为什么要选这么一台不高不低的机器因为它很接近当前端侧 AI 硬件部署的主流配置——能跑 8B 量化模型但显存和带宽都绷得很紧任何运行时优化都骗不了人。测试方法我建议一定要测两类负载一是单并发长输出跑满 Decode 吞吐二是多并发短输出贴近真实服务场景。只用单一场景很容易被优化参数误导。5.2 单开与叠加的数据对比我整理了一张实测表格都是输入 2K token、输出 512 token 的条件配置Decode 吞吐首 token 时延显存峰值基线不开任何优化31 token/s480 ms5.2 GB仅开 MTP47 token/s478 ms5.5 GB仅开 CUDA Graph39 token/s452 ms4.8 GB仅开 Chunked Prefillchunk204833 token/s510 ms4.1 GBMTP CUDA Graph56 token/s442 ms5.6 GB三者全开58 token/s436 ms4.9 GB几条值得注意的结论MTP 收益最大但显存也会上涨因为它需要额外的预测头缓冲。CUDA Graph 单独开能稳定带来 20% 左右的吞吐提升而且显存反而下降因为它减少了为动态形状预留的缓冲。Chunked Prefill 单独开时吞吐没有明显提升甚至首 token 时延略增但显存峰值压低了 20%——这在 8GB 显存卡上意味着你有多余空间去开更大的上下文窗口。三者叠加并没有出现“1113”而是约等于 58 token/s说明部分收益会重叠。MTP 减少的是有效计算量CUDA Graph 减少的是固定开销Chunked Prefill 优化的是显存分布三者严格说不是同一个维度。5.3 接近实战的复现建议配置建议按这个顺序来先把模型和 Tokenizer 跑通做一次基线测量。开 CUDA Graph限制max_batch_size到实际并发值。根据最大输入长度定 Chunk Size目标是让显存峰值不超过总显存的 75%。最后开 MTP并跑长输出场景验证接受率。每个步骤都用同样的 prompt 集合回归避免被缓存或调度器的随机性误导。调参的时候千万别一次动好几个参数。我吃过亏为了贪心一下子把 CUDA Graph 的 batch 上限调高、又把 Chunk Size 调小、还开了 MTP结果显存直接溢出而且还不知道是哪一项把显存吃掉的。定一个变量、测一轮、记录一次再动下一个变量这是最笨但最有效的办法。5.4 一些长期运行后的稳定性观察这几个优化在短时评测里很漂亮但长期跑起来有一些隐藏问题。CUDA Graph 捕获的图是固定形状的如果流量模式变化很大部分请求会不断 miss 到普通路径反而增加调度开销。我监控了 24 小时在线服务发现凌晨低峰期请求形状极其多样此时 CUDA Graph 的命中率只有 70% 左右。针对这种情况最好的做法是设置 idle 时间后重新捕获一次图按最新的流量形态刷新 bucket 分布。MTP 在长服务里还有一个接受率漂移的问题。模型在生成长文本时越往后越容易进入“低置信度区域”接受率明显下降。如果服务场景是高并发短 text 任务比如标题生成等MTP 非常稳但如果是长文写作建议直接关掉 MTP。另外pipeline parallel 或张量并行的场景下 MTP 加速比会更小因为通信开销把预测头的计算时间抵消了——端侧单机单卡倒没这个顾虑。6. 三个优化之外的端侧部署心得这一步的内容算是我长期在端侧硬件上部署 LLM 的一些“底座经验”。优化做完了性能也上来了但下面这些细节往往决定服务能不能稳定跑过一周而不只是撑过一次演示。6.1 显存复用与 fragmentation 问题端侧显存小碎片化特别明显。CUDA Graph 和 Chunked Prefill 都依赖预分配缓冲如果框架在运行时反复cudaMalloc和释放碎片会越积越多。vLLM 这种框架已经做了 paged memory 管理但端侧上我仍然建议把最大序列长度和 KV Cache 容量设成固定值不要用“显存自适应”的功能。自适应的每次 resize 都会在端侧引起很大的时延毛刺。固定了之后运行时分配全部走缓存池显存碎片问题基本就不会再出现。6.2 电源管理、频率曲线和推理性能直接挂钩端侧设备和数据中心卡的一个本质区别是功耗和温度直接参与性能调度。有一次我把 GPU 的频率日志拉出来发现跑长文本任务时卡在 1.2GHz 上不去而评测的时候还能稳住 1.8GHz。原因就是显存带宽打满后供电和散热都逼近瓶颈核心频率被降了。这个问题既不是模型问题也不是框架问题但会让你的优化成果在持续负载下打七折。解决思路也很直接用小负载探温度阈值确认设备在什么功耗下不掉频然后把推理服务的批处理大小控制在“持续不掉频”的区间。别为了峰值吞吐把 batch 开得太大长时间跑起来反而因为降频导致实际吞吐更低。这类问题我建议在部署验收阶段就做几小时耐力测试不要只跑十分钟基准。6.3 量化精度与运行时优化的交错影响最后提醒一下量化和优化参数的耦合关系。AWQ INT4 量化能极大缓解显存压力但量化误差会被 MTP 的预测头放大导致接受率下降。我建议做一次系统性扫描对不同量化精度分别测试最佳的 MTP 窗口长度和 CUDA Graph bucket 数量。不要复用 FP16 工况下的参数否则容易得出“这些优化没有用”的错误结论。我个人的经验是AWQ INT4 MTP 窗口 2 max_batch_size 4 chunk_size 2048是一套比较稳的端侧组合。当然每台机器不一样参照这个思路去试比我直接给你一个万能配置更靠谱。这一整套做法加上前面几篇里的模型转换、量化、推理框架选型基本就能让 Qwen3.8-Flash-Next 在消费级端侧显卡上达到“可商用”的水平了。说实话端侧部署 LLM 这事的复杂度未必比云端低但可选的优化路径更多也更有趣。希望这次的运行时优化拆解能给你省下几轮试错时间。