大模型推理这件事真正跑过生产环境的人都知道训练只是冰山一角部署才是长期消耗精力的地方。一个7B参数的模型用FP16精度加载光权重就要吃掉14GB显存再加上KV Cache、中间激活值实际占用轻松突破20GB。如果换成70B的模型即便做了4-bit量化也需要接近40GB显存才能跑起来。这就意味着单卡消费级显卡基本没有太多腾挪空间云端GPU推理方案几乎是大多数团队绕不开的选择。但云端推理方案并不是“租一张卡就完事”这么简单。不同的业务场景——是低频的离线批处理还是高并发的在线对话是追求首token延迟还是追求吞吐量是短期验证性项目还是长期稳定的产品线——对应的方案选型差异非常大。选错了要么成本翻几倍要么延迟高到用户直接关页面。下面我结合自己在几个生成式AI产品部署中的实际经验把云端GPU推理的几条主流路线拆开讲清楚包括各自的适用边界、成本结构、踩过的坑以及一些容易被忽略的细节。1. 先搞清楚你的推理负载到底长什么样在讨论选哪个云端方案之前有一个前置问题必须回答你的推理负载是什么形态这个问题不搞清楚后面所有选型都是拍脑袋。1.1 在线交互式和离线批处理是两套完全不同的逻辑在线交互式推理的典型场景是对话机器人、代码补全、实时翻译。这类负载的核心指标是首token延迟TTFT和每token输出延迟TPOT。用户发出请求后如果首token超过1.5秒还没出来体验就会明显变差。这类场景对GPU的要求是显存要够大装得下模型和KV Cache计算要够快缩短prefill阶段而且需要支持连续批处理continuous batching来应对并发请求。离线批处理的典型场景是文档摘要、数据标注、内容生成流水线。这类负载不在乎单条请求的延迟在乎的是单位时间内能处理多少token也就是吞吐量。这时候你可以用更大的batch size甚至可以把GPU利用率拉到90%以上。对这类场景来说按token计费的API方案往往比自建推理集群更划算。我见过不少团队在这件事上犯迷糊拿离线批处理的成本模型去估算在线服务的预算结果上线后发现账单是预估的三倍。原因很简单——在线服务为了保延迟GPU利用率通常只能维持在30%到50%而离线批处理可以跑到80%以上。同样的GPU小时数能处理的请求量差了一倍多。1.2 模型规模和量化策略直接决定显存底线显存是推理部署的第一约束。先看一个粗略的估算公式FP16精度显存需求 ≈ 参数量 × 2字节 × 1.2含KV Cache和激活值开销INT8量化显存需求 ≈ 参数量 × 1字节 × 1.2INT4量化显存需求 ≈ 参数量 × 0.5字节 × 1.2按这个公式7B模型FP16需要约16.8GBINT8需要约8.4GBINT4需要约4.2GB。13B模型FP16需要约31GBINT4需要约7.8GB。70B模型INT4需要约42GB。这里有个容易踩的坑KV Cache的显存占用会随着并发数和上下文长度线性增长。以一个7B模型为例如果上下文长度是4096每个并发请求的KV Cache大约占用0.5GB取决于层数和注意力头配置。如果你要支持32路并发光KV Cache就要16GB加上模型权重本身一张24GB的卡根本不够。很多人在测试阶段用单请求跑得好好的一上并发就OOM根源就在这里。所以选云端方案时第一个要问自己的问题是我的模型量化后占多少显存我需要支持多少并发上下文长度上限是多少这三个数乘起来才是你真正需要的显存底线。1.3 延迟敏感型和吞吐敏感型的选型分叉延迟敏感型业务选型时优先考虑单卡高性能GPU比如A100 80GB、H100 80GB甚至L40S 48GB。这些卡的单卡算力足够强不需要跨卡通信避免了多卡推理的通信开销。如果模型能塞进单卡就尽量不要用多卡张量并行因为张量并行会引入额外的通信延迟对首token延迟的影响非常明显。吞吐敏感型业务选型时优先考虑多卡并行高性价比GPU比如用多张A10、L4或者消费级4090组成推理集群配合vLLM这类支持PagedAttention的推理框架把吞吐量拉满。这时候单卡延迟高一点无所谓关键是单位成本能处理多少token。2. 云端GPU推理的五条主流路线把负载形态搞清楚之后接下来看具体的云端方案。目前市面上能跑大模型推理的云端路线大致可以分成五类每一类的成本结构、运维复杂度和适用场景都不一样。2.1 按token计费的Serverless推理API这是最省心的方案。你不需要管GPU、不需要管显存、不需要管并发直接调API按输入输出token数付费。代表性的服务包括各类大模型厂商提供的推理API以及一些云平台提供的模型托管服务。适用场景原型验证、低频调用、流量波动大的业务、团队没有GPU运维能力。成本结构按token计费输入和输出价格通常不同。以目前市场行情来看7B级别模型的输出价格大约在每百万token几元到十几元不等70B级别模型则可能到每百万token几十元甚至上百元。优点零运维、弹性伸缩、按需付费、无需担心GPU利用率。缺点单价高、数据要出自己可控的环境、无法深度定制推理参数、高峰期可能限流。我自己的经验是如果你的日调用量在百万token以下Serverless API几乎总是最划算的选择。一旦超过这个量级自建推理的成本优势就开始显现了。但自建的前提是你有稳定的流量否则GPU闲置的成本比API贵得多。2.2 按小时租用的单卡GPU实例这是最直接的方案在云平台上租一张GPU卡自己部署推理框架自己管理服务。常见的卡型包括A100、H100、L40S、A10、L4、V100等价格从每小时几元到几十元不等。适用场景流量稳定、需要深度定制、数据不能出可控环境、模型规模能塞进单卡。成本结构按小时计费包月通常有折扣。以A100 80GB为例按需价格大约每小时20到30元包月可能降到每小时10到15元。L4 24GB按需大约每小时3到5元。优点完全可控、可以自由选择推理框架和量化策略、数据不出自己的环境、延迟稳定。缺点需要自己运维、GPU利用率低时成本浪费严重、扩容需要手动操作或自己写自动化脚本。这里有个实操细节租单卡实例时一定要确认云平台是否支持GPU直通passthrough而不是虚拟化切分。有些云平台的GPU实例是vGPU切分出来的显存和算力都有折扣跑大模型推理时性能会明显低于物理卡。租之前最好先跑一个benchmark确认实际算力。2.3 多卡GPU实例与张量并行推理当模型塞不进单卡时就需要多卡实例。比如70B模型INT4量化后约42GB一张A100 80GB能塞下但如果你要用FP16精度跑就需要两张A100做张量并行。再比如一些MoE架构的模型参数量更大可能需要4卡甚至8卡。适用场景大模型70B以上、高精度推理、需要支持长上下文。成本结构按卡数×小时计费。8卡A100实例按需价格可能每小时150到250元。优点能跑大模型、显存充足、可以通过张量并行降低单卡显存压力。缺点成本高、多卡通信有开销、推理框架配置复杂、扩容粒度粗。多卡推理最容易踩的坑是张量并行的通信开销。以vLLM为例张量并行度设置为2时两张卡之间需要频繁同步激活值如果卡间通信带宽不够比如PCIe而不是NVLink首token延迟可能比单卡还高。所以多卡推理时优先选择支持NVLink的实例或者在推理框架里调整并行策略把通信量降到最低。2.4 容器化推理服务与Kubernetes编排当你的推理服务需要弹性伸缩、多模型共存、灰度发布时容器化编排是绕不开的路。典型做法是把推理框架打包成Docker镜像通过Kubernetes管理GPU节点池用HPAHorizontal Pod Autoscaler根据请求量自动扩缩容。适用场景多模型、多版本、流量波动大、需要灰度发布和A/B测试。成本结构GPU节点按小时计费加上Kubernetes集群的管理成本。如果使用云托管的Kubernetes服务还有额外的控制面费用。优点弹性伸缩、资源隔离、部署标准化、支持滚动更新。缺点运维复杂度高、GPU调度需要额外配置如NVIDIA Device Plugin、冷启动慢拉镜像加载模型可能需要几分钟。这里有个经验GPU节点的扩容不像CPU节点那么快。CPU节点几十秒就能起来GPU节点从创建到可用可能需要3到5分钟再加上拉取镜像和加载模型的时间冷启动可能超过5分钟。所以如果你的业务有明显的流量波峰最好保留一定的常驻GPU节点作为缓冲不要完全依赖自动扩容。2.5 推理专用托管平台除了通用云平台还有一些专门做推理托管的平台它们把推理框架、量化、批处理、自动扩缩容都封装好了你只需要上传模型或者指定模型名称就能得到一个推理端点。适用场景不想碰底层推理框架、需要快速上线、模型是主流开源模型。成本结构通常按GPU小时或按token计费价格介于Serverless API和自建之间。优点部署快、运维少、自带优化如连续批处理、量化。缺点定制能力有限、支持的模型有限、数据要经过第三方平台。这类平台适合快速验证和中小规模上线。但如果你的模型有特殊结构或者需要深度定制推理逻辑托管平台往往不够灵活。3. 推理框架选型vLLM、TGI、llama.cpp还是TensorRT-LLM选好了云端GPU实例接下来要决定用什么推理框架。这个选择对性能和成本的影响非常大不同框架的吞吐量差距可能达到2到3倍。3.1 vLLM目前在线推理的主流选择vLLM的核心优势是PagedAttention它把KV Cache分成固定大小的块来管理大幅减少了显存碎片使得同样的显存能支持更多并发。实测下来vLLM在7B模型上的吞吐量通常比HuggingFace Transformers的原生推理高出10倍以上。vLLM支持连续批处理新请求可以在当前batch还在生成时插入不需要等整个batch结束。这对在线服务非常关键能把GPU利用率从30%提升到70%以上。配置上vLLM的关键参数包括python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 64 \ --dtype auto其中--gpu-memory-utilization 0.9表示允许vLLM使用90%的显存剩下的留给系统。--max-num-seqs控制最大并发序列数这个值要根据显存和上下文长度来调。调太大容易OOM调太小吞吐上不去。vLLM的坑主要在两个地方一是首次加载模型时会做显存profiling如果显存不够会直接报错所以启动前要确认显存余量二是不同版本的vLLM对模型的支持程度不同新模型可能需要等vLLM更新才能支持部署前先查一下版本兼容性。3.2 TGIHuggingFace生态的推理服务TGIText Generation Inference是HuggingFace推出的推理框架和Transformers生态结合紧密支持大部分HuggingFace上的模型。它的特点是部署简单、文档完善、和HuggingFace Hub集成好。TGI同样支持连续批处理和量化但在吞吐量上通常略低于vLLM。不过TGI的稳定性不错适合对稳定性要求高、对极致吞吐要求不那么高的场景。TGI的启动命令示例docker run --gpus all \ -p 8080:80 \ -v /data/models:/data \ ghcr.io/huggingface/text-generation-inference:latest \ --model-id /data/Qwen2.5-7B-Instruct \ --max-input-length 4096 \ --max-total-tokens 8192 \ --max-batch-prefill-tokens 8192TGI的一个优势是内置了token流式输出对需要SSE流式渲染的对话产品很友好。另外它的健康检查和指标暴露做得比较完善方便接入监控。3.3 llama.cppCPU和低显存场景的备选llama.cpp最初是为CPU推理设计的后来也支持了GPU加速。它的优势是显存占用极低通过GGUF格式的量化7B模型可以压到4GB以下甚至能在CPU上跑。但llama.cpp的吞吐量远不如vLLM和TGI不适合高并发在线服务。它更适合本地部署、边缘设备、低流量场景。如果你在云端租了一张低显存卡比如T4 16GB想跑一个13B模型llama.cpp可能是唯一选择。llama.cpp的量化等级很多从Q2到Q8量化越低显存占用越小但质量损失越大。我的经验是Q4_K_M是质量和显存的最佳平衡点再低就会出现明显的质量下降。3.4 TensorRT-LLM极致性能但门槛高TensorRT-LLM是NVIDIA推出的推理优化框架通过算子融合、kernel优化、量化等手段能把推理性能推到极致。在相同硬件上TensorRT-LLM的吞吐量通常比vLLM高20%到50%。但它的门槛也最高需要把模型转换成TensorRT引擎转换过程复杂且耗时对模型结构有要求不是所有模型都能直接转换调试困难出问题后排查链路长。TensorRT-LLM适合对性能有极致要求、模型结构固定、有专门推理优化团队的场景。对大多数团队来说vLLM的性价比更高。框架吞吐量部署难度显存效率适用场景vLLM高中高在线高并发推理TGI中高低中高HuggingFace生态、稳定优先llama.cpp低低极高低显存、CPU、边缘TensorRT-LLM极高高高极致性能、固定模型4. 成本控制的几个关键杠杆云端GPU推理的成本可以差出好几倍同样的业务量有人每月花几千有人花几万。差距主要来自几个关键杠杆。4.1 量化用精度换显存和算力量化是降低成本最直接的手段。FP16转INT8显存减半吞吐量通常还能提升20%到40%因为INT8的计算效率更高。INT8转INT4显存再减半但质量损失开始明显需要根据业务容忍度来定。实操中AWQ和GPTQ是两种最常用的4-bit量化方法。AWQ在推理时的精度保持更好GPTQ的量化速度更快。对于7B到13B的模型INT4量化后的质量损失通常在可接受范围内对于70B以上的模型INT4量化可能会在复杂推理任务上出现明显退化。量化后的模型在vLLM中加载时需要确认vLLM版本支持对应的量化格式。有些量化格式需要额外的kernel支持不是所有框架都能直接加载。4.2 批处理与并发调优把GPU利用率拉满GPU利用率是成本的核心。一张A100按小时计费不管你是跑10个请求还是1000个请求价格都一样。所以关键是把利用率拉高。连续批处理是提升利用率的核心手段。vLLM默认开启连续批处理但--max-num-seqs和--max-model-len的配置会直接影响并发能力。我的经验是先用小并发压测逐步增加并发数观察GPU利用率和延迟的变化找到延迟可接受前提下的最大并发数。另一个杠杆是动态批处理窗口。有些推理框架支持设置一个短暂的时间窗口比如10毫秒把窗口内到达的请求合并成一个batch。这能提升吞吐但会增加少量延迟。对延迟不敏感的场景可以开大一点。4.3 自动扩缩容让GPU跟着流量走如果你的流量有明显的波峰波谷自动扩缩容能省下大量成本。白天高峰用8张卡夜间低谷缩到2张卡成本能降一半以上。但GPU自动扩缩容有几个坑一是扩容慢前面说过GPU节点从创建到可用需要几分钟所以缩容要保守不要一没流量就立刻缩二是模型加载慢新Pod启动后要加载模型权重7B模型从磁盘加载到显存可能需要30秒到1分钟这期间请求会排队三是缩容时要处理正在进行的请求不能直接杀掉Pod要等请求处理完再缩。实操中我通常设置一个最小常驻节点数比如2张卡保证低谷期也有服务能力然后根据GPU利用率和请求队列长度来触发扩容。扩容阈值设低一点比如利用率超过60%就扩缩容阈值设高一点比如利用率低于20%才缩避免频繁抖动。4.4 混合部署不同模型共享GPU如果你的产品里有多个模型比如一个对话模型一个摘要模型一个embedding模型可以考虑混合部署让它们共享GPU。小模型比如embedding模型可以和主模型部署在同一张卡上通过显存隔离来避免互相干扰。vLLM支持在同一个实例里加载多个模型但需要显存足够。另一种做法是用NVIDIA MPSMulti-Process Service把一张卡切分给多个进程但MPS的隔离性不如独立实例一个进程OOM可能影响其他进程。5. 上线之后才会遇到的真实问题方案选完、框架搭好、服务跑起来这只是开始。真正的问题往往在上线之后才暴露出来。5.1 显存碎片与长稳运行的OOM推理服务跑几个小时没问题跑几天后突然OOM这是很常见的现象。原因通常是显存碎片不同长度的请求反复分配和释放KV Cache导致显存中出现大量不连续的小块最终无法分配出足够大的连续空间。vLLM的PagedAttention很大程度上缓解了这个问题但不是完全消除。如果遇到长稳OOM可以尝试降低--gpu-memory-utilization留更多余量限制--max-model-len减少单请求最大显存定期重启服务比如每天凌晨低峰期滚动重启。5.2 首token延迟的抖动首token延迟TTFT的抖动比平均延迟更影响体验。用户不介意偶尔慢一次但介意忽快忽慢。TTFT抖动通常来自几个方面请求排队并发太高新请求要等前面的prefill完成、显存不足导致的swap、GPU降频散热问题或功耗限制。排查TTFT抖动时先看GPU利用率和显存占用再看请求队列长度。如果队列长度经常超过并发数说明需要扩容或者调大batch size。如果GPU利用率不高但延迟高可能是显存swap或者PCIe带宽瓶颈。5.3 模型更新与灰度发布模型迭代时不能直接替换线上服务需要灰度发布。常见做法是双实例部署新模型起一个新实例通过网关把少量流量切过去观察指标正常后再逐步放大流量最后下线旧实例。灰度发布时要注意显存隔离新旧模型如果共享GPU可能互相抢显存。最好用独立实例或者至少用MPS做隔离。另外新模型的推理框架版本可能和旧模型不同需要确认依赖兼容。5.4 监控指标不只看GPU利用率推理服务的监控不能只看GPU利用率。至少需要关注这几类指标延迟指标TTFT、TPOT、端到端延迟的P50/P95/P99吞吐指标每秒处理token数、每秒完成请求数资源指标GPU利用率、显存占用、GPU温度、功耗队列指标等待请求数、队列等待时间错误指标OOM次数、超时次数、5xx错误率这些指标要接入统一的监控面板设置告警阈值。特别是显存占用建议设置80%的告警线留出反应时间。6. 不同规模团队的选择建议最后结合团队规模和业务阶段给一些具体的选择建议。6.1 个人开发者和小团队优先Serverless API如果你是一个人或者两三个人的小团队没有专门的运维日调用量不大直接用Serverless API。省下来的运维时间用来打磨产品比省那点token费用有价值得多。如果确实需要自建比如数据敏感租一张L4或者4090的单卡实例用vLLM部署一个量化后的7B模型每月成本可以控制在几百到一千元。这个配置能支撑日均几万次调用。6.2 中型团队单卡实例自动扩缩容有稳定流量、有基本运维能力的中型团队建议用单卡GPU实例容器化部署自动扩缩容。模型选择上7B到13B的量化模型能塞进单卡成本可控。推理框架优先vLLM配合Kubernetes做弹性伸缩。这个阶段的关键是把监控和告警做起来把成本可视化。很多团队在这个阶段成本失控就是因为不知道钱花在哪里了。6.3 大型团队多卡集群推理专用优化流量大、模型大、对延迟和吞吐都有要求的大型团队需要多卡集群TensorRT-LLM或者深度优化的vLLM。这个阶段要考虑的东西更多卡间通信、负载均衡、多区域部署、容灾切换。到这个规模推理成本已经是百万级甚至千万级的支出值得投入专门的推理优化工程师来做kernel优化、量化调优、调度策略优化。每提升10%的吞吐量一年能省下的成本可能就够养一个团队。6.4 一个容易被忽略的细节出口带宽成本很多人算成本时只算GPU小时费忽略了出口带宽费。大模型推理的输出是token流如果通过公网传输云平台的出口带宽费用可能相当可观。特别是流式输出场景每个请求持续几十秒带宽占用时间长。如果业务允许尽量把推理服务和业务服务部署在同一区域走内网通信避免出口带宽费。如果必须走公网考虑压缩输出或者用CDN加速。7. 一些实操中总结的零碎经验最后分享几条零碎但实用的经验都是实际部署中踩出来的。关于GPU选型A100和H100适合大模型和高并发但价格高L4和A10性价比高适合中小模型4090单卡算力强但显存只有24GB且云平台上的4090实例通常有散热和稳定性问题生产环境慎用。关于镜像推理框架的Docker镜像动辄几个GB拉取时间长。建议把镜像预拉到节点上或者用私有镜像仓库加速。另外镜像里的CUDA版本要和宿主机的驱动版本兼容否则会报错。关于模型加载模型权重文件很大从对象存储加载到GPU显存的时间可能成为冷启动瓶颈。可以把模型权重缓存在本地SSD上或者用内存文件系统加速加载。关于压测上线前一定要做压测而且要用真实分布的请求做压测。用固定长度的请求压测出来的吞吐量和真实场景差距很大。真实场景里请求长度是变化的长请求会拖慢整个batch。关于成本监控给GPU实例打上标签按项目、按环境分类每月对账时能清楚看到每个项目的推理成本。没有标签的GPU实例月底对账时就是一笔糊涂账。关于版本锁定推理框架和CUDA驱动的版本一定要锁定不要用latest标签。推理框架更新频繁新版本可能引入不兼容的改动生产环境要用固定版本升级前先在测试环境验证。关于降级策略推理服务要有降级策略。当GPU资源不足时可以降级到更小的模型或者限制输出长度或者排队等待。没有降级策略的服务在流量突增时容易雪崩。关于数据安全如果业务涉及敏感数据推理服务要部署在可控的环境内输入输出要加密日志要脱敏。用第三方API时要确认数据不会被用于训练并且有数据删除机制。这些经验看起来琐碎但每一条都是实际踩坑换来的。大模型推理部署这件事方案选型只是起点真正的功夫在细节里。同样一套方案细节处理得好和不好成本可能差一倍稳定性可能差一个数量级。 云端GPU推理部署实战：从显存估算到框架选型的成本优化指南
大模型推理这件事真正跑过生产环境的人都知道训练只是冰山一角部署才是长期消耗精力的地方。一个7B参数的模型用FP16精度加载光权重就要吃掉14GB显存再加上KV Cache、中间激活值实际占用轻松突破20GB。如果换成70B的模型即便做了4-bit量化也需要接近40GB显存才能跑起来。这就意味着单卡消费级显卡基本没有太多腾挪空间云端GPU推理方案几乎是大多数团队绕不开的选择。但云端推理方案并不是“租一张卡就完事”这么简单。不同的业务场景——是低频的离线批处理还是高并发的在线对话是追求首token延迟还是追求吞吐量是短期验证性项目还是长期稳定的产品线——对应的方案选型差异非常大。选错了要么成本翻几倍要么延迟高到用户直接关页面。下面我结合自己在几个生成式AI产品部署中的实际经验把云端GPU推理的几条主流路线拆开讲清楚包括各自的适用边界、成本结构、踩过的坑以及一些容易被忽略的细节。1. 先搞清楚你的推理负载到底长什么样在讨论选哪个云端方案之前有一个前置问题必须回答你的推理负载是什么形态这个问题不搞清楚后面所有选型都是拍脑袋。1.1 在线交互式和离线批处理是两套完全不同的逻辑在线交互式推理的典型场景是对话机器人、代码补全、实时翻译。这类负载的核心指标是首token延迟TTFT和每token输出延迟TPOT。用户发出请求后如果首token超过1.5秒还没出来体验就会明显变差。这类场景对GPU的要求是显存要够大装得下模型和KV Cache计算要够快缩短prefill阶段而且需要支持连续批处理continuous batching来应对并发请求。离线批处理的典型场景是文档摘要、数据标注、内容生成流水线。这类负载不在乎单条请求的延迟在乎的是单位时间内能处理多少token也就是吞吐量。这时候你可以用更大的batch size甚至可以把GPU利用率拉到90%以上。对这类场景来说按token计费的API方案往往比自建推理集群更划算。我见过不少团队在这件事上犯迷糊拿离线批处理的成本模型去估算在线服务的预算结果上线后发现账单是预估的三倍。原因很简单——在线服务为了保延迟GPU利用率通常只能维持在30%到50%而离线批处理可以跑到80%以上。同样的GPU小时数能处理的请求量差了一倍多。1.2 模型规模和量化策略直接决定显存底线显存是推理部署的第一约束。先看一个粗略的估算公式FP16精度显存需求 ≈ 参数量 × 2字节 × 1.2含KV Cache和激活值开销INT8量化显存需求 ≈ 参数量 × 1字节 × 1.2INT4量化显存需求 ≈ 参数量 × 0.5字节 × 1.2按这个公式7B模型FP16需要约16.8GBINT8需要约8.4GBINT4需要约4.2GB。13B模型FP16需要约31GBINT4需要约7.8GB。70B模型INT4需要约42GB。这里有个容易踩的坑KV Cache的显存占用会随着并发数和上下文长度线性增长。以一个7B模型为例如果上下文长度是4096每个并发请求的KV Cache大约占用0.5GB取决于层数和注意力头配置。如果你要支持32路并发光KV Cache就要16GB加上模型权重本身一张24GB的卡根本不够。很多人在测试阶段用单请求跑得好好的一上并发就OOM根源就在这里。所以选云端方案时第一个要问自己的问题是我的模型量化后占多少显存我需要支持多少并发上下文长度上限是多少这三个数乘起来才是你真正需要的显存底线。1.3 延迟敏感型和吞吐敏感型的选型分叉延迟敏感型业务选型时优先考虑单卡高性能GPU比如A100 80GB、H100 80GB甚至L40S 48GB。这些卡的单卡算力足够强不需要跨卡通信避免了多卡推理的通信开销。如果模型能塞进单卡就尽量不要用多卡张量并行因为张量并行会引入额外的通信延迟对首token延迟的影响非常明显。吞吐敏感型业务选型时优先考虑多卡并行高性价比GPU比如用多张A10、L4或者消费级4090组成推理集群配合vLLM这类支持PagedAttention的推理框架把吞吐量拉满。这时候单卡延迟高一点无所谓关键是单位成本能处理多少token。2. 云端GPU推理的五条主流路线把负载形态搞清楚之后接下来看具体的云端方案。目前市面上能跑大模型推理的云端路线大致可以分成五类每一类的成本结构、运维复杂度和适用场景都不一样。2.1 按token计费的Serverless推理API这是最省心的方案。你不需要管GPU、不需要管显存、不需要管并发直接调API按输入输出token数付费。代表性的服务包括各类大模型厂商提供的推理API以及一些云平台提供的模型托管服务。适用场景原型验证、低频调用、流量波动大的业务、团队没有GPU运维能力。成本结构按token计费输入和输出价格通常不同。以目前市场行情来看7B级别模型的输出价格大约在每百万token几元到十几元不等70B级别模型则可能到每百万token几十元甚至上百元。优点零运维、弹性伸缩、按需付费、无需担心GPU利用率。缺点单价高、数据要出自己可控的环境、无法深度定制推理参数、高峰期可能限流。我自己的经验是如果你的日调用量在百万token以下Serverless API几乎总是最划算的选择。一旦超过这个量级自建推理的成本优势就开始显现了。但自建的前提是你有稳定的流量否则GPU闲置的成本比API贵得多。2.2 按小时租用的单卡GPU实例这是最直接的方案在云平台上租一张GPU卡自己部署推理框架自己管理服务。常见的卡型包括A100、H100、L40S、A10、L4、V100等价格从每小时几元到几十元不等。适用场景流量稳定、需要深度定制、数据不能出可控环境、模型规模能塞进单卡。成本结构按小时计费包月通常有折扣。以A100 80GB为例按需价格大约每小时20到30元包月可能降到每小时10到15元。L4 24GB按需大约每小时3到5元。优点完全可控、可以自由选择推理框架和量化策略、数据不出自己的环境、延迟稳定。缺点需要自己运维、GPU利用率低时成本浪费严重、扩容需要手动操作或自己写自动化脚本。这里有个实操细节租单卡实例时一定要确认云平台是否支持GPU直通passthrough而不是虚拟化切分。有些云平台的GPU实例是vGPU切分出来的显存和算力都有折扣跑大模型推理时性能会明显低于物理卡。租之前最好先跑一个benchmark确认实际算力。2.3 多卡GPU实例与张量并行推理当模型塞不进单卡时就需要多卡实例。比如70B模型INT4量化后约42GB一张A100 80GB能塞下但如果你要用FP16精度跑就需要两张A100做张量并行。再比如一些MoE架构的模型参数量更大可能需要4卡甚至8卡。适用场景大模型70B以上、高精度推理、需要支持长上下文。成本结构按卡数×小时计费。8卡A100实例按需价格可能每小时150到250元。优点能跑大模型、显存充足、可以通过张量并行降低单卡显存压力。缺点成本高、多卡通信有开销、推理框架配置复杂、扩容粒度粗。多卡推理最容易踩的坑是张量并行的通信开销。以vLLM为例张量并行度设置为2时两张卡之间需要频繁同步激活值如果卡间通信带宽不够比如PCIe而不是NVLink首token延迟可能比单卡还高。所以多卡推理时优先选择支持NVLink的实例或者在推理框架里调整并行策略把通信量降到最低。2.4 容器化推理服务与Kubernetes编排当你的推理服务需要弹性伸缩、多模型共存、灰度发布时容器化编排是绕不开的路。典型做法是把推理框架打包成Docker镜像通过Kubernetes管理GPU节点池用HPAHorizontal Pod Autoscaler根据请求量自动扩缩容。适用场景多模型、多版本、流量波动大、需要灰度发布和A/B测试。成本结构GPU节点按小时计费加上Kubernetes集群的管理成本。如果使用云托管的Kubernetes服务还有额外的控制面费用。优点弹性伸缩、资源隔离、部署标准化、支持滚动更新。缺点运维复杂度高、GPU调度需要额外配置如NVIDIA Device Plugin、冷启动慢拉镜像加载模型可能需要几分钟。这里有个经验GPU节点的扩容不像CPU节点那么快。CPU节点几十秒就能起来GPU节点从创建到可用可能需要3到5分钟再加上拉取镜像和加载模型的时间冷启动可能超过5分钟。所以如果你的业务有明显的流量波峰最好保留一定的常驻GPU节点作为缓冲不要完全依赖自动扩容。2.5 推理专用托管平台除了通用云平台还有一些专门做推理托管的平台它们把推理框架、量化、批处理、自动扩缩容都封装好了你只需要上传模型或者指定模型名称就能得到一个推理端点。适用场景不想碰底层推理框架、需要快速上线、模型是主流开源模型。成本结构通常按GPU小时或按token计费价格介于Serverless API和自建之间。优点部署快、运维少、自带优化如连续批处理、量化。缺点定制能力有限、支持的模型有限、数据要经过第三方平台。这类平台适合快速验证和中小规模上线。但如果你的模型有特殊结构或者需要深度定制推理逻辑托管平台往往不够灵活。3. 推理框架选型vLLM、TGI、llama.cpp还是TensorRT-LLM选好了云端GPU实例接下来要决定用什么推理框架。这个选择对性能和成本的影响非常大不同框架的吞吐量差距可能达到2到3倍。3.1 vLLM目前在线推理的主流选择vLLM的核心优势是PagedAttention它把KV Cache分成固定大小的块来管理大幅减少了显存碎片使得同样的显存能支持更多并发。实测下来vLLM在7B模型上的吞吐量通常比HuggingFace Transformers的原生推理高出10倍以上。vLLM支持连续批处理新请求可以在当前batch还在生成时插入不需要等整个batch结束。这对在线服务非常关键能把GPU利用率从30%提升到70%以上。配置上vLLM的关键参数包括python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 64 \ --dtype auto其中--gpu-memory-utilization 0.9表示允许vLLM使用90%的显存剩下的留给系统。--max-num-seqs控制最大并发序列数这个值要根据显存和上下文长度来调。调太大容易OOM调太小吞吐上不去。vLLM的坑主要在两个地方一是首次加载模型时会做显存profiling如果显存不够会直接报错所以启动前要确认显存余量二是不同版本的vLLM对模型的支持程度不同新模型可能需要等vLLM更新才能支持部署前先查一下版本兼容性。3.2 TGIHuggingFace生态的推理服务TGIText Generation Inference是HuggingFace推出的推理框架和Transformers生态结合紧密支持大部分HuggingFace上的模型。它的特点是部署简单、文档完善、和HuggingFace Hub集成好。TGI同样支持连续批处理和量化但在吞吐量上通常略低于vLLM。不过TGI的稳定性不错适合对稳定性要求高、对极致吞吐要求不那么高的场景。TGI的启动命令示例docker run --gpus all \ -p 8080:80 \ -v /data/models:/data \ ghcr.io/huggingface/text-generation-inference:latest \ --model-id /data/Qwen2.5-7B-Instruct \ --max-input-length 4096 \ --max-total-tokens 8192 \ --max-batch-prefill-tokens 8192TGI的一个优势是内置了token流式输出对需要SSE流式渲染的对话产品很友好。另外它的健康检查和指标暴露做得比较完善方便接入监控。3.3 llama.cppCPU和低显存场景的备选llama.cpp最初是为CPU推理设计的后来也支持了GPU加速。它的优势是显存占用极低通过GGUF格式的量化7B模型可以压到4GB以下甚至能在CPU上跑。但llama.cpp的吞吐量远不如vLLM和TGI不适合高并发在线服务。它更适合本地部署、边缘设备、低流量场景。如果你在云端租了一张低显存卡比如T4 16GB想跑一个13B模型llama.cpp可能是唯一选择。llama.cpp的量化等级很多从Q2到Q8量化越低显存占用越小但质量损失越大。我的经验是Q4_K_M是质量和显存的最佳平衡点再低就会出现明显的质量下降。3.4 TensorRT-LLM极致性能但门槛高TensorRT-LLM是NVIDIA推出的推理优化框架通过算子融合、kernel优化、量化等手段能把推理性能推到极致。在相同硬件上TensorRT-LLM的吞吐量通常比vLLM高20%到50%。但它的门槛也最高需要把模型转换成TensorRT引擎转换过程复杂且耗时对模型结构有要求不是所有模型都能直接转换调试困难出问题后排查链路长。TensorRT-LLM适合对性能有极致要求、模型结构固定、有专门推理优化团队的场景。对大多数团队来说vLLM的性价比更高。框架吞吐量部署难度显存效率适用场景vLLM高中高在线高并发推理TGI中高低中高HuggingFace生态、稳定优先llama.cpp低低极高低显存、CPU、边缘TensorRT-LLM极高高高极致性能、固定模型4. 成本控制的几个关键杠杆云端GPU推理的成本可以差出好几倍同样的业务量有人每月花几千有人花几万。差距主要来自几个关键杠杆。4.1 量化用精度换显存和算力量化是降低成本最直接的手段。FP16转INT8显存减半吞吐量通常还能提升20%到40%因为INT8的计算效率更高。INT8转INT4显存再减半但质量损失开始明显需要根据业务容忍度来定。实操中AWQ和GPTQ是两种最常用的4-bit量化方法。AWQ在推理时的精度保持更好GPTQ的量化速度更快。对于7B到13B的模型INT4量化后的质量损失通常在可接受范围内对于70B以上的模型INT4量化可能会在复杂推理任务上出现明显退化。量化后的模型在vLLM中加载时需要确认vLLM版本支持对应的量化格式。有些量化格式需要额外的kernel支持不是所有框架都能直接加载。4.2 批处理与并发调优把GPU利用率拉满GPU利用率是成本的核心。一张A100按小时计费不管你是跑10个请求还是1000个请求价格都一样。所以关键是把利用率拉高。连续批处理是提升利用率的核心手段。vLLM默认开启连续批处理但--max-num-seqs和--max-model-len的配置会直接影响并发能力。我的经验是先用小并发压测逐步增加并发数观察GPU利用率和延迟的变化找到延迟可接受前提下的最大并发数。另一个杠杆是动态批处理窗口。有些推理框架支持设置一个短暂的时间窗口比如10毫秒把窗口内到达的请求合并成一个batch。这能提升吞吐但会增加少量延迟。对延迟不敏感的场景可以开大一点。4.3 自动扩缩容让GPU跟着流量走如果你的流量有明显的波峰波谷自动扩缩容能省下大量成本。白天高峰用8张卡夜间低谷缩到2张卡成本能降一半以上。但GPU自动扩缩容有几个坑一是扩容慢前面说过GPU节点从创建到可用需要几分钟所以缩容要保守不要一没流量就立刻缩二是模型加载慢新Pod启动后要加载模型权重7B模型从磁盘加载到显存可能需要30秒到1分钟这期间请求会排队三是缩容时要处理正在进行的请求不能直接杀掉Pod要等请求处理完再缩。实操中我通常设置一个最小常驻节点数比如2张卡保证低谷期也有服务能力然后根据GPU利用率和请求队列长度来触发扩容。扩容阈值设低一点比如利用率超过60%就扩缩容阈值设高一点比如利用率低于20%才缩避免频繁抖动。4.4 混合部署不同模型共享GPU如果你的产品里有多个模型比如一个对话模型一个摘要模型一个embedding模型可以考虑混合部署让它们共享GPU。小模型比如embedding模型可以和主模型部署在同一张卡上通过显存隔离来避免互相干扰。vLLM支持在同一个实例里加载多个模型但需要显存足够。另一种做法是用NVIDIA MPSMulti-Process Service把一张卡切分给多个进程但MPS的隔离性不如独立实例一个进程OOM可能影响其他进程。5. 上线之后才会遇到的真实问题方案选完、框架搭好、服务跑起来这只是开始。真正的问题往往在上线之后才暴露出来。5.1 显存碎片与长稳运行的OOM推理服务跑几个小时没问题跑几天后突然OOM这是很常见的现象。原因通常是显存碎片不同长度的请求反复分配和释放KV Cache导致显存中出现大量不连续的小块最终无法分配出足够大的连续空间。vLLM的PagedAttention很大程度上缓解了这个问题但不是完全消除。如果遇到长稳OOM可以尝试降低--gpu-memory-utilization留更多余量限制--max-model-len减少单请求最大显存定期重启服务比如每天凌晨低峰期滚动重启。5.2 首token延迟的抖动首token延迟TTFT的抖动比平均延迟更影响体验。用户不介意偶尔慢一次但介意忽快忽慢。TTFT抖动通常来自几个方面请求排队并发太高新请求要等前面的prefill完成、显存不足导致的swap、GPU降频散热问题或功耗限制。排查TTFT抖动时先看GPU利用率和显存占用再看请求队列长度。如果队列长度经常超过并发数说明需要扩容或者调大batch size。如果GPU利用率不高但延迟高可能是显存swap或者PCIe带宽瓶颈。5.3 模型更新与灰度发布模型迭代时不能直接替换线上服务需要灰度发布。常见做法是双实例部署新模型起一个新实例通过网关把少量流量切过去观察指标正常后再逐步放大流量最后下线旧实例。灰度发布时要注意显存隔离新旧模型如果共享GPU可能互相抢显存。最好用独立实例或者至少用MPS做隔离。另外新模型的推理框架版本可能和旧模型不同需要确认依赖兼容。5.4 监控指标不只看GPU利用率推理服务的监控不能只看GPU利用率。至少需要关注这几类指标延迟指标TTFT、TPOT、端到端延迟的P50/P95/P99吞吐指标每秒处理token数、每秒完成请求数资源指标GPU利用率、显存占用、GPU温度、功耗队列指标等待请求数、队列等待时间错误指标OOM次数、超时次数、5xx错误率这些指标要接入统一的监控面板设置告警阈值。特别是显存占用建议设置80%的告警线留出反应时间。6. 不同规模团队的选择建议最后结合团队规模和业务阶段给一些具体的选择建议。6.1 个人开发者和小团队优先Serverless API如果你是一个人或者两三个人的小团队没有专门的运维日调用量不大直接用Serverless API。省下来的运维时间用来打磨产品比省那点token费用有价值得多。如果确实需要自建比如数据敏感租一张L4或者4090的单卡实例用vLLM部署一个量化后的7B模型每月成本可以控制在几百到一千元。这个配置能支撑日均几万次调用。6.2 中型团队单卡实例自动扩缩容有稳定流量、有基本运维能力的中型团队建议用单卡GPU实例容器化部署自动扩缩容。模型选择上7B到13B的量化模型能塞进单卡成本可控。推理框架优先vLLM配合Kubernetes做弹性伸缩。这个阶段的关键是把监控和告警做起来把成本可视化。很多团队在这个阶段成本失控就是因为不知道钱花在哪里了。6.3 大型团队多卡集群推理专用优化流量大、模型大、对延迟和吞吐都有要求的大型团队需要多卡集群TensorRT-LLM或者深度优化的vLLM。这个阶段要考虑的东西更多卡间通信、负载均衡、多区域部署、容灾切换。到这个规模推理成本已经是百万级甚至千万级的支出值得投入专门的推理优化工程师来做kernel优化、量化调优、调度策略优化。每提升10%的吞吐量一年能省下的成本可能就够养一个团队。6.4 一个容易被忽略的细节出口带宽成本很多人算成本时只算GPU小时费忽略了出口带宽费。大模型推理的输出是token流如果通过公网传输云平台的出口带宽费用可能相当可观。特别是流式输出场景每个请求持续几十秒带宽占用时间长。如果业务允许尽量把推理服务和业务服务部署在同一区域走内网通信避免出口带宽费。如果必须走公网考虑压缩输出或者用CDN加速。7. 一些实操中总结的零碎经验最后分享几条零碎但实用的经验都是实际部署中踩出来的。关于GPU选型A100和H100适合大模型和高并发但价格高L4和A10性价比高适合中小模型4090单卡算力强但显存只有24GB且云平台上的4090实例通常有散热和稳定性问题生产环境慎用。关于镜像推理框架的Docker镜像动辄几个GB拉取时间长。建议把镜像预拉到节点上或者用私有镜像仓库加速。另外镜像里的CUDA版本要和宿主机的驱动版本兼容否则会报错。关于模型加载模型权重文件很大从对象存储加载到GPU显存的时间可能成为冷启动瓶颈。可以把模型权重缓存在本地SSD上或者用内存文件系统加速加载。关于压测上线前一定要做压测而且要用真实分布的请求做压测。用固定长度的请求压测出来的吞吐量和真实场景差距很大。真实场景里请求长度是变化的长请求会拖慢整个batch。关于成本监控给GPU实例打上标签按项目、按环境分类每月对账时能清楚看到每个项目的推理成本。没有标签的GPU实例月底对账时就是一笔糊涂账。关于版本锁定推理框架和CUDA驱动的版本一定要锁定不要用latest标签。推理框架更新频繁新版本可能引入不兼容的改动生产环境要用固定版本升级前先在测试环境验证。关于降级策略推理服务要有降级策略。当GPU资源不足时可以降级到更小的模型或者限制输出长度或者排队等待。没有降级策略的服务在流量突增时容易雪崩。关于数据安全如果业务涉及敏感数据推理服务要部署在可控的环境内输入输出要加密日志要脱敏。用第三方API时要确认数据不会被用于训练并且有数据删除机制。这些经验看起来琐碎但每一条都是实际踩坑换来的。大模型推理部署这件事方案选型只是起点真正的功夫在细节里。同样一套方案细节处理得好和不好成本可能差一倍稳定性可能差一个数量级。