权重装进了 24 GiB，四路 32K 上下文还装得下吗？

权重装进了 24 GiB四路 32K 上下文还装得下吗模型权重已经加载短问题也能回答于是把服务目标改成四路长上下文。接下来遇到的却是缓存不足、请求等待或者在某个峰值阶段显存不够。第一反应往往是“权重才占一部分剩下的显存为什么不够”加载成功只验证了当时那笔开销。生成中的历史信息也要留在 GPU 上运行时还会需要临时空间。要判断四路长请求是否可行需要回答的是扣掉权重和非缓存峰值后每张卡到底还有多少空间能够同时保留多少 token 的 KV下面用 Qwen2.5-7B-Instruct 的公开配置算一笔账。24 GiB 显存、权重与运行开销都是明确设定的教学条件没有加载该模型、运行 vLLM 或做 GPU 压测。算式用于排除不成立的容量承诺不作为这款模型在某张显卡上的实测结果。先从每张卡的预算里扣掉非 KV 开销先固定单位1 GB 是 10⁹ 字节1 GiB 是 2³⁰ 字节。本文的 24 GiB 指假设运行时可见总量恰为 24 × 2³⁰ 字节不是把任何厂商标称的“24 GB”直接代入。实际机器应读取字节数再换算。对某一张 GPU先写一个用于规划的简式可规划的 KV 空间 ≈ 本实例显存预算 − 本卡权重 − 其他非 KV 峰值预留“其他”包括该执行配置下的激活与临时工作区、图捕获等非权重开销不能用空闲时截图代替峰值。若权重已经单列其他项就不要再把同一权重算一遍。这里是分账方法不是保证每项峰值会在相同时刻达到最大也不是某个版本内部变量的逐一映射。vLLM v0.28.0 的自动预算路径提供了直接证据。在 GPU Worker 源码中KV 可用量的计算包含下面三项self.requested_memory-profile_result.non_kv_cache_memory-cudagraph_memory_estimate_applied这是赋值表达式中的连续项省略了外侧变量和括号不能单独运行。它说明引擎会从请求的预算里扣除已分析的非 KV 开销及适用的 CUDA Graph 估算而不是把权重加载后看见的全部空闲量直接交给缓存。vLLM GPU Worker 源码现在设定单卡 24 GiB显式选择利用率参数 0.9权重预算记为 15 GiB其他非 KV 峰值预留 2 GiB。后两项只是本例输入不是 Qwen 官方公布或本文测得的占用真实部署必须用当前精度、加载布局与执行配置重新测量。也没有用模型名里的“7B”乘两字节冒充精确运行时权重。于是本例得到实例预算 24 × 0.9 21.6 GiB KV 规划空间 21.6 − 15 − 2 4.6 GiB预算外的 2.4 GiB 不再重复算作 KV 可用空间。本例也没有把它承诺为能抵挡任意峰值的安全保证。这里的 0.9 是主动设定。核验时 v0.28.0 文档默认值为 0.92gpu_memory_utilization描述当前实例的预算比例不是监控面板上的 GPU 忙碌百分比。另一个参数kv_cache_memory_bytes直接指定每 GPU的 KV 字节量设置后会忽略前述比例的自动预算方式不能把两者当成可叠加的额度。引擎参数说明四路 32K需要缓存的是 131,072 个 tokenKV Cache 保存后续生成还会使用的注意力 Key 和 Value。对普通全注意力、相同结构的各层采用相同 K/V 维度和精度、不考虑共享时可以从数据形状推导KV 字节数 2 × 层数 × KV head 数 × head 维度 × 每元素字节 × 已缓存 token 总数开头的 2 是 Key 与 Value。并发序列长度不同时总 token 数应该逐条相加。它既不是本轮新计算的 token 数也不只是输入长度已处理的 prompt 和生成历史都可能占缓存。队列里尚未获得 KV 的请求则不能按“已驻留”重复计入。Qwen 官方配置给出了这个例子需要的原始字段hidden_size:3584,num_attention_heads:28,num_hidden_layers:28,num_key_value_heads:4这四行从配置不同位置选取非连续摘录。由此得到 head 维度 3584 ÷ 28 128GQA 使用 4 个 KV heads不能把 28 个 Query heads 代入 KV 公式。配置同时记录use_sliding_window: false本例不套用滑动窗口缓存缩减。Qwen2.5-7B-Instruct 配置再明确选择 BF16 KV每元素 2 字节不启用 KV 量化、前缀共享或缓存卸载TP1、PP1。每 token 在完整模型各层合计需要2 × 28 × 4 × 128 × 2 57,344 字节 56 KiB若一个序列已经缓存 32,768 个 token就是 1.75 GiB。本文用“32K”指这 32,768 个已缓存总 token不是 32K 输入之外还免费附送输出空间。四条这样的序列合计 131,072 个 tokenKV 为 7 GiB。同时驻留的序列状态总缓存 token理想 KV 量1 条各 32,76832,7681.75 GiB2 条各 32,76865,5363.5 GiB3 条各 32,76898,3045.25 GiB4 条各 32,768131,0727 GiB与 4.6 GiB 预算比较第三条已经超过四条更缺 2.4 GiB。权重能加载与这组请求不能全部保持目标 KV 状态可以同时成立。表中是张量载荷的理想值不含块取整、对齐等实现成本不能把“3.5 小于 4.6”写成两路一定能稳定服务。vLLM 的缓存规范按块描述存储实际可用块数仍要从引擎配置和启动结果确认。KV Cache 存储规范反过来四条连接也不意味着始终占 7 GiB。它们若尚未增长到目标长度实际用量会较小。本表问的是目标状态能否同时驻留不能拿短输入试通的结果证明长尾请求组合也成立。当前配置的上下文上限是另一个限制本例只算到配置中 32,768 的量级不宣称完成上下文扩展。加一张卡之前先看 KV 实际分到了哪里两张卡的总显存可以写在资产表里但同一个缓存分配不会自动跨进另一张卡的空闲区。容量计算必须落实到每个执行 rank——参与执行的进程及其设备——所持有的权重、层和 KV heads。若第二张卡运行另一个完整副本它会重新承担该副本的权重和运行开销。它能接走别的请求却不会替第一张卡保存一条请求缺少的 KV。因此不能把“2 × 24 GiB”直接替换进刚才单副本的算式。若采用 TP并且模型与实现允许按 KV heads 均匀切分本例 4 个 KV heads 在 TP2 时每 rank 两个在 TP4 时每 rank 一个。只看同一组四路 32K 的 KV 载荷每 rank 分别是 3.5 GiB 和 1.75 GiB。这里仅说明 KV 分账变化权重、其他峰值和通信开销要按新的布局重新记录不能假设所有项目一律除以 TP。尤其不能无限除下去。vLLM 的QKVParallelLinear在 TP 数量不小于 KV head 总数时把本 rank 的 KV head 数设为 1并计算 head 的复制份数。也就是说适用这种路径的 GQA 模型可能复制 KV heads而不是把一个 head 继续切成任意小数。QKV 并行层源码候选并行度还要满足 Query heads 等切分限制本例有 28 个 Query heads不能见到八张卡就直接列 TP8 的均分预算。这里不推荐更大 TP只要求先核实实际布局再把每 rank 的 KV 数填回公式。采用 PP 时同样应使用本 rank 真正持有的层而不是只用整机总显存盖过局部超额。把“能加载”改成一份有条件的容量结论回到四路长请求的目标现在能够写出的结论是“在 24 GiB、0.9、15 GiB 权重和 2 GiB 其他预留这些假设下BF16 KV 的 7 GiB 理想需求超过 4.6 GiB 预算。”它足以否决这组假设下的同时驻留承诺却不足以宣布某个具体 GPU 必然 OOM。引擎可能通过等待或抢占等方式维持运行。vLLM 优化文档说明 KV 空间不足可能触发抢占这不等同进程必然崩溃也不说明请求延迟仍能满足目标。vLLM 抢占说明下一次调整只需围绕这张容量账改一笔并重算。减少同时驻留的长度或数量会降低 KV 需求但也缩小服务承诺改变权重表示只会直接影响权重一项不自动改变选定的 BF16 KV。选择更低精度 KV则必须重新核实模型、后端支持与质量不能把理想字节减半直接称为可上线收益。增加设备则要重新核实分片与复制而非相加总显存。最终保留一份按 rank 的记录设备可见字节、模型配置与精度、预算方式、实测权重、当前负载下的非 KV 峰值、引擎可用 KV 块以及目标序列长度总和。把本例的假设字段逐个换成实际证据才知道缺口究竟在权重、临时峰值还是活跃缓存。容量账通过后仍要用目标输入输出长度与并发检查延迟、失败和内存峰值这里没有完成这一步。它的价值是让测试从一个明确的可行候选开始而不是从“权重加载成功所以四路长上下文应该也行”开始。