NexGPU-算力租赁,GPU服务器,GPU云算力,AI服务器租用-新闻博客 - KV Cache
vLLM多卡张量并行配置指南：TP设多少与5步排查
先给结论：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 决定单请求预留多长的逻辑上下文。如果你直接把 --max-model-len 设成模型的理论极大值，单个请求会吃掉过多 KV block，系统最大并发会被剧烈压缩NVIDIA 博客。正确的次序是：先固定 --gpu-memory-utilization，再根据实际请求长度压 --max-model-len，观察吞吐和并发变化。同时改两个参数，出了问题你无法判断是谁引起的。一般建议 --max-model-len 设为略大于你最长的真实请求，而不是模型极限。第五步：vllm fp8 kv cache 怎么开启，以及腾出的余量给谁当 KV Cache 成为瓶颈时，可以开启 FP8 量化：--kv-cache-dtype fp8（硬件支持时也可用 fp8_e4m3 或 fp8_e5m2）。这不会量化模型权重，只把每 Token 的 KV Cache 占用降低约 50%，相当于可用 Token 容量翻倍FP8 KV Cache 文档。腾出的余量怎么分配？分场景判断：如果你的业务是长文档、长上下文，优先提高 --max-model-len；如果是聊天或高并发 API，优先提升并发。注意，FP8 会带来精度损失，上线前务必做质量回归测试。如果对显存分账理解不深，可参考 GPU集群规划 做整体规划。引擎版本为什么必须写进配置基线同样一份启动参数，vLLM 引擎版本变了，结果未必能复现——因为算子实现、默认值、显存 Profiling 行为都可能变化。所以配置基线里必须记录四项：引擎版本、模型版本、完整启动命令、硬件拓扑。升级前后，重跑同一组对照，确保性能变化不是版本漂移造成的。配完怎么验证：同请求分布下 TP=1/2/4 对照照本文这份 vLLM多卡张量并行配置指南配完后，验证时固定模型、请求分布和并发梯度，分别记录 TTFT（首字延迟）、单 Token 时延、总吞吐、最大并发和显存占用。注意：TP 的主要收益是摊薄单卡显存和降低 TTFT，但跨卡 All-Reduce 开销可能让总吞吐不升反降，尤其在 Decode 密集的高并发场景。所以必须实测，不要默认线性加速。用 NexGPU 的按量多卡实例，可以快速拉起 TP=1/2/4 三组环境，配合预制模板保证引擎版本一致，避免漂移。把 vLLM多卡张量并行配置指南的五步倒过来，就是下面这张排查顺序表。排查顺序表故障现象优先检查项调整动作启动报维度切分断言注意力头数能否被 TP 整除改为整除的 TP（如 2、4、8）CUDA out of memory显存余量降 --gpu-memory-utilization 或 --max-model-len，再考虑开 FP8吞吐不涨互联带宽与并发先确认是否跨节点误切 TP、互联是否为 PCIe；再检查 --max-model-len 是否远大于真实请求长度而压死并发，应下调至略大于最长真实请求。首字延迟高预填充负载增加 TP 或检查请求长度分布常见问题TP 设多少合适？TP 取决于模型头数整除约束和显存需求。先算显存账确定下限，再查头数整除确定上限，取满足两者的最大值。例如 32 头模型可支持 2、4、8，但不能是 3、5、6。TP 和 PP 有什么区别？TP 将单层切分到多卡并行计算，适合单机高速互联；PP 按层分段，适合跨节点。单机优先 TP，跨节点才用 PP，避免低速网络拖累。双卡吞吐上不去是什么原因？最常见的原因不是参数，而是互联：TP 的收益主要在摊薄单卡显存与降低 TTFT，若两卡走 PCIe 而非 NVLink，或场景是 Decode 密集的高并发，跨卡 All-Reduce 的通信开销可能吃掉并行收益，总吞吐不升反降。此外，未开 --gpu-memory-utilization 调优导致 KV Cache 不足，或 TP 设置不当引入通信开销，也可能 --max-model-len 设置过大压缩了并发。按排查表逐项检查。gpu-memory-utilization 设多少？默认 0.90-0.92 即可，但如果出现 OOM，可以逐步降低到 0.8 或 0.85，同时观察吞吐变化。不要设太低，否则 KV Cache 过小影响并发。FP8 KV Cache 怎么开启？启动命令加 --kv-cache-dtype fp8，硬件支持时可用 fp8_e4m3 或 fp8_e5m2。开启后 KV Cache 占用降约 50%，但需做质量回归测试。启动报 CUDA out of memory 怎么办？先降 --gpu-memory-utilization 至 0.8，再降 --max-model-len，如果仍不够，考虑开启 FP8 KV Cache 或提高 TP 以摊薄显存。建议先按上述五步在自己的模型与真实请求分布上跑一次 TP=1/2/4 对照，把引擎版本、启动命令、硬件拓扑与实测指标一起存成配置基线，升级引擎后重跑同一组对照。需要临时多卡环境做这组对照时，可用 NexGPU 的按量多卡实例与预制模板拉起同一引擎版本，避免版本漂移让参数不可复现。
GPU利用率优化怎么做？5步定位算力空转真原因
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 次数，但可能拉长排队时间。你需要根据自己的请求到达率和显存余量，在排队时长与 Preemption 次数之间取平衡。第五步：把吞吐提升换算成每百万 Token 成本，判断值不值得做计算方法：时租成本 ÷ 有效 Token 产出。有效 Token 产出 = 每请求输出 Token 数 × 单位时间成功请求数。迁移工程量、稳定性风险也要折算进收益侧。如果调参后吞吐提升明显，再考虑长期占用资源；否则用按量实例做短期验证更划算。用按量计费实例（如 NexGPU 上即开即用的同规格机型）跑短时验证，可把优化前后的有效吞吐差直接换算成时租差。GPU利用率优化的落地判据最终要回到每百万 Token 成本。做一次同请求分布的双引擎对照：该记录哪些指标才有可比性进行 A/B 对照实验时，必须保持同模型、同精度、同请求分布、同并发梯度，并记录以下指标：TTFT、每输出 Token 时延、有效吞吐、前缀缓存命中率、抢占次数。需要说明的是，这种对照需要在同规格实例上运行，NexGPU 提供按量计费的 GPU 资源和预制模型模板，方便你短时开出同规格实例跑两轮对照，用完即释放。如果你对集群规划有疑问，可参考 GPU集群规划。多卡场景下还需考虑张量并行与数据并行的切分方式，以及跨卡通信开销对吞吐的影响，可参考 多卡推理优化 中的实践建议。四个常见误判与排查检查清单把 nvidia-smi 满载当成算力用满——需要用细粒度指标交叉验证。把 TTFT 改善当成总吞吐改善——TTFT 降低不代表吞吐提升。盲信“某引擎全场景领先 29%”的非对照结论——注意版本、参数、请求分布是否一致。把显存比例一味调高导致 OOM——保留 10% 缓冲是为了稳定运行。排查检查清单[ ] 确认 GPU 利用率指标来源（nvidia-smi vs 引擎 metrics）[ ] 查看请求排队时长，判断是否空闲[ ] 统计前缀重合度，估算重复计算比例[ ] 检查 KV Cache 命中率与抢占次数[ ] 调整 gpu-memory-utilization 与 max_num_seqs 等参数[ ] 必要时同请求分布下做双引擎对照常见问题GPU利用率低怎么排查？先看请求排队时长：如果排队多但 GPU 空闲，可能是并发设置偏低或请求到达不均。再看前缀缓存命中率，如果命中率低，大量前缀被重复计算，浪费算力。最后检查显存比例是否过小导致频繁 Preemption。按此顺序即可定位。为什么GPU利用率100%但吞吐上不去？这通常是显存带宽受限或 Preemption 重算导致。Decode 阶段受显存带宽限制，即使 SM 满载，Token 产出也无法提升。另外 KV Cache 不足触发 RECOMPUTE 也会消耗算力但不出结果。此时应调大 gpu-memory-utilization 或减少并发。gpu-memory-utilization设多少合适？默认 0.9 是推荐起点，它分配 90% 显存给模型和 KV Cache，保留 10% 缓冲防止 OOM。如果频繁出现 Preemption，可在 0.9 基础上小幅上调，每次上调后观察 CUDA Graph 与运行时临时张量是否触发 OOM，具体上限取决于模型与显卡显存。若仍有问题，则降低 max_num_seqs。前缀缓存命中率怎么看？在 vLLM 的 Prometheus metrics 中查找 prefix cache hit rate 指标。若命中率低，说明大量前缀重复计算，可考虑启用前缀复用功能。你需要自行计算线上请求的共享前缀比例，以判断是否属于高重合场景。RAG场景推理引擎怎么选？如果前缀重合度超过 60%，优先考虑 SGLang，其 RadixAttention 可降低 20%~40% 的首字延迟。如果重合并不高，vLLM 与 SGLang 吞吐差距在 5% 以内，选择成熟度更高的 vLLM 即可，同时注意调优显存参数。多轮对话首字延迟太高怎么优化？先测多轮历史造成的前缀重合度，>60% 再评估前缀复用；同时检查是否因 KV Cache 不足触发抢占重算。可调大 gpu-memory-utilization 或降低并发参数，减少 Preemption 次数。
当你的团队准备把 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 (SM100) 的硬件级优化——如 FP8 KV Cache 和 FlashAttention 4——L40S 并不能直接套用。前缀复用是架构无关的通用机制，可以放心使用；但 Blackwell 专属项别指望。对 SGLang 的部署细节，可参考SGLang部署的实践指南。把时租换算成每百万 Token 成本：L40S 与 A100 的对照算法要判断L40S租用划不划算，不能只看时租单价，必须换算成每百万 Token 成本。公式：每百万 Token 成本 = 时租价格 ÷ 实测稳定吞吐（token/秒） × 1,000,000这里的“实测稳定吞吐”必须是同模型、同上下文长度、同并发数、同引擎版本下跑出来的数字，否则没有可比性。比如 A100 时租贵一些，但吞吐可能更高；L40S 时租便宜，但如果并发一高就吞吐暴跌，单位成本未必占优。关于价格，需要说明：目前公开报道只覆盖 H100（约 $2.00/小时）、H200（$2.50-$3.99/小时）和 B200 的按量区间，L40S 与 A100 的具体时租因平台和配置差异很大，本文不提供数字。你可以按上述公式，用自己平台的报价代入计算。L40S适合推理还是微调？三种该往上走的出局信号L40S适合推理还是微调？答案是：L40S 适合推理，尤其是单卡能装下的模型；但以下三种情况该直接考虑 A100/H100 级别：长上下文 + 高并发：如果上下文长度超过 32K 且并发要求超过 8，KV Cache 会迅速吃掉显存，L40S 会频繁 OOM。大模型训练或全参微调：训练需要频繁的梯度同步，PCIe 互联无法满足多卡通信需求，L40S 不适合。多卡张量并行：如果模型必须切分到多卡才能跑，且切分粒度很细，通信瓶颈会拖垮性能。出现这些信号时，建议往上选型，可以对比H100租用的成本与算力，重新做成本测算。用按量资源做一次跨卡型同负载实测：该记录哪些指标才有可比性与其信参数表，不如自己动手做对照实测。例如可以在 NexGPU 这类支持多型号 GPU 服务器、按量计费的云算力平台上，选取你实际可租到的中端卡与更高档卡各一台，跑完全相同的负载并记录下表指标：指标记录口径首 Token 延迟从发请求到收到第一个 token 的时间稳定输出吞吐稳定状态下每秒输出 token 数并发上限不违反延迟目标的最高并发数显存峰值运行时显存占用最高值缓存命中率前缀缓存命中的请求比例单位 Token 成本时租 ÷ 实测吞吐NexGPU 提供多种 GPU 服务器型号选择、按量使用和即开即用的模型模板，你可以先用按量方式在不同档位卡上跑同一模型、同一上下文、同一并发的对照，再决定长期占用哪一档，而不是靠参数表拍板。选型检查清单与四个常见误判最后把 L40S租用的判据收敛成一张清单，帮你快速决策：[ ] 模型权重 + KV Cache + 中间张量 + 引擎开销 ≤ 48GB × 0.8[ ] 单卡能装下模型，优先用多副本水平扩展而非张量并行[ ] 明确推理引擎版本，确认哪些优化是 Blackwell 专属、哪些通用[ ] 用同负载压测记录首 Token 延迟、稳定吞吐、显存峰值[ ] 用“时租 ÷ 实测吞吐”算出每百万 Token 成本再对比常见误判：只看显存容量不看带宽：带宽和互联同样关键。忽略引擎版本差异：不同版本的前缀缓存和 KV Cache 策略会影响有效容量。按参数表推算吞吐：实际吞吐必须实测。忽视多卡通信成本：PCIe 互联下张量并行扩展收益有限。常见问题L40S租用一小时多少钱？L40S租用的时租价格没有统一标准，不同平台按配置、机房和计费方式差异很大。公开报道只覆盖了 H100/H200/B200 的按量区间，L40S 需向平台询价。建议同时问清是否含出网流量费，并对比同类卡的报价。你可以用“时租 ÷ 实测吞吐”算出单位成本，再决定是否值得。L40S跑32B模型并发能到多少？没有固定答案，取决于上下文长度、量化精度和引擎优化。你可以按上文公式代入你模型的 config.json 参数自行计算。例如：假设 32B 模型为 64 层、KV head 数为 8、head_dim 为 128，FP16 下每元素 2 字节，则单 token KV 占用 = 2 × 64 × 8 × 128 × 2 = 256KB。若上下文 4K、并发 4，KV Cache 总量 = 256KB × 4096 × 4 = 4GB，余下显存足够支撑权重和中间张量，实际并发建议压测确认。L40S适合推理还是微调？L40S 更适合推理，尤其是短上下文、低并发的在线服务。微调需要频繁更新权重，对通信带宽和显存要求高，48GB 可能装不下梯度，多卡 PCIe 互联也会拖慢速度。如果你的微调任务较轻（如 LoRA），L40S 可以尝试，但全参微调建议直接上 A100/H100。L40S没有NVLink对多卡推理有影响吗？有影响，但取决于并行方式。张量并行对卡间带宽敏感，PCIe 互联会严重限制扩展收益；模型并行（按层切分）或数据并行（多副本）受影响较小。如果你的模型单卡装不下，优先考虑量化或换更大显存的卡，而不是用 L40S 做多卡切分。
多卡推理优化怎么做？加卡前先算通信税的6个判据
多卡推理优化的正确做法，是先按 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。KV Cache 从 FP16 切到 FP8，理论上每 token 缓存字节数减半，实际余量还要看实现与对齐开销，需以自己的负载实测为准。腾出的显存余量，优先应该用来扩大 batch 大小或上下文长度，以提升单卡吞吐；还是用来减少卡数、降低通信开销？这取决于你的负载特征：如果请求并发高、上下文长，扩大 batch 和上下文通常更划算；如果卡数多但通信已吃紧，减少卡数反而可能提升整体效率。但要注意，精度优化可能引入精度损失，需要根据模型对误差的敏感度权衡。另外，vLLM 版本升级后，FP8 KV Cache 的具体配置可参考 vLLM部署 的实际操作。判据五：Prefill/Decode 分离适合什么样的请求分布，不适合什么样的prefill decode 分离是什么意思？简单说，就是把 Prefill 和 Decode 阶段拆到不同的 GPU 实例上运行，各自独立扩缩容。这样 Prefill 实例可以专注吃算力，Decode 实例专注吃带宽，避免两类负载互相干扰。PD 分离的收益取决于请求分布：当请求上下文很长、共享前缀较多、Prefill 与 Decode 负载比例失衡时，分离能明显降低整体时延与通信开销。SGLang 2026 年在 Blackwell 上落地 NVFP4 PD 分离，并支持 FlashInfer 的 NSA 与 DSA 稀疏注意力算子，针对长上下文场景提升性能。但 PD 分离不适合所有场景：请求短、并发低、卡数少时，分离反而引入额外调度成本，是否启用需结合请求分布实测。判据六：把吞吐换算成每百万 Token 成本，再判断加卡值不值加卡的最终目的是降低单位产出成本，而不是单纯提升吞吐。决策时应该用“每百万 Token 产出成本”来对比：获取同负载下的吞吐（tokens/s）与总时租成本；计算每百万 Token 成本 = 单位时间成本 ÷ 单位时间吞吐 × 1,000,000。注意，对比不同代际卡型时，务必在同一精度下进行。某些宣传数据混淆了 FP4 与 FP8 精度下的吞吐倍率：同为 FP8 精度，B200 比 H200 提升约 1.5-1.8 倍；只有启用 Blackwell 专属的 Native FP4 量化，吞吐提升才接近 3 倍。所以不能把 FP4 与 FP8 的数据混为一谈。按同精度折算每百万 Token 成本时，Hopper 代际的 H200租用 仍常是对照基线。一份排查顺序：从利用率、通信占比到 batch 与上下文参数的调整次序8 卡推理吞吐上不去时，按下面的次序逐项排查，比乱调参数有效得多：先看各卡利用率是否均衡：是否存在某张卡跑满、其他卡闲置的情况，这通常指向负载不均或同步等待。再看通信占比与同步点：用 profiler 统计 NCCL 通信耗时，若通信占比过高，考虑降低 TP 或改用 PP/序列维切分。调整 batch、并发与上下文上限：在显存允许范围内增大 batch 或上下文，提升计算密度。最后才动并行切分与引擎版本：一次只改一个变量，避免相互干扰。卡间通信瓶颈怎么定位？最直接的方法是跑一段固定负载，对比不同 TP 配置下的吞吐与通信耗时。如果 TP=4 与 TP=8 的吞吐几乎持平，说明通信已饱和，继续增大 TP 没有意义。用按量多卡资源做一次同负载对照实测：记录哪些指标才有对比意义理论分析终究要落地。在决定加卡之前，建议用按量计费的多卡资源做一轮同负载对照实测：固定模型、请求分布与并发数，分别跑不同 TP/PP 组合、是否启用 PD 分离，记录以下指标：TTFT（首 token 延迟）各卡利用率与均衡度通信耗时占比每百万 Token 成本这类对照实验非常适合在按量计费的云 GPU 上进行：同模型同请求跑一轮，跑完即释放，比长期锁定 8 卡节点再试错的成本低得多。像 NexGPU 这类平台提供多种 GPU 型号选择、按量使用与预制模型模板，正好用于快速起停的对照实验。四个常见误判：卡数越多越快、利用率高就等于跑满、只看单卡显存、把 FP4 与 FP8 数据混谈卡数越多越快：通信开销随卡数增长，存在拐点。利用率高就等于跑满：可能计算在等通信，利用率虚高。只看单卡显存：忽略 KV Cache 与通信需求，导致跨机通信税压过收益。把 FP4 与 FP8 数据混谈：代际倍率必须同精度比较。加卡前，先按排查顺序跑一轮同负载对照，再折算每百万 Token 成本，才不会凭感觉做决定。NexGPU 提供的按量使用与预制模型模板，正好适合这类快速起停的对照实验，跑完即释放，成本可控。常见问题多卡推理为什么比单卡还慢？因为卡间通信开销抵消了并行收益。尤其是 Decode 阶段对带宽敏感，TP 过大或跨节点时，每次生成 token 都要等待 All-Reduce 完成，导致延迟不降反升。检查通信占比，适度降低 TP，或改用流水线并行。tensor parallel size 设多少合适？没有固定值，取决于卡间互联与负载。单机内高速互联可尝试 TP=8，跨节点建议不超过 TP=4，并用 PP 或序列维切分补充。实测对比不同 TP 下的吞吐，选择通信占比低且吞吐最高的配置。prefill decode 分离是什么意思？把 Prefill 和 Decode 拆到不同的 GPU 实例上运行，各自独立扩缩容。适合长上下文、共享前缀多的场景，可降低整体时延与通信开销；短请求、低并发时不建议，反而增加调度成本。8卡推理吞吐上不去，先查什么？先查各卡利用率是否均衡，再看通信耗时占比。若某卡利用率低而通信高，多半是 TP 过大或跨机通信。然后调整 batch 与上下文参数，最后再动并行切分与引擎版本，一次只改一个变量。卡间通信瓶颈怎么定位？用 profiler 统计 NCCL 通信耗时，对比不同 TP 下的吞吐与通信占比。若 TP 增大但吞吐不再提升，说明通信已饱和。同时关注 KV Cache 是否溢出导致跨机取数，那是隐形的通信税。
先别急着看卡型参数表，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.27.0 官方 Release Notes（2026 年 8 月），该版本针对 DeepSeek-V4 引入了序列并行与路由优化，通过跳过空的 c128 启动节省了 448 MiB 显存，并将端到端首字延迟（E2E TTFT）降低 3.4%。同时，该版本在 Blackwell SM100 架构上深化了 FlashAttention 4 FP8 KV Cache 与 headdim-256 支持。这些优化意味着：同样的模型和硬件，升级引擎版本后显存占用可能降低。但注意，448 MiB 是 DeepSeek-V4 特定模型、特定场景下的结果，不能外推为通用节省比例。所以当你评估显存时，必须明确自己所使用的引擎版本，并在理论值基础上多留一些余量以应对版本差异。把显存区间映射到卡型档位：什么时候单卡够用，什么时候必须上多卡算出显存区间后，再对照卡型。常见档位有 24GB、48GB、80GB 及以上。触发换更大显存或多卡并行的信号有：长上下文（如 32K 以上）、高并发（同时几十路请求）、KV Cache 超过权重量级等。24GB 档位的典型单卡是 RTX 4090，可参考 RTX 4090云服务器 的规格说明，适合 7B 级模型在中短上下文、低并发下做验证与轻量线上。若并发提升到 16，KV Cache 会翻倍，24GB 铁定 OOM，此时解法是降精度到 FP8/INT4、缩短上下文，或上 48GB 及以上档位/多卡并行。GPU显存怎么选的最后一步，是把推算区间对齐到最接近且高于上沿的显存档位，而不是卡着理论值买。用按量资源实测显存峰值：观测指标、压测步骤与检查清单理论推算完成后，强烈建议用真实负载验证。步骤如下：选定目标上下文长度与并发数。在按量计费的 GPU 实例上部署模型，跑一轮推理。观察显存峰值、波动以及是否出现 CUDA out of memory。记录 OOM 边界，即显存不够时的上下文或并发阈值。NexGPU 提供多档 GPU 型号与按量计费，你可以先用小规格跑通流程，再逐步增加负载实测显存峰值，避免一次性买高或买低。这种验证成本低，且能拿到真实数据。检查清单包括：是否出现 OOM、显存利用率是否超过 90%、延迟是否满足要求。五个常见误判：只算权重、忽略并发、把理论值当上限误判一：只算权重，忽略 KV Cache。比如 7B 模型 FP16 权重 14GB，以为 16GB 卡够用，结果跑长上下文直接 OOM。误判二：按单请求估容量，忽略并发。实际生产环境并发高，KV Cache 成倍增长。误判三：不留碎片余量。直接用标称显存，忽略框架预留的 10%。误判四：忽略引擎版本差异。升级 vLLM 后显存占用可能下降，但旧版本可能更耗显存，选型时必须绑定版本。误判五：精度切换只改权重，不改缓存。FP16 换 FP8 时，KV Cache 同样要改，否则省不下预期显存。先按本文四步法算出区间，再在 NexGPU 的按量实例上用预制模型/应用模板快速起环境跑一轮压测，确认档位后再决定长期占用。常见问题7B模型需要多少显存？以 7B 模型、FP16、上下文 8K、并发 4 为例（假设 32 层、8 个 KV 头、头维度 128，GQA 结构），权重 14GB，KV Cache 按公式单 Token 约 128KB，8K 上下文约 1GB，并发 4 约 4GB，加上中间开销约 3GB，总需求约 21GB。加余量后需求落在 24GB~28GB，24GB 卡处于临界（需压低并发或上下文），稳定线上建议 32GB 及以上。若采用 32 头 MHA 结构，KV Cache 约为 GQA 的 4 倍（约 16GB），总需求约 33GB，建议 48GB 起。KV Cache占多少显存怎么算？以下为按公式代入的示例推算，非实测数据。按公式 2×层数×KV头数×头维度×每参数字节数，再乘以序列长度和并发数。例如，32 层、8 个 KV 头（GQA）、头维度 128、FP16，单 Token 约 128KB，8K 上下文约 1GB，并发 4 则约 4GB。FP8 可减半。若用 32 头 MHA 结构，则单 Token 约 0.5MB，约为 GQA(8 KV 头) 的 4 倍，相应增大。FP16和FP8显存差多少？权重部分，FP16 每参数 2 字节，FP8 每参数 1 字节，差一倍。KV Cache 同样差一倍。例如 7B 模型 FP16 权重 14GB，FP8 只要 7GB，KV Cache 也从 4GB 降到约 2GB（8K上下文，并发4，按 32 层 / 8 KV 头 / 头维度 128 估算）。显存够用还是要留多少余量？建议至少 10%~20% 的余量给碎片和运行时。vLLM 默认用 90% 显存。若负载波动大，余量可加到 20%~30%。宁多勿少，避免频繁 OOM 影响服务。CUDA out of memory 怎么解决？先降低并发或上下文长度，再考虑降低 KV Cache 精度（如 FP8），或减少批处理大小。也可以升级引擎版本（如 vLLM v0.27.0）利用优化，或换更大显存卡。使用像 DeepSeek部署 中推荐的按量测试，逐步定位瓶颈。
vLLM v0.26.0 发布后，SGLang部署还值不值得做？共享前缀吞吐领先 29% 的选型与落地指南
一、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，下面是一套可复用的 SGLang部署教程式顺序。核心方法论是“先跑通再调优、每次只改一个变量”，避免把参数调成一团乱麻。环境与权重准备：拉取官方镜像，按目标模型准备权重与 tokenizer，确认精度与量化格式（例如 NVFP4 类新格式的支持差异以官方文档当前版本为准）。单卡跑通：先用单张 GPU 启动，跑一个最简单的请求，确认服务正常响应，此时先不追求性能。启动 RadixAttention 前缀缓存：确认是否默认开启，记录缓存命中率是否随请求增多而上升；缓存池大小按显存余量分配（具体参数以官方文档为准，示例值如 --max-prefill-tokens 等仅示意）。多卡与并行扩展：单卡稳定后，再考虑张量并行或多卡部署，一次只加一个维度，避免同时改并行方式和缓存参数。并发与批处理收敛：逐步提高并发，观察吞吐、TTFT、TPOT 与显存峰值，找到拐点；每轮只调整一个并发或批大小参数。结构化输出接入：如果业务需要 JSON 等受限解码，接入 SGLang 的结构化输出能力，并做端到端测试。每一步都要记录指标，这样可以回溯是哪一步带来收益或回退。六、迁移成本评估：接口兼容、量化权重格式与可观测性从 vLLM 迁到 SGLang（或反向），摩擦点往往不在性能而在工程细节。首先，OpenAI 兼容接口层通常改动不大，但你自己的封装、错误处理和流式逻辑需要回归测试。其次，量化权重格式与精度方案能否复用是关键：NVFP4 这类新格式在不同引擎上的支持不一致，需要以官方文档当前版本为准，确认你的权重能否直接加载，否则要转换或重新量化，这是一笔不小的成本。最后是可观测性：SGLang 与 vLLM 暴露的指标项和标签不尽相同，原本的监控告警、日志采集、成本核算管道可能要重建。所以迁移决策要把这些一次性成本与预期吞吐收益放在同一时间窗内比较：如果收益只有 5%，但迁移要花两周，那可能不值得；如果收益 29% 且负载匹配，那就值得认真做。七、在按量 GPU 上做一次同模型同负载的双引擎对照实测公开榜单的数字只能作为参考，不能直接照搬。要得到属于你的结论，建议在按量 GPU 上跑一次同模型、同负载、同精度的双引擎对照。具体流程如下：固定模型与权重精度：两个引擎使用同一份权重，精度一致，排除变量。用线上请求回放：从日志中采样一段真实请求，包含系统模板、用户 prompt、上下文长度分布，统计前缀重复率。统一并发梯度：在同一套并发梯度（比如 8/16/32/64）下分别跑两套引擎，保证压力一致。记录关键指标：吞吐（tokens/s）、TTFT、TPOT、显存峰值、前缀缓存命中率，每项至少三次取中位数。按单位成本折算：把吞吐除以按量 GPU 的每小时租金，得到单位 token 成本，而不是只看峰值吞吐。如果你的前缀重复率很高，可能会复现接近 29% 的差距；如果重复率低，差距可能缩小甚至反转。若本地没有合适卡型，可用 NexGPU 这类按量 GPU 平台，它提供按量租用与预制模板，可以在同一模型、同一负载下把两套引擎各跑一遍，按实测结果决定长期配置。这只是一个落地手段，不牵扯平台与框架的官方关系，选择权在你。八、SGLang部署决策检查清单与四个常见误判最后，做决策前请逐项打勾：[ ] 已量化自己的前缀重复率与输入输出长度比，而不是凭感觉。[ ] 已确认显存余量，是否吃紧到需要量化或 KV 卸载。[ ] 已确认是否有结构化输出需求及其在两个引擎上的支持。[ ] 已准备迁移的回滚预案，能在一小时内切回原引擎。[ ] 已确认新旧引擎的可观测性指标覆盖是否满足告警要求。同时，避开四个常见误判：把共享前缀场景的 29% 当作通用增益——务必确认自己的负载是否属于高前缀重复类。认为新版本发布即意味着旧选型作废——vLLM v0.26.0 的新特性解决的是显存与单请求路径问题，不影响 SGLang 在前缀复用上的优势。忽略 KV 卸载带来的延迟代价——卸载对象存储能腾显存，但延迟会变差，要实测尾延迟。只看吞吐不看单位 Token 成本——算上按量 GPU 租金与总时延，才是真实的生产力。引擎是工具，不是信仰。用一周线上日志统计自己的前缀重复率和输入输出比，然后在按量 GPU 上做一次对照实测，用数据拍板，而不是被版本号和新特性带着走。
DeepSeek部署选型：从精度、显存到卡型的三段式推算指南
一、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并非无损压缩，它们会在数值精度上有所取舍，影响输出质量，但具体损失程度无法一概而论。因此，你需要一套自己的验证流程：固定一组有代表性的prompt，覆盖代码、推理、长文本等场景。对比量化前后模型在长上下文和推理链任务上的输出。监控显存水位和并发上限，观察是否出现OOM或性能下降。这样你就能在吞吐、延迟和输出质量之间找到适合业务的平衡点。不要轻信“量化后完全无损”的说法，一切以实际测试为准。六、在NexGPU上用按量资源做一次显存与吞吐验证纸上谈兵不如实战验证。NexGPU作为GPU云算力平台，提供多种GPU服务器型号、按量使用和即开即用的体验，非常适合先用小时级资源跑通验证。操作建议：选择一档目标GPU型号（如RTX 4090或A100），按量启动vLLM/SGLang服务。加载量化后的模型，开启FP8 KV Cache和Prefix Caching。压测目标上下文长度和并发数，观察显存水位和吞吐。根据数据决定长期使用单卡还是多卡节点，避免一次性锁定错误规格。跑完这一轮，你就有了自己的GPU云服务器配置依据，而不是照搬别人的推荐清单。七、DeepSeek部署选型检查清单与常见踩坑最后，给你一份可执行的检查清单：确认权重精度和量化格式（FP8、Q4_K_M等），使用官方或可信来源的模型文件。按显存区间上界预留，如32B量化至少预留24GB，70B至少45GB。单独核算KV Cache，根据上下文长度和并发计算，并考虑压缩手段。为显存碎片与突发并发单独留出余量，余量大小由压测得到的显存水位峰值决定，而不是取固定百分比。先按小时级按量验证，再锁定长期规格。常见错误包括：只按权重估显存，忽略长上下文和并发；盲目上最高端卡，导致浪费；量化后不验证质量，直接上线。避开这些坑，你的DeepSeek部署之路会顺畅很多。记住，选型的核心是匹配实际需求，用数据驱动决策。