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 batching，vLLM、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 / L4 | 16GB / 24GB | 小模型、多模型并行、成本敏感的入门级 | 1B-3B模型 |
| A10G | 24GB | 中等模型推理，AI绘画类 | 7B-13B模型加量化 |
| L40S | 48GB | 高吞吐的LLM、视频生成 | 7B-13B全精度 |
| A100 40G/80G | 40GB/80GB | 中大规模LLM，多请求高并发 | 7B-70B |
| H100 80G | 80GB | 大规模LLM、需要极高吞吐 | 34B-70B+ |
选卡不只看模型参数量，还要看量化策略和KV Cache预留。举个例子，你用FP16跑一个7B模型，权重大概占14GB显存；如果开了8并发，每个请求预计占用4GB KV Cache，那它总共就需要14+32=46GB。用40GB的A100会非常勉强，24GB的L4完全不可能，80GB的H100就很从容。这也是为什么“看起来够用”的卡，实际一压测就崩。
量化的作用在这里就体现出来了。把模型从FP16降到INT8，权重直接减半，7B模型只需要7GB左右；降到INT4，只要3.5GB。代价是精度有一定损失，但多数业务场景下可接受。我建议生产环境至少做INT8量化，既能提高吞吐，又能减少显存压力，是性价比最高的一步。
3.2 别被P50骗了，看延迟要看P99和TPOT
不少团队看平台宣传页上写着“延迟低于200ms”，就兴冲冲地接入，结果用户反馈卡成狗。问题出在统计口径：200ms可能是中位数P50，你在白天高峰压测时P99可能已经到了2秒。
评估推理服务的延迟，至少要盯三个指标：
- TTFT（Time To First Token）：用户发出的请求到接收到第一个token的时间。对交互式应用来说，这个值决定“首响”体验，一般控制在300ms以内才算良好。
- TPOT（Time 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_seqs=32，结果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成本，用数据而不是宣传页来做决定。踩过太多次“看着便宜，用起来贵，跑起来慢”的坑，现在宁可多花两天做验证，也不愿意上线后再靠熬夜救火。
