70B参数的模型往两块A100 80GB上一放，权重只占一半空间。剩下的40多GB被谁吃掉了？答案是每个并发请求都要存一份"记忆"——KV缓存（键值缓存），这东西随上下文长度和批量大小线性膨胀，团队预算就这么悄无声息地翻倍。
GPU显存不是硬盘，是战场
部署大语言模型时，显存是唯一的硬约束。模型参数、KV缓存、中间激活值、推理框架的缓冲区，全得挤在同一块显存里。算少了，高负载下直接OOM崩溃；算多了，闲置的显存按月烧钱——两块A100和四块的月租差价，2000到4000美元。
权重计算的公式很简单：显存（GB）= 参数量（B）× 每个参数的字节数。FP16精度下，70B模型需要140GB。但这只是起点，实际还要预留20%-40%给KV缓存、激活值和框架开销。
权重是可预测的，KV缓存是刺客。
团队往往在KV缓存上栽跟头。每个并发请求都要为序列中的每个token存储键向量和值向量，上下文拉到32K、批量开到8，额外40GB就这么没了。两块A100瞬间不够，得上四块。
一张速查表，三种精度对比
用vLLM框架、批量大小8、4K上下文的配置，FP16精度下不同模型的显存需求如下：
7B模型约14GB权重，KV缓存和开销再加几GB，单卡A100 40GB能跑。13B模型约26GB权重，余量开始紧张。70B模型140GB权重，两卡A100 80GB刚好卡住，但稍微加点并发或上下文就得扩容。
量化是最有效的杠杆。INT4相比FP16显存直降75%，多数生产推理任务的质量损失可以忽略。7B模型INT4量化后权重仅3.5GB，13B约6.5GB，70B约35GB——一张消费级显卡都能跑。
但量化不是万能药。精度敏感的场景，比如需要精确数值计算或特定格式输出的任务，INT4的误差会累积放大。
为什么你的估算总是偏低
上面的公式适合信封背面快速估算，真实负载涉及具体的批量分布、上下文长度分布、吞吐量目标。团队常犯的错误是用平均上下文长度计算，但峰值负载下的最长上下文才是显存瓶颈。
另一个盲区是框架开销。vLLM的PagedAttention（分页注意力）机制显著降低了KV缓存的内存碎片，但调度器本身也有固定开销。不同版本的框架，这个数字能差出10%-15%。
云厂商的定价策略也在放大这种误判。按需实例和预留实例的价差、不同区域的GPU可用性、 spot实例的中断风险，让"刚好够用"的配置在实际运营中频繁触顶，被迫临时扩容，成本反而更高。
有团队做了公开的GPU选型计算器，用屋顶线模型（roofline model）结合vLLM的基准测试数据，估算显存、吞吐量和延迟。方法论和假设条件全部公开，可以自行验证。模型目录支持按价格、基准测试和能力跨厂商筛选对比。
工具的价值不在于给出答案，在于逼你回答那些原本被忽略的问题：你的上下文分布是什么形状？批量大小的峰值和均值差多少？延迟敏感型任务和吞吐量优先型任务的资源配置完全不同。
模板功能可以快速回答常见问题或存储复用片段——比如"32K上下文、8并发、INT4量化"的标准配置，直接粘贴给新来的后端工程师。
最后留一个开放问题：你的团队上次复盘GPU显存使用率是什么时候？监控面板里那个"峰值显存占用"的曲线，和当初容量规划时的假设，偏差有多大？
热门跟贴