AI读长文档慢:加GPU之前,先分清两段等待

同一个AI服务，问一句短问题很快，交一份长文档却迟迟不出字；开始回答以后，速度有时又恢复正常。遇到这种情况，直接增加GPU，可能花了钱却没有解决最主要的等待。

先把一次回答拆成两段，问题会清楚很多。

第一段读输入，第二段往外写

预填充，可以理解为处理已有输入、建立后续计算需要的状态；解码，则是逐步生成回答。前者可能被长文档拖重，后者会受到输出长度和同时服务人数的影响。

这两段的资源需求不同。NVIDIA Dynamo等框架支持把它们交给不同的工作池，并在中间传递KV缓存。

KV缓存保存了模型计算中的部分中间状态。拆开以后，计算资源可以分别安排，但也多出一项开销：把这些状态送到接下来负责回答的设备。

拆开能省排队，也会增加搬运

假设一次交接需要传输10GB缓存，有效传输速度为25GB/s，仅搬运的理论下限就是0.4秒；若有效速度降到10GB/s，下限变成1秒。排队、协议与调度开销还要另算。

这是假设算例，不对应某个模型固定的缓存大小。缓存量会随模型、精度、上下文和并发变化。

是否值得拆，取决于少等的时间，能否抵过新增的传输和调度。

长短请求混杂、高峰并发明显的业务，值得测试分离部署。规模较小、请求相近的业务，原来较简单的部署方式也可能更合适。

不只测“总共输出多少字”

一个系统总吞吐更高，某些客户却可能等得更久。采购验收至少要记录三件事：

首字等待：提交请求后，多久出现第一个输出。

输出速度：开始回答后，文字生成是否连续，是否频繁停顿。

达标请求量：在约定等待时间与错误率范围内，一小时能完成多少请求。

测试请求要保留真实的长短比例。全部用短问题测试，发现不了长文档压力；全部挑长文档，也不能代表日常业务。

把测试结果换成经营判断

对算力服务商，最有用的结果是：同样设备能否多接达标订单，或者相同订单量能否少用设备。

如果一套新部署只提高总吞吐，却让客户高峰等待更长，还增加网络和维护费用，就不能仅凭跑分宣布更省钱。反过来，如果能在服务要求不变的情况下减少排队与闲置，即使单卡峰值没有变化，也可能改善经营。

总结

AI回答慢，先分清慢在读取输入、连续生成，还是中间排队。把这几段时间测出来，再决定增加GPU、调整部署或升级网络，预算才更有针对性。