1. 这块卡到底为谁而生H20 的定位与核心取舍第一次拿到 H20 的参数表我盯着那个 96GB 的显存数字看了很久。做推理部署的人都知道显存就是命根子模型能不能塞进去、并发能开多大、KV Cache 能留多长全看这块容量。但紧接着往下看算力指标心里又凉了半截——它的 FP16/BF16 稠密算力被压得很低跟同代的旗舰训练卡完全不在一个量级。这种“大显存、低算力”的组合乍看很矛盾实际上恰恰是它最清晰的产品定位它不是拿来训模型的是拿来跑推理的。我在几个实际项目里接触过这块卡也帮朋友评估过“一台 8 卡 H20 预算”该怎么配。结论先放这儿如果你的核心诉求是大模型推理服务、长上下文、高并发、多模型共存H20 的显存容量和互联能力是它真正的杀手锏但如果你指望它去微调大模型、跑训练任务那基本是花钱买罪受。下面我把这套判断拆开讲透包括它为什么这么设计、实际能跑什么、怎么配、踩过哪些坑。1.1 为什么是“大显存 低算力”这个组合要理解 H20得先理解推理和训练对硬件的需求差异。训练阶段尤其是大模型预训练和全参微调瓶颈在算力——你要反复做前向、反向、梯度更新矩阵乘法的吞吐直接决定训练时长。这时候算力就是一切显存够用就行。推理阶段完全是另一回事。推理是前向计算算力需求相对可控但显存需求会随着上下文长度和并发数急剧膨胀。一个 70B 的模型光权重用 FP16 存就要 140GB 左右量化到 INT8 也要 70GBINT4 大概 35GB。这还只是权重真正吃显存的是 KV Cache——上下文越长、并发越高KV Cache 占用越夸张。我实测过一个 32B 模型在 32K 上下文、并发 16 的场景下KV Cache 能吃掉几十 GB。所以 H20 的设计逻辑就很清楚了把算力砍到够用把显存和显存带宽堆上去专门服务推理。96GB 的 HBM3 显存意味着你可以单卡塞下 INT4 量化的 70B 模型甚至留出可观的 KV Cache 空间单卡同时跑多个中小模型做多模型路由8 卡组成 768GB 显存池跑 671B 级别的 MoE 模型推理这些场景里算力不是瓶颈显存才是。H20 就是冲着这个来的。1.2 和同门、竞品的横向对比光说定位不够直观拉个表对比一下更清楚。下面是我根据公开参数和实际使用感受整理的对比注意算力数值是量级参考具体以官方规格为准维度H20旗舰训练卡同代消费级旗舰显存容量96GB HBM380GB HBM324GB GDDR6X显存带宽约 4TB/s 级约 3TB/s 级约 1TB/s稠密算力大幅削减极高中等互联能力高速卡间互联高速卡间互联无仅 PCIe典型用途推理、长上下文训练、微调游戏、小模型单卡功耗约 400W约 700W约 450W从表里能看出几个关键点。第一H20 的显存带宽其实不低甚至比某些训练卡还高这对推理很关键——推理是访存密集型任务权重读取速度直接影响吞吐。第二它的卡间互联能力保留了这意味着 8 卡可以高效组成一个大显存池跑张量并行。第三功耗相对温和8 卡整机的散热和供电压力比旗舰训练卡小不少这对机房改造预算是实打实的利好。我帮朋友算过一台 8 卡 H20 的整机预算包括服务器本体、供电改造、散热整体比同数量的旗舰训练卡方案省下一大截。对于预算有限但又需要大显存跑推理的团队这个差价很关键。1.3 谁该买谁该绕道基于上面的分析我给个直接的判断清单。适合买 H20 的情况你要部署 70B 以上大模型的推理服务尤其是长上下文场景你需要多模型共存比如一个网关后面挂好几个不同尺寸的模型你要跑 MoE 架构的大模型推理显存池越大越好你的团队预算有限但需要卡间互联来做张量并行你主要做 RAG、Agent、批量推理这类任务不建议买 H20 的情况你要做模型训练或全参微调算力会成为致命瓶颈你要做 LoRA 微调虽然显存够但训练速度会让你抓狂你的模型很小7B 以下24GB 消费卡就够没必要上这个你追求单卡极致算力那应该看别的型号我见过有人拿 H20 去跑 LoRA 微调一个 9B 模型结果训练一轮的时间比预期长了好几倍最后换回算力卡才解决问题。这就是典型的定位错配。2. 96GB 显存到底能装下什么容量规划实战显存容量是 H20 最大的卖点但“96GB”这个数字本身没有意义关键是它能装下什么、怎么装。这一块我讲点实在的包括模型权重的显存占用计算、KV Cache 的估算方法以及多模型共存的显存分配策略。2.1 模型权重占用的快速估算法很多人问“XX 模型需要多少显存”其实有个简单的估算法则。模型权重的显存占用约等于参数量 × 每参数字节数不同精度的每参数字节数FP324 字节FP16/BF162 字节INT81 字节INT40.5 字节拿一个 70B 模型举例FP1670 × 2 140GB单卡装不下INT870 × 1 70GB单卡能装但 KV Cache 空间紧张INT470 × 0.5 35GB单卡轻松装KV Cache 空间充裕所以 H20 单卡跑 70B 模型INT4 量化是最舒服的选择权重占 35GB剩下 60GB 左右可以留给 KV Cache 和运行时开销。如果跑 INT8权重占 70GB只剩 26GB长上下文就捉襟见肘了。这里有个坑要提醒量化不是免费的。INT4 量化会带来精度损失尤其是对数值敏感的模型可能出现输出质量下降、重复、逻辑混乱等问题。我一般建议先试 INT8如果显存不够再降到 INT4并且一定要做效果对比测试。2.2 KV Cache 的估算与上下文长度权衡KV Cache 是推理显存占用的隐形大户很多人算显存只算权重结果一上长上下文就 OOM。KV Cache 的占用跟这几个因素有关层数num_layers注意力头数num_heads和每头维度head_dim上下文长度seq_len并发数batch_size精度FP16 还是 INT8粗略估算公式每 token 的 KV Cache 字节数2 × num_layers × num_heads × head_dim × 精度字节数以某个 70B 模型为例假设 80 层、64 头、每头 128 维、FP16每 token KV Cache ≈ 2 × 80 × 64 × 128 × 2 ≈ 2.6MB如果上下文 32K、并发 82.6MB × 32768 × 8 ≈ 680GB这个数字远超单卡容量所以实际部署必须用分页注意力PagedAttention、KV Cache 量化、前缀缓存共享等技术来压缩。这也是为什么 vLLM、SGLang 这类推理框架这么重要——它们把 KV Cache 管理做到了极致。我实测下来用 SGLang 启动推理服务时通过--mem-fraction-static参数控制显存预分配比例配合--max-running-requests限制并发能在 96GB 卡上把 70B INT4 模型跑到 32K 上下文、并发 8 左右这个表现对大多数业务场景够用了。2.3 多模型共存的显存分配策略H20 的 96GB 显存还有个玩法单卡跑多个模型。比如一个 7B 的意图识别模型 一个 32B 的对话模型 一个 Embedding 模型全塞一张卡上。这种架构在 Agent 场景里很常见。分配策略上我一般这样规划主对话模型占大头比如 50GB辅助小模型每个 5-10GBEmbedding/Rerank 模型2-4GB预留缓冲10GB 左右应对峰值关键是预留缓冲。我踩过一次坑把显存算得刚刚好结果业务高峰期并发上来KV Cache 一涨直接 OOM服务挂了。后来学乖了永远留 10% 以上的余量。另外多模型共存时要注意显存碎片问题。不同模型加载顺序、释放时机不同容易产生碎片。用推理框架的统一显存池管理能缓解这个问题比如 vLLM 的--gpu-memory-utilization参数就是干这个的。3. 从裸机到推理服务完整部署实操这一块是重头戏。我按从驱动安装到服务上线的完整流程走一遍包括 Ubuntu 下驱动安装、CUDA 环境配置、推理框架选型和启动参数调优。这些步骤我在多个项目里反复验证过可以直接抄作业。3.1 驱动与 CUDA 环境搭建拿到新卡第一步是装驱动。Ubuntu 下装 NVIDIA 驱动有几个常见坑我一个个说。首先确认系统识别到了卡lspci | grep -i nvidia如果能看到 NVIDIA 设备说明硬件层面没问题。接下来装驱动我推荐用apt方式比手动跑.run文件省心sudo apt update sudo apt install -y nvidia-driver-550 sudo reboot重启后验证nvidia-smi如果这里报nvidia-smi has failed because it couldnt communicate with the nvidia driver别慌这是最常见的问题。原因通常是驱动没装成功检查dkms status看驱动模块有没有编译Secure Boot 拦截BIOS 里关掉 Secure Boot或者给驱动模块签名内核版本不匹配升级内核后驱动需要重新编译跑sudo dkms autoinstall我遇到过最诡异的一次是驱动装好了但nvidia-smi还是报错最后发现是之前装过旧版驱动没清干净。解决办法是先彻底卸载sudo apt purge -y ^nvidia-.* sudo apt autoremove -y sudo reboot然后再装新版。这个清理步骤很多人会跳过结果新旧驱动打架。CUDA 环境我一般装 CUDA 12.x 系列配合对应的 cuDNN。装完后在~/.bashrc里配好环境变量export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATH验证nvcc --version3.2 推理框架选型vLLM vs SGLang vs TensorRT-LLM框架选型直接决定部署效率和最终性能。我三个都用过说说各自的特点。vLLM是最通用的选择。PagedAttention 是它的招牌KV Cache 管理做得好支持的模型多社区活跃。启动命令简单python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --quantization awq--gpu-memory-utilization 0.9表示用 90% 显存留 10% 缓冲。--max-model-len控制最大上下文。--quantization指定量化方式。SGLang在结构化生成和前缀缓存上更强适合 Agent、RAG 这类有大量重复前缀的场景。启动方式python -m sglang.launch_server \ --model-path /path/to/model \ --tp 1 \ --mem-fraction-static 0.85 \ --context-length 32768SGLang 的 RadixAttention 对前缀共享做了优化多轮对话场景下能显著降低显存占用和延迟。TensorRT-LLM性能上限最高但编译流程复杂模型转换、引擎构建都要额外步骤。适合对延迟极度敏感、且愿意投入工程成本的团队。一般业务场景我不推荐一上来就用它。我的建议先用 vLLM 跑通遇到性能瓶颈再考虑 SGLang 或 TensorRT-LLM。别一上来就追求极致先把服务跑起来最重要。3.3 启动参数调优与显存监控参数调优是门手艺我分享几个关键参数的经验值。--gpu-memory-utilizationvLLM 里这个参数控制显存预分配。设太高容易 OOM设太低浪费显存。我一般从 0.85 开始试稳定后逐步提到 0.9。如果业务并发波动大就保守点用 0.85。--max-model-len最大上下文长度。这个值直接影响 KV Cache 的预分配。设太大浪费显存设太小长文本请求会被拒。根据业务实际需求设别盲目拉满。--max-num-seqs最大并发序列数。这个和 KV Cache 占用直接相关。我一般根据显存余量和平均上下文长度反推。监控方面除了nvidia-smi我推荐用nvitop或gpustat能实时看显存、利用率、温度pip install nvitop nvitop服务上线后重点盯这几个指标显存占用率、GPU 利用率、请求队列长度、首 token 延迟、每 token 输出延迟。显存占用率长期高于 95% 就要警惕GPU 利用率长期低于 30% 说明算力没吃满可能是并发不够或框架有瓶颈。4. 踩坑实录那些文档里不会写的问题这一块是我最想分享的因为都是真金白银换来的教训。文档里只会告诉你“怎么装”不会告诉你“装完为什么会炸”。4.1 显存够但依然 OOM 的几种情况显存明明够服务却 OOM这种情况我遇到过好几次。原因通常有这几类第一显存碎片。长时间运行后显存被反复分配释放产生碎片虽然总量够但没有连续大块。解决办法是定期重启服务或者用框架的显存池管理。第二KV Cache 预分配过大。有些框架会按max-model-len预分配 KV Cache如果你设了 128K 上下文但实际只用 8K显存就被白白占着。用分页注意力能缓解但参数还是要设合理。第三并发突增。平时并发 4突然来一波并发 32KV Cache 瞬间膨胀。这种要靠限流和队列管理别让请求无限制堆积。第四模型加载时的临时占用。加载模型时会有临时显存峰值如果加载前显存已经用了很多加载就会失败。所以启动服务前要确保显存干净。4.2 驱动、CUDA、框架版本的三方兼容版本兼容是另一个大坑。我整理了一个常见组合的兼容表组件推荐版本备注Ubuntu22.04 LTS长期支持生态最全NVIDIA 驱动550支持新卡和新 CUDACUDA12.4兼容性好PyTorch2.4对应 CUDA 12.4vLLM0.6支持新架构版本不匹配的典型症状PyTorch 报CUDA error: no kernel image is available或者框架启动时报找不到某个 CUDA 库。解决办法是严格按框架官方文档的版本矩阵来配别自己乱搭。我踩过最深的坑是 PyTorch 和 CUDA 版本对不上折腾了一整天才发现是 pip 装的 PyTorch 自带 CUDA 运行时和系统 CUDA 冲突了。后来统一用 conda 管理环境问题就少了。4.3 常见问题速查表把高频问题整理成表方便快速定位现象可能原因排查方向nvidia-smi 报错驱动未装/冲突清理旧驱动重装服务启动 OOM显存预分配过大调低 gpu-memory-utilization推理速度慢算力瓶颈/并发不足看 GPU 利用率调并发输出质量差量化精度损失换 INT8 或 FP16长文本被拒max-model-len 太小调大上下文限制显存泄漏框架 bug/碎片升级框架定期重启卡间通信慢互联配置问题检查拓扑和 NCCL 配置4.4 几个独家避坑技巧最后分享几个我总结的小技巧。技巧一先用小模型验证环境。别一上来就加载 70B 模型先用 7B 跑通整个流程确认驱动、CUDA、框架都没问题再上大模型。这样出问题好定位。技巧二显存监控常开。服务跑起来后开一个终端常驻nvitop随时观察显存曲线。异常增长能第一时间发现。技巧三压测要模拟真实流量。别只用固定长度的请求压测真实业务的请求长度是变化的。用混合长度的请求压测才能暴露 KV Cache 管理的真实问题。技巧四保留回滚方案。每次调参或升级框架前记下当前可用的配置。出问题能快速回滚别把自己逼到死角。技巧五关注显存带宽而非只看容量。推理是访存密集型显存带宽往往比容量更影响吞吐。H20 的带宽表现不错这是它推理性能的底气之一。5. 8 卡集群从单卡到规模化的关键一跃单卡玩明白了下一步就是组集群。8 卡 H20 是很多团队的目标配置但组集群不是简单插 8 张卡就完事互联、并行策略、调度都有讲究。5.1 张量并行与流水线并行的选择8 卡跑大模型核心是并行策略。主流有两种张量并行TP把单个矩阵运算拆到多卡上卡间通信频繁但延迟低。适合单机 8 卡场景因为卡间互联带宽高。H20 的卡间互联能力支持高效的 TP。流水线并行PP把模型按层切分到不同卡上通信量小但有流水线气泡。适合跨机场景。单机 8 卡我一般用纯 TP配置简单性能好。vLLM 里设--tensor-parallel-size 8就行。跨机才考虑 TPPP 混合。TP 的代价是卡间通信开销。8 卡 TP 时每层都要做 All-Reduce通信量不小。所以卡间互联带宽很关键这也是为什么 H20 保留高速互联很重要——它让 8 卡能高效协同。5.2 768GB 显存池能跑什么8 卡 H20 组成 768GB 显存池能玩的就多了。671B MoE 模型INT4 量化后权重约 335GB768GB 池子绰绰有余还能留大量 KV Cache多个 70B 模型并行服务每个模型分 2-4 卡同时跑好几个超大上下文单模型独占 8 卡上下文可以拉到 128K 甚至更高我实测过一个 671B MoE 模型在 8 卡 H20 上的推理INT4 量化上下文 32K并发 16整体吞吐能满足中等规模业务需求。这个配置在以前需要更多卡才能实现H20 的显存密度优势在这里体现得很明显。5.3 集群调度与资源隔离多卡多模型时调度和隔离很重要。我一般用容器化部署每个模型一个容器通过 Kubernetes 或 Docker Compose 管理。资源隔离的关键是显存隔离。虽然 GPU 本身不支持硬隔离但可以通过CUDA_VISIBLE_DEVICES指定容器可见的卡配合框架的显存限制参数实现软隔离。调度策略上我建议核心模型独占卡保证稳定性辅助模型共享卡提高利用率预留 1-2 张卡做弹性调度应对突发流量这样既保证核心业务又不浪费资源。6. 值不值得买一笔算清楚的账回到标题的问题。H20 值不值得买取决于你的场景和预算。我给几个判断维度。从显存性价比看96GB 显存单 GB 显存的成本比消费卡低不少比旗舰训练卡也低。如果你需要大显存H20 的性价比是突出的。从算力性价比看如果按算力算H20 不划算。它的算力被大幅削减纯算力单价偏高。所以千万别拿它做训练。从整机成本看8 卡 H20 整机的供电、散热压力比旗舰训练卡小机房改造成本低。这个隐性成本很多人会忽略但实际影响不小。从生态和稳定性看NVIDIA 的软件生态成熟驱动、CUDA、框架支持都好。H20 作为合规产品供货和售后有保障这对企业采购很重要。我的最终建议如果你的业务是推理为主、需要大显存、预算有限H20 是当前很务实的选择。如果你要训练、要微调、追求单卡极致算力那就别考虑它。买卡之前先把自己的业务场景和瓶颈想清楚别被参数表带偏。我在实际项目里的体会是选卡最怕的不是买贵了而是买错了。H20 是一块定位极其清晰的卡它的优点和缺点都摆在明面上。想清楚你要什么答案自然就有了。