去年我们做的AI客服项目差点因为延迟达标这件事在上线前翻车。当时我们对照厂商的benchmark文档选了一个在单路测试里延迟很漂亮的云端推理平台结果内测跑到几十路并发时首Token延迟直接从800ms飙到2.8s用户排队问题也跟着来了。后来我才意识到推理延迟、吞吐量不是平台宣传页上的两个亮点而是一组需要拿自己的业务流量去压、去换算的参数。这篇文章把我这一年多评估云计算推理平台的方法、踩过的坑和最终推荐思路整理出来。不管你是刚起步的AI创业团队还是准备从本地部署迁移到云端的成熟业务只要你的产品要跟大模型推理打交道都应该先看明白延迟和吞吐这对关系再去做选型。我的核心观点很简单没有哪个平台绝对最好只有哪个平台在你设定的延迟预算下能提供更高的吞吐、更低的成本。1. 延迟和吞吐量为什么天生打架先把决策坐标建立起来1.1 GPU推理的食堂窗口模型batch size是跷跷板先说明一个容易被忽略的事实云端推理和传统Web接口完全不同。传统API是请求-响应的短任务几百毫秒内完成但GPU推理是大计算 流式输出的长任务。一个请求进来模型要先对输入做一次Prefill计算然后再逐Token地生成输出。在Decode阶段GPU单卡每秒能生成的Token数量非常有限而这个数量恰恰就是吞吐量的瓶颈。为什么延迟和吞吐常常互相打架我用一个生活里的例子解释。把GPU当作一个食堂打饭窗口如果每个窗口只给一个人打饭每个人从排队到拿到饭的时间自然很短这就是低延迟但食堂单位时间能服务的人数很少这就是高吞吐上不去。如果你让一个窗口一次给一小批人打饭先等这批人到齐再一起打那单位时间服务人数会明显上升但这批人里最后一个人等待时间就变长了。这里的小批人就是推理里的batch size。batch越大GPU越忙吞吐越高但每个请求在batch里等别人的Token一起算延迟也就越高。所以所谓既要低延迟又要高吞吐并不是物理上做不到而是你要在一条batch size的曲线上找到一个最优点。举个我们实际测过的参考数据13B模型在A100上用vLLM部署batch size从1调到32时总吞吐翻了将近10倍但Token间延迟从45ms涨到105ms。如果你的产品本来就支持流式输出105ms一个Token其实还能接受但如果你要求3秒内输出完整答案这个方案就不行了。1.2 感知延迟和系统延迟要分开算很多团队一听延迟高就Pass掉一个平台其实是把系统内部指标和用户真实体验搞混了。对Token生成类应用来说用户能感受的延迟由两部分组成第一个Token出来的时间和后续每个Token之间的间隔。如果平台用的是流式输出用户根本不需要等整段答案生成完他看到的画面是文字一个字一个字蹦出来。这里的关键认知是用户对等待答案开始的耐心很有限但对文字生成过程的耐心远比我们想象中大。因为正常人阅读速度大概每秒能看6到7个字折合到LLM场景每个Token间隔在150ms左右人的感知就已经非常流畅了。所以你完全不需要把系统里每一个Token的生成时间都压到极致只需要保证首Token延迟落在产品承诺的SLA里Token速度不比人的阅读速度快太多或慢太多就行。这意味着你在选平台时真正的优化目标不是最低延迟而是在能被用户接受的感知延迟范围内尽可能提高吞吐、降低成本。如果你把系统最低延迟当作硬指标去套必然会把batch size压到1等于一个人一个窗口买饭成本高到让你的创业项目撑不住。1.3 给不同应用画一条延迟容忍曲线为了让团队内部对齐我当时做了一张表把常见AI应用按延迟容忍度划分并且给每个场景定了两个核心目标TTFT和TPOT。应用场景首Token延迟TTFT目标Token间延迟TPOT目标吞吐压力典型模型规模实时语音对话300ms100ms/token高1B-8B在线客服/聊天1s150ms/token中高7B-14B代码补全500ms80ms/token中7B-70BAI写作/内容生成2s200ms/token中低7B-70B离线批量处理分钟级不敏感极高7B-70B有了这张表选型会议就不会变成谁家最低延迟谁赢的纯参数比拼了。你先把产品的SLA定下来再让平台方用你的SLA去实测数据。我见过太多团队把时间浪费在争论这个平台为什么比那个平台慢100ms上却没有意识到自己的业务根本不需要那么低。最后真正该问的问题是在你们平台能接受的batch策略下我承诺的P95延迟能换回多少吞吐这个问题的答案才直接关系钱。2. 参数背后的真相厂商给的延迟数字为什么不靠谱2.1 TTFT、TPOT、end-to-end三个指标别只看一个平台说明书上最常看到的宣传语是生成XX Token平均耗时X秒这个数字通常是单路、无并发、固定长度下测出来的基本只能当参考。真正要关注的指标是下面三个TTFTTime To First Token首Token延迟包含网络往返、请求排队、Prefill计算时间。它受输入长度影响很大。TPOTTime Per Output Token平均生成一个Token要多久它几乎只由Decode阶段决定是流式输出流畅度的核心指标。End-to-end latency整个请求从发出到收完所有Token的总时间适合评估离线批量任务不适合交互式应用。我见过很多团队拿着输出100个Token总耗时2秒证明平台快但做成流式以后用户根本感知不到这一点。你在压测时一定要把这三个值分开统计并且分别计算P50、P95和P99因为平均值会把长尾问题掩盖得很干净。2.2 吞吐数字的口径系统吞吐 vs 用户感知吞吐平台说我们的推理吞吐是1000 tokens/s时你必须追问两个问题这个数据是在多大batch、多少并发下测出来的是GPU的纯算力吞吐还是用户实际拿到的Token速度这两个数字很可能差一个数量级。我自己每次做选型时都会先算一个数业务需要的真实并发能力。计算公式很简单并发需求 每秒请求数RPS × 单个请求平均生成时长秒。举个例子你的对话应用每秒会进来5个用户请求每个回答平均要生成8秒那么系统里同时存在的流式任务数量就是5×840个。换句话说平台必须有能力同时维持40个生成任务而不是每秒能接40个HTTP请求。如果平台并发上限是每实例4个流那就至少需要10个实例同时工作否则请求就会排队。这个公式能帮你直接从业务指标倒推出算力需求而不是被我们支持高并发这种描述带跑。2.3 冷启动、预热、排队延迟最容易吃掉的三个隐藏时间很多serverless推理平台宣传自动扩缩容到几十卡但流量突增时新实例从拉镜像、加载模型到正式Ready可能需要几十秒甚至几分钟。第一批进来的请求要么一直在队列里等实例Ready要么直接超时报错。这段时间不会出现在任何benchmark里但真实用户会遭遇而且很容易变成差评来源。所以选型阶段要问清楚三个问题第一平台从0个实例扩容到1个实例的冷启动时间是多少第二有没有可配置的最小实例池最小实例数设多少才能保证SLA第三当实例池打满时请求是在队列里等待、限流还是直接失败这三点必须写进评估表权重甚至应该高于GPU单价。我们后来就遇到过自称秒级扩容的平台实测冷启动花了47秒这个数据直接把它淘汰了。3. 云端推理平台的几类方案与适用边界别只听我们家GPU多3.1 MaaS模型托管平台省心但自主权最小MaaSModel as a Service指OpenAI API、AWS Bedrock、Azure OpenAI、阿里云百炼、百度千帆这类平台。最大的优势是省心模型、推理、扩缩容、监控都是平台帮你管了你只要调用API。延迟通常也稳定因为平台有成熟的排队和资源调度机制。但代价是你基本没有自主权底层推理参数被隐藏动态batching策略是平台统一调度的你无法为了某个具体场景去调优。单价通常也最高因为它把运维成本和利润都打进Token价格里。如果你在验证MVP、急着上线、团队里没有专门做推理工程的人MaaS是最好起步的选择。它的核心价值不是省钱而是帮你把时间省下来花在产品上。3.2 自建GPU云主机开源推理框架上限最高但很吃团队在AWS EC2、Azure VM、阿里云ECS、腾讯云CVM上租一块A10/A100/H100自己部署vLLM、TGI或者TensorRT-LLM这是过去两年最主流的高性能玩法。vLLM的PagedAttention、连续batching等优化已经把自建门槛降得非常低稍微资深一点的工程师两三天就能把服务跑起来。这个方案的上限也是最高的因为你可以自由调节并发batch、显存策略、量化方式还能结合投机解码、语义缓存等手段来进一步降低延迟、提升吞吐。成本上也最划算尤其当你的请求量稳定之后自建的每Token成本通常比MaaS低一个量级。但代价极其明显运维变重。实例挂了要恢复、流量要扩容、模型发新版要部署这些都占研发人力。创业公司如果只有两三个后端工程师在保证产品功能迭代的同时还要维护一整套GPU推理集群很容易被拖垮。我的建议是如果没有专职的MLOps或推理平台工程师不要轻易走这条路线至少不要在早期走。3.3 面向推理优化的Serverless平台性价比和灵活度的平衡点这是过去两年发展最快的一类方案代表包括Replicate、Modal、RunPod、Together AI、Fireworks AI、Baseten以及各大云厂商推出的Serverless推理服务比如AWS SageMaker Serverless Inference、阿里云PAI-EAS。这类平台的定位是MaaS的自定义模型版你可以上传自己训练或微调的模型甚至可以上传一个包含vLLM的推理容器平台负责自动扩缩容、计费和基础监控。按秒计费流量低时不烧钱流量高时有自动扩容能力。相比MaaS它的灵活度明显更高相比自建GPU它又把运维负担吃掉一大半。需要注意的点是各平台的并发插槽机制差异很大有的平台一个实例只能同时处理1个请求有的支持动态并发。平台宣称的并发数可能是实例数而不是同时处理的流式请求数这点要仔细看文档并且实测。3.4 三类方案快速对比对比项MaaS模型托管自建GPUvLLMServerless推理平台代表OpenAI API、阿里云百炼等AWS EKSGPU、阿里云GPU ECSModal、RunPod、PAI-EAS、SageMaker延迟控制弱平台统一调度强可精细调优中可调整并发槽位吞吐上限中受套餐限制高取决于GPU和参数中高取决于实例池配置运维成本无高低单价最高最低算上人工后仍低中等上手时间小时级周级天级适合阶段原型验证、MVP业务平稳后降本增效产品上线到成长期这张表的意义不是替你做结论而是帮你看清你在不同阶段选型逻辑应该完全不同。比如一个刚完成种子轮的项目直接选最便宜的A10自建方案可能并不划算因为省下的钱会被工程师的时间成本覆盖掉。等到业务量稳定了再迁移到自建集群才是把成本打下来的正确时间点。4. 实测选型方法从写压测脚本到算清算力成本4.1 一个可复用的流式推理压测脚本到这一步你已经知道自己需要的延迟预算和吞吐目标也列好了候选平台。接下来必须用数据说话。我不推荐直接用Apache Bench这类传统HTTP压测工具因为LLM是长连接、流式返回传统工具测不出TTFT和TPOT。我自己用一个Python异步脚本核心逻辑不复杂给大家参考。思路是用asyncio并发发起N个流式请求服务端必须按SSE格式返回对每个请求记录第一个Token到达时间以及每个Token之间的实际间隔最后统计所有请求的延迟分位数和总吞吐。import asyncio, time, statistics import httpx MODEL_URL https://your-endpoint/v1/chat/completions API_KEY your-key async def one_request(session, idx, results): payload { model: your-model, messages: [{role: user, content: 请用五句话介绍太阳系}], max_tokens: 256, stream: True, } headers {Authorization: fBearer {API_KEY}} t0 time.perf_counter() first_token_at None token_times [] async with session.stream(POST, MODEL_URL, jsonpayload, headersheaders) as resp: async for line in resp.aiter_lines(): if not line or line data: [DONE]: continue now time.perf_counter() if first_token_at is None: first_token_at now - t0 else: token_times.append(now) results.append({ ttft: first_token_at, tpot: sum(token_times[i1] - token_times[i] for i in range(len(token_times)-1)) / max(1, len(token_times)-1), total_time: now - t0, num_tokens: len(token_times) 1, }) async def run(n_concurrency): results [] async with httpx.AsyncClient(timeout120) as client: tasks [asyncio.create_task(one_request(client, i, results)) for i in range(n_concurrency)] await asyncio.gather(*tasks) return results if __name__ __main__: for conc in [1, 4, 8, 16, 32]: r asyncio.run(run(conc)) print(conc, len(r))这段代码只是骨架实际跑的时候要把P50/P95/P99的计算和日志补全。有一个细节必须提醒用固定字符数当输入不可靠因为不同tokenizer切出来的Token数不一样。你最好在脚本里先用同一个tokenizer数好Token再固定Token数量发请求这样不同平台之间的数据才可比。4.2 压测要覆盖的变量并发梯度、输入输出长度、区域网络延迟并发梯度我建议固定为1→4→8→16→32→64每个点至少跑三轮取中位数而不是平均值。平均值很容易被偶发抖动影响中位数更稳定。输入长度也要覆盖两种极端短文本约128 token和长文本约2048 token。因为首Token延迟在很大程度上取决于Prefill阶段对输入的预处理长输入场景下不同平台的差异会被明显放大。输出长度同样要固定否则TPOT会被不同长度拉平。比如一个平台生成50个Token另一个平台生成200个Token前者的平均Token间隔通常更小但这不代表它更快。还一个非常容易漏掉的变量是区域网络延迟。如果平台节点在美国西部而你的用户都在国内那每次请求光网络底噪就有100ms甚至更高。把这个时间叠到TTFT上对实时交互类产品来说几乎是灾难。正确做法是先对每个候选Endpoint做50次curl测试统计TLS握手时间和首字节时间再用网络底噪 平台推理延迟一起计算最终用户感知延迟。4.3 性价比计算把每小时价格折算到每万Token成本选型讨论到最后一定会落到价格上。但价格不能只看一小时几美金必须把它和实测吞吐放在一起算。我习惯用一个指标每万Token生成成本。单位生成成本 实例每小时成本 ÷ 实测吞吐量tokens/s × 10000举个例子某次我们实测三个方案的数据如下平台方案单实例价格美元/时并发16下实测吞吐tokens/s每万Token成本美元MaaS A按Token计费5000.18平台直接报价Serverless B2.13600.058自建C0.96A102800.034从这张表能明显看到MaaS最省心但最贵自建最便宜但有隐性的人工成本。每一家平台给的价格都有它的道理你要算的是对于我这个阶段的业务量哪种方案的总体拥有成本最低。如果每天只有一两千次请求用MaaS多出来的几百美元成本比专门请人维护GPU集群便宜得多。当量起来了再考虑迁移。4.4 一个真实测试结果的粗印象不同平台的曲线形状不一样我不在这里写死某家平台的具体数据因为版本迭代太快但有几条性能曲线非常具有代表性MaaS平台的TTFT在并发从1升到16时基本平稳说明它的排队和隔离机制做得很好资源池也大但价格确实贵。Serverless平台在并发1到8之间延迟表现惊艳甚至比MaaS还低一旦到16并发以上TPOT会明显上涨通常是实例池里的并发插槽被占满新请求开始排队。自建vLLM在开大batch以后吞吐一路猛涨但P99 TTFT像过山车你必须额外加一个请求队列做削峰否则高峰期会出现个别请求卡顿。这个测试告诉我们没有一种方案的性能曲线在所有并发段都是最优的。你在选型的时候要看自己业务通常落在曲线的哪一段。如果是客服这种白天稳定、高峰期明确的应用Serverless平台的高性价比时段正好覆盖大部分流量那它就是好选择如果业务是全天候均流量自建集群的吞吐优势会更值钱。5. 不换平台也能提升延迟/吞吐的工程细节5.1 先说最立竿见影的三招流式输出、量化、输入精简即使平台已经定下来应用层仍然有大量可以优化的空间。第一件必须做的事就是流式输出。很多团队在初期为了省事让服务端等模型生成完整个答案后才一次性返回JSON这会让用户感知延迟等于总生成时间。只要改成SSE流式返回用户看到第一个Token的时间就会从好几秒降到几百毫秒而平台侧的吞吐完全不受影响。这是性价比最高的一步。第二件值得做的是模型量化。把13B模型从FP16压到INT4可以用GPTQ或AWQ显存占用下降约50%相同GPU上能塞进更多并发batch吞吐一般能提升1.5到2倍。代价是输出质量可能下降所以要在自己的业务数据上做A/B测试不要盲目套用网上的量化参数。第三件是输入精简。很多团队把系统提示词写到1000字以上还把完整历史聊天记录全量塞给模型。这些输入每次请求都要参与Prefill计算输入越长首Token延迟越慢。实际上很多提示词内容对回答质量影响很小砍掉一半重复表述TTFT能明显下降。对于历史消息与其逐字传给模型不如先做一轮“压缩摘要”把关键信息浓缩之后再传进去。5.2 业务层加一个可控的预取和排队层另一个容易忽略的优化是在业务侧加一个轻量级的请求队列统一控制发往推理后端最大并发数。很多平台在实例被打满以后会直接排队但队列策略是平台定的优先级不可控。业务层自己加队列以后你可以给付费用户进“快车道”给免费用户进“慢车道”慢车道的batch可以故意调大用延迟换吞吐。这个队列容量怎么设用前面的公式容量 RPS × 单请求平均生成时长再多加20%缓冲。比如RPS是10平均生成时间是8秒那队列容量可以设置成96左右。太少了会误杀峰值流量太多了会加重排队。5.3 平台侧要设好最小实例数而不是依赖自动扩缩容Serverless平台最大的隐患是冷启动。很多平台宣传的“自动扩缩容”只在有流量时触发而冷启动一次可能就要几十秒。为了避免这种现象我的做法是分析一周的流量曲线把平台的最小实例数设置为“平峰期峰值流量的30%-50%”。这样绝大多数请求都落在热实例上只有突发流量走扩容通道冷启动对体验的影响就小多了。另外平台侧通常有“单实例最大并发”配置一定要根据实测数据把它设好。如果设置得太大一个实例同时接太多流式请求显存和算力都会被抢P99延迟会很难看。宁可把单实例并发调小一点、多开几个实例用水平扩展分摊压力也别让一个实例撑到极限。这是分布式系统里最朴素的道理但放到GPU服务上经常被忽略。6. 场景化推荐配置和我们的踩坑复盘6.1 五大创业场景的配置清单下面这些结论是我个人实践后的推荐不能说放之四海皆准但至少可以帮你在初期少走弯路在线客服/客服机器人7B模型RPS低于20推荐直接上MaaS或云厂商的serverless推理服务优先保证TTFT小于1s。这个场景的产品价值在对话质量和稳定性不值得为了省钱自建GPU集群。代码补全/IDE插件14B-70B流式要求高推荐用自建vLLM GPU云主机或者支持自定义推理容器的serverless平台。代码补全对TPOT很敏感最好开启投机解码speculative decoding配合动态batching把TPOT压到80ms以内。内容生成/营销文案7B-70B对延迟不敏感直接上按量计费的serverless平台甚至可以容忍一定程度的排队。把batch开大让吞吐拉满成本最低。语音Agent1B-8B低延迟硬要求推荐A10或4090这类低成本卡部署多个副本每个副本并发设为1到2用“堆副本”的方式换低延迟。平台层面不能有共享排队否则无法满足300ms级别的TTFT。RAG问答14B取决于检索链路重点是打通检索和生成选一个稳定的MaaS或serverless把性能压力放在优化向量库上不要在GPU调优上花太多时间。6.2 我们踩过的第一个坑只看单路延迟忽略了放大效应回到开头那个AI客服项目我们在选型阶段看了多个平台的单路并发报告全部都在800ms以下非常漂亮。但内测跑到30路并发时P99直接飙到3秒以上。后来排查发现平台说的“支持高并发”实际是“每秒能接收很多请求”但它对每个实例设置了最大并发流数比如4个超出部分的请求全部排队。也就是说单路延迟低不代表它扛得住并发必须看平台在目标并发数下的延迟分布。这个教训之后我们把选型流程改了候选平台必须提供“在目标并发数下测出的P95延迟”和“在目标延迟下可持续的最大吞吐”两个数少一个就不进入下一轮。平台上挂着的benchmark再好看也不如自己压一遍来得真实。6.3 第二个坑并发数计算方法错误把连接池当成了并发能力还有一次我们用一个传统压测工具测平台每秒发送50个HTTP请求平台都扛住了我们以为并发50稳定没问题。但LLM请求不是瞬间返回的每个请求平均要跑10秒那系统里同时存在的流式连接其实是50×10500个而不是50个。平台实例数显然不够流量一大立刻开始排队而且因为HTTP连接被复用压测工具报告的“每秒请求数”虚高掩盖了真实并发压力。这个坑是为了给投资方演示的时候才暴露的十分狼狈。后来我们做了一个“流式请求模拟器”严格按照真实用户行为随机到达间隔、随机生成长度去压测才真正把平台的并发特性测明白。6.4 第三个坑区域选错性能再好也白搭最后说一个很容易被忽略的点云端推理平台的地域节点和你的用户所在地之间的网络延迟会直接叠在TTFT上。我们有个面向国内用户的工具当时为了省成本选了美西节点。服务器内部测起来单路TTFT只有300ms但用户实际感受是底噪网络延迟500ms加上推理300ms经常超过1秒用户投诉不断。后来把主节点迁回国内Region虽然单价略高但P95延迟从1.4s降到800ms投诉直接清零。选平台前一定要把“Region与目标用户的位置关系”设为硬指标并且用真实的终端网络环境做测试不能只在机房内网里压。上面这些经验都是真金白银买回来的。如果你正在做选型我强烈建议不要急着看哪家平台参数好看先照第4节的方法跑一轮目标并发压测把P95延迟和每万Token成本算出来再谈“推荐”。没有数据的选型都是猜测。另外选型报告里永远留一列叫“迁移成本”因为创业公司最大的不确定性是业务量变化今天选的平台三个月后可能就不合适了能快速迁移比什么都重要。