云原生大模型推理：从单机到多机多卡的实战指南

去年调一个开源大模型的线上推理服务单机单卡在开发环境怎么压测都稳上线第二天就被业务方的并发打懵了。后来走上云原生这条路从单机容器化到多机多卡编排把推理链路彻底重构了一遍才真正理解了“企业级部署”这几个字的分量。这篇文章就把这段经历里最关键的部分梳理出来为什么单机方案撑不住、云原生推理平台的核心组件、模型并行策略怎么选、以及从单机到多机多卡的真实落地路径。如果你也在做云原生大模型推理或者正准备把本地的大模型服务推向生产环境这篇应该能帮你省不少弯路。1. 单机玩得好好的为什么一到生产环境就崩先别急着搭Kubernetes得先说清楚单机部署到底败在哪。很多团队第一次接触大模型推理就是在一台GPU服务器上把模型拉下来写个FastAPI服务包一层能返回结果就觉得完事了。这在一两个人调试的时候完全没问题但一旦进入企业级环境问题会从好几个方向同时压过来。1.1 显存不是“够用”而是“够不着”大模型推理最容易被低估的就是显存消耗。以7B模型为例FP16精度下权重本身约14GB单张80GB的A100/H100看起来绰绰有余但推理时模型权重要常驻显存同时还要给KV Cache、CUDA context、临时计算图预留空间。KV Cache的大小跟序列长度和并发数直接相关计算公式可以简化成KV Cache大小 ≈ 2K和V × 层数 × 注意力头维度 × 序列长度 × 并发请求数 × 每个元素字节数一个7B模型如果配置2048的上下文长度、并发8个请求KV Cache就要额外吃掉几个GB。用vLLM这类框架时还会预分配一定比例的显存作为KV Cache池。开发环境一次调一个请求看不出问题压测时并发一上来显存瞬间就爆了OOM来得毫无预兆。更隐蔽的是CUDA context本身。每个进程初始化CUDA context通常会占用几百MB到1GB显存多个推理进程同时跑还没开始算就已经吃掉一大块。很多团队在“提升并发”的时候习惯多开几个进程副本结果单个副本都能跑加起来卡就崩了。1.2 从资源利用看单机的天花板单机哪怕插满8张卡也存在严重的资源碎片问题。一个推理服务可能只用了其中一张卡剩下7张卡闲着另一个服务想用两张卡插进去发现显存被第一个服务占着等调度又等不到人。团队里有人抢A100跑大模型有人只想要一张4090做小模型验证算力资源完全没法复用最后全都僵在那里。“GPU利用率不高”在企业里不只是技术问题还是成本问题。一张A100/H100的年成本远超一台普通服务器如果平均利用率长期在10%以下老板迟早要来问账。单机方案的弹性也基本为零流量高峰只能硬扛扛不住就超时报错流量低谷资源空转但你还得付费。1.3 可靠性问题比性能问题更致命单机部署还有个要命的问题没有生存性。机器重启、显卡掉驱动、服务进程被OOM Killer干掉整个推理服务就跟着一起下线了。更麻烦的是企业环境里经常有多个团队共用一台GPU服务器别人在训练任务里把显存吃满你的推理服务就会莫名奇妙地变慢甚至崩溃查都查不到原因。发布新版本同样让人头疼。单机部署时更新代码要手动停服、替换、重启中途业务全部中断。没有优雅停机机制的话正在处理的请求直接就断掉了客户端拿到的是一堆连接错误。灰度发布滚动更新在单机模式下基本是奢望。1.4 管理维度版本、配置、成本全部失控模型文件本身也是大问题。一个大模型动辄几十GB本地跑的时候随手放个路径过段时间你自己都不记得跑的是哪个版本。团队里其他人更新了模型配置文件改了日志里没有任何记录出了问题只能全员排查。再往上一层成本归属也没法算。算力资源是共享的但每个业务线用了多少卡、多少显存、多少带宽单机模式下完全是糊涂账。企业级部署的核心其实不只是“把模型跑起来”而是让算力成为一种可治理、可计量的资源。维度单机模式企业级要求算力资源单卡/单机独占无法复用池化共享按需分配弹性伸缩无高峰期硬扛按QPS/排队长度动态扩缩高可用单点故障全部下线多副本、自动恢复发布方式停服更新滚动更新、金丝雀发布可观测性看进程日志指标、链路、日志全链路覆盖成本归属糊涂账按租户/业务线核算这就是为什么从单机到云原生不是“追新”而是被这些问题逼出来的。2. 云原生推理平台的核心组件与架构设计把大模型推理放到云原生架构里很多人第一反应就是“我要上Kubernetes”。但Kubernetes只是底座一个真正能支撑业务的推理平台需要把资源、服务、流量、弹性、可观测性这几层全部串起来。我习惯把它拆成四个层面来看。2.1 底层GPU资源池化与调度GPU必须从“某一台机器上的硬件”变成“调度器眼里的一种资源”。在Kubernetes里这一步靠NVIDIA device plugin完成。它会把每张GPU上报给kubelet然后通过resources.limits的nvidia.com/gpu字段让Pod申请GPU。企业起步阶段我强烈建议先用“整卡调度”。整卡调度的意思是一个Pod至少占用一整张GPU不能两张卡各占一半。原因很简单GPU卡粒度的隔离是硬件级别的稳定可靠而显存共享、时间片切分这类精细调度虽然能提升资源利用率但会引入隔离性、性能干扰、显存隔离等一堆新问题需要专门的调度器和运维经验去兜底。先把整卡跑顺再考虑MIG切分或者时间片这个顺序不能反过来。资源池化之后调度策略也很关键。集群里有多台GPU节点时Scheduler默认的调度策略可能把Pod散得到处都是。推理场景一般建议用binpack策略尽量把Pod集中调度到少量节点把空闲节点的GPU空出来这样既方便运维排查也给大任务留出了整节点资源。2.2 中间层模型服务与推理框架选型模型服务化是这层最核心的东西。把模型跑起来不难难的是让业务方调用起来像调用一个标准API。两条路比较主流用vLLM、SGLang这类自带OpenAI兼容API的推理框架用Triton Inference Server做统一推理后端后面再接TensorRT-LLM或vLLM从我的实践看大部分团队选vLLM起步最省事它自带PagedAttention和continuous batching吞吐表现好而且直接暴露/metrics给Prometheus对后续弹性伸缩很友好。但要注意continuous batching追求的是整体吞吐单个请求的排队时延会随batch增大而升高业务方如果有低延迟要求需要通过max_num_seqs限制单次batch大小或者为高优先级请求单独开服务副本。OpenAI兼容API的意义被很多人低估了。业务方只要按照OpenAI的聊天补全格式发请求背后跑的是vLLM、Triton还是TensorRT-LLM对业务方完全透明。以后想换推理引擎、升级模型都只动服务端业务方代码一行不用改。这个抽象层的价值会在后续无数个升级场景里体现出来。2.3 流量层大模型网关与路由策略推理服务在企业里不可能只有一个模型。线上可能同时跑着7B、13B、70B好几个模型还有同一模型的不同版本预发版、灰度版、稳定版。这时候需要一个网关层做统一入口负责三件事路由根据请求头、模型名、租户信息把请求分发到对应模型后端灰度新模型版本先接2%流量观察指标没问题再逐渐扩大治理鉴权、限流、超时控制不让突发流量直接压垮推理服务网关层的灰度价值我在实际项目里体会特别深。有一次优化了一个对话模型的prompt模板自测效果不错但不敢直接全量上线。通过网关把5%的流量切到新版本跑了一天发现新版本在某个业务场景下回答长度明显失衡于是立刻回滚线上用户几乎没有感知。没有网关这种操作基本不可能这么丝滑。2.4 可观测层从“能查日志”到“能定位问题”可观测性是最容易被忽略、但线上排查时救命的一层。至少需要三件套指标QPS、平均/最大显存占用、GPU利用率、KV Cache用量、排队请求数、P50/P99时延日志请求日志结构化输出包含模型版本、prompt长度、生成token数、耗时明细链路追踪请求从网关到推理服务的全链路耗时拆分告警规则也要按推理场景定制。CPU告警意义不大核心告警应该围绕这几类服务器OOM、显存OOM、GPU掉卡、P99时延飙高、排队请求数超过阈值。规则宁可少而精也不要设置一堆永远不触发的僵尸告警那样只会让值班同学麻木最后真的故障了也没人看。3. 单机到多机多卡模型并行策略怎么选这一节是全篇最硬核的部分。单机部署只需要考虑“这模型单卡能不能装下”到了多机多卡并行策略直接决定了你能跑多大的模型、跑多快、网络要花多少钱。选错了钱花了性能还上不去。3.1 三种并行方式的原理与代价数据并行、张量并行、流水线并行是三个最基本的维度。我尽量用直白的方式说清楚以及它们分别要付出什么代价。数据并行最简单每个GPU上都放一份完整模型副本各自处理不同的请求多个副本一起提升整体吞吐。代价是显存消耗翻倍模型装不下时这个方案直接失效。张量并行TP把一次前向计算的矩阵运算拆到多张卡上。比如一个7B模型TP2时同一层的大矩阵被切到两张卡上各算一半最后汇总。优势是单请求时延最低因为所有卡都在同时算同一个请求代价是卡间通信量巨大每一层的输出都需要跨卡all-reduce卡的通信带宽直接决定性能。NVLink和PCIe这种高速互联是TP的生存土壤跨机器用TP基本等于把大文件频繁通过网线搬运慢到怀疑人生。流水线并行PP适合跨机。它把模型按层切分GPU0负责前几层GPU1负责中间层GPU2负责最后几层数据依次流过。代价是流水线空泡bubble也就是排队等前一个micro-batch算完的时间浪费。用足够小的micro-batch可以缓解但也会带来额外的调度开销。并行方式切分对象通信量跨机可用性适用场景数据并行请求batch小仅梯度/同步高多副本提升吞吐模型单卡装得下张量并行TP层内矩阵极大低依赖超高速网络单机多卡降低单请求时延流水线并行PP网络层较小仅层间激活高跨机部署超大模型层间切分还有DeepSpeed ZeRO-3的权重切分训练场景很常见但推理场景除非是超大模型加多机协作否则一般不用它因为推理过程中每层前向计算时要临时聚合权重通信开销太大。3.2 用真实参数算一算500B模型要怎么拆拿一个500B参数模型举例。FP16精度下权重大小约500B × 2字节 1000GB也就是1TB。单张A100/H100是80GB单卡肯定装不下单台8卡机器一共640GB也装不下。所以至少需要2台8卡机器也就是16张卡。策略一般是TP PP混合。假设16卡分成2个节点每个节点8卡。节点内TP8把每层的计算切到8张卡上并行靠NVLink互联节点间PP2把网络层切成两段第一段在节点A上跑完激活值传到节点B继续跑后半段。这样设计的原因很直接TP在节点内有NVLink通信效率极高PP跨节点只传激活值频率和数量都远小于TP的all-reduce千兆以上的网络就能接受。如果反过来TP跨节点每层算完都要跨机器同步一次假设一层权重几十GB1000Gbps的网络跟NVLink的600GB/s带宽差了将近5倍推理时延会直接崩掉。3.3 KV Cache对显存规划的影响部署推理服务时很多人只算模型权重多少GB而忘了KV Cache。KV Cache是推理过程中产生的中间量随序列长度和并发数线性增长。显存规划必须给KV Cache留足空间否则并发一大就OOM。我习惯用vLLM部署时把gpu_memory_utilization设到0.85到0.9预留10%~15%显存给CUDA context和临时变量。剩下的显存扣除权重就是KV Cache可用的空间。通过max_num_batched_tokens和max_num_seqs控制单次推理的batch大小避免KV Cache被瞬间填满。举个例子假设7B模型权重14GB一张80GB卡gpu_memory_utilization0.9那么可用显存72GB减去14GB权重剩下约58GB给KV Cache。如果每个请求平均序列长度1024KV Cache每请求约消耗几百MB那么并发上限轻轻松松破百。但如果序列长度拉到8192并发稍微一高58GB瞬间就被吃完了。所以“允许的最大上下文长度”和“并发数”必须一起限流不能只限制其中一个。3.4 没有高速互联网络怎么办不是每家公司都有25G/100G网卡和InfiniBand。普通万兆以太网环境多机多卡部署要注意策略选择。我踩过的坑是强行在两张卡之间开了TP结果单请求时延比单机还慢因为网卡成了瓶颈。这种条件下的正解是TP限制在单机内跨机只用PP或纯数据并行尽量用小模型 多副本数据并行网络只承担很少的同步开销用INT8/INT4量化把权重体积压下来让更小的模型放进单卡或单机量化虽然会带来一定的精度损失但对企业级推理服务来说能大幅降低机器数量省下的钱足够买更好的网络设备了。选择怎样的精度取决于业务对输出质量的敏感度没有绝对答案只有取舍。4. 三个阶段的落地路径容器化、整卡编排、多机多卡前面全是理论分析来点能直接照着做的。我复盘了当时的实施过程把它拆成三个阶段。每一步的验收标准都很明确做完一个阶段再进入下一个不要跳过。4.1 阶段一单机容器化与标准化第一步不是上Kubernetes而是先把单机部署“容器化”。容器化解决的是环境一致性和交付标准化问题让模型服务从一个“只在这台机器上能跑”的东西变成一个“镜像走到哪跑到哪”的标准产物。你需要做三件事安装NVIDIA Container Toolkit配置Docker的GPU runtime让容器里能正常使用GPU把推理服务代码和依赖打包成Docker镜像启动命令里通过环境变量注入模型路径、模型版本、监听端口等配置固化基础镜像统一CUDA版本、Python版本、推理框架版本避免“A机器能跑B机器报依赖错误”的尴尬这里有个容易忽略的点模型文件不应该打进镜像里。模型动辄几十GB打进镜像会导致镜像构建和分发非常慢而且每次模型升级都要重打镜像。正确做法是把模型文件放到共享存储或对象存储容器启动时挂载进去镜像只包含代码和依赖。模型版本通过环境变量或启动参数来控制这样同样一份镜像可以跑7B、13B、70B只需要换挂载路径和启动命令。4.2 阶段二单机整卡编排容器化跑稳之后引入Kubernetes做编排。这个阶段的目标是把GPU变成可调度的资源同时解决高可用、弹性和发布问题。首先是NVIDIA device plugin的部署。它是个DaemonSet会在每个GPU节点上自动把GPU上报给kubelet。部署完成后在Pod里这样申请GPUapiVersion: apps/v1 kind: Deployment metadata: name: llama-7b-inference namespace: ai-platform spec: replicas: 2 selector: matchLabels: app: llama-7b-inference template: metadata: labels: app: llama-7b-inference spec: containers: - name: inference image: registry.internal/ai/llama-7b:v1.2.0 resources: limits: nvidia.com/gpu: 1 env: - name: MODEL_PATH value: /models/llama-7b - name: MODEL_VERSION value: 1.2.0 ports: - containerPort: 8000 readinessProbe: httpGet: path: /health port: 8000 initialDelaySeconds: 60 periodSeconds: 10readinessProbe一定要配。推理服务启动时要把模型权重加载进显存这个过程可能持续几十秒甚至几分钟这段时间Pod还不能对外提供服务。readinessProbe好了之后Kubernetes才把流量放进来避免请求打到未就绪的Pod上导致超时。多副本部署时建议加一个PodAntiAffinity让不同副本尽量分布到不同节点affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app: llama-7b-inference topologyKey: kubernetes.io/hostname这个配置的作用是防止两个副本被调度到同一个节点挤同一张卡。模型推理服务A和B如果共享一张GPU显存和算力都会互相干扰最终表现就是时延飘忽不定、偶发OOM、问题特别难排查。弹性伸缩在这个阶段用Kubernetes HPA就能实现。不过要注意推理场景的伸缩指标不建议用CPUCPU跟推理负载的关系太弱了。更合理的指标是每副本的QPS排队请求数vLLM暴露的指标里能看到KV Cache使用率HPA配置示例apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: llama-7b-inference-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: llama-7b-inference minReplicas: 2 maxReplicas: 8 metrics: - type: Pods pods: metric: name: vllm_num_requests_waiting target: type: AverageValue averageValue: 16这个示例是当平均排队请求数超过16时扩容副本。开始阶段也可以先用QPS作为指标跑一段时间观察流量特征再切换更适合的指标。伸缩动作本身是有代价的新副本拉镜像、加载模型到显存需要几分钟所以HPA的扩缩要提前预留Buffer不要等到队列全堵了才扩容。4.3 阶段三多机多卡当单机8卡都放不下模型时才进入真正意义上的多机多卡阶段。这一步的内容不仅是“连几台机器”还包括调度、通信、发布等一整套机制。多卡模型并行通常有两种落地形态训练式多卡用NCCL做集合通信TP/PP混合并行要求节点间网络质量高推理式多卡把同一模型切分到多卡上每个Pod固定申请多张GPU比如一个推理Pod申请8张卡在Kubernetes里多卡Pod的调度要特别注意一个点gang scheduling。TP8的Pod必须一次性成功调度到8张卡不能先调度成功6张卡等另外2张。Kubernetes默认调度器是逐个Pod调度的对于一组Pod缺一不可的场景要么用Volcano这类支持gang scheduling的调度器要么自己控制好资源预留否则集群碎片化之后多卡任务会一直pending等资源研发和运维都会很焦虑。多机多卡部署时网络规划比在Kubernetes里配置更关键。同一组TP/PP的Pod最好限定在同一节点通过nodeSelector或nodeAffinity跨节点的TP会严重拖累时延。多机之间走PP的通信要确保网络带宽和延迟达到预期。我一般先跑一个NCCL all_reduce测试脚本验证一下跨节点带宽达不到预期就先排网不要直接上模型否则后面排查问题你会分不清是模型问题还是网络问题。无损发布和灰度在这个阶段尤其重要。模型并行部署一组Pod之后更新新版本不能直接“全量重启”。理想做法是新版Pod组先在旁边启动加载新模型权重然后通过网关把流量从旧版平滑切到新版切换过程中持续对比错误率、时延、用户反馈发现问题立刻切回。整个过程对用户无感这就是前面说的网关层的价值。最后别忘了节点池的弹性。多机多卡意味着对GPU实例的需求是动态的高峰期可能要20台GPU节点低谷期10台就够。Kubernetes的cluster-autoscaler可以自动根据Pod调度需求扩缩节点数量。但要注意缩容节点前要确保上面没有正在运行的推理Pod并且GPU节点的缩容速度远比普通节点慢需要提前做好时间容忍度设计。5. 多机多卡实测中最容易踩的坑与排查思路这一节全是真金白银的踩坑经验。有段时间我几乎每天都在看NCCL、看时延、看显存指标问题排查到后来都形成条件反射了。列三个最常见的坑每个都有完整的排查链路。5.1 跨机通信带宽上不去推理时延暴涨现象模型从单机切到多机后单个请求的推理时延不降反升甚至比单机还慢一半。排查链路先怀疑网络在参与推理的GPU节点之间跑一次NCCL all_reduce bench看实际带宽和延迟。如果实测带宽只有理论的20%基本是网络配置问题检查网卡状态ethtool确认网卡速率和双工模式检查MTU是否配置一致容器网络是否有带宽限制或QoS策略检查通信模式用nsys或NCCL debug日志确认通信是走NVLink还是走跨机网络。如果TP跨了节点每层计算完都要跨机同步时延肯定高修正策略TP只在节点内用跨节点用PP或数据并行如果条件允许开启RDMA/ROCE减少CPU参与网络拷贝的开销这个坑的核心教训是并行策略必须跟网络拓扑匹配。买再多高端GPU如果网络规划不对性能全部浪费在通信上。5.2 OOM反复出现服务重启后过几分钟又爆现象单测时服务一切正常小流量也没问题一旦压测或者真实流量进来不久就OOM崩溃。排查链路不是模型权重占满显存而是KV Cache随并发涨满。先把并发数限制下来比如把max_num_seqs从256降到64观察显存曲线检查gpu_memory_utilization设置。很多人图省事设到0.95结果KV Cache和模型权重抢显存一有峰值就爆。我建议设到0.85~0.9宁可少一点并发也要留出安全余量限制单个请求的max_tokens。对话服务如果对方要求生成长文一个请求就能吃掉大量KV Cache。在网关层做per-request的max_tokens限制等于给显存上了一道保险在网关层加限流。即便有弹性伸缩伸缩也有延迟限流是兜底手段保证极端情况下服务不雪崩5.3 GPU利用率拉满但P99时延反而飘红现象监控面板上GPU利用率几乎100%但P99时延异常高业务方怨声载道。排查链路GPU利用率高不等于“都在算”。有大量时间可能花在等待通信、等待batch凑齐、或busy wait上。把时延拆细看生成阶段和排队阶段的耗时占比continuous batching调度下batch越大单请求的平均等待越长。GPU利用率高了但每个请求都在排队P99自然就上去了解法是给“吞吐优先”和“延迟优先”两类业务分开部署。对低延迟要求的业务单独跑一个max_num_seqs较小的副本宁可用较低的吞吐换稳定的P99对离线批处理类任务跑一个max_num_seqs很大的副本追求极致吞吐5.4 上线前必做的五件事多机多卡环境比单机复杂一个量级很多问题只有故障发生后才知道。建议上线前把下面五件事全部演练一遍杀掉一个推理Pod确认服务能自动恢复正在处理的请求不丢失或超时可控拔掉一台GPU节点确认流量能平滑转移到其他节点集群不会因为资源不足而连锁崩溃发布新版本并故意制造异常确认网关能自动把流量切回旧版用压测工具把并发打到正常峰值的两倍确认限流和弹性伸缩能顶住查看所有监控告警面板确保关键指标都能看到、告警能触发、值班同学知道怎么处理6. 一点个人体会多机多卡部署这件事真正难的地方其实不是把机器连起来。GPU服务器、Kubernetes、vLLM、NCCL这些都是现成的工具照着文档搭一套不难。难的是让组织流程、资源治理和模型本身都具备可演进性。模型会越来越大流量会越来越复杂团队规模也在变架构必须随着这些变化持续打磨。最后分享一个小技巧如果你们正准备做多机多卡先把网络带宽和延迟测试脚本加到发布流水线里每次扩容或新增节点后自动跑一遍。这个动作看似简单但能帮你排除掉一整个类别的坑。等哪一天模型在几十张卡上稳定跑起来回头再看当初单机部署时的提心吊胆你会觉得这条路走得值。