1. 为什么大模型部署要聊从单机到集群这个演进1.1 单机部署不是起点而是最该被认真对待的阶段很多刚接触大模型的人看到动辄几十GB甚至上百GB的模型权重文件下意识觉得这玩意儿肯定得上集群。但实际落地的时候我见过太多反例某个内部知识库问答项目模型量化到4bit之后只有不到7GB一张消费级显卡就能跑起来日调用量只有几百次直接单机部署绰绰有余。这种情况下硬上集群纯粹是给运维和自己找麻烦。单机部署最大的价值有三个。一是验证成本极低改代码、重启、看日志的迭代闭环非常短特别适合调prompt、调采样参数、调后处理逻辑二是排除变量分布式环境里一个通信超时就能让你排查半天而单机环境里如果推理结果不对问题基本都集中在模型和推理逻辑内部定位范围小很多三是它可以作为一个性能基线后续无论怎么扩展都要拿单机的吞吐和时延数据做对比没有这个基线集群优化就是盲人摸象。所以我建议任何做模型部署的团队都先把单机跑顺当成一道硬性关卡。不要觉得这是在浪费时间恰恰相反这是整个部署链路里性价比最高的一段投入。很多团队一上来就花大半个月搭集群最后发现吞吐上不去、问题定位不了、回滚困难根源就是单机阶段欠了太多技术债。1.2 什么信号出现才说明单机确实不够了单机部署的边界不是模型参数放不下这一个条件就能判定的。我总结过三个典型信号满足任何一个就可以认真考虑往多卡或集群走了。第一个信号是单次推理的显存占用量接近显卡物理显存的上限而且没有余量做更大的批处理。这个很容易理解批处理大小直接决定吞吐如果batch size最大只能开到1或2那承载并发的能力就非常有限。这时候加机器不解决问题得先把并行做起来。第二个信号是请求量和并发上去了但时延开始出现明显的长尾。单机场景下服务端要同时处理多个请求如果用的是同步推理前面的请求没结束后面的请求就会排队P99时延会显著恶化。这时候即使模型本身跑得动服务的可用性也已经不合格了。第三个信号是可用性要求变高了。单机是个单点显卡宕机、驱动崩了、服务进程OOM任何一个故障都会让整个服务中断。当你的使用者从自测变成业务方依赖时高可用就不是可选项了。当然信号归信号真到了单机兜不住的时候扩展路径也要想清楚是先走单机多卡还是直接上多机集群我的答案很简单优先单机多卡。因为单机内总线带宽高得多通信开销小并行改造的工作量和失败风险都比跨机低一个数量级先把手里的硬件压榨干净再往外扩。2. 单机推理部署先把一条链路彻底跑通2.1 环境与模型选型先跑起来再说单机部署看起来简单但选型一样容易翻车。先说推理框架。早期我写过裸的PyTorch推理脚本加载模型、手动管显存、自己实现批处理说实话在demo阶段确实够用了但一旦要考虑并发和吞吐自己维护的成本就完全失控。后来转向了专门的推理引擎这类框架自带连续批处理、KV Cache管理、量化算子优化这些能力省掉了我大量造轮子的时间。模型选型上我的经验是先量化后部署。原版FP16的模型在消费级显卡上往往吃不下而量化为4bit或8bit之后体积可以压缩到原来的四分之一甚至更小。量化方案上我踩过几个坑之后形成了一套自己的选择逻辑注重推理速度就优先用GPTQ或AWQ这一类权重量化注重内存占用极低就可以用GGUF格式配合CPU/GPU混合推理。实际项目中如果只是做文本生成、对话这类场景4bit量化后的模型质量损失在多数情况下是可以接受的至少我做ROUGE指标对比时差异很小。这里给一组我常用的选型参考部署场景推荐路径备注个人开发机、原型验证量化为4bit优先CPU推理或单卡小显存换模型快迭代效率最高内部工具、低并发服务8bit量化 推理引擎加载质量和吞吐比较均衡对外服务、需要高吞吐FP8/FP16 服务化推理框架依赖高端显卡但决定质量上限有一点要特别提醒量化并不是无脑压到4bit就完事。如果模型里包含一些特殊的多模态分支或者工具调用逻辑某些极低bit的量化方式会让输出结构变乱。我在一个图文理解任务上就出现过量化后模型经常输出不合法JSON的问题排查了好久才定位到是量化精度把logits分布带偏了。所以量化的比特数要和具体业务场景一起验证不能只看显存放下了就觉得大功告成。2.2 性能调优的三个关键点批处理、显存管理、缓存复用单机部署一旦跑通接下来要面对的就是性能调优。我把它拆成三个关键点实际上也是推理引擎优化最核心的三个方向。第一是批处理。传统深度学习的批处理是攒够一批再一起算但LLM推理有个特点每个请求的输入长度和生成长度都不一样如果硬凑batch就会因为最长的那个请求而拖慢整批。现在主流的做法是连续批处理每生成完一个token就把结束的请求移出batch把新来的请求插进来这样batch里永远都是正在进行时的活跃请求吞吐能比静态批处理高好几倍。这个优化不是我手动能做的所以选推理框架时支持连续批处理是硬指标不支持的直接淘汰。第二是显存管理。推理过程中的KV Cache会随并发请求数线性增长如果不做精细管理显存利用率会非常低。我见过一个现象同样的显卡没开显存管理优化的引擎并发一高就OOM换了成熟推理框架之后显存利用率直接上到90%以上。背后的思路是把KV Cache分成小块、按需分配、用完释放跟操作系统的内存分页非常像。这个机制默认开启但要注意它的上限配置设得太大同样会OOM。第三是缓存复用。很多业务里用户会反复问相似的问题或者说前缀是完全相同的比如系统prompt很长每次请求都带。如果推理引擎支持前缀缓存这部分计算就可以直接复用极大降低首token时延。我实际测试过带长系统提示词的场景下开了前缀缓存之后请求的TTFT可以减少大约40%效果非常直观。这三件事在单机阶段就应该逐一验证清楚。因为它们决定了同样的硬件你到底能扛多大的流量也决定了后面集群化的时候每个实例到底应该定多大的副本数。单机调优不扎实集群阶段的容量评估就是拍脑袋。3. 单机多卡从一张卡到张量并行3.1 并行策略的取舍逻辑当单卡放不下模型或者单卡吞吐已经到了物理上限的时候第一个要考虑的就是单机多卡。但很多人在这一步容易懵扛着我的70B模型手头有四张卡到底该怎么切模型是把模型复制四份吗还是把每层拆开这里面的核心问题就是并行策略怎么选。我见过的团队能把这几个策略讲清楚的人不少但真到部署的时候还能选对的不多因为每种并行方式都有它适用的场景和代价选错了不但显存没省下来速度反而会拖得更慢。我用打团队来类比这几种并行方式。数据并行是把同一份活分给很多人干每人一个副本大家干同一类任务好处是逻辑简单、吞吐跟人数量成正比坏处是显存放不下大模型时它解决不了。张量并行是把一层网络切成好几块不同负责不同的计算块块与块之间有紧密的通信协作适合单卡放不下但机器内有高速互联的场景。流水线并行则是把整个模型按层切成几段像流水线一样一段接一段地处理请求每一张卡只负责其中一段通信频率低但存在流水线气泡利用率不容易拉满。实际部署中最常用的开场组合是张量并行数据并行。比如一个70B参数的模型量化到8bit之后体积大约70GB单张卡放不下就用4张卡跑张量并行把权重切到4张卡上每张卡持有四分之一如果同时还要提升吞吐就再用多个这样的4卡组来各自服务不同的请求这就是数据并行在外层协作。我自己的经验是单机内优先张量并行跨机再考虑流水线并行或者干脆再接一层数据并行这个思路可以避免大部分通信热点问题。3.2 单机多卡部署实操要点实际操作单机多卡部署时有几个点值得专门记录下来。首先是通信链路的确认。张量并行的每次前向计算都要做集合通信操作机器内部的高速总线和PCIe之间的带宽差距非常明显。我曾经在同一台机器上测过一组数据8卡并行时高速互联环境下单次通信耗时比PCIe直连环境下快了将近一倍推理吞吐差距直接拉到了40%以上。所以组机器的时候同一机器内的卡必须尽量靠高速互联打通这一点在买卡和选主板的时候就要定下来后面想改成本极高。其次是推理引擎层面的并行参数配置。主流推理引擎基本都支持设置张量并行大小这个值的底层逻辑是告诉引擎模型权重要被切成几份、跨卡通信要怎么组织。这里有一个很容易犯的错误把张量并行大小设置成跟显卡数量一样然后发现显存占用确实降下来了但吞吐反而不涨甚至更慢。原因是切分粒度太细通信开销超过了并行收益。一般我建议从2或4开始试逐步往上加找到一个吞吐的峰值点而不是简单地把所有卡都塞进一个并行组。第三是CPU绑核和显卡亲和性。多卡推理时每个进程应该绑定到特定的CPU核心和对应的显卡上避免跨NUMA访问内存这个优化在单卡时不明显但多卡之后性能差距能拉到百分之十几。多数推理框架都支持这样的绑定配置花几分钟改一下配置就能白拿的性能不拿白不拿。最后单机多卡并不意味着万事大吉。一张卡的显存要是被KV Cache占满整个张量并行组都会阻塞组内任何一张卡故障服务就整体不可用。所以进入多卡阶段之后监控和容错机制的优先级就得提上来了不然哪天半夜三点的告警电话会教你怎么做人。4. 跨到多机集群服务化、调度与横向扩展4.1 从进程到服务先让推理变成可调度的模块跨到多机之前有一个工程改造必须先完成把推理从一个进程变成一个可被调度的服务。这一步很多人会忽略直接拿单机脚本往集群里一扔结果发现起停、扩缩容、日志收集全都乱套。我一般把服务化分成三层来做。第一层是模型加载与推理逻辑分离推理引擎作为一个常驻服务进程启动时加载模型权重启动后监听请求端口外部通过HTTP或gRPC调用而不是每次请求都重新加载模型。这一层不做后面的并发和集群化都没有基础因为每次请求都重新加载模型的话一个请求还没处理完下一个就排队到天荒地老了。第二层是容器化。把推理引擎连同运行环境、相关依赖一起打成镜像这样无论是开发机、测试机还是生产机运行环境完全一致。镜像还有一个很大的好处是版本控制模型换版、引擎升级都可以通过镜像版本号来管理回滚非常快。我踩过一个坑早期用裸进程部署某次升级Python依赖之后线上推理结果全部异常回滚花了两个多小时后来全部容器化之后回滚就是一条命令的事。第三层是配置外置。模型路径、量化参数、并行大小、超时时间、显存上限这些都应该通过环境变量或配置文件注入而不是硬编码在代码里。这样同一个镜像可以在不同规格的资源上启动不同的实例集群调度才有灵活性。比如同一个模型开发环境可以起一个小batch的实例生产环境起一个大batch的实例镜像完全不变只改配置。4.2 集群调度与服务发现的工程细节推理服务变成容器之后接下来要考虑的就是谁来调度它、它怎么被找到。调度层面业界用得最多的方案是Kubernetes这套生态但我要说的是它在大模型推理场景里的一些特殊之处。普通Web服务调度看CPU和内存就够了但推理服务真正的资源瓶颈是GPU所以必须声明GPU资源需求并且让调度器根据GPU型号、显存大小、已占用情况来做分配。如果集群里有多种显卡混用我建议按GPU型号划分节点池避免调度器把任务派到一张显存不够的卡上那样实例永远起不来排查起来又费时间又费心情。还有一个很多人踩过的坑是请求的亲和性。推理服务启动之后前几十秒要加载模型和构建KV Cache索引这段时间如果被压入流量不仅请求会超时还可能导致服务启动失败。所以集群调度里一定要设置就绪探针等待推理服务的健康检查接口返回成功之后再把它加入到流量转发中。我见过生产事故就是因为没有这个探针服务还在加载模型请求已经打进来了直接把进程压崩然后调度器又拉起一个新实例又被压崩形成一个死循环。服务发现相对成熟推理服务注册到服务发现中心之后调用方通过服务名访问后端实例的增删完全由调度器管理调用方无感知。这里我会额外关注一个细节一个推理实例的吞吐上限是受显存和batch策略限制的不是配置了副本数量就一定能接住对应流量所以服务发现后面一定要对接流量治理不能只靠副本数量硬扛。5. 集群部署的流量治理与高可用设计5.1 负载均衡与弹性伸缩怎么落地多机集群搭起来之后怎么把流量分到多个推理实例上就成了第一个要命的问题。大模型推理服务有个特点单个请求的耗时可能是秒级甚至几十秒级而且每个请求占用的显存和计算资源差异很大。普通Web的负载均衡策略在这里不完全够用比如轮询就不合适因为一个慢请求会占用实例很久后面排队的请求容易堆积。我建议的方案是网关层做两层分发。第一层是接入层的负载均衡负责把请求公平地分配到各个推理实例以及处理实例的健康状态变化。第二层是推理实例内部引擎自己还会对请求做调度和排队所以网关层要给每个实例设置合适的最大并发数超过这个数就返回排队或限流信号而不是继续往里灌请求。这个最大并发数不能拍脑袋定要根据单实例压测得到的吞吐和时延数据来反推否则设高了会拖垮实例设低了浪费算力。弹性伸缩方面我见过两种主流做法。一种是基于QPS指标扩缩容优点是直观缺点是模型推理的QPS曲线和资源消耗并不是严格的线性关系同样的QPS请求的输入长度不同算力消耗差好几倍很容易误判。另一种是基于GPU利用率、排队长度等更接近真实负载的指标来扩缩容我优先推荐这种。举个例子某个实例GPU利用率持续超过85%且请求排队变长就自动扩容出一个新实例如果利用率连续半小时低于30%就缩容减掉一个实例。用更贴近真实压力的信号来做决策扩缩容才不瞎忙。还要提醒一句扩容和缩容不能做得太激进。推理实例的启动要重新加载模型冷启动时间可能是几十秒到几分钟如果流量一波动就立刻扩容可能反而造成资源抖动。我给团队定过一个原则扩容可以快缩容必须慢至少观察10分钟以上的低利用率窗口再执行缩容。5.2 监控、容灾和灰度发布的一些经验谈到高可用我的态度是没有监控就别谈高可用。在大模型推理集群里至少要盯住这几个指标GPU显存利用率、GPU计算利用率、请求排队长度、首token时延、生成耗时、错误率、实例存活数。其中首token时延和生成耗时这两个指标最能反映用户体验建议在监控面板上单独醒目展示。我团队现在的做法是把它们做成趋势图让值班的人一眼就能看出服务是不是在劣化。容灾设计上我的经验是把实例分为多个部署组每个组都有完整服务能力。当一个组内的实例出现批量故障时调度器可以把新请求全部导到健康组同时自动重建故障实例。这个过程如果做得顺滑用户基本感知不到。另外模型权重文件一定要放到分布式存储里并且做好版本管理和备份否则节点坏了连重新拉起一个实例都拿不到权重文件那就真的是灾难现场了。有一次我就因为权重文件只存在某台机器的本地磁盘上结果那台机器硬盘故障整个服务直接瘫痪后来再也不敢这么干。灰度发布这块我走过弯路。早期是改完配置直接全量发布结果某次模型升级后生成质量严重下降虽然没有崩溃但业务方反馈很差。后面我改成先发布一个金丝雀实例用小比例流量验证生成质量和响应速度确认没问题再逐步扩大流量比例最后全量发布。这个流程虽然多一些步骤但极大降低了线上事故概率。灰度发布时还要特别注意生成质量这种问题不像崩溃那么明显要主动盯业务侧反馈和采样检查不能只等告警。6. 常见问题与排查技巧实录6.1 显存相关的高频报错我把这一年多排查过的显存问题整理成了一份速查表实战里照着它排查能省不少时间现象直接原因推荐排查方向推理启动即报显存不足模型权重加载需要的显存超过物理显存先确认量化格式再确认并行切分是否生效运行一段时间后突然OOMKV Cache占用持续增长没有及时释放检查是否开启缓存复用的显存回收机制限制最大缓存量并发一高就OOM单发正常批处理策略过于激进或缓存容量设置过大降低并发上限调小缓存预分配额度观察显存曲线多卡之间显存占用不均衡张量并行切分不均匀或某一层权重过大检查并行配置考虑启用自动均衡的显存调度功能显存问题的排查有个笨但有效的方法开监控把过去一小时的显存曲线拉出来看。如果曲线是慢慢爬上去然后突然跌下来的锯齿状说明是KV Cache的分配和回收在打架如果是直线冲到顶就崩那多半是初始化时就把显存占满了。先看曲线再猜原因不要一上来就翻日志日志里往往只有一句干巴巴的OOM帮不了什么忙。6.2 通信瓶颈与超时问题多机集群里最让人头疼的问题之一就是通信。多机集群和单机多卡的差别就在这里单机内通信走的是高速内部总线跨机通信走的是网线不管是带宽还是延迟都差着一个量级。很多在单机多卡上跑得好好的并行策略一跨机就卡成PPT原因就是通信开销把计算收益全吃掉了。所以排查通信问题不能只盯着应用日志网络基础能力才是第一个要确认的。排查通信问题时有三条经验我反复跟团队强调。第一网络环境必须先测。加入集群之前用通信测试工具跑一遍多机间的传输带宽和延迟。我做过一次对比同一批代码在千兆网和万兆网环境下的训练通信耗时能差出两三倍推理场景虽然不像训练那么频繁但张量并行时每一步都有集合通信延迟高了照样拖慢整体。第二注意集合通信库的超时设置。默认超时时间在某些慢网络环境下会误报失败但也不能把超时设得无限大否则真故障时服务会卡死很久。我的做法是把超时设成正常通信耗时的5到10倍既留足余量又不会无限等待。第三多机部署时尽量把通信密集的并行策略控制在机器内。同样是4卡张量并行放在一台机器里跑和分散在两台机器上跑通信开销完全不同。这个问题没有银弹只能在分配实例时尽量让同一并行组的卡落在同一台机器上靠调度策略来规避。6.3 推理服务长时间运行的稳定性问题部署完不等于结束真正考验人的其实是服务上线之后的日常维护。推理服务跟普通Web服务不一样它是个典型的长跑运动员跑一两天看不出什么问题跑上一周两周各种慢性病就会陆续冒出来。我这边有一类工单特别高频几乎每隔几周就会出现一次内容就是一句话服务怎么越跑越慢了这个现象背后通常是几个原因叠加一是KV Cache碎片化越来越严重二是长期请求导致的部分算子性能退化三是日志和临时文件写出拖慢了磁盘。处理办法是给推理服务设计定期的优雅重启机制在低峰期滚动重启实例把状态清理干净再拉起来。别小看这个操作它解决过无数次莫名变慢的疑难杂症。以前没有这个机制的时候每次都是人肉去重启还总是担心丢请求现在做成定时任务加优雅下线省心很多。还有一个高频问题是多副本之间生成结果不稳定。同一个问题不同副本回答的内容不完全一致。这在很多业务场景里是可以接受的但如果要严格保证一致就要注意推理引擎的采样参数是否完全一致、随机种子是否固定、是否开启了确定性算子模式。我在一个需要结果可复现的项目里踩过这个坑同一个问题测了五次五次答案都不同排查半天发现是两个副本的采样温度配置不一致后来统一配置了固定种子和确定性模式问题才解决。最后聊一下优雅下线。集群缩容或版本升级时如果直接把实例杀掉正在处理的请求就会中断用户会看到超时。正确的做法是实例先停止接收新请求等存量请求处理完毕再执行退出。这个逻辑在单机阶段不需要关心但到集群阶段它会直接影响用户体验。我给团队定的标准是任何一个推理实例下线前必须保证在途请求完成率不低于99%。其实就是一段逻辑的事但很多集群事故都是因为省了这一步才发生的。我个人做了这么多年部署最大的一个体会是架构演进不是越复杂越好而是越合适越好。从单机到集群每一步演进背后都应该有一个明确的业务痛点或资源约束在推着走而不是为了技术上的高级感。先把单机跑透再谈并行最后才上集群这套路径虽然看起来慢但每一步踩实了后面集群阶段的返工成本会低很多。如果看完这篇能让你少走一两个弯路那比什么都强。 
长河君 · 2026/10/20 20:31:16 · 阅读 1.2k 大模型部署从单机到集群：推理性能调优与架构演进实践
1. 为什么大模型部署要聊从单机到集群这个演进1.1 单机部署不是起点而是最该被认真对待的阶段很多刚接触大模型的人看到动辄几十GB甚至上百GB的模型权重文件下意识觉得这玩意儿肯定得上集群。但实际落地的时候我见过太多反例某个内部知识库问答项目模型量化到4bit之后只有不到7GB一张消费级显卡就能跑起来日调用量只有几百次直接单机部署绰绰有余。这种情况下硬上集群纯粹是给运维和自己找麻烦。单机部署最大的价值有三个。一是验证成本极低改代码、重启、看日志的迭代闭环非常短特别适合调prompt、调采样参数、调后处理逻辑二是排除变量分布式环境里一个通信超时就能让你排查半天而单机环境里如果推理结果不对问题基本都集中在模型和推理逻辑内部定位范围小很多三是它可以作为一个性能基线后续无论怎么扩展都要拿单机的吞吐和时延数据做对比没有这个基线集群优化就是盲人摸象。所以我建议任何做模型部署的团队都先把单机跑顺当成一道硬性关卡。不要觉得这是在浪费时间恰恰相反这是整个部署链路里性价比最高的一段投入。很多团队一上来就花大半个月搭集群最后发现吞吐上不去、问题定位不了、回滚困难根源就是单机阶段欠了太多技术债。1.2 什么信号出现才说明单机确实不够了单机部署的边界不是模型参数放不下这一个条件就能判定的。我总结过三个典型信号满足任何一个就可以认真考虑往多卡或集群走了。第一个信号是单次推理的显存占用量接近显卡物理显存的上限而且没有余量做更大的批处理。这个很容易理解批处理大小直接决定吞吐如果batch size最大只能开到1或2那承载并发的能力就非常有限。这时候加机器不解决问题得先把并行做起来。第二个信号是请求量和并发上去了但时延开始出现明显的长尾。单机场景下服务端要同时处理多个请求如果用的是同步推理前面的请求没结束后面的请求就会排队P99时延会显著恶化。这时候即使模型本身跑得动服务的可用性也已经不合格了。第三个信号是可用性要求变高了。单机是个单点显卡宕机、驱动崩了、服务进程OOM任何一个故障都会让整个服务中断。当你的使用者从自测变成业务方依赖时高可用就不是可选项了。当然信号归信号真到了单机兜不住的时候扩展路径也要想清楚是先走单机多卡还是直接上多机集群我的答案很简单优先单机多卡。因为单机内总线带宽高得多通信开销小并行改造的工作量和失败风险都比跨机低一个数量级先把手里的硬件压榨干净再往外扩。2. 单机推理部署先把一条链路彻底跑通2.1 环境与模型选型先跑起来再说单机部署看起来简单但选型一样容易翻车。先说推理框架。早期我写过裸的PyTorch推理脚本加载模型、手动管显存、自己实现批处理说实话在demo阶段确实够用了但一旦要考虑并发和吞吐自己维护的成本就完全失控。后来转向了专门的推理引擎这类框架自带连续批处理、KV Cache管理、量化算子优化这些能力省掉了我大量造轮子的时间。模型选型上我的经验是先量化后部署。原版FP16的模型在消费级显卡上往往吃不下而量化为4bit或8bit之后体积可以压缩到原来的四分之一甚至更小。量化方案上我踩过几个坑之后形成了一套自己的选择逻辑注重推理速度就优先用GPTQ或AWQ这一类权重量化注重内存占用极低就可以用GGUF格式配合CPU/GPU混合推理。实际项目中如果只是做文本生成、对话这类场景4bit量化后的模型质量损失在多数情况下是可以接受的至少我做ROUGE指标对比时差异很小。这里给一组我常用的选型参考部署场景推荐路径备注个人开发机、原型验证量化为4bit优先CPU推理或单卡小显存换模型快迭代效率最高内部工具、低并发服务8bit量化 推理引擎加载质量和吞吐比较均衡对外服务、需要高吞吐FP8/FP16 服务化推理框架依赖高端显卡但决定质量上限有一点要特别提醒量化并不是无脑压到4bit就完事。如果模型里包含一些特殊的多模态分支或者工具调用逻辑某些极低bit的量化方式会让输出结构变乱。我在一个图文理解任务上就出现过量化后模型经常输出不合法JSON的问题排查了好久才定位到是量化精度把logits分布带偏了。所以量化的比特数要和具体业务场景一起验证不能只看显存放下了就觉得大功告成。2.2 性能调优的三个关键点批处理、显存管理、缓存复用单机部署一旦跑通接下来要面对的就是性能调优。我把它拆成三个关键点实际上也是推理引擎优化最核心的三个方向。第一是批处理。传统深度学习的批处理是攒够一批再一起算但LLM推理有个特点每个请求的输入长度和生成长度都不一样如果硬凑batch就会因为最长的那个请求而拖慢整批。现在主流的做法是连续批处理每生成完一个token就把结束的请求移出batch把新来的请求插进来这样batch里永远都是正在进行时的活跃请求吞吐能比静态批处理高好几倍。这个优化不是我手动能做的所以选推理框架时支持连续批处理是硬指标不支持的直接淘汰。第二是显存管理。推理过程中的KV Cache会随并发请求数线性增长如果不做精细管理显存利用率会非常低。我见过一个现象同样的显卡没开显存管理优化的引擎并发一高就OOM换了成熟推理框架之后显存利用率直接上到90%以上。背后的思路是把KV Cache分成小块、按需分配、用完释放跟操作系统的内存分页非常像。这个机制默认开启但要注意它的上限配置设得太大同样会OOM。第三是缓存复用。很多业务里用户会反复问相似的问题或者说前缀是完全相同的比如系统prompt很长每次请求都带。如果推理引擎支持前缀缓存这部分计算就可以直接复用极大降低首token时延。我实际测试过带长系统提示词的场景下开了前缀缓存之后请求的TTFT可以减少大约40%效果非常直观。这三件事在单机阶段就应该逐一验证清楚。因为它们决定了同样的硬件你到底能扛多大的流量也决定了后面集群化的时候每个实例到底应该定多大的副本数。单机调优不扎实集群阶段的容量评估就是拍脑袋。3. 单机多卡从一张卡到张量并行3.1 并行策略的取舍逻辑当单卡放不下模型或者单卡吞吐已经到了物理上限的时候第一个要考虑的就是单机多卡。但很多人在这一步容易懵扛着我的70B模型手头有四张卡到底该怎么切模型是把模型复制四份吗还是把每层拆开这里面的核心问题就是并行策略怎么选。我见过的团队能把这几个策略讲清楚的人不少但真到部署的时候还能选对的不多因为每种并行方式都有它适用的场景和代价选错了不但显存没省下来速度反而会拖得更慢。我用打团队来类比这几种并行方式。数据并行是把同一份活分给很多人干每人一个副本大家干同一类任务好处是逻辑简单、吞吐跟人数量成正比坏处是显存放不下大模型时它解决不了。张量并行是把一层网络切成好几块不同负责不同的计算块块与块之间有紧密的通信协作适合单卡放不下但机器内有高速互联的场景。流水线并行则是把整个模型按层切成几段像流水线一样一段接一段地处理请求每一张卡只负责其中一段通信频率低但存在流水线气泡利用率不容易拉满。实际部署中最常用的开场组合是张量并行数据并行。比如一个70B参数的模型量化到8bit之后体积大约70GB单张卡放不下就用4张卡跑张量并行把权重切到4张卡上每张卡持有四分之一如果同时还要提升吞吐就再用多个这样的4卡组来各自服务不同的请求这就是数据并行在外层协作。我自己的经验是单机内优先张量并行跨机再考虑流水线并行或者干脆再接一层数据并行这个思路可以避免大部分通信热点问题。3.2 单机多卡部署实操要点实际操作单机多卡部署时有几个点值得专门记录下来。首先是通信链路的确认。张量并行的每次前向计算都要做集合通信操作机器内部的高速总线和PCIe之间的带宽差距非常明显。我曾经在同一台机器上测过一组数据8卡并行时高速互联环境下单次通信耗时比PCIe直连环境下快了将近一倍推理吞吐差距直接拉到了40%以上。所以组机器的时候同一机器内的卡必须尽量靠高速互联打通这一点在买卡和选主板的时候就要定下来后面想改成本极高。其次是推理引擎层面的并行参数配置。主流推理引擎基本都支持设置张量并行大小这个值的底层逻辑是告诉引擎模型权重要被切成几份、跨卡通信要怎么组织。这里有一个很容易犯的错误把张量并行大小设置成跟显卡数量一样然后发现显存占用确实降下来了但吞吐反而不涨甚至更慢。原因是切分粒度太细通信开销超过了并行收益。一般我建议从2或4开始试逐步往上加找到一个吞吐的峰值点而不是简单地把所有卡都塞进一个并行组。第三是CPU绑核和显卡亲和性。多卡推理时每个进程应该绑定到特定的CPU核心和对应的显卡上避免跨NUMA访问内存这个优化在单卡时不明显但多卡之后性能差距能拉到百分之十几。多数推理框架都支持这样的绑定配置花几分钟改一下配置就能白拿的性能不拿白不拿。最后单机多卡并不意味着万事大吉。一张卡的显存要是被KV Cache占满整个张量并行组都会阻塞组内任何一张卡故障服务就整体不可用。所以进入多卡阶段之后监控和容错机制的优先级就得提上来了不然哪天半夜三点的告警电话会教你怎么做人。4. 跨到多机集群服务化、调度与横向扩展4.1 从进程到服务先让推理变成可调度的模块跨到多机之前有一个工程改造必须先完成把推理从一个进程变成一个可被调度的服务。这一步很多人会忽略直接拿单机脚本往集群里一扔结果发现起停、扩缩容、日志收集全都乱套。我一般把服务化分成三层来做。第一层是模型加载与推理逻辑分离推理引擎作为一个常驻服务进程启动时加载模型权重启动后监听请求端口外部通过HTTP或gRPC调用而不是每次请求都重新加载模型。这一层不做后面的并发和集群化都没有基础因为每次请求都重新加载模型的话一个请求还没处理完下一个就排队到天荒地老了。第二层是容器化。把推理引擎连同运行环境、相关依赖一起打成镜像这样无论是开发机、测试机还是生产机运行环境完全一致。镜像还有一个很大的好处是版本控制模型换版、引擎升级都可以通过镜像版本号来管理回滚非常快。我踩过一个坑早期用裸进程部署某次升级Python依赖之后线上推理结果全部异常回滚花了两个多小时后来全部容器化之后回滚就是一条命令的事。第三层是配置外置。模型路径、量化参数、并行大小、超时时间、显存上限这些都应该通过环境变量或配置文件注入而不是硬编码在代码里。这样同一个镜像可以在不同规格的资源上启动不同的实例集群调度才有灵活性。比如同一个模型开发环境可以起一个小batch的实例生产环境起一个大batch的实例镜像完全不变只改配置。4.2 集群调度与服务发现的工程细节推理服务变成容器之后接下来要考虑的就是谁来调度它、它怎么被找到。调度层面业界用得最多的方案是Kubernetes这套生态但我要说的是它在大模型推理场景里的一些特殊之处。普通Web服务调度看CPU和内存就够了但推理服务真正的资源瓶颈是GPU所以必须声明GPU资源需求并且让调度器根据GPU型号、显存大小、已占用情况来做分配。如果集群里有多种显卡混用我建议按GPU型号划分节点池避免调度器把任务派到一张显存不够的卡上那样实例永远起不来排查起来又费时间又费心情。还有一个很多人踩过的坑是请求的亲和性。推理服务启动之后前几十秒要加载模型和构建KV Cache索引这段时间如果被压入流量不仅请求会超时还可能导致服务启动失败。所以集群调度里一定要设置就绪探针等待推理服务的健康检查接口返回成功之后再把它加入到流量转发中。我见过生产事故就是因为没有这个探针服务还在加载模型请求已经打进来了直接把进程压崩然后调度器又拉起一个新实例又被压崩形成一个死循环。服务发现相对成熟推理服务注册到服务发现中心之后调用方通过服务名访问后端实例的增删完全由调度器管理调用方无感知。这里我会额外关注一个细节一个推理实例的吞吐上限是受显存和batch策略限制的不是配置了副本数量就一定能接住对应流量所以服务发现后面一定要对接流量治理不能只靠副本数量硬扛。5. 集群部署的流量治理与高可用设计5.1 负载均衡与弹性伸缩怎么落地多机集群搭起来之后怎么把流量分到多个推理实例上就成了第一个要命的问题。大模型推理服务有个特点单个请求的耗时可能是秒级甚至几十秒级而且每个请求占用的显存和计算资源差异很大。普通Web的负载均衡策略在这里不完全够用比如轮询就不合适因为一个慢请求会占用实例很久后面排队的请求容易堆积。我建议的方案是网关层做两层分发。第一层是接入层的负载均衡负责把请求公平地分配到各个推理实例以及处理实例的健康状态变化。第二层是推理实例内部引擎自己还会对请求做调度和排队所以网关层要给每个实例设置合适的最大并发数超过这个数就返回排队或限流信号而不是继续往里灌请求。这个最大并发数不能拍脑袋定要根据单实例压测得到的吞吐和时延数据来反推否则设高了会拖垮实例设低了浪费算力。弹性伸缩方面我见过两种主流做法。一种是基于QPS指标扩缩容优点是直观缺点是模型推理的QPS曲线和资源消耗并不是严格的线性关系同样的QPS请求的输入长度不同算力消耗差好几倍很容易误判。另一种是基于GPU利用率、排队长度等更接近真实负载的指标来扩缩容我优先推荐这种。举个例子某个实例GPU利用率持续超过85%且请求排队变长就自动扩容出一个新实例如果利用率连续半小时低于30%就缩容减掉一个实例。用更贴近真实压力的信号来做决策扩缩容才不瞎忙。还要提醒一句扩容和缩容不能做得太激进。推理实例的启动要重新加载模型冷启动时间可能是几十秒到几分钟如果流量一波动就立刻扩容可能反而造成资源抖动。我给团队定过一个原则扩容可以快缩容必须慢至少观察10分钟以上的低利用率窗口再执行缩容。5.2 监控、容灾和灰度发布的一些经验谈到高可用我的态度是没有监控就别谈高可用。在大模型推理集群里至少要盯住这几个指标GPU显存利用率、GPU计算利用率、请求排队长度、首token时延、生成耗时、错误率、实例存活数。其中首token时延和生成耗时这两个指标最能反映用户体验建议在监控面板上单独醒目展示。我团队现在的做法是把它们做成趋势图让值班的人一眼就能看出服务是不是在劣化。容灾设计上我的经验是把实例分为多个部署组每个组都有完整服务能力。当一个组内的实例出现批量故障时调度器可以把新请求全部导到健康组同时自动重建故障实例。这个过程如果做得顺滑用户基本感知不到。另外模型权重文件一定要放到分布式存储里并且做好版本管理和备份否则节点坏了连重新拉起一个实例都拿不到权重文件那就真的是灾难现场了。有一次我就因为权重文件只存在某台机器的本地磁盘上结果那台机器硬盘故障整个服务直接瘫痪后来再也不敢这么干。灰度发布这块我走过弯路。早期是改完配置直接全量发布结果某次模型升级后生成质量严重下降虽然没有崩溃但业务方反馈很差。后面我改成先发布一个金丝雀实例用小比例流量验证生成质量和响应速度确认没问题再逐步扩大流量比例最后全量发布。这个流程虽然多一些步骤但极大降低了线上事故概率。灰度发布时还要特别注意生成质量这种问题不像崩溃那么明显要主动盯业务侧反馈和采样检查不能只等告警。6. 常见问题与排查技巧实录6.1 显存相关的高频报错我把这一年多排查过的显存问题整理成了一份速查表实战里照着它排查能省不少时间现象直接原因推荐排查方向推理启动即报显存不足模型权重加载需要的显存超过物理显存先确认量化格式再确认并行切分是否生效运行一段时间后突然OOMKV Cache占用持续增长没有及时释放检查是否开启缓存复用的显存回收机制限制最大缓存量并发一高就OOM单发正常批处理策略过于激进或缓存容量设置过大降低并发上限调小缓存预分配额度观察显存曲线多卡之间显存占用不均衡张量并行切分不均匀或某一层权重过大检查并行配置考虑启用自动均衡的显存调度功能显存问题的排查有个笨但有效的方法开监控把过去一小时的显存曲线拉出来看。如果曲线是慢慢爬上去然后突然跌下来的锯齿状说明是KV Cache的分配和回收在打架如果是直线冲到顶就崩那多半是初始化时就把显存占满了。先看曲线再猜原因不要一上来就翻日志日志里往往只有一句干巴巴的OOM帮不了什么忙。6.2 通信瓶颈与超时问题多机集群里最让人头疼的问题之一就是通信。多机集群和单机多卡的差别就在这里单机内通信走的是高速内部总线跨机通信走的是网线不管是带宽还是延迟都差着一个量级。很多在单机多卡上跑得好好的并行策略一跨机就卡成PPT原因就是通信开销把计算收益全吃掉了。所以排查通信问题不能只盯着应用日志网络基础能力才是第一个要确认的。排查通信问题时有三条经验我反复跟团队强调。第一网络环境必须先测。加入集群之前用通信测试工具跑一遍多机间的传输带宽和延迟。我做过一次对比同一批代码在千兆网和万兆网环境下的训练通信耗时能差出两三倍推理场景虽然不像训练那么频繁但张量并行时每一步都有集合通信延迟高了照样拖慢整体。第二注意集合通信库的超时设置。默认超时时间在某些慢网络环境下会误报失败但也不能把超时设得无限大否则真故障时服务会卡死很久。我的做法是把超时设成正常通信耗时的5到10倍既留足余量又不会无限等待。第三多机部署时尽量把通信密集的并行策略控制在机器内。同样是4卡张量并行放在一台机器里跑和分散在两台机器上跑通信开销完全不同。这个问题没有银弹只能在分配实例时尽量让同一并行组的卡落在同一台机器上靠调度策略来规避。6.3 推理服务长时间运行的稳定性问题部署完不等于结束真正考验人的其实是服务上线之后的日常维护。推理服务跟普通Web服务不一样它是个典型的长跑运动员跑一两天看不出什么问题跑上一周两周各种慢性病就会陆续冒出来。我这边有一类工单特别高频几乎每隔几周就会出现一次内容就是一句话服务怎么越跑越慢了这个现象背后通常是几个原因叠加一是KV Cache碎片化越来越严重二是长期请求导致的部分算子性能退化三是日志和临时文件写出拖慢了磁盘。处理办法是给推理服务设计定期的优雅重启机制在低峰期滚动重启实例把状态清理干净再拉起来。别小看这个操作它解决过无数次莫名变慢的疑难杂症。以前没有这个机制的时候每次都是人肉去重启还总是担心丢请求现在做成定时任务加优雅下线省心很多。还有一个高频问题是多副本之间生成结果不稳定。同一个问题不同副本回答的内容不完全一致。这在很多业务场景里是可以接受的但如果要严格保证一致就要注意推理引擎的采样参数是否完全一致、随机种子是否固定、是否开启了确定性算子模式。我在一个需要结果可复现的项目里踩过这个坑同一个问题测了五次五次答案都不同排查半天发现是两个副本的采样温度配置不一致后来统一配置了固定种子和确定性模式问题才解决。最后聊一下优雅下线。集群缩容或版本升级时如果直接把实例杀掉正在处理的请求就会中断用户会看到超时。正确的做法是实例先停止接收新请求等存量请求处理完毕再执行退出。这个逻辑在单机阶段不需要关心但到集群阶段它会直接影响用户体验。我给团队定的标准是任何一个推理实例下线前必须保证在途请求完成率不低于99%。其实就是一段逻辑的事但很多集群事故都是因为省了这一步才发生的。我个人做了这么多年部署最大的一个体会是架构演进不是越复杂越好而是越合适越好。从单机到集群每一步演进背后都应该有一个明确的业务痛点或资源约束在推着走而不是为了技术上的高级感。先把单机跑透再谈并行最后才上集群这套路径虽然看起来慢但每一步踩实了后面集群阶段的返工成本会低很多。如果看完这篇能让你少走一两个弯路那比什么都强。