算力、显存、上下文长度之间是什么关系

算力、显存、上下文长度之间是什么关系

看机器配置或者云服务报价，这三个词总是一起出现。有人把它们当成同义词，觉得数字越大就越强。实际上它们各管一段，缺一段就卡住，其中一段不够会直接跑不起来。

把这三件事分清，采购时就不会买错，部署时也知道瓶颈在哪。

三个词各管什么

算力指每秒能做多少次运算，衡量的是快慢。算力高，同一个问题答得快，能一起服务的人多。

显存指显卡上那块内存有多大，衡量的是装得下多少。模型权重、对话内容、中间计算结果，全都要放在这块地方。

上下文长度指一次能处理多少字，衡量的是能看多长。一份合同、一份年报、一段几百轮的对话，能不能一次读完，看这个数。

三者之间不是简单的正比关系。算力翻倍不会让显存变大，上下文加长会反过来吃掉显存，这一点最容易被忽略。

显存是硬门槛

显存不够，程序直接报错退出，或者被系统降级成慢速模式。这一关卡没有折中方案，不够就是不够。

权重占一块

模型参数本身要占地方。粗略算法是参数量乘以每个参数占的位数，再除以八。七十亿参数、每个占十六位，算下来十几 G；换成每个占四位，降到三 G 多。

这是最容易被算清的一块，也是唯一一块固定的。剩下的两块是变量，而变量才是坑。

上下文占一块

模型读你的输入时，会把每个字内部的计算结果缓存下来，方便后面复用。这份缓存叫 KV 缓存，它的大小跟上下文长度成正比，跟并发数也成正比。

具体算起来有个经验量级：七十亿参数的模型，单条对话的上下文每增加一千字，缓存占几十兆。上下文拉到三万二千字，单条就要占掉好几 G。十条并发一起跑，这一块会超过权重本身。

所以看到一个模型宣称「支持二十万字上下文」，别急着高兴。它说的是能力上限，实际跑起来要的显存可能是权重的好几倍。

并发也吃显存

每多一个并行对话，就要多存一份上下文缓存。单用户测试跑得飞快，上线后十个人一起用，显存爆了，服务开始排队或者报错。

这也是为什么很多自建方案在测试阶段表现好，一上生产就崩。测试只算了一个人的账，实际要算二十个人的。

压并发有代价。把并发限死，多出来的请求排队，用户看到的是转圈。把上下文限死，长文档被截断，用户看到的是答一半。两个限制都得提前跟业务方说清楚，别等上线了才发现业务要的东西硬件撑不住。

上下文长了为什么变慢

注意力机制的计算量，跟上下文长度的平方成正比。长度翻一倍，计算量翻四倍。长度翻十倍，计算量翻一百倍。

这个平方关系解释了很多现象。短对话响应很快，长文档分析慢得让人等不了；同样的模型，处理两千字要一秒，处理两万字要几十秒，不是线性变慢。

实际感受还要加上排队。十个人一块提交长文档，第一个人的请求在算，后面九个在等。等待时间跟并发数成正比，跟单条耗时也成正比。长文档场景的并发一高，体感会比单机测试糟糕得多。

工程上有各种办法缓和这个增长，包括稀疏注意力、分块处理、缓存复用。它们能把曲线压平一些，压不成直线。长度和速度之间的交换关系一直存在。

算力不够会怎样

不会报错，只是慢。慢到某个程度，用户就不用了。

衡量慢不慢有两个数：首字时间，就是从提交到看见第一个字的时间；出字速度，就是每秒出几个字。前者决定用户觉不觉得卡，后者决定用户愿不愿意等完。

首字时间跟预填充阶段的计算量有关，输入越长，这一段越久。出字速度跟解码阶段有关，每个字都要跑一遍模型，速度基本恒定。

所以长文档分析的首字时间会很难看，而闲聊的首字时间很快。同一个模型，两种场景的体感差距巨大。

采购时该怎么算

顺序反了会买错。正确的顺序是先定业务要求，再算显存，最后看算力。

先定上下文长度要求

你的场景要一次读多长的内容？是把客服对话摘要成三句话，还是把三十页合同逐条比对？前者两千字够，后者三万起步。

这个数定下来，显存的下限就定了。为了省显存去砍上下文，最后做不到业务要求，机器再贵也没用。

再算显存

三块加起来：权重、单条上下文缓存、并发数乘以缓存。留三成余量给中间计算和碎片。算出来的数往上取一档，不要卡着线买。

卡着线买的后果很具体：跑单条刚好，跑两条就开始交换内存，速度掉到原来的十分之一。

最后看算力

算力决定你能服务多少人，以及等多久。按目标并发和可接受的出字速度反推，别按峰值买，按日常峰值的一点五倍买。

按峰值买是浪费，因为峰值一年出现不了几次。按平均买会崩，因为峰值那几天恰好是最要紧的几天。一点五倍是个不多不少的折中。

三个常见误判

把上下文长度当成能力指标。它只是容量，长不等于好。上下文塞得太满，模型对中间内容的注意力会下降，问它第十页的细节，它答不出来。这个现象业内叫「lost in the middle」。

把显存当成算力。买了一张显存大但算力弱的卡，模型装得下但跑得慢，用户等不了。反过来买算力强但显存小的卡，模型装不下。

忽略带宽。同样显存的卡，显存带宽差一倍，出字速度也差不少。解码阶段每一步都要把权重从显存读一遍，带宽就是这条路的宽度。这个参数在规格表里不好找，但影响很直接。

还有一个常被忽略的账：租还是买。云上按小时租卡，前期零投入，随时换配置，单价高；自己买机器，单价低，但一次付清，配置过时就只能认。用量稳定且长期，自建划算；用量波动或者还在试阶段，租更省心。

租赁还有个隐性好处，配置能跟着业务调。这个月做长文档需要大显存，下个月做高并发需要多卡，机房里换一台就行。自建要把这套变化提前押在采购单上，押错一次就是几万块的沉没成本。

回到三个词的关系：显存决定能不能跑，算力决定跑得多快，上下文长度决定能看多长。三者互相牵制，加长上下文要多花显存和多花时间，加并发要多花显存，加算力只能换速度换不了容量。

采购前把业务要求翻译成这三个数，比对比参数表有用得多。

落到纸上就三行：一次要读多长的内容，日常有多少人一块用，能接受等几秒。这三个数报给供应商，对方给不出匹配的配置，就知道对方在卖标准套餐，不是在做方案。