显卡跑分之外：模型上线前该测的几项

买卡之前，大家都会看跑分。跑分有用，但它测的是峰值性能；而你上线之后真正在意的，是「连续跑一周别出事」。

这两件事差得很远。我自己踩过一回：按跑分选的卡，单次推理确实快，但并发一上来就掉到一半以下，最后只能加钱换。

跑分测峰值，上线要稳定

跑分通常是：单卡、固定批量、短时间。真实服务是：多请求、长度不一、持续不断。

三个变量一变，结论就可能翻转。所以选型时应该先写下自己的约束：输入多长、并发多大、能接受多少延迟、要连续运行多久。

这份约束清单越具体越好。写「延迟要低」没有意义，写「九成请求首字延迟不超过 800 毫秒」才能拿去比对。

显存不是「够不够」，是「够多久」

显存占用会随上下文长度增长。短输入能跑，不代表长输入能跑；长输入能跑，也不代表并发起来还能跑。

一个实用的测法：按业务里最长的输入加最大并发跑，看峰值显存是多少，再留出余量。把余量当预留而不是浪费——碎片和缓存会吃掉一部分，中间还可能因为某个长请求突然拉高水位。

如果算下来余量只剩几个百分点，那这不是「刚好够用」，而是「随时会崩」。

长上下文下的吞吐会掉

注意力计算随长度增长，吞吐下降几乎是必然的，差别只在掉多少、掉得急不急。

测的时候要分长度档：短、中、长各跑一组，看吞吐曲线和延迟曲线的拐点在哪。如果拐点正好落在你的业务区间里，就要提前准备降级策略，比如超长内容走异步、先回一句再补结果。

还有一个常被忽略的变量：输出长度。生成比预填充更慢，让模型写 2000 字和写 200 字，是两种完全不同的负载。

并发和批处理是两个数

有人把并发调大，以为吞吐会跟着涨。实际吞吐会涨到一个点，然后开始掉，延迟同步恶化。

这个点要靠压测找出来，不能拍脑袋。找到之后把它定成线上阈值，超过就排队或拒绝，比硬扛着让所有人一起变慢要好。用户体验上，快速失败加稍后重试，通常比转半分钟圈更可接受。

稳定性要压着跑够时间

短测看不出降频、显存泄漏和偶发报错。至少要连续跑一两天，记录错误率、显存水位和延迟分位数。

跑的时候别只跑理想请求，要掺入长输入、空输入、超长输出这些边界情况。很多问题是在第两千次请求、某个特殊长度下才冒出来的。

先定义「够用」，再决定买什么

我的建议是反过来做：先写清服务目标——延迟上限、最低吞吐、可用率，再拿它去筛硬件。

这样做还有个好处：租和买可以直接比。同样的目标下，租的成本和买的成本能在同一口径上算，而不是拿「一个月多少钱」跟「一张卡多少钱」对不上。

跑分帮你排除明显不行的选项，但它决定不了你的选择。

本文不构成任何采购建议，硬件与云服务请结合自身用量、预算与合规要求评估。