NexGPU-算力租赁,GPU服务器,GPU云算力,AI服务器租用-新闻博客 - 显存规划
type: channel
link: https://nexgpu.net/blog/index.php/tag/%E6%98%BE%E5%AD%98%E8%A7%84%E5%88%92/
items: Qwen2.5-72B多卡量化部署教程：4步完成
items: Qwen部署要多少显存？72B/32B 双卡分账指南
items: H100租用多少钱一小时？5个该不该租的自查条件
items: SGLang 新版本 DCP 与前缀缓存落地后，GPU集群怎么规划：节点数、拓扑与显存账
items: B300 288GB上线后，B200与H100算力性价比分析是否被改写？单位Token成本重算指南

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、显存峰值。若退…

Qwen部署要多少显存？72B/32B 双卡分账指南
type: item
date: 2026-08-15T10:52:15+08:00
description: Qwen部署要多少显存？结论先给：Qwen 2.5 72B 在 FP16 下仅权重就约 144GB~146GB，需双卡 80GB（TP=2）；INT4 量化后约 38GB~40GB，可落到单卡 80GB/96GB 或双卡 32GB；32B FP16 权重约 63.5GB~64GB，需 80GB 级单卡或双卡，INT4 约 18GB。2026 年私有化部署选型时，AI 开发者与算法工程师最常卡在“显存看着够，实际跑不动”的环节。原因很简单：显存由权重、KV Cache、激活张量与引擎预留四笔账共同构成，只看权重数字极易误判。动手前先回答三个问题，否则显存数字没有意义：模型档位：72B 还是 32B？两者权重差距近一倍，直接影响卡型选择。上下文长度：Qwen 2.5 原生支持 128K（131,072 tokens），但上下文越长，KV Cache 占用越大，必须提前限定。并发规模：同时处理的请求数越多，KV Cache 总量越大，显存需求会成倍放大。脱离后两者谈显存，等于只算了一半账。第一笔账：权重占用，从 FP16 到 INT4 的换算表权重是显存的大头，也是最容易查到的基准。下表给出 Qwen 2.5 32B 与 72B 在 FP16、FP8、INT4 下的权重占用区间，以及对应的显存缺口判断。模型FP16/BF16FP8INT4（AWQ）能否进单卡 80GBQwen 2.5 32B约 63.5~64GB约 32GB约 18GB80GB 可行（FP16 勉强，量化更稳）Qwen 2.5 72B约 144~146GB未提供约 38~40GB单卡不可行（FP16），INT4 可单卡 80GB/96GB换算规律很简单：FP16 每 10 亿参数约占 2GB，FP8 减半，INT4 再减半（约 0.5GB/10 亿参数）。该换算为通用经验值，用于粗估，最终以实际加载后的显存读数为准。但注意，32B FP16 需要约 64GB，单张 24GB 或 32GB 消费卡绝对装不下；而 72B FP16 高达约 145GB，单张 80GB 也无法直接加载，需要双卡 80GB 并行，这正是后文 TP=2 的由来。若采用 INT4 量化，72B 可压缩到约 38~40GB，32B 仅约 18GB，单卡 24GB（如 RTX 4090）才有可能跑。第二笔账：KV Cache 为什么是上下文与并发的乘法如果说权重是固定支出，KV Cache 就是随上下文长度线性增长、再与并发数相乘放大的浮动支出。Qwen 2.5 原生支持 128K 上下文，但请记住一个数字：单请求在 128K 长度下的 KV Cache 即可超过 40GB。这意味着什么？假设你部署 32B INT4（权重约 18GB），单卡 24GB 只余 6GB 给 KV Cache，连 8K~16K 上下文都撑不住。并发数对显存的影响是乘法关系：N 个并发请求，KV Cache 总量约为单个请求的 N 倍。如果你设定了 32K 上下文且并发 8，KV Cache 就可能超过 80GB，直接顶爆双卡 80GB 的剩余空间。按单请求超 40GB 线性外推，并发 4 时估算需 160GB 以上（该数字为按线性关系推算的估算值，实际随模型 GQA 配置与量化方式浮动，需实测确认）。这就是为什么很多团队在长文本和并发上来后频繁触发 CUDA out of memory——不是权重问题，而是 KV Cache 这笔浮动账没算清。第三、四笔账：激活张量与引擎常驻，为什么要留 30%-50% 余量除了权重和 KV Cache，vLLM 运行时还会占用显存用于激活张量和引擎常驻开销（CUDA context、内存池等）。可用 KV Cache = 总显存 × 利用率 - 权重 - 常驻开销，因此生产部署建议预留 30%-50% 余量，不要卡着权重极限去算。同时注意，vLLM 默认按显存利用率预分配显存，即便权重只在 38GB，剩余空间不足时，上下文或并发上升同样会触发 OOM。为什么双卡 80GB（TP=2）是 72B 的生产基准形态把四笔账合起来看，72B FP16 权重约 145GB，双卡 A100/H100 80GB 合计 160GB，减去权重后还剩约 15GB 给 KV Cache 和激活。在限制上下文（如 8K）和低并发（如 4）下勉强能跑，但若要支持较长上下文或更高并发，就需要进一步量化或者扩充到 4 卡。这也解释了为什么 --tensor-parallel-size 2 是 72B Qwen部署的默认起点：单卡 80GB 物理上无法加载，双卡正好把权重分到两张卡上，显存利用率最高。对于 32B FP16（约 64GB），双卡 80GB 或单卡 80GB/96GB 都可行，但双卡 TP=2 能提供更…

H100租用多少钱一小时？5个该不该租的自查条件
type: item
date: 2026-08-11T10:54:37+08:00
description: H100租用按量价格已下探到 $1.99–$2.99/GPU-小时，中位数 $2.29–$3.12；该不该租，取决于你的负载是否真的吃满 80GB 显存。训练脚本刚跑起来不到十分钟，显存就逼近 80GB，你盯着监控面板开始犹豫。2026 年 8 月的价格横评显示，B200 均价还在 $7.11/GPU-小时，H200 则在 $2.60–$4.50 之间，H100 在中间提供了一个相当有吸引力的性价比锚点。下文先给出一张价格快照，再给你 5 条可自查的判据，最后附上同负载对照实测的清单（注：以下价格与显存判断均基于 2026 年 3–8 月公开监测数据，实际会随区域与合约浮动）。价格快照：H100、H200、B200 的价差摆在一起看下表把 H100租用与相邻卡型的按量价格并排列出。需要说明，这里的价格是区间而非某一家的固定报价，且传统超大规模云厂商 8 卡整机的折算单价通常更高。卡型按量均价（$/GPU-小时）Spot/预留最低说明H100$1.99–$2.99监测数据未单列专业 GPU 云平台主力报价区间H200$2.60–$4.50未单列显存与带宽更高，价格上浮B200$7.11$3.35–$3.60均价较高，Spot 价有吸引力超大规模云厂商的整机折算单价（$3.00–$8.00+）明显高于专业 GPU 云，差异来自合约形态、区域与是否包含存储网络等附加服务。价格区间来自 GetDeploying 跨 26 家云厂商的 B200/H100 价格索引（2026-08）与 GMI Cloud 的 H100 租买成本分析（2026-04），监测口径为 2026 年 3–8 月。H100 spot 实例与预留模式在部分平台可进一步压低单价，但需要能接受中断与重排队。判据一：80GB 显存装不装得下——权重、KV Cache 与中间张量的分账法显存占用不是只看权重大小，要按三段分账：权重×精度字节 + KV Cache + 激活与碎片余量。以 70B 模型为例，使用 4-bit AWQ 量化推理或 QLoRA 微调，显存需求约 35–73GB，可以落在单卡 H100 的 80GB 内；但若是 FP16 全参微调，70B 模型需要超过 1TB 显存，就得 8×H100 或多节点。你可以这样粗算：权重显存 = 参数量 × 每参数字节（FP16 为 2 字节，INT4 为 0.5 字节），再加上输入序列的 KV Cache，最后留出 15–20% 余量。那么微调 7B 模型需要租 H100 吗？FP16 下 7B 权重仅约 14GB，中端卡通常就够，除非你同时跑高并发推理或超长上下文。判据二：上下文长度与并发数，决定你先撞显存墙还是带宽墙KV Cache 会随上下文长度和并发数线性增长，直接压缩可用的 batch 大小。你可以先设定目标并发数，反推可支持的上下文长度：先算出 KV Cache 每 token 占用，乘以上下文与并发，看剩余显存是否够放权重。长文本场景下，吞吐瓶颈往往从显存容量转向带宽，信号是 batch 上不去了但显存还没满——这时候加并发，延迟会快速恶化。H100 的 80GB 在 128K 上下文下可能只够支撑较小并发，具体取决于模型与优化程度。判据三：持续满载还是断续脉冲——按量与长期占用的分界点H100租用的按量计费适合低频或脉冲式负载，但如果你每月有效满载小时数超过 400 小时（示意阈值，按自身单价与包月折扣重算），长期包月或预留更划算。Spot 实例和按量哪个便宜？答案是 Spot，但代价是随时可能被回收。另外注意空转计费：实例开起来但没跑任务也会计费，关掉或自动休眠可省隐性成本。判据四：是否依赖 Blackwell 专属算子路径，以及怎么核实如果你的代码或推理框架用到了 B200 上的专属算子（如特定精度或并行模式），在 H100 上可能回退到通用路径，性能打折。核实方法很直接：查推理框架的 kernel/后端支持矩阵，看编译目标算力版本；再验证量化格式（如 AWQ）在 Hopper 上的可用性与回退路径，必要时查阅 vLLM 和 SGLang 等框架官方文档或 GitHub 上的算子支持列表。多数主流部署路径在 H100 上仍可用，但个别新算子未必有优化。判据五：单价不等于成本——把 $/小时换算成每百万 Token 成本比价不能只看小时单价，要看单位产出成本。公式很简单：每百万 Token 成本 = 小时单价 ÷ 实测吞吐 tokens/s ÷ 3600 × 1,000,000务必使用自己的实测吞吐，而非官方标称 TFLOPS。比如你测出 H100 在某负载下吞吐为 3000 tokens/s（示意值），按 $2.50/小时算，每百万 Token 成本约为 **$0.23**；而若 H200 在同一负…

SGLang 新版本 DCP 与前缀缓存落地后，GPU集群怎么规划：节点数、拓扑与显存账
type: item
date: 2026-08-10T10:48:35+08:00
description: SGLang 在 2026 年 7 月底的官方 Release 中，提供了对 Kimi K3 2.8T LatentMoE 模型与 MiniMax-H3 音视频模型的 Day-0 原生推理支持，并引入了 DCP（Decode Context Parallelism）、DSpark 投机解码、KDA-aware 前缀缓存与 FlashInfer 优化，且已在 GB300 与 B200 硬件集群上验证落地（以上信息来自 SGLang 官方 Release）。对大多数负责大模型推理上线的工程师来说，真正值得关注的不是“模型又能跑新架构了”，而是这些变化正在重新定义 GPU集群 的规划参数：节点数怎么定、拓扑怎么选、显存账怎么算。本文将从这三个维度，把这次更新翻译成可落地的集群决策依据。一、SGLang 这次更新，改的其实是 GPU集群的哪一层SGLang 最新 Release 的 Day-0 支持通常被视为“兼容性更新”，但这次涉及的两类模型——万亿参数级 LatentMoE 与音视频一体化模型——恰恰是当前生产推理中最吃集群资源的负载。Kimi K3 2.8T 这样的规模意味着模型权重本身就远超单卡显存，而音视频一体化模型在通用意义上更易产生长序列与较大中间激活（此为一般性推断，官方 Release 未给出该模型的序列长度或激活规模说明）。官方部署文档在介绍分布式并行与集群部署时，明确了拓扑配置原则：单节点内优先利用 NVLink 高带宽实施张量并行（TP），跨节点扩展时则通过 DCP 将 Decoding 阶段的 KV Cache 沿 Sequence 维度切分，或结合流水线并行（PP）与 RadixAttention 前缀缓存，以消除跨节点 AllReduce 通信冗余并降低显存占用与首字延迟（TTFT）。换句话说，这次更新不是“模型能不能跑”的问题，而是“集群该怎么切”的问题。它直接影响你在规划 GPU集群 时的三个决策点：节点内用什么样的并行策略、跨节点时用什么通信模式、以及显存预算该如何分配。二、把 DCP 翻译成集群语言：解码阶段沿 Sequence 切 KV，省掉的是哪一段跨节点通信DCP 的核心机制是将 Decoding 阶段的 KV Cache 沿 Sequence 维度切分。传统上，当模型大到需要跨节点部署时，张量并行（TP）会在每个 Transformer 层内把权重和激活切到多张卡上，这会导致每步计算都需要跨节点同步中间激活结果，产生高频的 AllReduce 通信。在节点间带宽远低于 NVLink 的背景下，这种通信往往成为吞吐瓶颈。官方部署文档给出的机制是：在 Decoding 阶段沿 Sequence 维度切分 KV Cache，用以消除跨节点 AllReduce 通信冗余。按此机制推断，其通信模式与按张量维度切分存在本质差别，但官方未给出通信次数或数据量的量化说明。注意：官方文档并未提供 DCP 的加速比或 TTFT 数值，我们不应臆测具体收益。但机制上的差异是明确的——按序列切分与按张量切分在通信模式上有本质区别，前者更适配跨节点集群的低带宽环境。可执行的判断：如果你当前模型需要跨节点，且主要瓶颈是跨节点通信等待，那么 DCP 值得作为首要考虑的并行方案；但收益需在自己的负载上实测。三、单节点 TP、跨节点 PP/DCP：官方给出的拓扑分界线怎么理解官方部署指南给出的拓扑原则非常清晰：单节点内优先用 TP，跨节点用 PP/DCP。这条原则背后是互联带宽的现实约束。TP 吃互联带宽：张量并行需要在每一层计算都做中间结果的 AllReduce，通信量巨大，因此必须依赖节点内 NVLink 的高带宽，节点内互联带宽显著高于常见的节点间网络，具体数值需以自身机型规格为准。PP/DCP 通信量更小：流水线并行只在层边界传递激活，通信频率低；DCP 则在解码步骤间传递少量 KV 信息。两者对带宽要求更低，因此适合跨节点部署。这条分界线告诉我们，大模型推理GPU集群拓扑选择 的第一约束，不是“有多少张卡”，而是“节点内互联能够支撑什么并行度”。如果你的模型权重需要 4 张卡才能装下，且这 4 张卡在同一个节点内，那么 TP 是优先选项；一旦卡数超过单节点上限（通常 8 卡），就必须考虑跨节点，此时应切换为 PP/DCP，而不是强行扩大 TP 规模。可执行的判断：规划 GPU集群时，先算单节点可容纳的 TP 规模，再决定是否需要跨节点。四、超大 MoE 与多模态模型对 GPU集群的三类压力：显存、互联带宽、长上下文 KVSGLang 此次 Day-0 支持的两类模型，分别代表了两种典型的负载压力，抽象来看，它们对 GPU集群 的压力主要分三类：权重显存压力：万亿级 LatentMoE 的模型权重总量巨大，即使 M…

B300 288GB上线后，B200与H100算力性价比分析是否被改写？单位Token成本重算指南
type: item
date: 2026-08-09T10:47:53+08:00
description: 2026年年中，NVIDIA Blackwell Ultra（B300）上线，面对B200的时租，多付约1.75倍时租能否被拓扑简化赚回？本文用单位Token成本框架给出答案。一、B300上线后，高端卡的价格梯队被拉成了什么样B300（Blackwell Ultra）的公开规格是288GB HBM3e显存（2026年公开规格）和15 PFLOPS密集FP4算力（2026年公开规格），显存容量比B200的192GB提升50%，密集计算性能提升1.5倍。在2026年年中的云算力平台公开数据里，B300的按量租赁中位价格在8.13-8.75美元/GPU-小时（2026年6-7月云算力平台公开报价数据），而B200的单卡租金分布在3.70-5.89美元/小时（2026年6-7月云算力平台公开报价数据）。按中位价估算，B300时租约为B200的1.7-1.8倍，但显存只多了50%。这并非线性关系，如果B300不能带来等比例的吞吐提升或节点数缩减，它可能只是纸面上的性能冠军。原有针对B200与H100的性价比结论，需要拉回真实负载下重新验算。注意，本文所有价格和规格均来自公开可查的2026年资料，不引用任何未经证实的基准测试数据。二、288GB对192GB：50%显存提升真正解决的是哪一类问题显存多出96GB，看起来只是容量变化，但实际上受益场景是阶跃式的。第一类是大参数模型的权重驻留：当模型权重加KV Cache超过192GB时，B200 单卡放不下，通常会先走单节点多卡张量并行；只有当整机显存也不够时才需要跨节点。真正产生成本跃迁的是“跨节点”这一步，而非“跨卡”。B300 可能单节点装下，省去通信开销。第二类是长上下文场景：上下文长度翻倍，KV Cache几乎线性增长，比如一个百B级模型，上下文从32K扩到128K，KV Cache可能多出几十GB，这正是288GB显存的用武之地。但要注意，显存提升的收益不是对所有模型都生效。如果你的模型权重加KV Cache远小于192GB，或者并发很低，那50%显存增量只是冗余，无法转化为成本优势。所以，288GB的价值在于它是否跨过了“模型能否装进单卡或单节点”的门槛。那么，288GB显存大致能装下什么规模的模型？按FP8口径，权重约230GB以内的模型有机会单卡驻留，具体仍取决于KV Cache和框架开销，需按第三节公式估算。三、把显存容量换算成节点数：什么规模的模型会从跨节点回到单节点以下为估算方法示例，参数需用自身负载替换。所需显存 ≈ 参数量（B）× 精度字节数 + KV Cache大小 + 框架与激活开销（通常留20%余量）例如，一个700B参数的模型用FP8（每参数1字节），设KV Cache估算为100GB（假设值，非实测），则总需求 = 700GB + 100GB = 800GB，加上20%余量后为 800GB × 1.2 = 960GB。若每节点4卡（示例设定），B200单卡192GB，需要卡数 = 960 ÷ 192 = 5 卡，按每节点4卡（示例设定）需跨2个节点；B300单卡288GB，需要卡数 = ceil(960/288) = 4卡，单节点即可。节点数从2降至1，省去的不仅是跨节点通信的延迟，还有网络带宽的租用成本。但若参数降到100B规模，权重约100GB（FP8），加上KV Cache是否超过192GB取决于上下文长度与并发，请用上式代入你的上下文长度与并发自算。若未超过，B200单卡即可，B300的显存提升就不改变节点数，这时多付的时租就是纯溢价。四、15 PFLOPS密集FP4与1.5倍算力提升，落到实际吞吐上还剩多少纸面算力提升是上界，而非预期收益。实际吞吐受限于三个环节：访存瓶颈、batch组织、解码阶段的带宽特性。生成式推理中，KV Cache的反复读取常使GPU处于内存带宽受限状态，而不是计算受限。B300的15 PFLOPS密集FP4是峰值，但若模型未用FP4量化（可能带来精度损失），或算子库未充分优化，实际吞吐可能远低于1.5倍提升。资料包未提供B300的实测吞吐数据，因此这里只给出判断框架，要点如下：预填充 vs 解码阶段：预填充阶段通常计算密集，解码阶段通常带宽受限。峰值算力提升更可能体现在预填充阶段；若你的负载长解码占主导，算力提升可能大打折扣。FP4量化精度回归：若采用FP4量化，需对比量化前后模型在验证集上的精度下降是否在可接受范围内；若不能接受，则无法利用FP4峰值。batch与并发影响：峰值利用率往往需要高batch size才能达到，若你的并发分布较稀疏，实际吞吐可能远低于峰值。以上为判断框架而非实测，请根据自身负载验证。五、单价不等于成本：一套可复用的每百万Token成本推算公式核心公式：每百万Token成本 =（卡数 × 时租…