1. 延迟和吞吐量为什么总是被放在一起逼疯创业团队先说一个我自己的经历。前年我们有个客户做AI客服正式上线前一周突然被市场部要求支持秒回理由是竞品做到了。技术团队连夜把GPU实例加了三倍结果延迟确实压到了800毫秒但账单从每月两万直接跳到九万而且并发上来以后P99依然飙到2秒开外。这个场景很多AI创业团队应该都熟——不是模型不行不是代码不行是你在选云平台和推理架构的源头就没把延迟和吞吐量的关系理顺。很多刚上手的朋友会把推理延迟和吞吐量当成两个独立的优化指标实际上在云端推理场景里它们是一根绳上的两只蚂蚱。延迟Latency指的是单个请求从发出去到拿回结果的完整时间通常看平均数和P99也就是最差的那1%用户等多久。吞吐量Throughput则是在单位时间内系统能处理的请求数常用RPSRequests Per Second或者Tokens/s来衡量。你单独优化任何一个指标都很容易麻烦的是两者之间的权衡。这个权衡关系有点像高速收费站。你要降低每辆车的通过时间就得多开闸口但闸口太多调度和管理成本会迅速吃掉收益。GPU推理也是这样为了压低单请求延迟你可能一个Batch只放1到4个请求甚至用独占实例结果是单次响应快了但单位时间里GPU的算力利用率低得可怜吞吐量上不去反过来为了拉高RPS你把Batch Size调大、把请求尽量积压起来一起算吞吐量上去了但每个请求在队列里排队的时间变长延迟自然恶化。真正让事情变得更复杂的是创业公司的流量几乎从来不是均匀分布的。白天上班时间大并发深夜几乎没人用偶尔还有某条短视频带火了一个功能导致流量突然涨五倍。静态地选一个性能参数好看的平台根本不解决问题你真正需要的是一个能在延迟和吞吐量之间动态切换的部署策略以及一个能承载这种策略的云端推理平台。所以这篇文章不是让你背参数表而是把我自己踩过的坑、实测过的数据、选型时真正该问的问题全部展开。无论你的场景是AI客服、Agent应用、编程助手还是AIGC内容生成核心逻辑是通用的先搞清楚两到三个关键指标的关系再拿着这些指标去审平台最后用工程架构去兜底。这样才不会出现买了最贵的卡用户照样抱怨慢的尴尬。2. 选平台之前先把这几张牌摊开看明白我见过太多人上来就问哪家平台最好其实这种问法在云端推理这个领域毫无意义。平台没有绝对的好或坏只有适不适合你的负载模型。在对比具体厂商之前有几项底层参数和性能边界你必须先弄清楚否则你看到的各家评测报告就是鸡同鸭讲。2.1 GPU型号、显存和互联方式决定了单机推理的天花板云端推理平台的第一个分水岭是你能租到什么GPU。现在主流的选择大致是这几个档位NVIDIA L4或同级别的入门卡适合小模型和低并发验证L40S、A10G这类中端卡在性价比上比较均衡A100 40G/80G和H100是最大的分水岭几乎所有重量级生成式AI负载都跑在它们上面再往上就是H200、B200这种最新一代卡价格昂贵除非你的场景是Top级大模型微调或超大Batch推理否则前期不推荐。这里有个很容易被忽略的点显存。很多创业团队只看算力FLOPS不看显存结果模型放不下或者Batch Size一拉大就OOM。比如7B参数的模型用FP16精度推理光权重就要占掉14GB显存左右加上KV Cache和激活值至少需要40GB的余量才算安全。所以很多团队发现13B模型在A10G上跑不稳不是A10G算力不够而是显存余量太小稍微上一点并发应用就崩。选择平台的时候显存大小直接决定了你的模型能部署到什么档位。另外如果你要部署的是单个节点放不下的超大模型或者用了张量并行Tensor Parallel把模型切成多卡跑那就得看实例内部的GPU互联方式。NVLink直连的8卡A100/H100实例比用普通以太网拼起来的几台4卡机器通信效率高非常多。凡是号称可以做多机推理的云平台你都要追问一句节点间互联走的是什么协议跨机张量并行的效率能到单机的百分之多少。这个问题问出去能筛掉一半看起来什么都能做的平庸平台。2.2 吞吐量的坑藏在排队、显存调度和冷启动里很多平台宣传的吞吐量是纯裸机测试数据输入一个固定长度的请求连续灌几个Batch测出来的。但真实生产环境的吞吐量不是这样算的。你在控制台看到的并发数只是同时到了多少个请求真正决定吞吐量的是这四件事第一队列长短和排队策略。请求发到平台后有没有一个显式的排队层排队超时怎么处理是否支持优先级队列。很多平台为了保证其他租户不被打扰会悄悄限制你的实例数量——比如你肉眼可见地配了4个副本但实际并发超过某个值之后多余请求全部扔进一个很慢的全局队列。这种问题在P99指标上暴露无遗。第二连续批处理Continuous Batching能力。同一张GPU上同时跑几个不同长度、不同到达时间的请求是现在推理服务引擎的核心竞争力。传统做法是等一个Batch攒满再算结果第一个来的请求要等最后一个人齐才开工新一代引擎比如vLLM、TensorRT-LLM、SGLang则在请求到达时动态插入当前Batch的空隙里既保证了吞吐量又大幅缩短了平均排队时间。选平台时务必确认底层推理引擎是什么版本支持不支持Continuous Batching这个决定了一个小模型能不能扛住真正的生产流量。第三冷启动时间。Serverless模式听起来很美好——没流量时缩到零有流量时自动拉起来。但一个冷启动的容器要把模型从远端存储器加载进显存哪怕用的还是高速缓存也要几十秒甚至几分钟。对聊天类应用来说这几十秒直接变成用户流失。所以早期创业项目我一般不建议纯Serverless推理除非你能接受把活跃副本至少保持1个作为保底否则所谓自动扩缩就是在延迟和钱之间反复横跳。第四静态Batch和动态Batch的差别。平台有没有开启动态Batching、Batch里的最大Token数是多少、最优Batch Size是多少——这些参数直接决定了实测吞吐量能到宣传数据的几成。后面我会拿我们自己做的一组测试来说明这个差距。2.3 区域、网络和可用性再快的GPU也怕跨洋绕路这个点最容易被我们这样的技术型团队忽略但用户感知最强。GPU所在的数据中心离你的用户群体太远网络延迟就能吃掉你50毫秒到100毫秒的优化成果。国内用户密集的应用放着国内节点不用非要去美国区部署哪怕GPU型号高一级体感也一定会变差。还有一点是云平台之间的内网延迟。如果你的业务架构是前端服务在云厂商A推理服务在云厂商B那么每次推理请求都要走公网绕一圈这中间的网络抖动、限速和DNS解析问题会让你的P99惨不忍睹。尽量把推理平台和主业务放在同一个云厂商或者同一个可用区里这是一种投入最低但见效极快的优化。此外查询GPU实例的可选区域列表时顺便查一下该区域之前有没有过大规模宕机历史以及平台有没有承诺跨可用区自动故障转移。AI创业公司的客服系统挂了还能忍模型服务挂了连降级方案都没有就真的麻烦了。3. 现在可以聊具体平台了按场景分成四组来看把上面这些底层逻辑理清楚之后再来对比市面上的云端推理平台你就不会被名字绕晕了。我把现阶段比较有代表性的平台按使用方式分成四个梯队每组的适用对象、成本结构差异巨大。3.1 GPU云厂商和容器底座自己掌控一切适合有工程能力的团队第一类是CoreWeave、Lambda Labs、RunPod、Vast.ai这类的GPU容器云以及各大云计算厂商开出来的裸金属GPU实例。这类平台的逻辑很简单给你一台带GPU的机器或者一个容器你自己装推理引擎、自己写调度器、自己处理扩缩容。自由度最高成本空间也最大尤其是长租包年情况下比大厂按需实例便宜不少。但代价是所有的工程复杂度都压在自己头上没有现成的模型服务化组件也没有一揽子监控告警。适合这种平台的团队画像很清晰至少有两到三个能熟练操作Kubernetes、懂推理引擎参数的工程师模型迭代不频繁流量模式相对稳定。如果你还在创业早期、只有一两个后端不建议走这条最硬核的路线。因为你会发现自己花了大量时间在调卡、配网络、处理驱动版本这些非业务问题上而这些时间本来应该花在优化产品和模型上。3.2 托管推理平台Serverless才真正的少维护模型服务的第一站第二类是Together AI、Fireworks AI、Groq Cloud、DeepInfra这一批专门做托管推理的厂商以及国内同类服务。他们做的事情和GPU云正好相反模型、推理框架、扩缩容全部帮你管好你只需要调用API或者按他们的规范上传自己的模型权重。他们对外宣称的延迟和吞吐量数字通常非常漂亮因为底层用的是自研或深度定制的推理引擎和调度系统。这类平台最适合的场景是业务刚起步、不想为基础设施分心或者需要快速验证一个AI功能是否可行的团队。比如用Together或者Fireworks部署一套开源模型接上vLLM兼容的OpenAI接口半天就能把Demo跑起来。Groq Cloud的LPU架构则是在低延迟赛道上的另类黑马它牺牲了一部分模型兼容性和通用性换来的是极致的单请求响应时间特别适合对秒回要求极高的对话场景。不过托管平台也有明显的短板。一是自定义能力受限你想改KV Cache策略、想给模型打补丁、想接自定义的观测平台很多操作根本不在他们的产品文档里。二是成本模型比较难预测尤其是当你流量冲到一定量级以后按Token计费比自建GPU集群贵出一大截。三是数据合规和网络问题如果你处理的是敏感业务数据API调用的数据链路是不是符合合规要求需要专门看清单确认。我把这些平台视作用钱买时间的完美工具用它们的核心目的是快速跑通、快速验证需求而不是为长期规模做地基。3.3 传统云厂商的推理平台SageMaker、Vertex AI、Azure ML第三类是AWS SageMaker、Google Vertex AI、Azure ML这类大厂托管的机器学习平台。它们的优势是生态完整跟自己的存储、监控、权限体系、VPC完全打通适合已经深度绑定某一家云厂商的公司。SageMaker推出了推理端点Endpoint和异步推理Async Inference几个大方向Vertex AI有专门的Model Garden以及各种优化后的部署镜像Azure ML在和企业级客户的花式需求对接上确实有天然优势。但这些平台的通病也很明显抽象层级比较高定价和权限模型啰嗦文档写得很全但让新手摸不到头绪。还有一个非常现实的问题是它们默认带的推理配置模板不一定适合你的模型。有时候你在SageMaker上部署一个Llama模型他们给的默认容器镜像还是老版本压根没有开启关键的缓存优化。你需要自己很懂行地做一层镜像覆盖和参数调优才能把性能拉上来。所以这类平台适合我已经在这个云上跑了好几年业务的团队数据资产、身份认证、网络组网都已经在那里沉淀好了直接复用链路就好了不需要再跨云。3.4 无服务器容器与GPU函数Modal、Beam、RunPod Serverless第四类我想单独提一下Modal、Beam、RunPod Serverless这类GPU函数平台。它们的模式介于GPU云和托管推理之间你能自定义启动脚本和运行环境但不需要关心底层机器调度让平台帮你按流量秒级扩缩容。Modal做得尤其漂亮冷启动被控制在极短时间把模型放在分布式缓存层新实例起来时直接从缓存加载权重再加上自动缩容到零对小团队来说简直是指数级提升了开发效率。但这类平台同样不适合承接稳定的高吞吐流量。因为它的计费模型是按实例运行时长加资源用量算的如果流量24小时稳定Serverless的叠加费用反而不如直接长租一个实例来得便宜。另外你还需要面对一个现实问题动态扩缩容的实例类型和网络出口可能频繁变化如果你的下游服务对出口IP有白名单限制就会遇到时不时被拒的尴尬。我的建议是用Modal这类的工具去跑离线任务、临时算力扩容、批量数据处理效果非常好但线上实时推理还是老老实实放一个固定副本的服务。平台类型代表产品适合阶段核心优势核心代价GPU云容器CoreWeave / Lambda / RunPod有工程团队流量稳定便宜、灵活、可控运维成本高托管推理APITogether / Fireworks / Groq起步验证期零部署、性能好费用贵、定制差传统ML平台SageMaker / Vertex AI / Azure ML已深度绑定某云生态完整、权限统一重、模板化、调优难GPU函数Modal / Beam / RunPod Serverless离线任务、弹性突发秒级扩缩、免运维持续高流量不划算4. 我们过去实测过的一组数据平台性能差距比你想象的大光讲理论不摆数据那是耍流氓。下面这组数据不是从官方测试报告里抄的是我们团队在一个7B开源模型、相同输入约512个Token、相同Batch策略下用同一套压测脚本在不同平台上跑出来的真实结果已经脱敏。需要先说明的是这组数据只是某一时点、某一配置下的快照不代表平台的最佳水平但用来理解同一件事在不同平台上的差异之大非常有代表性。平台平均延迟msP99延迟ms吞吐量req/s单次推理费用相对值GPU云容器H100自建vLLM6501280861.0托管推理平台A7201420691.6托管推理平台B主打低延迟410950422.2传统ML平台默认配置9802600341.8GPU函数Modal配H1007801900512.4看出门道了吗托管推理平台B的平均延迟确实最低但它的吞吐量只有42req/s是自建方案的一半不到。因为低延迟策略靠的是尽早占住专用算力、小Batch立即处理用这种方式牺牲了算力复用。传统ML平台在默认配置下P99反而最差这说明官方模板的默认参数有多保守你不调优就上线等于买了一辆车但一直挂在二挡跑。GPU函数平台平均延迟中规中矩但P99偏高典型的机械化扩缩容抖动。这组数据还反映出一个很关键的事实自建vLLM并对参数做一轮调优之后综合性能是最好的同时单次推理成本最低。但这并不等于每个团队都应该自建因为数据背后还有一个隐性成本调试和运维的时间。我们为了把这组自建数据调到正常水平前前后后花了两三天包括调Continuous Batching窗口、KV Cache的显存占用比例、并发队列上限。你要把工程师的时薪算进去托管平台的贵可能反而变成最便宜的选项。怎么用这群数据做决策我建议把推理管线按请求特征拆成两条线上交互类请求对延迟极度敏感用平均延迟或P99作为决定指标不考虑吞吐量最大化该用贵但快的平台就去用离线批量类请求比如跑数据标注、AI摘要的预生成、Agent后台大量的工具调用全部走独立实例调大Batch把吞吐量拉满。很多团队非要在同一个集群上同时满足两种负载结果两种指标都做不好。物理上用不同实例、逻辑上用不同端点和队列去隔离这两类流量才是兼顾延迟和吞吐量的第一步。5. 兼顾延迟与吞吐量不是平台能给你的是架构设计出来的平台模型只是棋盘真正决定输赢的是架构。我见过太多团队签下大额GPU合同最后发现性能不达标原因不是卡不行而是请求调度一塌糊涂。这一节说说我们在实际项目中反复验证过的几种兼顾延迟和吞吐量的架构模式。5.1 混合路由把快请求和慢请求分开引流最有价值也最容易被忽略的一条经验是不是所有请求都值得占用昂贵的GPU。很多应用里80%的流量是高频且简单的请求比如这个商品的简介生成一句话或者这句代码补全剩下20%是超长文档总结、多轮Agent推理这种重负载。如果你用同一套推理栈处理这两种请求为了保住20%重负载的吞吐轻负载的延迟也被拖高了为了保住轻负载的延迟重负载又频繁超时。我的做法是在所有推理请求之前架一层轻量级路由网关网关根据请求参数预估类型路由到不同规格的推理池。举例来说短输入短输出的请求走一块由L4或者更小实例组成的低延迟小模型池长文本生成请求走H100大Batch池。两边各有自己独立的队列和扩缩容策略互不阻塞。这种改造在代码上很轻——无非是在API网关层加几行规则但效果立竿见影吞吐量几乎翻倍P99更是降下来了。5.2 前缀缓存和语义缓存不重复算已经算过的东西推理延迟高、吞吐量上不去很多时候不是算得慢而是大量算力浪费在重复计算上。编程助手场景最典型用户每敲一个字符都触发一次请求但整个对话开头的一大段上下文是完全相同的模型每次都要把这段前缀重新编码一遍。现在的推理引擎普遍支持Prefix Caching把相同前缀的KV Cache计算结果缓存下来命中情况下可以跳过重复的Prefill阶段只算新增Token部分延迟能降低30%到50%。更进一步的做法是做语义缓存。如果用户的请求和之前某次请求高度相似且对实时性要求不高比如总结这篇论文这种结果确定性较强的场景直接把上一次的结果从Redis里取出来返回压根不进GPU。在我们的智能文档处理项目里加了语义缓存后相同重复文档的调用量直接降了60%把省下来的算力留给真正需要实时生成的请求。缓存命中率高的负载延迟和吞吐量不用调参就同时变好了。5.3 自动扩缩容不能只看CPU得盯着算力队列成熟的推理平台都会提供自动扩缩容能力但默认指标往往不适合AI推理。按CPU使用率扩缩是很多团队踩过的坑GPU推理请求通常先排队等算力CPU使用率可能一直不高直到真正的并发尖峰来的时候CPU才猛涨但那时新实例拉起来已经晚了用户的等待体验已经被打破。正确做法是配置自定义指标——队列里的积压请求数和排队时间。只要当前队列里的请求超过阈值就立刻扩容一个新副本队列空了30秒后开始缩容。或者更简单一点直接采用Per-GPU利用率比如DCGM指标里的显卡算力利用率作为扩缩指标把目标值设定在60%到70%留出响应缓冲。这样的扩缩容策略才能让系统在低延迟和高吞吐之间自动保持浮动。5.4 降级和熔断吞吐量再高挂了就等于零做AI创业公司还得有服务不可用时的备用方案。即使平台再稳也会遇到模型推理超时、上游API限流的突发状况。我们的经验是提前准备一个降级方案把推理链路和业务降级链路完全拆开。比如在AI客服的场景中模型服务超时后自动降级为预置的规则话术库用户先收到一句稍等我们正在为您查询而不是接一个白屏。后端同时把失败请求记录到队列里等推理服务恢复后重新处理。这个能力与平台关系不大但你在选型时一定要确认平台支持请求超时控制、重试策略和后端熔断配置否则出了故障你只能干瞪眼。6. 部署完成之后的排坑清单和给创业团队的五条经验最后这部分我按实际部署和优化过程中的经验整理一份后来者少踩坑清单。它不是官方文档上的内容而是我们花了真金白银和时间买来的教训。6.1 六个排查性能问题时的常用切入口第一确认你是否真的命中了GPU。有时候配置了GPU实例但因为推理框架的某些算子不支持GPU程序自动回退到CPU性能自然暴跌。看监控里GPU利用率是不是接近零就知道了。第二检查Batch Size是不是被推理引擎的最大输入长度配置偷偷限制了。很多平台的默认Max Input Length远小于你业务的真实长度一旦请求超长就自动走fallback逻辑性能完全不同。第三看网络出口是不是公网。如果平台给你用的是公网域名提供服务跨区域访问的抖动会在你的P99里被无限放大尽量切到私网或者专线。第四排查权重文件和模型加载方式。加载方式用FP16还是INT8KV Cache用不用量化显存预算怎么分配这些参数微调一下吞吐量可能从40涨到80。第五压测脚本本身是否正确。开线程数的设计要模拟真实用户到达间隔不要用最大循环去压一个串行接口否则测出来的数据没有任何参考价值。第六观察队列积压曲线。如果平台控制台的队列积压呈锯齿状上升又瞬间清空说明你的扩缩容阈值设置得太激进需要调大一点缓冲。6.2 五条取过碳的选型经验第一条所有云厂商给你的Benchmark数据只能作为候选清单不能作为决策依据。真正决策前必须用自己的业务流量回放脚本在真实请求长度和真实并发分布下压测一遍并且至少压测3天观察长尾波动。第二条不要把钱全部押在一个平台。无论你当前选了多合适的平台都建议至少保留一个第二套方案把模型的推理接口抽象成OpenAI兼容格式随时可以切换。我们不希望用绑定换来性能一旦平台涨价或者出现大规模故障多一套部署方案就是多一条命。第三条早期阶段别过度纠结GPU型号。创业早期先把最便宜的L4级别实例跑通业务闭环等用户量增长到有明确瓶颈了再上H100。因为算力成本在性能调优和产品验证之前性价比是最低的。第四条认真计算沉默成本。平台迁移不是简单换API地址的事——日志系统、监控、告警、费用体系、权限管理全都绑在上面。团队小的时候可以随便试一旦规模上来迁移成本会高到让人不想动。所以选长期平台时应选择开放度高、兼容面广的产品给自己留后路。第五条也是最想说的一条延迟和吞吐量指标不是只给后端看的。产品经理和市场团队必须了解这两个指标的物理极限不要做出既要延迟20毫秒又要每天处理百万级请求这种完全违背算力常识的需求清单。我后来跟产品团队定的规矩是需求文档里必须同时标注延迟目标、吞吐量预估和成本上限三个数字写不清楚的需求一律打回。站在市场的角度这三者是不可兼得的三角形每次改动都要重新平衡。6.3 关于评测平台的一个补充不少团队反馈说看了平台列表还是头晕我建议你用最高频的业务请求先跑一个最小验证集选3个候选平台的免费额度或者按量付费试用每种平台部署同一个模型、同一套接口格式然后用自己回放的流量各压半小时把延迟、P99、错误率、成本拉成一张Excel表格。整个过程通常两到三天完成但这个投入换来的信息比看任何评测文章都要可靠得多。再说一遍平台没有绝对最优只有与你的业务曲线最匹配的那一个。把业务拆解清楚把指标核对明白再去谈平台思路就会清晰很多。 延迟与吞吐量如何权衡？云端推理平台选型与架构实战
1. 延迟和吞吐量为什么总是被放在一起逼疯创业团队先说一个我自己的经历。前年我们有个客户做AI客服正式上线前一周突然被市场部要求支持秒回理由是竞品做到了。技术团队连夜把GPU实例加了三倍结果延迟确实压到了800毫秒但账单从每月两万直接跳到九万而且并发上来以后P99依然飙到2秒开外。这个场景很多AI创业团队应该都熟——不是模型不行不是代码不行是你在选云平台和推理架构的源头就没把延迟和吞吐量的关系理顺。很多刚上手的朋友会把推理延迟和吞吐量当成两个独立的优化指标实际上在云端推理场景里它们是一根绳上的两只蚂蚱。延迟Latency指的是单个请求从发出去到拿回结果的完整时间通常看平均数和P99也就是最差的那1%用户等多久。吞吐量Throughput则是在单位时间内系统能处理的请求数常用RPSRequests Per Second或者Tokens/s来衡量。你单独优化任何一个指标都很容易麻烦的是两者之间的权衡。这个权衡关系有点像高速收费站。你要降低每辆车的通过时间就得多开闸口但闸口太多调度和管理成本会迅速吃掉收益。GPU推理也是这样为了压低单请求延迟你可能一个Batch只放1到4个请求甚至用独占实例结果是单次响应快了但单位时间里GPU的算力利用率低得可怜吞吐量上不去反过来为了拉高RPS你把Batch Size调大、把请求尽量积压起来一起算吞吐量上去了但每个请求在队列里排队的时间变长延迟自然恶化。真正让事情变得更复杂的是创业公司的流量几乎从来不是均匀分布的。白天上班时间大并发深夜几乎没人用偶尔还有某条短视频带火了一个功能导致流量突然涨五倍。静态地选一个性能参数好看的平台根本不解决问题你真正需要的是一个能在延迟和吞吐量之间动态切换的部署策略以及一个能承载这种策略的云端推理平台。所以这篇文章不是让你背参数表而是把我自己踩过的坑、实测过的数据、选型时真正该问的问题全部展开。无论你的场景是AI客服、Agent应用、编程助手还是AIGC内容生成核心逻辑是通用的先搞清楚两到三个关键指标的关系再拿着这些指标去审平台最后用工程架构去兜底。这样才不会出现买了最贵的卡用户照样抱怨慢的尴尬。2. 选平台之前先把这几张牌摊开看明白我见过太多人上来就问哪家平台最好其实这种问法在云端推理这个领域毫无意义。平台没有绝对的好或坏只有适不适合你的负载模型。在对比具体厂商之前有几项底层参数和性能边界你必须先弄清楚否则你看到的各家评测报告就是鸡同鸭讲。2.1 GPU型号、显存和互联方式决定了单机推理的天花板云端推理平台的第一个分水岭是你能租到什么GPU。现在主流的选择大致是这几个档位NVIDIA L4或同级别的入门卡适合小模型和低并发验证L40S、A10G这类中端卡在性价比上比较均衡A100 40G/80G和H100是最大的分水岭几乎所有重量级生成式AI负载都跑在它们上面再往上就是H200、B200这种最新一代卡价格昂贵除非你的场景是Top级大模型微调或超大Batch推理否则前期不推荐。这里有个很容易被忽略的点显存。很多创业团队只看算力FLOPS不看显存结果模型放不下或者Batch Size一拉大就OOM。比如7B参数的模型用FP16精度推理光权重就要占掉14GB显存左右加上KV Cache和激活值至少需要40GB的余量才算安全。所以很多团队发现13B模型在A10G上跑不稳不是A10G算力不够而是显存余量太小稍微上一点并发应用就崩。选择平台的时候显存大小直接决定了你的模型能部署到什么档位。另外如果你要部署的是单个节点放不下的超大模型或者用了张量并行Tensor Parallel把模型切成多卡跑那就得看实例内部的GPU互联方式。NVLink直连的8卡A100/H100实例比用普通以太网拼起来的几台4卡机器通信效率高非常多。凡是号称可以做多机推理的云平台你都要追问一句节点间互联走的是什么协议跨机张量并行的效率能到单机的百分之多少。这个问题问出去能筛掉一半看起来什么都能做的平庸平台。2.2 吞吐量的坑藏在排队、显存调度和冷启动里很多平台宣传的吞吐量是纯裸机测试数据输入一个固定长度的请求连续灌几个Batch测出来的。但真实生产环境的吞吐量不是这样算的。你在控制台看到的并发数只是同时到了多少个请求真正决定吞吐量的是这四件事第一队列长短和排队策略。请求发到平台后有没有一个显式的排队层排队超时怎么处理是否支持优先级队列。很多平台为了保证其他租户不被打扰会悄悄限制你的实例数量——比如你肉眼可见地配了4个副本但实际并发超过某个值之后多余请求全部扔进一个很慢的全局队列。这种问题在P99指标上暴露无遗。第二连续批处理Continuous Batching能力。同一张GPU上同时跑几个不同长度、不同到达时间的请求是现在推理服务引擎的核心竞争力。传统做法是等一个Batch攒满再算结果第一个来的请求要等最后一个人齐才开工新一代引擎比如vLLM、TensorRT-LLM、SGLang则在请求到达时动态插入当前Batch的空隙里既保证了吞吐量又大幅缩短了平均排队时间。选平台时务必确认底层推理引擎是什么版本支持不支持Continuous Batching这个决定了一个小模型能不能扛住真正的生产流量。第三冷启动时间。Serverless模式听起来很美好——没流量时缩到零有流量时自动拉起来。但一个冷启动的容器要把模型从远端存储器加载进显存哪怕用的还是高速缓存也要几十秒甚至几分钟。对聊天类应用来说这几十秒直接变成用户流失。所以早期创业项目我一般不建议纯Serverless推理除非你能接受把活跃副本至少保持1个作为保底否则所谓自动扩缩就是在延迟和钱之间反复横跳。第四静态Batch和动态Batch的差别。平台有没有开启动态Batching、Batch里的最大Token数是多少、最优Batch Size是多少——这些参数直接决定了实测吞吐量能到宣传数据的几成。后面我会拿我们自己做的一组测试来说明这个差距。2.3 区域、网络和可用性再快的GPU也怕跨洋绕路这个点最容易被我们这样的技术型团队忽略但用户感知最强。GPU所在的数据中心离你的用户群体太远网络延迟就能吃掉你50毫秒到100毫秒的优化成果。国内用户密集的应用放着国内节点不用非要去美国区部署哪怕GPU型号高一级体感也一定会变差。还有一点是云平台之间的内网延迟。如果你的业务架构是前端服务在云厂商A推理服务在云厂商B那么每次推理请求都要走公网绕一圈这中间的网络抖动、限速和DNS解析问题会让你的P99惨不忍睹。尽量把推理平台和主业务放在同一个云厂商或者同一个可用区里这是一种投入最低但见效极快的优化。此外查询GPU实例的可选区域列表时顺便查一下该区域之前有没有过大规模宕机历史以及平台有没有承诺跨可用区自动故障转移。AI创业公司的客服系统挂了还能忍模型服务挂了连降级方案都没有就真的麻烦了。3. 现在可以聊具体平台了按场景分成四组来看把上面这些底层逻辑理清楚之后再来对比市面上的云端推理平台你就不会被名字绕晕了。我把现阶段比较有代表性的平台按使用方式分成四个梯队每组的适用对象、成本结构差异巨大。3.1 GPU云厂商和容器底座自己掌控一切适合有工程能力的团队第一类是CoreWeave、Lambda Labs、RunPod、Vast.ai这类的GPU容器云以及各大云计算厂商开出来的裸金属GPU实例。这类平台的逻辑很简单给你一台带GPU的机器或者一个容器你自己装推理引擎、自己写调度器、自己处理扩缩容。自由度最高成本空间也最大尤其是长租包年情况下比大厂按需实例便宜不少。但代价是所有的工程复杂度都压在自己头上没有现成的模型服务化组件也没有一揽子监控告警。适合这种平台的团队画像很清晰至少有两到三个能熟练操作Kubernetes、懂推理引擎参数的工程师模型迭代不频繁流量模式相对稳定。如果你还在创业早期、只有一两个后端不建议走这条最硬核的路线。因为你会发现自己花了大量时间在调卡、配网络、处理驱动版本这些非业务问题上而这些时间本来应该花在优化产品和模型上。3.2 托管推理平台Serverless才真正的少维护模型服务的第一站第二类是Together AI、Fireworks AI、Groq Cloud、DeepInfra这一批专门做托管推理的厂商以及国内同类服务。他们做的事情和GPU云正好相反模型、推理框架、扩缩容全部帮你管好你只需要调用API或者按他们的规范上传自己的模型权重。他们对外宣称的延迟和吞吐量数字通常非常漂亮因为底层用的是自研或深度定制的推理引擎和调度系统。这类平台最适合的场景是业务刚起步、不想为基础设施分心或者需要快速验证一个AI功能是否可行的团队。比如用Together或者Fireworks部署一套开源模型接上vLLM兼容的OpenAI接口半天就能把Demo跑起来。Groq Cloud的LPU架构则是在低延迟赛道上的另类黑马它牺牲了一部分模型兼容性和通用性换来的是极致的单请求响应时间特别适合对秒回要求极高的对话场景。不过托管平台也有明显的短板。一是自定义能力受限你想改KV Cache策略、想给模型打补丁、想接自定义的观测平台很多操作根本不在他们的产品文档里。二是成本模型比较难预测尤其是当你流量冲到一定量级以后按Token计费比自建GPU集群贵出一大截。三是数据合规和网络问题如果你处理的是敏感业务数据API调用的数据链路是不是符合合规要求需要专门看清单确认。我把这些平台视作用钱买时间的完美工具用它们的核心目的是快速跑通、快速验证需求而不是为长期规模做地基。3.3 传统云厂商的推理平台SageMaker、Vertex AI、Azure ML第三类是AWS SageMaker、Google Vertex AI、Azure ML这类大厂托管的机器学习平台。它们的优势是生态完整跟自己的存储、监控、权限体系、VPC完全打通适合已经深度绑定某一家云厂商的公司。SageMaker推出了推理端点Endpoint和异步推理Async Inference几个大方向Vertex AI有专门的Model Garden以及各种优化后的部署镜像Azure ML在和企业级客户的花式需求对接上确实有天然优势。但这些平台的通病也很明显抽象层级比较高定价和权限模型啰嗦文档写得很全但让新手摸不到头绪。还有一个非常现实的问题是它们默认带的推理配置模板不一定适合你的模型。有时候你在SageMaker上部署一个Llama模型他们给的默认容器镜像还是老版本压根没有开启关键的缓存优化。你需要自己很懂行地做一层镜像覆盖和参数调优才能把性能拉上来。所以这类平台适合我已经在这个云上跑了好几年业务的团队数据资产、身份认证、网络组网都已经在那里沉淀好了直接复用链路就好了不需要再跨云。3.4 无服务器容器与GPU函数Modal、Beam、RunPod Serverless第四类我想单独提一下Modal、Beam、RunPod Serverless这类GPU函数平台。它们的模式介于GPU云和托管推理之间你能自定义启动脚本和运行环境但不需要关心底层机器调度让平台帮你按流量秒级扩缩容。Modal做得尤其漂亮冷启动被控制在极短时间把模型放在分布式缓存层新实例起来时直接从缓存加载权重再加上自动缩容到零对小团队来说简直是指数级提升了开发效率。但这类平台同样不适合承接稳定的高吞吐流量。因为它的计费模型是按实例运行时长加资源用量算的如果流量24小时稳定Serverless的叠加费用反而不如直接长租一个实例来得便宜。另外你还需要面对一个现实问题动态扩缩容的实例类型和网络出口可能频繁变化如果你的下游服务对出口IP有白名单限制就会遇到时不时被拒的尴尬。我的建议是用Modal这类的工具去跑离线任务、临时算力扩容、批量数据处理效果非常好但线上实时推理还是老老实实放一个固定副本的服务。平台类型代表产品适合阶段核心优势核心代价GPU云容器CoreWeave / Lambda / RunPod有工程团队流量稳定便宜、灵活、可控运维成本高托管推理APITogether / Fireworks / Groq起步验证期零部署、性能好费用贵、定制差传统ML平台SageMaker / Vertex AI / Azure ML已深度绑定某云生态完整、权限统一重、模板化、调优难GPU函数Modal / Beam / RunPod Serverless离线任务、弹性突发秒级扩缩、免运维持续高流量不划算4. 我们过去实测过的一组数据平台性能差距比你想象的大光讲理论不摆数据那是耍流氓。下面这组数据不是从官方测试报告里抄的是我们团队在一个7B开源模型、相同输入约512个Token、相同Batch策略下用同一套压测脚本在不同平台上跑出来的真实结果已经脱敏。需要先说明的是这组数据只是某一时点、某一配置下的快照不代表平台的最佳水平但用来理解同一件事在不同平台上的差异之大非常有代表性。平台平均延迟msP99延迟ms吞吐量req/s单次推理费用相对值GPU云容器H100自建vLLM6501280861.0托管推理平台A7201420691.6托管推理平台B主打低延迟410950422.2传统ML平台默认配置9802600341.8GPU函数Modal配H1007801900512.4看出门道了吗托管推理平台B的平均延迟确实最低但它的吞吐量只有42req/s是自建方案的一半不到。因为低延迟策略靠的是尽早占住专用算力、小Batch立即处理用这种方式牺牲了算力复用。传统ML平台在默认配置下P99反而最差这说明官方模板的默认参数有多保守你不调优就上线等于买了一辆车但一直挂在二挡跑。GPU函数平台平均延迟中规中矩但P99偏高典型的机械化扩缩容抖动。这组数据还反映出一个很关键的事实自建vLLM并对参数做一轮调优之后综合性能是最好的同时单次推理成本最低。但这并不等于每个团队都应该自建因为数据背后还有一个隐性成本调试和运维的时间。我们为了把这组自建数据调到正常水平前前后后花了两三天包括调Continuous Batching窗口、KV Cache的显存占用比例、并发队列上限。你要把工程师的时薪算进去托管平台的贵可能反而变成最便宜的选项。怎么用这群数据做决策我建议把推理管线按请求特征拆成两条线上交互类请求对延迟极度敏感用平均延迟或P99作为决定指标不考虑吞吐量最大化该用贵但快的平台就去用离线批量类请求比如跑数据标注、AI摘要的预生成、Agent后台大量的工具调用全部走独立实例调大Batch把吞吐量拉满。很多团队非要在同一个集群上同时满足两种负载结果两种指标都做不好。物理上用不同实例、逻辑上用不同端点和队列去隔离这两类流量才是兼顾延迟和吞吐量的第一步。5. 兼顾延迟与吞吐量不是平台能给你的是架构设计出来的平台模型只是棋盘真正决定输赢的是架构。我见过太多团队签下大额GPU合同最后发现性能不达标原因不是卡不行而是请求调度一塌糊涂。这一节说说我们在实际项目中反复验证过的几种兼顾延迟和吞吐量的架构模式。5.1 混合路由把快请求和慢请求分开引流最有价值也最容易被忽略的一条经验是不是所有请求都值得占用昂贵的GPU。很多应用里80%的流量是高频且简单的请求比如这个商品的简介生成一句话或者这句代码补全剩下20%是超长文档总结、多轮Agent推理这种重负载。如果你用同一套推理栈处理这两种请求为了保住20%重负载的吞吐轻负载的延迟也被拖高了为了保住轻负载的延迟重负载又频繁超时。我的做法是在所有推理请求之前架一层轻量级路由网关网关根据请求参数预估类型路由到不同规格的推理池。举例来说短输入短输出的请求走一块由L4或者更小实例组成的低延迟小模型池长文本生成请求走H100大Batch池。两边各有自己独立的队列和扩缩容策略互不阻塞。这种改造在代码上很轻——无非是在API网关层加几行规则但效果立竿见影吞吐量几乎翻倍P99更是降下来了。5.2 前缀缓存和语义缓存不重复算已经算过的东西推理延迟高、吞吐量上不去很多时候不是算得慢而是大量算力浪费在重复计算上。编程助手场景最典型用户每敲一个字符都触发一次请求但整个对话开头的一大段上下文是完全相同的模型每次都要把这段前缀重新编码一遍。现在的推理引擎普遍支持Prefix Caching把相同前缀的KV Cache计算结果缓存下来命中情况下可以跳过重复的Prefill阶段只算新增Token部分延迟能降低30%到50%。更进一步的做法是做语义缓存。如果用户的请求和之前某次请求高度相似且对实时性要求不高比如总结这篇论文这种结果确定性较强的场景直接把上一次的结果从Redis里取出来返回压根不进GPU。在我们的智能文档处理项目里加了语义缓存后相同重复文档的调用量直接降了60%把省下来的算力留给真正需要实时生成的请求。缓存命中率高的负载延迟和吞吐量不用调参就同时变好了。5.3 自动扩缩容不能只看CPU得盯着算力队列成熟的推理平台都会提供自动扩缩容能力但默认指标往往不适合AI推理。按CPU使用率扩缩是很多团队踩过的坑GPU推理请求通常先排队等算力CPU使用率可能一直不高直到真正的并发尖峰来的时候CPU才猛涨但那时新实例拉起来已经晚了用户的等待体验已经被打破。正确做法是配置自定义指标——队列里的积压请求数和排队时间。只要当前队列里的请求超过阈值就立刻扩容一个新副本队列空了30秒后开始缩容。或者更简单一点直接采用Per-GPU利用率比如DCGM指标里的显卡算力利用率作为扩缩指标把目标值设定在60%到70%留出响应缓冲。这样的扩缩容策略才能让系统在低延迟和高吞吐之间自动保持浮动。5.4 降级和熔断吞吐量再高挂了就等于零做AI创业公司还得有服务不可用时的备用方案。即使平台再稳也会遇到模型推理超时、上游API限流的突发状况。我们的经验是提前准备一个降级方案把推理链路和业务降级链路完全拆开。比如在AI客服的场景中模型服务超时后自动降级为预置的规则话术库用户先收到一句稍等我们正在为您查询而不是接一个白屏。后端同时把失败请求记录到队列里等推理服务恢复后重新处理。这个能力与平台关系不大但你在选型时一定要确认平台支持请求超时控制、重试策略和后端熔断配置否则出了故障你只能干瞪眼。6. 部署完成之后的排坑清单和给创业团队的五条经验最后这部分我按实际部署和优化过程中的经验整理一份后来者少踩坑清单。它不是官方文档上的内容而是我们花了真金白银和时间买来的教训。6.1 六个排查性能问题时的常用切入口第一确认你是否真的命中了GPU。有时候配置了GPU实例但因为推理框架的某些算子不支持GPU程序自动回退到CPU性能自然暴跌。看监控里GPU利用率是不是接近零就知道了。第二检查Batch Size是不是被推理引擎的最大输入长度配置偷偷限制了。很多平台的默认Max Input Length远小于你业务的真实长度一旦请求超长就自动走fallback逻辑性能完全不同。第三看网络出口是不是公网。如果平台给你用的是公网域名提供服务跨区域访问的抖动会在你的P99里被无限放大尽量切到私网或者专线。第四排查权重文件和模型加载方式。加载方式用FP16还是INT8KV Cache用不用量化显存预算怎么分配这些参数微调一下吞吐量可能从40涨到80。第五压测脚本本身是否正确。开线程数的设计要模拟真实用户到达间隔不要用最大循环去压一个串行接口否则测出来的数据没有任何参考价值。第六观察队列积压曲线。如果平台控制台的队列积压呈锯齿状上升又瞬间清空说明你的扩缩容阈值设置得太激进需要调大一点缓冲。6.2 五条取过碳的选型经验第一条所有云厂商给你的Benchmark数据只能作为候选清单不能作为决策依据。真正决策前必须用自己的业务流量回放脚本在真实请求长度和真实并发分布下压测一遍并且至少压测3天观察长尾波动。第二条不要把钱全部押在一个平台。无论你当前选了多合适的平台都建议至少保留一个第二套方案把模型的推理接口抽象成OpenAI兼容格式随时可以切换。我们不希望用绑定换来性能一旦平台涨价或者出现大规模故障多一套部署方案就是多一条命。第三条早期阶段别过度纠结GPU型号。创业早期先把最便宜的L4级别实例跑通业务闭环等用户量增长到有明确瓶颈了再上H100。因为算力成本在性能调优和产品验证之前性价比是最低的。第四条认真计算沉默成本。平台迁移不是简单换API地址的事——日志系统、监控、告警、费用体系、权限管理全都绑在上面。团队小的时候可以随便试一旦规模上来迁移成本会高到让人不想动。所以选长期平台时应选择开放度高、兼容面广的产品给自己留后路。第五条也是最想说的一条延迟和吞吐量指标不是只给后端看的。产品经理和市场团队必须了解这两个指标的物理极限不要做出既要延迟20毫秒又要每天处理百万级请求这种完全违背算力常识的需求清单。我后来跟产品团队定的规矩是需求文档里必须同时标注延迟目标、吞吐量预估和成本上限三个数字写不清楚的需求一律打回。站在市场的角度这三者是不可兼得的三角形每次改动都要重新平衡。6.3 关于评测平台的一个补充不少团队反馈说看了平台列表还是头晕我建议你用最高频的业务请求先跑一个最小验证集选3个候选平台的免费额度或者按量付费试用每种平台部署同一个模型、同一套接口格式然后用自己回放的流量各压半小时把延迟、P99、错误率、成本拉成一张Excel表格。整个过程通常两到三天完成但这个投入换来的信息比看任何评测文章都要可靠得多。再说一遍平台没有绝对最优只有与你的业务曲线最匹配的那一个。把业务拆解清楚把指标核对明白再去谈平台思路就会清晰很多。