一、两个指标先分清

（一）首字时延看体验

从发请求到看到第一个字的时间，决定用户是否觉得“卡”。这一项直接影响主观感受，很多时候用户记住的就是“等没等到第一个字”那一下，很关键。首字慢，用户可能直接退出，前面的所有优化都白做，所以体验要从这一毫秒抓起。

（二）吞吐看总量

单位时间能处理多少段，决定系统能扛多少并发。吞吐不足，高峰期就会排队，进而反过来拖慢每个人的首字时延，形成连环的负面效应。吞吐是底盘，底盘不稳，体验再怎么调也撑不住高峰，容量要给足才放心。

（三）两者互相牵

追求更快首字常要预留资源，会拉低吞吐。两者要按业务侧重取舍，不能都要，认清这一点才能定下合理的容量目标与边界，不贪。取舍要基于对业务的理解，用户更怕卡还是更怕慢，答案不同，资源倾斜方向也不同。

（四）还要看稳定

均值好看不够，高位分位更说明问题。长尾慢，用户感受到的正是这部分，所以评测报告里分位值比均值更有参考价值，要盯。均值掩盖长尾，长尾才是投诉来源，看分位才能知道最差的用户到底经历了什么。

二、首字时延受什么影响

（一）排队是否久

请求进入后是否要等实例空闲，直接决定起步快慢。排队可见，才能判断瓶颈在哪，是实例不够还是路由没把活分匀，才能对症施策，不瞎猜。排队是首字的头号杀手，看不见的排队最误事，把它显性化，优化才有抓手。

1. 实例是否预热

冷启需要读取模型准备运行，首字明显变慢。常驻实例能消除这部分等待，代价是持续占用资源，要按流量连续与否来取舍，不浪费。热实例贵在快，冷实例省在钱，流量连绵就热着，断续就冷着，按实情定最划算。

2. 输入是否过长

输入越长，处理前置步骤越久。超长输入会显著推高首字时延，必要时先截断或分段，比硬扛更划算，体验也更稳更可控。长输入不是不能接，是要先处理再送模型，前端多做一步，用户就少等一大截。

3. 路由是否就近

请求被发到负荷低的实例，比挤在忙碌实例更快。就近路由改善起步体验，也减少个别实例被压垮，拖慢全局的响应速度，连累所有人。路由是零成本就能拿到的提速，只要把活分匀，不让人闲死、有人忙死，整体首字就降下来了。

三、吞吐受什么影响

提升吞吐通常从三处入手，三者彼此相关，调一处常带动另两处，要放在一起看才完整：

① 提高并发：在拐点前增加同时处理的路数，单位时间产出随之上升，但过了拐点反而变慢，要守住边界。

② 用批处理：把多个请求合并计算，摊薄固定开销，整体效率更高，是提升吞吐最直接也最稳的手段。

③ 调优显存：更合理的显存使用能多跑几路，直接抬升吞吐额度，也给了并发更多可调配的空间。

四、容量怎么配

（一）先测拐点

逐步提高并发，找到吞吐不再涨而时延陡升的点。这个拐点就是合理工作区间，超过它运行性价比很低，纯属浪费算力与电费，别硬撑。拐点是容量的金矿，找到它，配置就有据可依，不再靠拍脑袋加机器，省钱又稳。

（二）留冗余

按峰值乘冗余系数，单实例故障不影响整体。冗余多少，取决于容错要求，关键业务要多留，实验性质可少留，按需而定，不浪费。冗余是买安心，安心值多少钱自己算，关键业务少留一分，出事就是十分的代价。

（三）可伸缩

用量波动时实例数能跟随调整，覆盖扩容完成前的空档。伸缩反应时间也要算进容量，否则峰值来了来不及补，用户已经排队，体验就崩了。伸缩要快，慢伸缩等于没伸缩，扩容链路要常练，真到高峰才敢放心交给它。

五、上线前验证

（一）压真实语料

用与生产分布一致的样本压测，随机文本会得出偏乐观结论。真实语料才可信，也才能暴露长尾请求带来的真实压力，不被均值值骗过，决策更准。压测料不对，结论全错，上线才发现撑不住，是最贵的学费，务必用真料。

（二）注入故障

停掉部分实例看调度是否生效。没验证过的容错，等于没有容错，真出事时才发现兜底没接上是常见的坑，要早验。容错要演练，纸面方案最不可信，演练一次暴露的问题，比开会讨论十次都管用。

（三）看分位值

报告至少含高位分位时延，只看均值会掩盖长尾。分位才贴近真实体验，也方便和业务方约定一个可接受的体验门槛，白纸黑字，不扯皮。分位值写进验收，体验才有硬性标准，否则“有点卡”这种主观话永远说不清。

六、持续跟踪

（一）三指标常看

首字时延、吞吐、错误率结合看，单看一个易误判。三者一起才能判断容量是否合适，也能区分是体验差还是真出错了，不乱猜，不误判。三指标像三角，缺一角就失真，合起来看，容量健康与否一眼就能看明白。

（二）成本要均衡

利用率长期偏低说明冗余过多，时延接近容忍额度则说明偏紧。两端都需回头看，找到体验与支出的合理交点，不偏不倚，钱才花在刀刃上。均衡不是一次定死，要随业务起伏动态调整，紧了加、松了收，容量才始终合身。

（三）数据分开存

压测结果存入天翼云存储，配置与日志放天翼云主机长期运行。分离保存，复查更方便，也能在扩容时直接调出历史基线来对照，省时省力，不重来。基线攒起来，每次扩容都有参照，不再从零摸索，团队进步也看得见、留得下。

七、落地清单

① 压测样本要覆盖长短输入，只用短样本会高估吞吐、低估首字时延，结论偏离真实，容量定出来自然也偏，埋下隐患，样本要全。

② 实例常驻能消除冷启等待，代价是持续占用资源，是否常驻要看流量是否连续，断续场景常驻纯属浪费，按实情定，不盲常驻，钱花在实处。

③ 批处理大小要实测，过大反而拉长首字，过小摊不薄开销，取拐点附近最划算，别照着别人的经验直接抄，环境不同，数要自己测才信。

结语：首字时延与吞吐，一个管体验一个管总量，缺一不可，偏废任一项都会出问题。容量要建立在拐点实测之上，而非拍脑袋，否则不是浪费就是卡顿。上线后三指标常看，才能及时发现偏紧或冗余，让体验与成本始终处在合理区间。