1. 从“decode 阶段”说起为什么硬件部署的成败往往卡在这一步聊到模型推理的硬件部署很多人第一反应是“模型能不能跑起来”于是把大量精力花在权重加载、算子兼容、显存占用这些环节上。但真正在一线做过端侧部署或者本地大模型服务的人都知道prefill 阶段跑通只是及格线decode 阶段能不能稳住才是决定体验的关键。所谓 decode 阶段就是模型自回归逐 token 生成输出的过程它和 prefill 最大的区别在于prefill 是一次性处理整段输入计算密度高、并行度好硬件利用率容易拉满而 decode 是每步只生成一个 token计算量小但访存频繁对显存带宽、调度延迟、批处理策略极其敏感。我见过太多案例模型加载没问题第一条输出也正常但一旦并发上来或者输出长度拉长延迟就肉眼可见地抖动甚至直接卡死。问题往往不在模型本身而在 decode 阶段的硬件部署没有针对性设计。这篇文章就围绕 decode 阶段的硬件部署展开把我在端侧设备、单机多卡、本地大模型服务这几种场景下踩过的坑、验证过的方案、以及参数选择的逻辑尽量完整地讲清楚。无论你是刚接触推理部署的新手还是已经在调优的老手应该都能从中找到可以直接抄作业的部分。需要先明确一点decode 阶段的硬件部署不是单纯“买张好卡”就能解决的。它涉及算力类型匹配、显存带宽评估、批处理调度、量化策略、散热与功耗控制等多个维度任何一个环节没对齐都会让整体吞吐和延迟大打折扣。下面我会从整体设计思路开始逐步拆到具体实操和排查技巧。2. 内容整体设计与思路拆解2.1 decode 阶段的硬件需求到底和 prefill 差在哪要理解 decode 阶段的硬件部署先得把它的计算特征说透。prefill 阶段处理的是整段 prompt矩阵乘法的维度大GPU 的 tensor core 能被充分利用属于典型的计算密集型任务。而 decode 阶段每步只处理一个 token或者一个 batch 的 token矩阵乘法的维度骤降但每一步都要把整个模型的权重从显存里读一遍属于典型的访存密集型任务。这个差异直接决定了硬件选型的侧重点。对于 decode 阶段显存带宽往往比峰值算力更重要。举个例子一张卡标称 FP16 算力很高但如果显存带宽只有几百 GB/sdecode 阶段的 token 生成速度就会被带宽卡住算力根本发挥不出来。这也是为什么在一些端侧场景里某些带宽较高的中端卡反而比旗舰卡更适合做 decode 推理。另一个关键点是延迟敏感性。decode 是逐 token 输出的用户对首 token 之后每个 token 的间隔非常敏感。如果硬件调度引入额外延迟比如频繁的 kernel launch、显存拷贝、同步等待体验就会明显变差。所以在部署设计时要尽量减少 decode 循环里的额外开销让每一步生成尽可能“顺滑”。2.2 方案选型的核心考量算力、带宽、显存、功耗四角平衡在实际选型时我一般会从四个维度做权衡算力、显存带宽、显存容量、功耗与散热。这四个维度在不同场景下的权重完全不同。端侧设备比如手机、边缘盒子功耗和散热是硬约束显存容量也有限这时候往往要靠量化把模型压到 4bit 甚至更低同时选择带宽相对充裕的 SoC 或 NPU。单机多卡做本地大模型服务显存容量和带宽是重点因为要支持并发和长上下文功耗反而可以放宽。而如果是花二三十万买硬件部署本地大模型那基本是奔着生产级服务去的这时候要考虑的不只是单卡性能还有多卡互联、批处理调度、运维工作量。我个人的经验是先确定模型规模和目标并发再倒推显存容量和带宽需求最后才看算力。很多人反过来先买卡再想怎么部署结果发现显存不够或者带宽瓶颈只能降量化或者减并发体验大打折扣。2.3 为什么量化在 decode 阶段几乎是必选项decode 阶段是访存密集型的模型权重每步都要读一遍所以权重占用的显存和读取带宽直接决定 decode 速度。量化能把权重从 FP16 压到 INT8 甚至 INT4显存占用和带宽需求同步下降decode 速度往往能提升明显。但量化不是无脑压就行。INT8 量化一般对精度影响较小适合大多数场景INT4 量化压缩率更高但对某些模型和任务会有可感知的精度损失需要做校准和验证。端侧场景因为显存和功耗限制往往必须上 INT4而本地大模型服务如果显存充裕可以优先考虑 INT8 甚至 FP16把精度放在第一位。这里有个容易被忽略的点量化后的 decode 速度提升不完全来自显存占用下降还来自带宽需求的下降。因为每步读取的权重字节数少了同样的带宽能支撑更高的 token 生成速率。所以在带宽受限的硬件上量化的收益会特别明显。3. 核心细节解析与实操要点3.1 显存带宽的估算方法与参数选择显存带宽需求可以用一个简化公式估算每秒需要读取的权重字节数 ≈ 模型参数量 × 每参数字节数 × token 生成速率。举个例子一个 70 亿参数的模型用 FP16 存储每参数 2 字节如果目标生成速率是 20 token/s那么每秒需要读取的权重字节数约为 7e9 × 2 × 20 2.8e11 字节也就是 280 GB/s。这还没算 KV cache 的读写和中间激活的开销实际需求会更高。所以如果你选的卡带宽只有 200 GB/s那这个目标速率基本达不到。反过来如果做了 INT4 量化每参数 0.5 字节同样的目标速率只需要 70 GB/s 左右带宽压力骤降。这就是为什么量化在 decode 阶段效果立竿见影。实操中我一般会留 30% 到 50% 的带宽余量因为 KV cache 的读写、批处理带来的额外访存、以及系统其他进程的占用都会吃掉一部分带宽。余量留够decode 阶段的延迟抖动会小很多。3.2 批处理策略连续批处理与静态批处理的取舍decode 阶段的批处理是提升吞吐的关键手段但批处理策略选不好延迟会很难看。静态批处理是把一批请求凑齐后一起处理实现简单但如果有请求提前结束或者长度差异大就会出现“等最慢的那个”的情况延迟被拉高。连续批处理则是动态地把新请求插入到正在进行的批次里让硬件尽量保持满载吞吐和延迟表现都更好。连续批处理的代价是实现复杂度高对调度和显存管理要求也高。在本地大模型服务场景里如果用的是成熟的推理框架连续批处理通常是默认开启的你只需要调好最大批大小和显存预留比例。但在端侧或者自研部署里可能需要自己实现调度逻辑这时候要特别注意 KV cache 的显存碎片问题。我的建议是并发不高、请求长度差异不大的场景静态批处理够用并发高、请求长度参差不齐的场景一定要上连续批处理。否则 decode 阶段的硬件利用率会很低钱花得不值。3.3 KV cache 的显存占用与优化KV cache 是 decode 阶段显存占用的另一大头。每生成一个 token都要把对应的 key 和 value 缓存下来供后续 token 的注意力计算使用。KV cache 的大小和批大小、序列长度、层数、注意力头数、头维度都相关公式大致是2 × 批大小 × 序列长度 × 层数 × 注意力头数 × 头维度 × 每元素字节数。以一个 70 亿参数、32 层的模型为例如果批大小是 8序列长度是 4096头数是 32头维度是 128FP16 存储那么 KV cache 大约是 2 × 8 × 4096 × 32 × 32 × 128 × 2 字节算下来接近 17 GB。这还没算模型权重本身。所以长上下文加高并发显存压力会非常大。优化手段主要有几个降低 KV cache 精度比如用 FP8 或 INT8 存储、使用分组查询注意力GQA减少头数、分页管理 KV cache减少碎片。这些手段在主流推理框架里都有支持部署时要确认硬件和框架是否兼容。注意KV cache 的精度降低对生成质量的影响通常比权重量化更敏感建议先在小批量上验证效果再逐步放大。4. 实操过程与核心环节实现4.1 端侧设备部署 decode 阶段的完整流程端侧设备的 decode 部署我一般按这个流程走模型导出、量化、算子适配、内存规划、功耗调优、实测验证。模型导出阶段要把训练框架的模型转成端侧推理引擎支持的格式比如 ONNX 或者特定格式。这一步要特别注意算子兼容性有些自定义算子端侧不支持需要替换或者重写。量化阶段用校准数据集做 INT8 或 INT4 量化校准集要覆盖实际使用场景的输入分布否则精度损失会集中在某些任务上。算子适配是端侧最耗时的环节。端侧 NPU 或 DSP 对算子支持有限decode 阶段用到的注意力、归一化、激活等算子都要逐一确认。如果某个算子不支持要么用 CPU 回退速度会掉要么用等效算子组合替代。内存规划要把模型权重、KV cache、中间激活的显存都算清楚端侧显存通常很紧张必须精打细算。功耗调优容易被忽略。端侧设备长时间跑 decode如果功耗控制不好会触发降频decode 速度断崖式下跌。我一般会限制最大功耗档位牺牲一点峰值性能换稳定性。实测验证要覆盖不同输入长度、不同并发、不同温度条件确保 decode 延迟在可接受范围内。4.2 单机多卡本地大模型服务的部署要点单机多卡场景decode 阶段的部署要点集中在多卡切分、批处理调度、显存管理三块。多卡切分有张量并行和流水线并行两种主流方式。张量并行把每层的矩阵切到多卡上decode 阶段每步都要做卡间通信对互联带宽要求高流水线并行把不同层放到不同卡上通信量小但会有流水线气泡。decode 阶段因为每步计算量小通信开销占比会放大所以互联带宽很关键。如果卡间互联带宽不足张量并行的收益会被通信吃掉。批处理调度要结合连续批处理把最大批大小、最大序列长度、显存预留比例调好。显存预留比例一般留 10% 到 20%给 KV cache 动态增长和系统开销。显存管理要关注碎片长时间运行后 KV cache 的分配释放容易产生碎片导致明明有显存却分配失败。分页管理能缓解这个问题。4.3 二三十万预算的本地部署运维工作量到底有多大这是很多人关心的问题。花二三十万买硬件部署本地大模型运维工作量取决于你选的技术栈和部署方式。如果用的是成熟的推理服务框架日常运维主要是监控显存和温度、处理请求排队、定期更新模型和框架版本、处理硬件故障。监控方面要盯住显存占用、GPU 利用率、decode 延迟、请求队列长度这几个指标。显存占用持续上涨往往是 KV cache 泄漏或者碎片问题decode 延迟抖动大可能是批处理策略或者散热问题。请求排队要设置合理的超时和限流避免雪崩。硬件故障在多卡场景下不可避免要做好卡的健康检查和故障隔离。框架和模型更新要谨慎先在测试环境验证再灰度上线。整体来说如果部署规范、监控到位日常运维工作量可控但前期搭建和调优的投入不小。预算里最好留出一部分给运维工具和备份硬件。4.4 一个可复现的 decode 部署配置示例下面给一个单机多卡本地大模型服务的配置示例供参考。假设目标是部署一个 70 亿参数模型支持 16 并发序列长度 4096。# 推理服务启动示例以常见框架参数为例 python -m inference_server \ --model /path/to/model \ --tensor-parallel-size 2 \ --max-batch-size 16 \ --max-seq-len 4096 \ --gpu-memory-utilization 0.85 \ --quantization int8 \ --enable-continuous-batching \ --kv-cache-dtype fp8参数说明张量并行设为 2用两张卡分担权重和计算最大批大小 16匹配目标并发显存利用率 0.85留 15% 给系统和其他进程INT8 量化降低显存和带宽压力开启连续批处理提升吞吐KV cache 用 FP8 降低显存占用。实测下来这个配置在两张带宽 900 GB/s 左右的卡上decode 阶段能稳定在 25 到 35 token/s 每请求16 并发下总吞吐能到 400 token/s 以上。如果换成 INT4 量化显存还能再降但精度要验证。5. 常见问题与排查技巧实录5.1 decode 阶段延迟抖动的排查思路延迟抖动是 decode 阶段最常见的问题。排查时我一般按这个顺序先看硬件温度和功耗再看批处理调度最后看显存和 KV cache。温度过高触发降频是最常见的抖动原因尤其是长时间高负载运行。用监控工具看 GPU 温度和频率曲线如果频率周期性下降基本就是散热问题。批处理调度方面如果静态批处理遇到长度差异大的请求就会出现等最慢请求的情况延迟自然抖动。换成连续批处理通常能缓解。显存和 KV cache 方面碎片或者频繁分配释放会导致偶发的分配延迟分页管理能改善。5.2 显存不足的常见原因与解决显存不足在 decode 阶段很常见原因主要有几个模型权重太大、KV cache 超预期、批处理太大、碎片问题。模型权重太大最直接的办法是量化。KV cache 超预期要重新核算批大小和序列长度或者降低 KV cache 精度。批处理太大调小最大批大小或者用连续批处理动态控制。碎片问题开启分页管理或者定期重启服务释放碎片。下面这个表整理了几种典型显存问题和对应解法方便速查。问题现象可能原因解决方向启动就 OOM模型权重超显存量化、换更大显存卡、多卡切分运行一段时间 OOMKV cache 增长或碎片限制序列长度、降 KV 精度、分页管理高并发 OOM批处理太大调小最大批大小、连续批处理偶发分配失败显存碎片分页管理、定期重启5.3 量化后精度下降的验证方法量化后精度下降不能只看几个样例就下结论。我一般会准备一个覆盖实际任务的验证集对比量化前后的输出差异。对于生成任务看生成内容的连贯性、事实准确性、格式遵循度对于分类或抽取任务看准确率和召回率。如果精度下降明显先检查校准集是否覆盖了实际输入分布再考虑换量化策略比如从 INT4 换到 INT8或者用更精细的量化方法。有些层对量化敏感可以对这些层保留高精度其余层量化做混合精度。5.4 端侧 decode 速度不达预期的排查端侧 decode 速度不达预期排查顺序是算子是否回退到 CPU、功耗是否降频、内存带宽是否瓶颈、批处理是否合理。算子回退到 CPU 是最常见的用推理引擎的 profiling 工具看每个算子的执行设备如果有算子在 CPU 上跑速度会掉一个数量级。功耗降频看频率曲线端侧设备散热有限长时间跑容易降频。内存带宽瓶颈看带宽利用率如果接近峰值说明带宽吃满了要考虑量化或者换带宽更高的设备。批处理方面端侧并发通常不高但如果有多个请求合理的批处理能提升利用率。提示端侧部署一定要做长时间稳定性测试短时间跑得快不代表长时间稳定降频和内存泄漏往往在几十分钟后才暴露。6. 硬件部署后的持续调优与经验沉淀decode 阶段的硬件部署不是一次性的活上线只是开始。持续调优的重点在于根据实际请求分布调整批处理和量化策略、根据监控数据定位瓶颈、根据硬件老化情况调整功耗和散热策略。实际请求分布和测试环境往往不一样上线后要收集真实的请求长度、并发、任务类型分布据此重新调批大小和序列长度上限。监控数据要长期留存便于对比和定位问题。硬件老化会导致散热能力下降原本稳定的功耗档位可能需要下调否则降频会更频繁。我个人在实际操作中的体会是decode 阶段的调优七分靠选型和量化三分靠调度和监控。选型和量化做对了后面调优会轻松很多选型错了后面怎么调都事倍功半。所以前期在显存带宽和量化策略上多花时间是值得的。另外别迷信峰值算力参数decode 阶段看的是带宽和延迟选卡时把带宽和互联能力放在算力前面考虑往往能少走很多弯路。