NexGPU-算力租赁,GPU服务器,GPU云算力,AI服务器租用-新闻博客 - 张量并行
type: channel
link: https://www.nexgpu.net/blog/index.php/tag/%E5%BC%A0%E9%87%8F%E5%B9%B6%E8%A1%8C/
items: Qwen2.5-72B多卡量化部署教程：4步完成
items: vLLM多卡张量并行配置指南：TP设多少与5步排查
items: 多卡推理优化怎么做？加卡前先算通信税的6个判据
items: H200租用价格下探到 $3.82/小时后，8×H200 单节点与 16 卡 H100 跨节点哪种更划算？

Qwen2.5-72B多卡量化部署教程：4步完成
type: item
date: 2026-08-20T10:47:10+08:00
description: Qwen2.5-72B多卡量化部署教程可以压缩成四步：按卡型倒推量化档位 → 定 tensor parallel size → 写启动参数 → 用自建对照集验证。开源主力模型在企业端加速落地，显存分账成为部署核心矛盾。动手前先打开终端执行 nvidia-smi，记下卡数、单卡显存与卡间互联方式。FP16 精度下 72B 权重加运行时开销大约需要 140GB+ 显存，通常要双卡 80GB（如 A100/H100）配合 TP=2 才装得下；而改用 AWQ-INT4 或 FP8 量化后，整体占用可降到 40GB–48GB，这让双卡 24GB/32GB 或单卡 80GB 成为可行起点。开始前的自查：你手上的卡决定了能选哪一档开始前先回答三个问题：几张卡？单卡多少显存？卡间是否同型号、同 PCIe/NVLink 互联？双卡 24GB（合计 48GB）：只能跑量化档，且必须 TP=2。双卡 32GB（合计 64GB）：量化档下余量较宽裕。单卡 80GB（如 A100/H100）：量化档可跑 TP=1；若坚持 FP16 则仍不够。卡型不一致会导致 TP 切分失效，vLLM 启动时直接报错。显存对照表：量化档位与卡型的匹配下表是量化档位、显存量级与适配卡型的对应关系，数字用于选型推算，不是任何具体卡上的实测峰值，请以你本地实际复测为准。量级数字只在表中出现一次，之后不再重复。量化档位显存量级（权重+运行）适配卡型TP 建议FP16约 140GB+双卡 80GB（A100/H100）TP=2AWQ-INT4 或 FP8约 40–48GB双卡 24GB/32GB，或单卡 80GB双卡必须 TP=2；单卡可 TP=1更细的选型核算可参考 GPU显存怎么选。第一步：选量化格式——AWQ-INT4 与 FP8 的取舍逻辑量化格式没有绝对优劣，按四个判据选：显存余量：INT4 通常压得更狠，给 KV Cache 留出的空间更大；FP8 精度保留更好，但占用略高。硬件支持：FP8 依赖 GPU 与推理引擎两端的低精度支持，同代卡在不同引擎上的可用性差异较大，以本地引擎的 help 输出与一次最小启动试跑确认，不要按架构名推断。权重现成性：社区是否已有对应格式的量化权重？用现成的省去自行量化时间，但必须确认格式与引擎匹配。任务敏感度：代码生成、数学推理等对精度敏感的任务，建议先试 FP8；普通对话可用 INT4。两条回退路线：若量化后质量不达标，先换回 FP8 或混合精度；若显存不足，再降并发或序列长度。第二步：定 TP 切分——量化后能不能把 tensor parallel size 从 2 降回 1TP 设置有两个硬性规则：必须等于实际可见卡数，且必须能整除注意力头数（例如 72B 模型头数通常为 64，因此 TP 可取 1、2、4、8、16）。单卡 80GB 量化后占用 40–48GB，可尝试 TP=1，省去卡间通信开销，提升小 batch 下的响应速度。双卡 24/32GB 必须 TP=2，且两卡必须同型号、同互联，否则性能下降甚至报错。长上下文（如 32K tokens）或高并发时，KV Cache 可能顶爆单卡，此时即便单卡 80GB 也可能被迫升 TP=2。判断依据是：先估算峰值 KV Cache 大小（随序列长度 × 并发数线性增长），加上权重占用，不超过单卡显存的 90% 才可考虑 TP=1。更完整的配置可参考 vLLM多卡张量并行配置指南。第三步：写启动参数——显存利用率、最大序列长度与 KV Cache 的调整次序Qwen2.5-72B多卡量化部署教程里最容易反复返工的就是这一步。启动参数不是一次性写对的，要按顺序调整：固定模型路径与量化格式（如 --quantization awq 或 --quantization fp8）。设 TP：--tensor-parallel-size 2。设显存利用率上限：例如 --gpu-memory-utilization 0.9，先留 10% 余量。压最大序列长度与并发数：--max-model-len 和 --max-num-seqs，先给保守值（如 4096 context、4 并发），逐步上调。这几个参数互相挤占同一块显存，一次只改一个，改完重启验证。具体参数名以你本地 vLLM 的 --help 输出为准，不同版本可能有差异。第四步：验证——自建对照集看输出退化，同请求分布看吞吐量化后不能假设能力与 FP16 无差异，必须自建对照集验证。准备 30–50 条提示词，覆盖你真实业务场景（如代码、摘要、客服问答）。跑两轮：量化版一轮，FP16 版（或用在线基准模型）一轮，参数一致。人工 + 规则比对：看关键字段、语法、逻辑是否退化。测吞吐：用相同的请求分布压测，记录吞吐、TTFT、显存峰值。若退…

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…

多卡推理优化怎么做？加卡前先算通信税的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…

H200租用价格下探到 $3.82/小时后，8×H200 单节点与 16 卡 H100 跨节点哪种更划算？
type: item
date: 2026-08-05T10:46:17+08:00
description: 2026 年 8 月的按量 GPU 市场出现了一个值得注意的变化：搭载 141GB HBM3e 的 H200 租用价格下探到 $3.82 - $4.50/GPU-小时（例如 Jarvislabs 报 $3.99/hr、RunPod 报 $4.39/hr）[fact_1]。这一价格水平让「H200租用」从单纯的高端算力选项，变成了与 H100 正面竞争的性价比选择。而比单价更关键的影响在于，H200 的显存容量让部署拓扑发生了根本改变——原本需要跨节点才能跑起来的 400B 级开源模型，现在可以收拢进单节点。那么问题来了：8×H200 单节点与 16 卡 H100 跨节点，到底哪种更划算？ 本文将围绕这个决策展开。一、H200租用价格多少钱一小时：2026年8月行情快照先回答最直接的问题：H200租用价格多少钱一小时？ 根据 2026 年 7-8 月的按量计费监测，H200 的单价区间为 $3.82 - $4.50/GPU-小时，具体报价如 Jarvislabs $3.99/hr、RunPod $4.39/hr、Nebius $4.50/hr [fact_1]。需要注意的是，这是按量计费口径，会随时段、地域和供给量波动。同时，H100 SXM 的租用价格已降至 $1.80 - $2.50/GPU-小时（中位价约 $2.27/hr），而 Blackwell B200 则维持在 **$5.50 - $7.13/GPU-小时** 的溢价区间 [fact_4]。这三代卡的价格阶梯，构成了今天决策的基础。然而，单价只是第一层信息。对于需要部署百B级模型的团队，真正该问的是：同样的显存需求，用 H200 单节点和 H100 跨节点，总账单相差多少？ 这需要先理解 H200 的显存优势如何改变拓扑。二、141GB HBM3e 改变的不是纸面速度，而是部署拓扑H200 与 H100 的最大差异不在于 TFLOPS，而在于单卡显存：H200 每卡配备 141GB HBM3e，而 H100 为 80GB。这意味着 8×H200 单节点可以提供高达 1,128GB 的聚合显存，足以将 400B 级开源模型及其长上下文 KV Cache 完整载入单节点 [fact_2]。而在 H100 架构下，同样需求需要跨 2 个 8-GPU 节点（共 16 卡）进行张量并行（Tensor Parallelism）和流水线并行（Pipeline Parallelism）组合部署 [fact_2]。这一差距对部署拓扑的影响是决定性的：单节点意味着 GPU 之间通过 NVSwitch/NVLink 全互连提供 900GB/s 双向带宽，而跨节点网络带宽远低于 NVLink，通信开销显著增加，直接影响 Decode 阶段延迟与并发稳定性 [fact_3]。三、把显存需求换算成节点数：400B 级模型的两种凑法要判断哪种方案划算，先要算出自己的模型需要多少显存。这里给出一个可复用的推算方法：权重显存：参数量 × 精度字节数。例如，400B 模型用 FP16（2 字节）需要约 800GB；用 INT8（1 字节）需要约 400GB。KV Cache：随并发数和上下文长度增长。例如，并发 32、上下文 4096、层数 80、头数 64 时，KV Cache 可能达到数十 GB。运行时开销：一般预留 10-20% 余量。将三者相加，得到所需显存池。以 400B 级模型（FP16）为例，总需求约 900-1000GB。此时有两种凑法：8×H200 单节点：1,128GB 聚合显存，单节点即可承载。16×H100 跨节点：16×80GB = 1,280GB 显存，但必须跨节点。这里要澄清一点：H200 的 141GB 显存能跑多大模型并非固定值，取决于量化精度和上下文长度。上述为通用估算，实际请代入自己的参数。四、单价 vs 总成本：跨节点方案被忽略的通信税与稳定性代价现在进行成本对比。按 2026 年 8 月按量计费区间 fact_1：方案卡数单卡单价区间总小时成本区间8×H200 单节点8$3.82-4.50/hr$30.56-36.00/hr16×H100 跨节点16$1.80-2.50/hr$28.80-40.00/hr可以看出，16×H100 的总小时成本下限更低，但上限反而超过 H200。当中位价计算时，16×H100 约为 $36.32/hr，与 8×H200 的 $33.28/hr 相差无几。然而，每小时账单之外还有隐藏成本：跨节点通信税。在 16×H100 跨节点部署中，张量并行（Tensor Parallelism）需要跨网络传输，其带宽远低于 NVLink [fact_3]。这会导致 Decode 阶段延迟显著增加，并降低并发稳定性 [fact_3]。如果您的应…