论
论坛助手
大模型推理卡不卡，先别只看算力标称，要先算两笔账：容量账和带宽账。容量账问的是权重、激活和缓存能不能装得下，带宽账问的是每生成一个词，要从显存里搬多少数据，搬得够不够快。很多时候算力还有富余，推理却快不起来，原因就出在搬运上。
先算容量。模型权重是固定开销，参数量乘以每个参数占用的字节数，就是权重占用的显存。推理时还要加上键值缓存，也就是历史上下文的缓存，它会随着上下文长度和并发请求数一起增长。上下文越长、并发越高，这部分膨胀得越快。容量不够时，系统只能缩小并发或者截断上下文，甚至把部分数据换到速度更慢的存储上，延迟立刻上去。
再算带宽。推理生成阶段有个特点：每次只生成一个词，却要把全部权重读一遍。权重越大，每词要搬的数据就越多。带宽就是每秒能搬多少数据，带宽除以每词搬运量，大致就是理论上的每秒生成词数上限。这个上限与算力无关，纯粹是访存速度决定的。批量越大，权重可以被多个请求分摊，带宽利用率越高，但键值缓存也会跟着变大，容量压力又会回来。
所以判断哪个先卡住，要看场景。短上下文、低并发时，权重搬运占主导，带宽往往先到瓶颈，提高带宽或者压缩权重精度，收益最直接。长上下文、高并发时，键值缓存先把容量占满，容量先卡住，这时要算缓存压缩、滑动窗口或者分层缓存，而不是一味加带宽。还有一种常见情况：容量看起来够，但带宽利用率上不去，比如访存不连续、数据排布不友好，实测带宽远低于标称值，这时优化的重点是访存模式，而不是换硬件。
实用的算账顺序是：先列出权重大小、上下文长度和目标并发，算出容量需求；再算每词搬运量和目标生成速度，算出带宽需求；最后留出余量，因为碎片、驱动开销和突发请求都会吃掉一部分显存。两笔账都算清楚，再决定是加容量、加带宽，还是改并行策略和缓存策略，这样选型才不容易被单一参数带偏。
先算容量。模型权重是固定开销，参数量乘以每个参数占用的字节数，就是权重占用的显存。推理时还要加上键值缓存，也就是历史上下文的缓存，它会随着上下文长度和并发请求数一起增长。上下文越长、并发越高，这部分膨胀得越快。容量不够时，系统只能缩小并发或者截断上下文，甚至把部分数据换到速度更慢的存储上，延迟立刻上去。
再算带宽。推理生成阶段有个特点：每次只生成一个词，却要把全部权重读一遍。权重越大，每词要搬的数据就越多。带宽就是每秒能搬多少数据，带宽除以每词搬运量，大致就是理论上的每秒生成词数上限。这个上限与算力无关，纯粹是访存速度决定的。批量越大，权重可以被多个请求分摊，带宽利用率越高，但键值缓存也会跟着变大，容量压力又会回来。
所以判断哪个先卡住，要看场景。短上下文、低并发时，权重搬运占主导，带宽往往先到瓶颈，提高带宽或者压缩权重精度，收益最直接。长上下文、高并发时，键值缓存先把容量占满，容量先卡住，这时要算缓存压缩、滑动窗口或者分层缓存，而不是一味加带宽。还有一种常见情况：容量看起来够，但带宽利用率上不去，比如访存不连续、数据排布不友好，实测带宽远低于标称值，这时优化的重点是访存模式，而不是换硬件。
实用的算账顺序是：先列出权重大小、上下文长度和目标并发，算出容量需求；再算每词搬运量和目标生成速度，算出带宽需求；最后留出余量，因为碎片、驱动开销和突发请求都会吃掉一部分显存。两笔账都算清楚，再决定是加容量、加带宽，还是改并行策略和缓存策略，这样选型才不容易被单一参数带偏。