1. 先看懂延迟、吞吐量、成本这三个指标是怎么互相打架的1.1 从一次真实故障说起我做AI应用开发这些年见过太多团队在MVP阶段跑得很顺一上线就崩的例子。有个做智能客服的创业团队模型用的开源7B本地测试时单次对话响应500毫秒演示效果堪称完美。结果上线第一天用户一多接口P99直接从500毫秒飙到5秒以上首页用户流失率肉眼可见地上升。问题出在哪里最经典的套路他们租了一台单卡GPU服务器在服务端用同步方式调用模型推理。当并发请求同时进来时所有请求都在显存里排队谁也别想跑。那个时刻我才真正意识到对一个AI创业公司来说推理延迟和吞吐量不是“调参”问题而是“生存”问题。你模型精度再高用户等不及就是废的。延迟是单个请求从发出到返回的耗时吞吐量是系统单位时间能处理的请求数成本是你为这两者付的钱。这三者天然矛盾想压低延迟你可能要为每个用户单独跑一个模型实例成本爆炸想提升吞吐量把一堆请求塞进一个batch并行处理但后进来的请求就得排队延迟上去了。云端推理平台的选型本质就是在这三个变量里找一个让你团队活得下去的最优解。1.2 延迟到底卡在哪个环节很多刚入行的同学会以为”延迟高GPU太慢“然后砸钱上更贵的卡结果问题依然在。延迟这个东西要从头到尾拆开看它一般由五部分组成网络传输时间用户到你服务的网络链路网关、负载均衡都有开销。请求排队时间请求到了服务端发现前面还有一堆请求在处理只能在队列里等着。这是最容易被忽略、也最致命的部分。prefill阶段大模型读取你的输入文本把它编码并生成第一个token。这个过程是计算密集型的特别吃算力。decode阶段逐token生成输出内容每生成一个token都要把最新的KV Cache读一遍。这个过程不是算力瓶颈而是显存带宽瓶颈。输出传输和解析返回数据的网络传输以及客户端解析。放到大模型场景里一个LLM请求的延迟大头通常不在网络而在prefill加decode这两个阶段。prefill像“看题”你得把整道题目读进去并理解decode像“打字”一个字一个字往外蹦。GPU的算力决定了看题速度显存带宽决定了打字速度。你光换一张算力更高的卡打字阶段很可能并没有明显变快因为带宽没跟上。这里还要深挖一个概念KV Cache。每次推理时模型要把输入的历史token的Key和Value缓存下来用于后续生成。请求一多KV Cache会疯狂占显存。它本质上像你考试时打的草稿纸草稿越详细后面计算越快但草稿纸本身也占桌子空间。一个7B模型的权重可能只占14GB显存但只要并发一高KV Cache能让80GB的H100也吃紧。这也是为什么后面说平台选型时显存和批量策略比单纯看卡型更重要。1.3 吞吐量的本质算力与并发的博弈吞吐量通常用两个单位衡量RPS每秒请求数和token/s每秒生成的token数。对LLM服务来说token/s更能反映真实的算力产出因为它避开了“有些请求答案长、有些答案短”的干扰。提升吞吐量的手段无非两种一是堆卡二是把单卡的利用率吃透。堆卡没有技术含量花钱罢了真正考验技术的是后者。举个例子GPU在执行矩阵乘法时不喜欢“一个请求一个请求”地干活它更喜欢“一批一模一样形状的矩阵”一起算。这就是批处理batching的由来。早期大家用静态批处理攒够一定数量再一起推理但这样单个请求的延迟会随着batch size线性上升。后来出现了动态批处理和continuous batchingvLLM、TensorRT-LLM这类推理框架都用上了简单说就是一个请求生成到一半新的请求可以立刻插进这个batch大家一起算谁先结束谁先走不再互相等待。这让“高吞吐”和“低延迟”从死对头变成了可以调和的兄弟关系。不过具讽刺意味的是很多云平台的默认配置压根没帮你把batching开启你在控制台把它当成一个“黑盒”直接调用时会发现延迟和吞吐两不沾。所以评估一个云端推理平台不能只看它写着“GPU性能多强”还得看它对推理框架的支持程度、是否支持动态batching、KV Cache的调度能力如何。2. 市面上的云端推理平台到底分哪几类2.1 按需GPU云服务器自由度最高但运维责任全在自己这是最传统的一种方式租一台带GPU的云服务器自己在上面装驱动、装推理框架vLLM、Triton、Text Generation Inference都可以然后把模型跑起来开放API。它的优点非常明确灵活性拉满模型怎么部署、批处理策略怎么调、量化用什么精度全部自己说了算。控制力最强性能调优空间也是最大的。它适合有一定工程能力的团队或者说接下来的技术选型你有信心自己搭。缺点也显而易见你要自己处理扩容、监控、告警、故障恢复。流量来了需要扩机器你得写好自动扩缩容的脚本机器挂了你得有办法快速拉起。对创业公司来说这部分运维成本很容易成为隐形支出消耗的是本来可以用在业务上的研发精力。从我实操角度看这个方案适合“流量已经相对稳定”或“模型版本迭代频繁需要一个可控环境随时切换”的场景。起步阶段如果每天就几百个请求买按量GPU实例属于把钱扔在角落吃灰。2.2 Serverless推理平台弹性很好但要理解冷启动的代价Serverless推理是云厂商专门为“不想管机器”的团队准备的。你只管上传模型或指定镜像平台负责拉起实例、自动扩缩容、按调用量计费。阿里云PAI-EAS、AWS SageMaker Serverless Inference、华为云ModelArts的推理端点都属于这一类。这类平台对流量突刺非常友好。某个功能上了热门请求量半小时涨10倍它能自动拉一批实例扛住流量退潮后实例会自动缩到零你不花冤枉钱。计费粒度可以细到“按请求数按实例运行时长”起步阶段成本极低。但“冷启动”是Serverless挥之不去的阴影。流量突然暴增时平台需要新拉实例、加载模型这个过程可能要几十秒甚至几分钟。如果平台做不好预热和实例复用用户撞上冷启动就得白等。我在实际项目里见过不少团队上线后把Serverless当API网关直接用结果流量稍微一跳延迟从300毫秒变成30秒后台监控一片红。所以Serverless的正确打开方式是预先设置好最小保留实例数让平台始终为你保留一两个“热”实例再通过并发请求数、响应时间等指标配置好弹性伸缩策略宁可多花一点点保底钱也别让用户去撞冷启动。2.3 专为推理优化的托管平台性能漂亮但要掂量绑定成本第三类是近几年冒出来的“专攻推理性能”的平台典型代表有Groq、Fireworks AI、Together AI、DeepInfra包括一些云厂商推出的“模型推理专属服务”底层用上了自研芯片或者深度优化的推理引擎。你可以直接调用它们托管的开源模型API也可以上传自己的模型权重让平台帮你跑。这类平台的卖点就一个性能极其能打。以Groq为例它用自研LPU语言处理单元跑LLM推理速度可以做到每秒几百甚至上千token在低延迟场景下几乎碾压通用GPU方案。Fireworks和Together则基于GPU集群但对推理栈做了深度优化通常能实现很低的P99延迟和很高的吞吐量。这种方案的吸引力在于小团队不需要一个专职推理优化工程师就能获得大公司级别的基础设施性能。但代价也很明确第一是供应商锁定你的推理栈、监控、SDK都和它绑定将来迁移要重写一部分代码第二是定制能力有限数据合规、私有化部署、模型版本控制都受制于平台第三是成本模型不太透明流量起来了之后单价未必比自建GPU集群便宜。适合用这类的团队画像很清晰业务需要极低延迟但不想投入基建且业务数据合规上允许走第三方平台。2.4 自建推理框架 云资源兼顾延迟与吞吐的最优解路径严格来说这不是一类“平台”而是“选型思路”用开源推理框架vLLM、TensorRT-LLM、Triton Inference Server作为服务层跑在Kubernetes集群上底层用云厂商的GPU实例或Serverless资源池。这条路工程复杂度最高但也是延迟与吞吐可调节空间最大的方案。vLLM提供了PagedAttention和continuous batching对吞吐量的提升属于“用了就回不去”级别Triton则擅长多模型管理和动态batch还支持把prefill和decode拆到不同阶段做并行。再加上Kubernetes的HPA水平Pod自动伸缩和KEDA基于事件驱动伸缩你能按真实的队列长度或GPU利用率来扩缩容而不是拍脑袋固定副本数。我个人的判断是AI创业公司如果已经过了“验证业务能不能跑通”的阶段团队里又有一两个能折腾K8s的人自建推理框架是“延迟与吞吐兼顾”的最佳路径。成本可控、性能可调、不被任何云平台绑架代价是你的周末可能会被集群故障占用。3. 怎么对比这些平台关键配置和性能指标3.1 GPU型号和显存怎么选你无论选哪种平台最终都要落到“用什么卡”上。先看一张我常用的GPU选型参考表GPU型号显存适合场景典型模型规模T4 / L416GB / 24GB小模型、多模型并行、成本敏感的入门级1B-3B模型A10G24GB中等模型推理AI绘画类7B-13B模型加量化L40S48GB高吞吐的LLM、视频生成7B-13B全精度A100 40G/80G40GB/80GB中大规模LLM多请求高并发7B-70BH100 80G80GB大规模LLM、需要极高吞吐34B-70B选卡不只看模型参数量还要看量化策略和KV Cache预留。举个例子你用FP16跑一个7B模型权重大概占14GB显存如果开了8并发每个请求预计占用4GB KV Cache那它总共就需要143246GB。用40GB的A100会非常勉强24GB的L4完全不可能80GB的H100就很从容。这也是为什么“看起来够用”的卡实际一压测就崩。量化的作用在这里就体现出来了。把模型从FP16降到INT8权重直接减半7B模型只需要7GB左右降到INT4只要3.5GB。代价是精度有一定损失但多数业务场景下可接受。我建议生产环境至少做INT8量化既能提高吞吐又能减少显存压力是性价比最高的一步。3.2 别被P50骗了看延迟要看P99和TPOT不少团队看平台宣传页上写着“延迟低于200ms”就兴冲冲地接入结果用户反馈卡成狗。问题出在统计口径200ms可能是中位数P50你在白天高峰压测时P99可能已经到了2秒。评估推理服务的延迟至少要盯三个指标TTFTTime To First Token用户发出的请求到接收到第一个token的时间。对交互式应用来说这个值决定“首响”体验一般控制在300ms以内才算良好。TPOTTime Per Output Token每生成一个token的时间。它直接决定了打字速度AI对话场景下通常需要控制在30-50ms/token换算过来就是每秒20-30个token读起来不难受。端到端延迟完整请求的从始至终耗时。长文本生成时主要由“token数 × TPOT”决定。压测时不能只看平均要看P95、P99分布。我习惯用k6或者wrk做压测先开1路并发跑3分钟再逐步升到5路、10路、20路拿每一档的P99对比。如果P99曲线在某个并发档位突然拐头向上这个拐点就是平台的真实吞吐上限也是你扩容的触发点。3.3 计费模式里的隐藏成本云端推理平台的计费大致有四类按量计费按实例规格和时间算钱适合流量稳定、长期在跑的场景。Spot/抢占式实例价格可以便宜70%-90%但平台随时可能回收实例。适合跑批处理类任务不适合承担在线流量。预留实例/包年包月提前锁定价钱便宜不少适合有明确流量预期的服务。按token计费Serverless推理或托管API常见模式每生成一个token收一次钱适合起步阶段但量大之后单价不一定划算。我在选型时习惯算一个指标单位成本 每小时实例费用 ÷ 每秒处理token数。用这个数来对比不同平台比单纯看每小时多少钱更实在。举个例子A平台L4实例每小时50元每秒处理200个token单位成本是0.25元/(每小时每token)B平台A100实例每小时200元每秒处理1500个token单位成本只有0.13元。看起来A便宜实际B的单token成本更低。这种账不算清楚很容易被“便宜”的表面价格带偏。4. 真实落地一套兼顾延迟与吞吐的推荐组合4.1 起步阶段Serverless为主加少量常驻保底如果你正处于“模型验证通过、业务准备上线”的阶段日请求量从几百到几万浮动我建议采用这样的组合线上推理走Serverless推理服务核心配置里把“最小实例数”设为1避免全部降为零导致每次请求都要冷启动。让开发同学通过OpenAI兼容接口对接不要直接用云平台特有SDK方便将来平迁。所有请求通过API网关统一接入在网关层做限流、超时控制和日志采集。这套结构下流量波谷时只有一个保底实例在跑成本可能就是几十块一天流量波峰时平台自动扩容哪怕瞬间涨10倍也不会打挂。这个阶段别去动GPU集群和自建推理框架先把业务验证出来比什么都重要。要注意的一点是Serverless平台对超长请求不友好。AI推理动辄十几秒如果平台网关的默认超时时间只有30秒生成到一半被切断就尴尬了。选平台前先确认它的最大超时时间和并发连接数别等到上线才发现。4.2 成长阶段常驻GPU集群加弹性扩容当你的日请求量稳定在数十万级并且单token成本成为主要矛盾时就该切换到常驻GPU集群了。我推荐的架构是“常驻池 弹性池”混合模式常驻池买2-4张GPU实例按量或包月部署vLLM做推理服务承载基础流量。弹性池同一个推理服务配置HPA基于“GPU利用率超过70%”或“请求排队长度超过N”两个指标自动扩容扩容出来的Pod可以跑到同账号的按量GPU也可以跑到Serverless实例上。队列层在常驻池和弹性池之间加一层消息队列比如RabbitMQ或Redis Stream。请求先进队列再由推理服务拉取。这能让流量突增时平滑缓冲而不是直接把所有请求打给GPU服务导致雪崩。这套结构的关键在于“队列长度”的监控。我在项目里设置过很实用的告警规则队列中积压的请求数量超过20且持续30秒就触发扩容。等队列消化到0后5分钟再逐步缩容。这个策略把延迟和吞吐的平衡点交给了实时流量而不是人的经验。4.3 高性能调优阶段把推理栈的每层都吃透常驻集群不是“把模型跑起来就完事”你还要做三件事第一件打开continuous batching。如果你用的是vLLM默认就支持PagedAttention和continuous batching但你要在部署时调整最大并发数max_num_seqs和模型并行度。值太小浪费算力值太大延迟飙高需要根据你的业务类型压测。以7B模型跑L4显卡为例我一开始设max_num_seqs32结果P99要3秒后来压测发现16更合适P99能稳定在800ms以内。第二件对显存做预算。vLLM支持配置KV Cache使用的显存比例gpu_memory_utilization默认0.9但如果同时跑多个模型需要手动调低。我还有两个习惯静态模型做权重量化FP16降到INT8请求里的历史对话保留最近10轮超过的就截断。这么做显存占用能降三分之一吞吐量自然涨。第三件区分交互型请求和批处理请求。实时聊天、生成式搜索属于交互型要求低延迟单独走常驻池文档总结、离线批处理属于吞吐型可以推到弹性池允许排队和做成异步任务。混在一起跑会被最差的那类请求拖累整个集群的SLA。我在一个落地项目里把两类请求拆开后交互接口的P99从2.1秒降到700ms批处理吞吐量反而提高了40%。5. 常见问题与排查技巧实录5.1 性能突然劣化从哪一步开始查线上推理服务延迟突然飙高这是每个AI应用开发都经历过的“深夜惊魂”。我的排查顺序是固定的第一看监控面板里的GPU利用率和显存占用。如果GPU利用率已经接近100%说明是算力满载需要扩容或优化批处理如果GPU利用率只有20%但延迟还是高那问题大概率不在推理本身。第二看请求队列。队列长度在涨说明消费速度跟不上生产速度先去查推理服务是不是卡在某个请求上。这类问题经常由“某个上传的超长文档或超大图片”引起单个请求占着GPU跑了一分钟后面所有请求全被堵住。解决办法是在API网关设单请求最大处理时间比如60秒超时直接切断再配合对输入长度限流。第三看外部依赖。很多AI服务不只有模型还有向量数据库、RAG检索、内容审核、缓存等环节。有一次排查半天发现是向量数据库在高峰期CPU跑满和推理平台一点关系都没有。所以一定要给每个外部依赖单独画监控曲线否则延迟飙了你都不知道去哪个系统里找。5.2 吞吐量上不去GPU利用率也不高这是最让人抓狂的一种情况集群闲着请求却在排队。常见原因有三类推理框架的batch size设置太小GPU吃不满但也没法并行处理更多请求。此时调大max_num_seqs会有立竿见影的效果。请求的输入输出长度极不均匀。有的请求只有几个字有的是几万字。模型在batch里要按最大的那个计算短的请求全在等长的GPU的利用率被“最长请求”牵制。解决办法是平台支持按长度分桶或者用动态批处理框架自动组合相似长度的请求。瓶颈在CPU侧的数据预处理比如tokenizer解析、图像解码、请求体反序列化。GPU在排队CPU在忙你得把数据预处理也做成异步或并行而不是单线程串行。另外确认过网络带宽没有有一次我们一个海外节点吞吐量上不去最后发现是云厂商实例的带宽被限到了100Mbps数据一批批卡在网卡上。改一下实例规格吞吐直接翻倍。5.3 成本失控这几板斧砍下去最有效AI推理成本失控是创业公司很常见的死法。我总结了几条立竿见影的砍成本策略启用Spot实例跑批处理任务。在线推理别用Spot但像夜间离线打标、数据清洗、报表生成这类任务用Spot能省60%以上被回收了也无所谓。让实例“无事可做就缩容”。HPA和Serverless都支持缩容到0但很多团队为了让“心里有底”而一直保留实例。实际上深夜访问量低到一定阈值后完全可以让实例缩掉。这个习惯帮我砍掉了至少三成日常支出。量化模型降显存规格。一个7B模型用FP16跑需要40GB左右显存才能高并发INT8量化低KV显存配置后用24GB的卡就能扛住每小时单价直接少一半。监控单实例吞吐。如果一台A100实例每秒只处理200个token大概率是配置太糙先调优再考虑降规格。成本问题没有一劳永逸的解法但盯住“单token成本”这个指标定期过一遍就不会失控。5.4 平台绑定的风险怎么防上云最怕搞到一半发现被某个平台锁死。我强烈建议从第一天起就用“OpenAI兼容接口”作为内部统一抽象层不管是自己部署vLLM还是接第三方托管API都用同一套路由和调用方式。这样哪天想换平台改一个环境变量就行不用重写业务代码。同理日志和监控也要用标准化格式。我习惯把每个请求的模型名称、输入输出长度、延迟、吞吐数据全部打一份结构化日志落到对象存储里做离线分析。这样以后做性能对比、异常审计数据都掌握在自己手里而不是被云平台的控制台界面绑架。6. 一张决策清单照着选基本不会出错业务阶段/特征推荐方案核心理由日请求量低于1万流量毛糙Serverless推理平台配1个最小实例弹性好、起步成本低日请求量1万到30万流量有规律常驻GPU实例vLLM部署 HPA弹性吞吐和成本最优平衡追求极低延迟例如实时语音对话推理优化托管平台Groq/Together/Fireworks类或高频H100集群底层优化差距明显离线批处理任务量大Spot实例 队列管理成本最低可接受排队团队里有强后端/平台工程师自建Triton vLLM Kubernetes性能和成本都能做到极致决策清单背后其实就三个问题你的流量是平稳型还是突刺型你的业务能不能接受秒级冷启动你的团队有没有能力hold住K8s这三个问题想清楚了方案基本就自动浮出水面。我个人现在的习惯是“分层不押宝”基础流量走常驻GPU集群弹性流量走Serverless或竞价实例极低延迟场景才考虑专用推理平台。每次做技术选型我还会跑到目标平台开一个最小规格实例把自己的真实模型放上去用真实流量回放压测一轮记录TTFT、TPOT、P99和单token成本用数据而不是宣传页来做决定。踩过太多次“看着便宜用起来贵跑起来慢”的坑现在宁可多花两天做验证也不愿意上线后再靠熬夜救火。
云端推理平台选型指南：平衡延迟、吞吐与成本
1. 先看懂延迟、吞吐量、成本这三个指标是怎么互相打架的1.1 从一次真实故障说起我做AI应用开发这些年见过太多团队在MVP阶段跑得很顺一上线就崩的例子。有个做智能客服的创业团队模型用的开源7B本地测试时单次对话响应500毫秒演示效果堪称完美。结果上线第一天用户一多接口P99直接从500毫秒飙到5秒以上首页用户流失率肉眼可见地上升。问题出在哪里最经典的套路他们租了一台单卡GPU服务器在服务端用同步方式调用模型推理。当并发请求同时进来时所有请求都在显存里排队谁也别想跑。那个时刻我才真正意识到对一个AI创业公司来说推理延迟和吞吐量不是“调参”问题而是“生存”问题。你模型精度再高用户等不及就是废的。延迟是单个请求从发出到返回的耗时吞吐量是系统单位时间能处理的请求数成本是你为这两者付的钱。这三者天然矛盾想压低延迟你可能要为每个用户单独跑一个模型实例成本爆炸想提升吞吐量把一堆请求塞进一个batch并行处理但后进来的请求就得排队延迟上去了。云端推理平台的选型本质就是在这三个变量里找一个让你团队活得下去的最优解。1.2 延迟到底卡在哪个环节很多刚入行的同学会以为”延迟高GPU太慢“然后砸钱上更贵的卡结果问题依然在。延迟这个东西要从头到尾拆开看它一般由五部分组成网络传输时间用户到你服务的网络链路网关、负载均衡都有开销。请求排队时间请求到了服务端发现前面还有一堆请求在处理只能在队列里等着。这是最容易被忽略、也最致命的部分。prefill阶段大模型读取你的输入文本把它编码并生成第一个token。这个过程是计算密集型的特别吃算力。decode阶段逐token生成输出内容每生成一个token都要把最新的KV Cache读一遍。这个过程不是算力瓶颈而是显存带宽瓶颈。输出传输和解析返回数据的网络传输以及客户端解析。放到大模型场景里一个LLM请求的延迟大头通常不在网络而在prefill加decode这两个阶段。prefill像“看题”你得把整道题目读进去并理解decode像“打字”一个字一个字往外蹦。GPU的算力决定了看题速度显存带宽决定了打字速度。你光换一张算力更高的卡打字阶段很可能并没有明显变快因为带宽没跟上。这里还要深挖一个概念KV Cache。每次推理时模型要把输入的历史token的Key和Value缓存下来用于后续生成。请求一多KV Cache会疯狂占显存。它本质上像你考试时打的草稿纸草稿越详细后面计算越快但草稿纸本身也占桌子空间。一个7B模型的权重可能只占14GB显存但只要并发一高KV Cache能让80GB的H100也吃紧。这也是为什么后面说平台选型时显存和批量策略比单纯看卡型更重要。1.3 吞吐量的本质算力与并发的博弈吞吐量通常用两个单位衡量RPS每秒请求数和token/s每秒生成的token数。对LLM服务来说token/s更能反映真实的算力产出因为它避开了“有些请求答案长、有些答案短”的干扰。提升吞吐量的手段无非两种一是堆卡二是把单卡的利用率吃透。堆卡没有技术含量花钱罢了真正考验技术的是后者。举个例子GPU在执行矩阵乘法时不喜欢“一个请求一个请求”地干活它更喜欢“一批一模一样形状的矩阵”一起算。这就是批处理batching的由来。早期大家用静态批处理攒够一定数量再一起推理但这样单个请求的延迟会随着batch size线性上升。后来出现了动态批处理和continuous batchingvLLM、TensorRT-LLM这类推理框架都用上了简单说就是一个请求生成到一半新的请求可以立刻插进这个batch大家一起算谁先结束谁先走不再互相等待。这让“高吞吐”和“低延迟”从死对头变成了可以调和的兄弟关系。不过具讽刺意味的是很多云平台的默认配置压根没帮你把batching开启你在控制台把它当成一个“黑盒”直接调用时会发现延迟和吞吐两不沾。所以评估一个云端推理平台不能只看它写着“GPU性能多强”还得看它对推理框架的支持程度、是否支持动态batching、KV Cache的调度能力如何。2. 市面上的云端推理平台到底分哪几类2.1 按需GPU云服务器自由度最高但运维责任全在自己这是最传统的一种方式租一台带GPU的云服务器自己在上面装驱动、装推理框架vLLM、Triton、Text Generation Inference都可以然后把模型跑起来开放API。它的优点非常明确灵活性拉满模型怎么部署、批处理策略怎么调、量化用什么精度全部自己说了算。控制力最强性能调优空间也是最大的。它适合有一定工程能力的团队或者说接下来的技术选型你有信心自己搭。缺点也显而易见你要自己处理扩容、监控、告警、故障恢复。流量来了需要扩机器你得写好自动扩缩容的脚本机器挂了你得有办法快速拉起。对创业公司来说这部分运维成本很容易成为隐形支出消耗的是本来可以用在业务上的研发精力。从我实操角度看这个方案适合“流量已经相对稳定”或“模型版本迭代频繁需要一个可控环境随时切换”的场景。起步阶段如果每天就几百个请求买按量GPU实例属于把钱扔在角落吃灰。2.2 Serverless推理平台弹性很好但要理解冷启动的代价Serverless推理是云厂商专门为“不想管机器”的团队准备的。你只管上传模型或指定镜像平台负责拉起实例、自动扩缩容、按调用量计费。阿里云PAI-EAS、AWS SageMaker Serverless Inference、华为云ModelArts的推理端点都属于这一类。这类平台对流量突刺非常友好。某个功能上了热门请求量半小时涨10倍它能自动拉一批实例扛住流量退潮后实例会自动缩到零你不花冤枉钱。计费粒度可以细到“按请求数按实例运行时长”起步阶段成本极低。但“冷启动”是Serverless挥之不去的阴影。流量突然暴增时平台需要新拉实例、加载模型这个过程可能要几十秒甚至几分钟。如果平台做不好预热和实例复用用户撞上冷启动就得白等。我在实际项目里见过不少团队上线后把Serverless当API网关直接用结果流量稍微一跳延迟从300毫秒变成30秒后台监控一片红。所以Serverless的正确打开方式是预先设置好最小保留实例数让平台始终为你保留一两个“热”实例再通过并发请求数、响应时间等指标配置好弹性伸缩策略宁可多花一点点保底钱也别让用户去撞冷启动。2.3 专为推理优化的托管平台性能漂亮但要掂量绑定成本第三类是近几年冒出来的“专攻推理性能”的平台典型代表有Groq、Fireworks AI、Together AI、DeepInfra包括一些云厂商推出的“模型推理专属服务”底层用上了自研芯片或者深度优化的推理引擎。你可以直接调用它们托管的开源模型API也可以上传自己的模型权重让平台帮你跑。这类平台的卖点就一个性能极其能打。以Groq为例它用自研LPU语言处理单元跑LLM推理速度可以做到每秒几百甚至上千token在低延迟场景下几乎碾压通用GPU方案。Fireworks和Together则基于GPU集群但对推理栈做了深度优化通常能实现很低的P99延迟和很高的吞吐量。这种方案的吸引力在于小团队不需要一个专职推理优化工程师就能获得大公司级别的基础设施性能。但代价也很明确第一是供应商锁定你的推理栈、监控、SDK都和它绑定将来迁移要重写一部分代码第二是定制能力有限数据合规、私有化部署、模型版本控制都受制于平台第三是成本模型不太透明流量起来了之后单价未必比自建GPU集群便宜。适合用这类的团队画像很清晰业务需要极低延迟但不想投入基建且业务数据合规上允许走第三方平台。2.4 自建推理框架 云资源兼顾延迟与吞吐的最优解路径严格来说这不是一类“平台”而是“选型思路”用开源推理框架vLLM、TensorRT-LLM、Triton Inference Server作为服务层跑在Kubernetes集群上底层用云厂商的GPU实例或Serverless资源池。这条路工程复杂度最高但也是延迟与吞吐可调节空间最大的方案。vLLM提供了PagedAttention和continuous batching对吞吐量的提升属于“用了就回不去”级别Triton则擅长多模型管理和动态batch还支持把prefill和decode拆到不同阶段做并行。再加上Kubernetes的HPA水平Pod自动伸缩和KEDA基于事件驱动伸缩你能按真实的队列长度或GPU利用率来扩缩容而不是拍脑袋固定副本数。我个人的判断是AI创业公司如果已经过了“验证业务能不能跑通”的阶段团队里又有一两个能折腾K8s的人自建推理框架是“延迟与吞吐兼顾”的最佳路径。成本可控、性能可调、不被任何云平台绑架代价是你的周末可能会被集群故障占用。3. 怎么对比这些平台关键配置和性能指标3.1 GPU型号和显存怎么选你无论选哪种平台最终都要落到“用什么卡”上。先看一张我常用的GPU选型参考表GPU型号显存适合场景典型模型规模T4 / L416GB / 24GB小模型、多模型并行、成本敏感的入门级1B-3B模型A10G24GB中等模型推理AI绘画类7B-13B模型加量化L40S48GB高吞吐的LLM、视频生成7B-13B全精度A100 40G/80G40GB/80GB中大规模LLM多请求高并发7B-70BH100 80G80GB大规模LLM、需要极高吞吐34B-70B选卡不只看模型参数量还要看量化策略和KV Cache预留。举个例子你用FP16跑一个7B模型权重大概占14GB显存如果开了8并发每个请求预计占用4GB KV Cache那它总共就需要143246GB。用40GB的A100会非常勉强24GB的L4完全不可能80GB的H100就很从容。这也是为什么“看起来够用”的卡实际一压测就崩。量化的作用在这里就体现出来了。把模型从FP16降到INT8权重直接减半7B模型只需要7GB左右降到INT4只要3.5GB。代价是精度有一定损失但多数业务场景下可接受。我建议生产环境至少做INT8量化既能提高吞吐又能减少显存压力是性价比最高的一步。3.2 别被P50骗了看延迟要看P99和TPOT不少团队看平台宣传页上写着“延迟低于200ms”就兴冲冲地接入结果用户反馈卡成狗。问题出在统计口径200ms可能是中位数P50你在白天高峰压测时P99可能已经到了2秒。评估推理服务的延迟至少要盯三个指标TTFTTime To First Token用户发出的请求到接收到第一个token的时间。对交互式应用来说这个值决定“首响”体验一般控制在300ms以内才算良好。TPOTTime Per Output Token每生成一个token的时间。它直接决定了打字速度AI对话场景下通常需要控制在30-50ms/token换算过来就是每秒20-30个token读起来不难受。端到端延迟完整请求的从始至终耗时。长文本生成时主要由“token数 × TPOT”决定。压测时不能只看平均要看P95、P99分布。我习惯用k6或者wrk做压测先开1路并发跑3分钟再逐步升到5路、10路、20路拿每一档的P99对比。如果P99曲线在某个并发档位突然拐头向上这个拐点就是平台的真实吞吐上限也是你扩容的触发点。3.3 计费模式里的隐藏成本云端推理平台的计费大致有四类按量计费按实例规格和时间算钱适合流量稳定、长期在跑的场景。Spot/抢占式实例价格可以便宜70%-90%但平台随时可能回收实例。适合跑批处理类任务不适合承担在线流量。预留实例/包年包月提前锁定价钱便宜不少适合有明确流量预期的服务。按token计费Serverless推理或托管API常见模式每生成一个token收一次钱适合起步阶段但量大之后单价不一定划算。我在选型时习惯算一个指标单位成本 每小时实例费用 ÷ 每秒处理token数。用这个数来对比不同平台比单纯看每小时多少钱更实在。举个例子A平台L4实例每小时50元每秒处理200个token单位成本是0.25元/(每小时每token)B平台A100实例每小时200元每秒处理1500个token单位成本只有0.13元。看起来A便宜实际B的单token成本更低。这种账不算清楚很容易被“便宜”的表面价格带偏。4. 真实落地一套兼顾延迟与吞吐的推荐组合4.1 起步阶段Serverless为主加少量常驻保底如果你正处于“模型验证通过、业务准备上线”的阶段日请求量从几百到几万浮动我建议采用这样的组合线上推理走Serverless推理服务核心配置里把“最小实例数”设为1避免全部降为零导致每次请求都要冷启动。让开发同学通过OpenAI兼容接口对接不要直接用云平台特有SDK方便将来平迁。所有请求通过API网关统一接入在网关层做限流、超时控制和日志采集。这套结构下流量波谷时只有一个保底实例在跑成本可能就是几十块一天流量波峰时平台自动扩容哪怕瞬间涨10倍也不会打挂。这个阶段别去动GPU集群和自建推理框架先把业务验证出来比什么都重要。要注意的一点是Serverless平台对超长请求不友好。AI推理动辄十几秒如果平台网关的默认超时时间只有30秒生成到一半被切断就尴尬了。选平台前先确认它的最大超时时间和并发连接数别等到上线才发现。4.2 成长阶段常驻GPU集群加弹性扩容当你的日请求量稳定在数十万级并且单token成本成为主要矛盾时就该切换到常驻GPU集群了。我推荐的架构是“常驻池 弹性池”混合模式常驻池买2-4张GPU实例按量或包月部署vLLM做推理服务承载基础流量。弹性池同一个推理服务配置HPA基于“GPU利用率超过70%”或“请求排队长度超过N”两个指标自动扩容扩容出来的Pod可以跑到同账号的按量GPU也可以跑到Serverless实例上。队列层在常驻池和弹性池之间加一层消息队列比如RabbitMQ或Redis Stream。请求先进队列再由推理服务拉取。这能让流量突增时平滑缓冲而不是直接把所有请求打给GPU服务导致雪崩。这套结构的关键在于“队列长度”的监控。我在项目里设置过很实用的告警规则队列中积压的请求数量超过20且持续30秒就触发扩容。等队列消化到0后5分钟再逐步缩容。这个策略把延迟和吞吐的平衡点交给了实时流量而不是人的经验。4.3 高性能调优阶段把推理栈的每层都吃透常驻集群不是“把模型跑起来就完事”你还要做三件事第一件打开continuous batching。如果你用的是vLLM默认就支持PagedAttention和continuous batching但你要在部署时调整最大并发数max_num_seqs和模型并行度。值太小浪费算力值太大延迟飙高需要根据你的业务类型压测。以7B模型跑L4显卡为例我一开始设max_num_seqs32结果P99要3秒后来压测发现16更合适P99能稳定在800ms以内。第二件对显存做预算。vLLM支持配置KV Cache使用的显存比例gpu_memory_utilization默认0.9但如果同时跑多个模型需要手动调低。我还有两个习惯静态模型做权重量化FP16降到INT8请求里的历史对话保留最近10轮超过的就截断。这么做显存占用能降三分之一吞吐量自然涨。第三件区分交互型请求和批处理请求。实时聊天、生成式搜索属于交互型要求低延迟单独走常驻池文档总结、离线批处理属于吞吐型可以推到弹性池允许排队和做成异步任务。混在一起跑会被最差的那类请求拖累整个集群的SLA。我在一个落地项目里把两类请求拆开后交互接口的P99从2.1秒降到700ms批处理吞吐量反而提高了40%。5. 常见问题与排查技巧实录5.1 性能突然劣化从哪一步开始查线上推理服务延迟突然飙高这是每个AI应用开发都经历过的“深夜惊魂”。我的排查顺序是固定的第一看监控面板里的GPU利用率和显存占用。如果GPU利用率已经接近100%说明是算力满载需要扩容或优化批处理如果GPU利用率只有20%但延迟还是高那问题大概率不在推理本身。第二看请求队列。队列长度在涨说明消费速度跟不上生产速度先去查推理服务是不是卡在某个请求上。这类问题经常由“某个上传的超长文档或超大图片”引起单个请求占着GPU跑了一分钟后面所有请求全被堵住。解决办法是在API网关设单请求最大处理时间比如60秒超时直接切断再配合对输入长度限流。第三看外部依赖。很多AI服务不只有模型还有向量数据库、RAG检索、内容审核、缓存等环节。有一次排查半天发现是向量数据库在高峰期CPU跑满和推理平台一点关系都没有。所以一定要给每个外部依赖单独画监控曲线否则延迟飙了你都不知道去哪个系统里找。5.2 吞吐量上不去GPU利用率也不高这是最让人抓狂的一种情况集群闲着请求却在排队。常见原因有三类推理框架的batch size设置太小GPU吃不满但也没法并行处理更多请求。此时调大max_num_seqs会有立竿见影的效果。请求的输入输出长度极不均匀。有的请求只有几个字有的是几万字。模型在batch里要按最大的那个计算短的请求全在等长的GPU的利用率被“最长请求”牵制。解决办法是平台支持按长度分桶或者用动态批处理框架自动组合相似长度的请求。瓶颈在CPU侧的数据预处理比如tokenizer解析、图像解码、请求体反序列化。GPU在排队CPU在忙你得把数据预处理也做成异步或并行而不是单线程串行。另外确认过网络带宽没有有一次我们一个海外节点吞吐量上不去最后发现是云厂商实例的带宽被限到了100Mbps数据一批批卡在网卡上。改一下实例规格吞吐直接翻倍。5.3 成本失控这几板斧砍下去最有效AI推理成本失控是创业公司很常见的死法。我总结了几条立竿见影的砍成本策略启用Spot实例跑批处理任务。在线推理别用Spot但像夜间离线打标、数据清洗、报表生成这类任务用Spot能省60%以上被回收了也无所谓。让实例“无事可做就缩容”。HPA和Serverless都支持缩容到0但很多团队为了让“心里有底”而一直保留实例。实际上深夜访问量低到一定阈值后完全可以让实例缩掉。这个习惯帮我砍掉了至少三成日常支出。量化模型降显存规格。一个7B模型用FP16跑需要40GB左右显存才能高并发INT8量化低KV显存配置后用24GB的卡就能扛住每小时单价直接少一半。监控单实例吞吐。如果一台A100实例每秒只处理200个token大概率是配置太糙先调优再考虑降规格。成本问题没有一劳永逸的解法但盯住“单token成本”这个指标定期过一遍就不会失控。5.4 平台绑定的风险怎么防上云最怕搞到一半发现被某个平台锁死。我强烈建议从第一天起就用“OpenAI兼容接口”作为内部统一抽象层不管是自己部署vLLM还是接第三方托管API都用同一套路由和调用方式。这样哪天想换平台改一个环境变量就行不用重写业务代码。同理日志和监控也要用标准化格式。我习惯把每个请求的模型名称、输入输出长度、延迟、吞吐数据全部打一份结构化日志落到对象存储里做离线分析。这样以后做性能对比、异常审计数据都掌握在自己手里而不是被云平台的控制台界面绑架。6. 一张决策清单照着选基本不会出错业务阶段/特征推荐方案核心理由日请求量低于1万流量毛糙Serverless推理平台配1个最小实例弹性好、起步成本低日请求量1万到30万流量有规律常驻GPU实例vLLM部署 HPA弹性吞吐和成本最优平衡追求极低延迟例如实时语音对话推理优化托管平台Groq/Together/Fireworks类或高频H100集群底层优化差距明显离线批处理任务量大Spot实例 队列管理成本最低可接受排队团队里有强后端/平台工程师自建Triton vLLM Kubernetes性能和成本都能做到极致决策清单背后其实就三个问题你的流量是平稳型还是突刺型你的业务能不能接受秒级冷启动你的团队有没有能力hold住K8s这三个问题想清楚了方案基本就自动浮出水面。我个人现在的习惯是“分层不押宝”基础流量走常驻GPU集群弹性流量走Serverless或竞价实例极低延迟场景才考虑专用推理平台。每次做技术选型我还会跑到目标平台开一个最小规格实例把自己的真实模型放上去用真实流量回放压测一轮记录TTFT、TPOT、P99和单token成本用数据而不是宣传页来做决定。踩过太多次“看着便宜用起来贵跑起来慢”的坑现在宁可多花两天做验证也不愿意上线后再靠熬夜救火。