NexGPU-算力租赁,GPU服务器,GPU云算力,AI服务器租用-新闻博客 - KV Cache
type: channel
link: https://nexgpu.net/blog/index.php/tag/KV-Cache/
items: vLLM多卡张量并行配置指南：TP设多少与5步排查
items: GPU利用率优化怎么做？5步定位算力空转真原因
items: L40S租用值不值？对比A100算清推理成本
items: 多卡推理优化怎么做？加卡前先算通信税的6个判据
items: GPU显存怎么选？4步算清权重与KV Cache占用
items: vLLM v0.26.0 发布后，SGLang部署还值不值得做？共享前缀吞吐领先 29% 的选型与落地指南
items: DeepSeek部署选型：从精度、显存到卡型的三段式推算指南

vLLM多卡张量并行配置指南：TP设多少与5步排查
type: item
date: 2026-08-18T10:50:07+08:00
description: 先给结论：vLLM多卡张量并行配置指南的参数决定顺序很多人以为把 --tensor-parallel-size 调得越大，多卡推理就一定越快，但实际上 TP 设多少要由显存分账和模型注意力头数共同决定，不是越大越好。正确的思路是：先按四笔显存账算出 TP 下限，再按注意力头数整除约束和卡间互联确定上限，然后依次调整 --gpu-memory-utilization、--max-model-len 和 KV Cache 精度，最后做同请求分布的对照验证。vLLM 官方文档明确，单机多卡优先用张量并行，跨节点才叠加流水线并行，以避免低速网络拖累高频通信官方并行文档。本文就以这套顺序，给你一份可直接照做的 vLLM多卡张量并行配置指南。第一步：四笔显存账算出 TP 下限启动 vLLM 时，显存分配遵循固定顺序：先加载模型权重，再执行一次 dummy forward 探测中间激活，最后按 --gpu-memory-utilization（默认约 0.90-0.92）把剩余显存划给 PagedAttention 的 KV Cache 池。因此，你至少要几张卡，取决于四笔账：权重、KV Cache、中间激活、引擎常驻开销。估算方法很简单：先拿单卡总显存乘以 --gpu-memory-utilization，得到可用显存；然后用模型权重大小加上预期 KV Cache 占用（与最大上下文长度和并发数相关）除以单卡可用显存，向上取整就是 TP 的下限。中间激活与引擎常驻开销的实际占用需以本机 Profiling 结果为准，建议先按保守估计预留余量、再用实际启动日志中的 KV Cache 块数回填修正。若可用显存与需求接近，应在同一模型上分别试跑相邻两档 TP，以启动日志与压测结果决定取哪一档。具体模型的权重与 KV Cache 量级可参考 Qwen部署显存需求 。第二步：注意力头数整除约束与卡间互联，决定 TP 上限TP 不是想设几就设几。vLLM 要求模型的总 Query 头数以及 GQA 架构下的 KV 头数都必须能被 --tensor-parallel-size 整除，否则初始化阶段会直接抛维度切分断言异常，服务起不来。例如一个 Query 头数为 32 的模型可以被 2、4、8 整除，但不能被 3、5、6 整除，所以 TP=3/5/6 这类取值在多数主流架构上不可用；上线前请以自己模型 config 中的 num_attention_heads 与 num_key_value_heads 逐一验算。另一个上限是卡间互联带宽。张量并行依赖高速总线（如 NVLink）做算子级切分和 All-Reduce 通信，如果你用的是 PCIe 互联的卡，跨卡通信开销会显著拉低性能，此时 TP 不宜设得过高。因此，TP 上限 = min(满足头数整除的最大值, 互联带宽允许的切分数)。关于跨卡通信与切分收益的更多实测思路，可参考 多卡推理优化。第三步：TP 与 PP 怎么分工，什么时候才动用跨节点流水线--tensor-parallel-size 和 --pipeline-parallel-size 的分工很清晰：单机内优先把 TP 拉满（TP=单机卡数），因为 NVLink 带宽高；当模型超过单机总显存时，再叠加跨节点的 PP，通常 PP=节点数。这样组合可以避免跨节点低速网络承载高频张量通信。一个常见的误配是单机内滥用 PP——明明卡间有高速互联，却切成 PP，导致流水线气泡降低利用率。另一个误配是跨节点强行切 TP，让 All-Reduce 走慢速网络，吞吐直接崩掉。所以跨节点时，正确做法是每台机器内部满切 TP，再跨节点切 PP。需要说明的是，千亿级 MoE 模型在跨节点部署下的 Expert Parallelism 与 TP/PP 三维混合切分比例，目前各硬件平台仍在动态演进，本文的 TP/PP 组合结论只覆盖稠密模型的单机与多机常规拓扑，不对 MoE 最优切分给定论。启动命令示例：# 单机 4 卡，TP=4 vllm serve your-model --tensor-parallel-size 4 # 跨 2 节点，每节点 4 卡，TP=4，PP=2 vllm serve your-model --tensor-parallel-size 4 --pipeline-parallel-size 2第四步：gpu-memory-utilization 与 max-model-len 的调整次序这两个参数都在改同一个 KV Cache 池，所以必须按顺序调，一次只动一个。--gpu-memory-utilization 决定池子多大（默认 0.90-0.92），--max-model-len 决定单请求预留多长的逻辑上下文。如果你直接把 --m…

GPU利用率优化怎么做？5步定位算力空转真原因
type: item
date: 2026-08-17T10:50:44+08:00
description: GPU利用率优化不是把利用率数字拉高，而是先打开监控面板，把 GPU 利用率、请求排队时长和前缀缓存命中率三个指标并列出来，再按下面的顺序排查：利用率数字→排队→带宽→重复计算→引擎选型。只看 nvidia-smi 的静态占用已经不够，需要结合请求分布和引擎参数做系统化判断。先给结论：GPU利用率优化的排查顺序是什么第一步，确认你看到的“利用率”数字到底代表什么；第二步，看请求是否在排队等待，导致 GPU 空闲；第三步，看是否因为显存带宽受限，导致利用率高但有效 Token 产出不涨；第四步，看是否有重复计算（比如前缀重复计算和 Preemption 重算）；最后一步，才考虑是否需要更换推理引擎。2026 年下半年的评测与观测实践（如 DeepInfra、Spheron 等机构的基准）反复证明，仅靠 nvidia-smi 的利用率百分比无法区分“真空转”“假满载”和“算了没产出”这三类问题。三种「利用率不好看」：真空转、假满载、算了没产出类型典型表现根因排查重点真空转GPU 利用率低，算力空置请求排队、批处理不足排队时长、并发设置假满载利用率 100% 但吞吐不涨Decode 阶段显存带宽受限显存带宽、KV Cache 命中率算了没产出利用率高但有效 Token 产出低前缀重复计算、Preemption 重算前缀缓存命中率、抢占次数很多人误以为把 GPU 利用率拉满到 100% 就能线性提升吞吐，但实际上当 KV Cache 不足触发 Preemption（抢占并重算）时，GPU 可能满载但有效 Token 产出并未提升。第一步：确认利用率数字本身的含义，该看哪些指标GPU利用率优化的第一件事，是确认 nvidia-smi 显示的数字到底代表什么。nvidia-smi 显示的 GPU 利用率反映的是 SM（流处理器）是否有 kernel 在跑，并不代表算力被有效使用。要判断是否存在“算力空转”，需要结合以下细粒度指标交叉验证：指标含义用途vllm:request_queue_time_seconds请求排队等待时间判断是否因排队导致 GPU 空闲prefix cache hit rate前缀缓存命中率判断重复计算占比preemption 计数抢占次数发现因 KV Cache 不足导致的重算这些指标可通过 Prometheus 采集，例如 vLLM 内置了相关的 metrics。如果你发现排队时间高但 GPU 利用率低，说明请求到达不均匀或并发设置偏小；如果利用率高但排队时间也高，可能是调度问题。第二步：估算请求分布的前缀重合度，60% 这条线为什么关键打开你的线上日志，统计请求之间的共享前缀比例——比如系统提示词、RAG 检索块、多轮对话历史等经常重复的部分。计算所有请求中前缀重复的比例，当这个值超过 60% 时，就值得考虑采用具备前缀复用能力的引擎。这个 60% 的量化边界来自 2026 年的受控基准测试（如 DeepInfra 与 Spheron 的对比评测），而非营销口径。第三步：前缀重合度高时怎么优化，可预期收益是多少如果你的场景前缀重合度超过 60%（比如典型的 RAG 应用），使用 SGLang 的 RadixAttention 相比 vLLM 可以降低 20%~40% 的首字延迟（TTFT）。注意，这是 TTFT 的改善，并不代表总吞吐翻倍。该结果来自控制模型、精度与并发梯度的受控基准，仅在前缀重合度 >60% 时成立，且只体现在 TTFT，不代表总吞吐同幅提升。在多轮对话和 RAG 这类前缀重合高的场景中，首字延迟对用户体验影响很大。这里可以结合 SGLang部署 一文了解实际部署要点。第四步：前缀重合度低时别急着换引擎，先调参数如果前缀重合度低于 60%，甚至独立 Prompt 占多数，两个引擎的吞吐差距在 5% 以内，此时迁移引擎的成本可能高于收益。该差距同样基于受控对照，建议用你自己的请求分布回放复现后再下结论。优先调整 vLLM 参数：例如 --gpu-memory-utilization 默认是 0.9，即分配 90% 显存给模型权重和 KV Cache，保留 10% 缓冲防止 CUDA Graph 及临时张量溢出触发 OOM。如果 KV Cache 空间不足频繁触发 Preemption 重算，可以适当调大这个比例，或者降低 max_num_seqs、max_num_batched_tokens 来减少并发压力。注意，max_num_seqs 和 max_num_batched_tokens 的调整方向相反：调大 max_num_seqs 可提高批处理能力、降低排队时长，但会增加显存压力、可能引发更多 Preemption；反之调小这两个参数会减少并发、降低 Preemption 次数，但可能拉长排…

L40S租用值不值？对比A100算清推理成本
type: item
date: 2026-08-14T10:48:48+08:00
description: 当你的团队准备把 32B 模型部署成线上服务，预算又够不上 A100 或 H100 时，L40S租用是不是一条值得走的路？答案是：取决于三个变量——模型多大、上下文多长、并发多少，只要这三者落在 48GB 显存和 PCIe 互联能承受的区间内，L40S 就是性价比很高的推理选择；反之，任何一个变量越界，省下的时租都会在排队和失败请求里还回去。2026 年 8 月的市场信号也在提醒我们：推理引擎版本和云 GPU 价格梯队都在快速变化，选型必须绑定当期引擎能力和报价一起算。vLLM v0.27.0 在 8 月 11 日发布，针对 Blackwell (SM100) 架构强化了 FP8 KV Cache 与 FlashAttention 4 支持；同一时期，H100/H200 的按量价格探底，B200 规模化上线后价格分化明显。这些变化直接影响中端卡的有效容量和成本对比，所以本文所有判据都会明确区分“架构无关的通用机制”与“Blackwell 专属能力”。48GB显存怎么分账：权重、KV Cache、中间张量与引擎常驻开销L40S 最吸引人的就是 48GB 显存，但它不是一整块给你放模型权重的。要判断“48GB显存能跑多大的模型”，得先把显存拆成四份：分账项占用内容影响因素权重模型参数本身参数量、量化精度（FP16/INT8/FP8）KV Cache已生成 token 的键值对上下文长度、并发数、每 token 占用字节中间张量激活值、临时计算结果Batch size、序列长度、模型结构引擎常驻推理框架、CUDA context、碎片引擎版本、并行策略、显存管理估算显存时，权重部分用 参数量 × 精度字节 计算（例如 32B FP16 约 64GB，INT8 约 32GB）；KV Cache 部分用 单 token 占用 × 上下文长度 × 并发数 计算。这里的单 token 占用公式为：2（K 和 V）× 层数 × KV head 数 × head_dim × 每元素字节（FP16=2，FP8/INT8=1）。实测中每元素字节通常为 0.5~2 字节，指的是每个缓存元素的精度字节，而非每 token 总占用。中间张量和常驻开销按经验值预留 20%~30%。把四份加起来，如果超出 48GB，就需要减小模型精度、缩短上下文或降低并发。不同参数量与精度下的显存余量对照，可结合GPU显存怎么选的推算方法一起用。判据一：装得下不等于跑得顺，显存余量该留多少很多人以为权重装进显存就能稳定服务，其实峰值激活、突发长请求和显存碎片会在运行时吃掉额外空间。例如一个 32B INT8 模型权重占 32GB，看起来离 48GB 还有余量，但如果并发请求的上下文长度波动大，KV Cache 会突然膨胀，再加上引擎临时分配，就可能触发 OOM。自查方法：用业务里最大上下文长度 × 目标并发数，算出 KV Cache 上限，再留出至少 20% 显存余量；然后用压测工具模拟真实请求分布，观察显存峰值。若峰值稳定在 40GB 以下，说明 L40S 能扛住负载；若频繁逼近 48GB，就该降低并发或换更大显存的卡。判据二：没有高速卡间互联时，L40S多卡扩展的收益边界在哪“L40S没有NVLink对多卡推理有影响吗？”这个问题要分场景回答。如果你把单个大模型切分到多张卡上做张量并行，那么卡间通信带宽就是关键瓶颈。L40S 走 PCIe 互联，带宽远低于 NVLink，多卡扩展时通信开销会显著拉低加速比。更合理的策略是优先选“单卡装得下”的模型规模，然后用多副本水平扩展——每张卡跑一个完整模型副本，通过负载均衡分担请求，这种部署不依赖卡间高速互联，扩展性更好。主流推理引擎近期在序列并行与并行缓冲区复用方向上的优化，能在一定程度上缓解通信成本，但这类优化在公开发布说明中是针对特定模型（如 DeepSeek-V4）给出的，不能默认等比例迁移到 L40S 上的任意模型。多卡场景下，建议参考多卡推理优化的通用原则，优先做模型副本扩容。判据三：引擎版本会改写有效容量——前缀复用与 KV Cache 策略带来的余量变化推理引擎的版本会直接改写 L40S 的有效容量，这一点常被忽略。2026 年 8 月 5 日，DeepInfra 发布的一项对比指出，SGLang 的 RadixAttention 前缀树机制在长上下文和共享前缀场景中能实现 KV Cache 零开销复用，吞吐表现优于传统哈希分片缓存。这意味着，如果你的业务有高频重复的前缀——比如多轮 Agent 对话或固定 system prompt——SGLang 能让同样的 48GB 显存支撑更高的并发，因为重复的 KV Cache 不需要重新计算。但反过来说，vLLM v0.27.0 里那些针对 Blackwell (SM1…

多卡推理优化怎么做？加卡前先算通信税的6个判据
type: item
date: 2026-08-13T10:48:15+08:00
description: 多卡推理优化的正确做法，是先按 Prefill 与 Decode 两段负载分别算账，再决定切分方式与加卡时机。很多团队直接翻倍卡数，结果 8 卡反而比单卡慢，归根结底是加的卡越多，通信税越重。这句话不是空谈。2026 年 8 月，vLLM 发布 v0.27.0，深入集成 FlashAttention 4，为 Blackwell SM100 提供 FP8 KV Cache 与 256 headdim 原生支持，并消除空 c128 启动、优化 Top-K 路由来降低 DeepSeek 模型的首包延迟（TTFT）；同期，SGLang 在 Blackwell 上推进 NVFP4 预填/解码分离（PD Disaggregation），并跟进 FlashInfer 的 NSA 与 DSA 稀疏注意力算子。这两条官方更新都指向同一个方向：把多卡推理的优化从“盲目加卡”转向“分段治理”。先分清两段负载：Prefill 吃算力，Decode 吃带宽与通信多卡推理优化要做的第一件事，是把推理过程拆成两段：Prefill（预填）阶段，处理输入 prompt 并生成首个 token，高度依赖 GPU 算力与并行计算能力；Decode（解码）阶段，逐 token 生成输出，主要受显存带宽与卡间通信速度制约。如果你不加区分地把两段混在一起谈，就会陷入“加卡之后延迟反而变高”的误区：比如 Decode 阶段卡间通信开销巨大，增加卡数反而拖慢单 token 生成。业界的最新实践正是沿着“分段治理”这条路径走。vLLM v0.27.0 针对 DeepSeek 架构强化了序列并行优化，SGLang 则在 Blackwell 上落地 NVFP4 PD 分离，让 Prefill 与 Decode 跑在不同实例上，各自按负载特征选择最优的硬件与切分方式。判据一：单卡显存装不装得下——你加卡是为了容量还是为了速度动手加卡之前，先问自己一个问题：你加卡是为了容量还是为了速度？容量型加卡：模型权重加上 KV Cache 超出单卡显存，需要多卡分摊显存。这种场景下，吞吐通常不会随卡数线性增长，因为卡间通信会吃掉一部分并行收益——这本来就是预期结果，不必焦虑。速度型加卡：目标是把吞吐拉高、把延迟压低，这时候切分方式与通信开销才是关键。一个容易被忽略的事实：671B 参数的模型即使做 4-bit 量化，依然需要超过 300GB 的显存，单张消费级 GPU 根本放不下，只能跑 32B 或 70B 的蒸馏版本。所以对超大模型来说，容量型加卡几乎是必然选择。参考已有的部署经验：GPU显存怎么选 可以帮你更快确定显存基线。判据二：切分维度选错，吞吐就不会线性增长（TP / PP / 序列维切分的适用边界）并行切分方式直接决定卡间通信的模式与吞吐表现。下表对比了三种常见切分维度：切分维度适用负载通信模式典型瓶颈张量并行（TP）Prefill 与 Decode 均适用，但对带宽敏感每层前向/反向都需要 All-Reduce卡间互联带宽，跨节点时急剧恶化流水线并行（PP）适合模型层数深、显存压力大的场景仅层间传递激活，通信量小流水线气泡（bubble）导致利用率下降序列维切分长上下文、共享前缀场景按序列块切分，稀疏注意力下通信减少序列切分与注意力计算的调度开销张量并行和流水线并行怎么选？简单来说：TP 切分权重与激活，适合单机内高速互联的环境；PP 按层切分，通信量小，但存在流水线气泡。对于 8 卡推理吞吐上不去的问题，往往不是卡数不够，而是 TP 过大导致通信占比过高。引擎版本会影响切分策略的最佳解。vLLM v0.27.0 对序列并行与 TTFT 做了专项优化，同样卡数下，更新引擎版本可能让 TP 的可用范围变大。因此，切分方式的选择必须结合你所用的引擎版本来实测，不能照搬旧结论。判据三：卡间互联决定 TP 的上限，什么时候单机内切、什么时候必须跨节点张量并行对卡间带宽极度敏感：单机内的高速互联（如 NVLink）能支撑较大的 tensor parallel size，跨节点走以太网或 InfiniBand 时，通信延迟和带宽都会明显劣化。因此，tensor parallel size 设多少合适，取决于卡间互联质量。在单机 8 卡内，TP=8 通常可行；一旦跨节点，TP 的通信税会急剧上升，这时应优先考虑 PP 或序列维切分来降低跨节点通信量。涉及集群规划时，可以参考 GPU集群规划 获取更多思路。一个经常被忽视的成本项是：KV Cache 溢出导致跨机通信的“通信税”，这会直接抵消加卡收益。判据四：KV Cache 精度会改写显存账，FP8 KV Cache 腾出的余量该怎么用vLLM v0.27.0 在 SM100 上原生支持 FP8 KV Cache 与 256 headdim。K…

GPU显存怎么选？4步算清权重与KV Cache占用
type: item
date: 2026-08-12T10:51:46+08:00
description: 先别急着看卡型参数表，GPU显存怎么选，答案要从你的负载反推：把模型权重、KV Cache、中间张量和框架常驻开销分开算，再加一层引擎版本与显存碎片的余量，最后才落到具体显存规格。vLLM v0.27.0 在 2026 年 8 月的更新里，就同时改写了 KV Cache 的字节宽度和启动期的显存占用，说明同一模型在不同引擎版本下显存账并不固定，这也正是选显存必须留余量的原因。推算前先问清三件事：模型多大、上下文多长、并发多少显存推算的三个输入变量缺一不可：模型参数量、目标上下文长度、并发请求数。脱离后两者谈“7B模型需要多少显存”必然算错，因为 KV Cache 随上下文与并发几乎线性放大。动手前先收集这几项：模型权重文件大小（可据此反推参数量与精度）、线上预期的上下文长度（比如 8K 还是 32K tokens）、同时推理的最大并发请求数。第一笔账：权重显存怎么算，FP16/FP8/INT4 三档精度换算权重显存 = 参数量 × 每参数字节数。FP16 每个参数占 2 字节，FP8 占 1 字节，INT4 占 0.5 字节。以 7B 模型为例，FP16 权重约 14GB，FP8 约 7GB，INT4 约 3.5GB。注意这只是权重部分，还没算 KV Cache 和框架开销。下表给出常见规模的量级参考，方便你代入自己的模型：模型参数量FP16 权重FP8 权重INT4 权重1B~2GB~1GB~0.5GB7B~14GB~7GB~3.5GB13B~26GB~13GB~6.5GB70B~140GB~70GB~35GB表中数值为按参数量×字节宽度推导的权重量级，不含 KV Cache、激活值与框架开销，也不代表任何具体型号的实测占用。第二笔账：KV Cache 与上下文长度、并发数的乘法关系KV Cache 的单 Token 基础推算公式是：2 × 层数（Layers）× KV头数（KV_Heads）× 头维度（Head_Dim）× 每参数字节数。这个值乘以序列长度再乘以并发数，就是 KV Cache 的总占用。该单 Token 推算式为 vLLM 官方文档给出的基础形式。上下文长度增加，KV Cache 会线性增长；并发数翻倍，KV Cache 也翻倍。FP16 与 FP8 的差别在这里同样体现：FP8 KV Cache 每个参数少 1 字节，整块缓存显著缩小。vLLM v0.27.0 在 Blackwell SM100 上深化了 FlashAttention 4 FP8 KV Cache 支持，意味着同一模型同一上下文，用 FP8 缓存能省出可观显存。第三、四笔账：中间张量与框架/引擎常驻开销为什么必须预留除了权重和 KV Cache，推理过程中还有激活值、通信缓冲、CUDA 上下文等中间张量，以及显存碎片。vLLM 官方将 gpu_memory_utilization 默认设为 0.9，意思是只使用 90% 的总显存，预留约 10% 给碎片和运行时分配。关于 gpu_memory_utilization 的实际配置，可参考 vLLM部署 的完整流程。这说明“可用显存”并不等于卡上标称显存。例如 24GB 的卡，实际可用约 21.6GB。因此，你算出来的理论占用必须小于这个可用值，否则容易触发 CUDA out of memory。四步推算法完整走一遍：从模型规模到目标显存区间GPU显存怎么选，落到操作上就是把四笔账按顺序算完：算权重：参数量 × 每参数字节数。算 KV Cache：单 Token KV Cache × 上下文长度 × 并发数。算中间张量与框架开销：一般按总显存的 10%~20% 预留，或根据引擎文档设定。加总得到理论下限，再乘 1.1~1.2 作为实际需求区间。这样你会得到一个显存区间而不是单点数值。区间的下沿对应刚好够用但风险偏高，上沿对应更安全但可能浪费。以 7B 模型 FP16、上下文 8K、并发 4 为例（按 32 层 / 8 个 KV 头 / 头维度 128 的 GQA 结构估算）：权重约 14GB + KV Cache 约 4GB + 中间张量与框架开销约 3GB ≈ 21GB，加余量后需求落在 24GB~28GB，24GB 卡处于临界（需压低并发或上下文），稳定线上建议 32GB 及以上。注意，若换成 32 头 MHA 结构（KV 头数由 8 升到 32），单 Token KV Cache 由约 128KB 升到约 0.5MB，KV Cache 约 16GB，总需求约 33GB，加余量后建议 48GB 档位或多卡。若并发继续提升，还需考虑多卡并行，可参考 GPU集群 方案。引擎版本会改写显存账：FP8 KV Cache 与启动期优化带来的余量变化这一节是重点：推理引擎的版本会直接改变显存账单。据 …

vLLM v0.26.0 发布后，SGLang部署还值不值得做？共享前缀吞吐领先 29% 的选型与落地指南
type: item
date: 2026-08-08T13:57:39+08:00
description: 一、vLLM v0.26.0 上线后，SGLang部署的价值坐标变了吗2026 年 7 月 28 日，vLLM 发布 v0.26.0，带来三项重磅更新：NVFP4 模型量化支持、DeepSeek-V4 专用路由算子（官方称 E2E TPOT 降低 2.94%）以及基于对象存储的 KV Cache 分级卸载（fact_1）。一周后的 8 月 5 日，DeepInfra 的 H100 评测显示，SGLang 在共享前缀场景下以 16,215 tokens/s 对 vLLM 的 12,553 tokens/s 领先 29%（fact_2）。这两条消息放在一起，自然让正打算做 SGLang部署的工程师心里打鼓：vLLM 版本更新这么快，SGLang 还值不值得押注？本文不打算做“谁更强”的站队，而是把两条事实放进同一个坐标系：vLLM v0.26.0 压的是单请求路径上的显存与计算，SGLang 的 RadixAttention 压的是跨请求的前缀重复计算。两者作用在不同成本段，因此选型的关键不是版本号新旧，而是你自己的请求分布长什么样。二、拆开那个 29%：RadixAttention 省掉的到底是哪一段计算先看 SGLang 领先 29% 这个数字是怎么来的。DeepInfra 的评测跑在 H100 GPU 上，场景是共享前缀——也就是大量请求带着相同的 system prompt、上下文或检索结果前缀。在这种负载里，SGLang 的 RadixAttention 机制会把前缀的 KV 缓存复用起来，新请求到达时直接跳过已经算过的那部分 prefill，省掉的是跨请求重复的前缀计算量。多轮对话里的历史上下文、RAG 里的固定检索模板、长 system prompt，都是典型的高前缀重复场景。但 29% 不是普适增益。它的出现依赖两个条件：一是前缀在总输入中的占比要高，二是请求之间的前缀重复率要高。如果你的请求彼此独立、前缀很短，或者生成长度远大于输入长度，那么 prefill 本来在单请求时延里就不占大头，RadixAttention 能削掉的部分自然有限，29% 会被显著抹平。所以，看到“29%”先别急着迁移，先量化自己的负载再说。要验证也很简单：在自己的服务里记录请求前缀的重复率，用线上日志统计前 1000 个请求的公共前缀长度占比，就能大致判断这个数字在你环境里的参考价值。三、NVFP4、路由算子与 KV 分级卸载分别压的是哪类成本vLLM v0.26.0 的三项新能力，各自作用的成本环节并不相同。先看 NVFP4 量化：它把权重压到 4-bit 浮点，直接减小权重显存占用和访存带宽压力，让同等显存能装下更大的模型或更大的 batch——这是“单请求路径”上的显存优化。再看 DeepSeek-V4 路由算子：它针对 MoE 架构的稀疏路由做优化，让 token 在专家间的分配更高效，官方口径是 E2E TPOT 降低 2.94%。TPOT 是每个输出 token 的生成时间，压的是 decode 路径上的单请求计算时延。最后是对象存储 KV Cache 分级卸载：当 KV Cache 超出显存时，把一部分卸载到对象存储，把显存压力转移为外部存储的读写和额外网络延迟——这是一项显存换吞吐的策略，但卸载本身会引入延迟成本。这三项都指向“单请求路径”与“显存占用”，与 RadixAttention 的“跨请求前缀复用”不在同一段成本上。因此它们并非互斥关系：你可以在 SGLang 上用 RadixAttention 拿前缀收益，也可以在 vLLM 上用 NVFP4 和 KV 卸载来腾显存。选型的本质是确认你的瓶颈在哪一段。四、按请求分布做选型：一张对照决策表把两类优化放进同一张决策表，别按引擎站队，按负载特征对号入座：负载特征偏向 SGLang（RadixAttention）偏向 vLLM v0.26.0（量化/KV卸载）判断依据多轮对话（长历史上下文）高前缀重复，缓存命中收益大前缀少时优势不明显记录每轮公共前缀占比RAG 场景（固定检索模板）高频共享 prompt/system prompt模板不固定时收益有限统计检索前缀重复概率单轮长生成（输出远长于输入）29% 会被抹平decode 优化与显存腾挪更务实比较输入/输出 token 长度比批量离线（请求相互独立）前缀复用概率低量化与 KV 卸载稳定可控分析请求间前缀相似度显存吃紧的大模型需额外显存做缓存池NVFP4 与 KV 卸载直接减显存看当前显存余量与峰值这张表不是替你做决定，而是告诉你该测什么。每行右侧的“判断依据”就是你要在自己环境里收集的指标。五、SGLang部署实操路径：从启动到前缀缓存与并发调优的顺序如果决策表把你推向 SGLang，下面是一套可复用的 SGLan…

DeepSeek部署选型：从精度、显存到卡型的三段式推算指南
type: item
date: 2026-08-04T19:13:49+08:00
description: 一、DeepSeek部署第一步不是选卡，而是先把显存台阶算清楚很多团队在考虑DeepSeek部署时，第一反应是“上什么卡”，但更合理的顺序应该是先算显存。因为不同精度下，同一个模型的显存需求可能相差数倍。以DeepSeek-R1蒸馏系列为例，在FP16/BF16原生精度下，32B和70B模型需要64GB-181GB显存，这个区间大到足以让单卡方案直接出局；而采用FP8或Q4_K_M量化后，显存需求骤降至18GB-45GB，单卡RTX 4090/5090或A100/H100都能成为可行选项。理解这个从“原生”到“量化”的显存台阶变化，是DeepSeek部署选型的第一课。本文不讨论模型能力，只做工程化的容量推算，帮你避开“先买卡再发现显存不够”的坑。需要说明的是，本文中的显存区间来自NVIDIA NIM对DeepSeek-R1-Distill-Qwen-32B的公开模型规格页，以及两篇2026年公开的显存/KV Cache推算研究文章（合计3个公开来源）。所有数字均为区间级推算，不含任何实测tokens/s或精度损失数值，实际占用需在自有环境压测确认。二、FP16原生占用 vs FP8/Q4_K_M量化占用：32B与70B的显存区间对照先看量化带来的显存变化。根据公开推算，DeepSeek-R1蒸馏32B模型在FP8或Q4_K_M量化后，权重显存约需18GB-24GB；而70B模型则需38GB-45GB。这个区间宽度来自量化方案（FP8 vs Q4_K_M）、词表大小以及运行时额外开销的差异。规划时建议按区间上界预留，避免因实现细节导致OOM。下表整理了一个精度—显存—卡型的映射关系，方便快速对照：模型尺寸原生精度（FP16/BF16）量化后（FP8/Q4_K_M）参考卡型32B64GB-181GB区间（整体估算）18GB-24GB单卡RTX 4090（24GB）、RTX 5090（32GB）70B64GB-181GB区间（整体估算）38GB-45GB单卡A100/H100（80GB），或双卡4090/5090注意：原生精度列两行均落在64GB-181GB区间，70B显著高于32B，需按区间上界规划。对于“DeepSeek部署 Q4_K_M 量化显存占用”的疑问，上表就是答案：这一区间即可作为Q4_K_M量化后权重显存占用的规划基线，按上界预留最稳。三、别只算权重：KV Cache、上下文长度与并发数如何吃掉剩余显存权重显存只是基础，真正让显存失控的是KV Cache。它会随着Transformer层数、KV Head数量、Head维度、上下文长度以及并发数（Batch Size）增长而暴涨。例如，处理长文档或高并发请求时，KV Cache可能轻松超过权重占用。好在vLLM、SGLang等推理框架提供了优化手段：启用FP8 KV Cache量化可以压缩缓存体积，Prefix Caching则能复用公共前缀的缓存，显著降低显存压力。估算KV Cache时，可用如下公式：KV Cache ≈ 层数 × KV Head数 × Head维度 × 2（K与V） × 序列长度 × 并发数 × 单元素字节数。各参数可从模型config中直接读取，字节数随FP16/FP8 KV Cache设置变化。先按业务最长上下文与峰值并发算一遍KV Cache，再回头看剩余显存是否够放权重。四、按显存台阶反推卡型：单卡4090/5090、单卡A100/H100与多卡节点的适用边界现在把显存台阶映射到具体卡型。18GB-24GB台阶：对应32B量化后，单卡RTX 4090（24GB）或RTX 5090（32GB）足够，但需预留KV Cache和并发余量，建议开启量化缓存压缩。38GB-45GB台阶：对应70B量化后，单卡A100/H100（80GB）最稳，或者用双卡RTX 4090/5090通过张量并行切分。未量化场景：原生FP16/BF16场景的显存需求处于64GB-181GB区间的高位，单卡80GB级也难以覆盖，需直接进入多卡切分或多机部署。对于“DeepSeek部署 单卡 RTX 4090 能跑吗”这类问题，答案是：32B量化后可以，70B则需双卡或更高显存卡。而“DeepSeek部署 A100 还是 H100”的取舍，取决于你的服务规模：A100的80GB显存足以应对量化后的70B模型，H100则提供更高吞吐，适合高并发场景。在确定卡型时，总显存 = 权重区间上界 + 按目标上下文长度与并发估算出的KV Cache + 框架与碎片开销，三项分别核算后再选卡，不用固定倍数拍脑袋。五、量化带来的取舍：吞吐、延迟与输出质量该怎么自己验证FP8和Q4_K_M并非无损压缩，它们会在数值精度上有所取舍，影响输出质量，但具体损失程度无法一概而论。因此，你需要一套自己…