首页/GPU/B300 部署 GLM-5.2-FP8 实测：这机器贵得离谱又难买，但我们真搞来一台 8 卡跑了一遍

B300 部署 GLM-5.2-FP8 实测：这机器贵得离谱又难买，但我们真搞来一台 8 卡跑了一遍

UCloud 运营管理员2026/8/17阅读 2GPUFP8B300部署实测GLM-5.2SGLang
AI 摘要 / TL;DR

B300稀缺昂贵，部署GLM 5.2 FP8需全链路升级（驱动、CUDA 13、Fabric Manager、推理框架等）。实测8卡Tensor Parallel运行SGLang，吞吐约0.93 req/s。适用于企业选型时评估环境一致性，而非单卡性能。

B300 现在根本不是你想买就能买到的，又贵又稀缺，到处都是询价的，却没几个人摸过真机。

我们就想做一件全网现在还很难看到的事——跑一次 GLM-5.2-FP8 的硬核实测，看看企业真要把它用到生产环境，选型到底该盯哪些点。

所以如果你正在考虑上 B300 跑 GLM-5.2 这类大模型先说结论：B300 绝不是简单把 H100/A100 换下来插上新卡就能完事的，它本质是一次 GPU、驱动、网络、多卡通信和推理框架的全链路升级。

最不该一上来就问的，就是“这卡性能有多强”。真正应该提前搞明白的是这几件事——

  • 驱动是不是 B300 对应版本；
  • Fabric Manager 是否与驱动严格一致；
  • CUDA 是否升级到 CUDA 13；
  • DOCA-OFED、InfiniBand、NCCL 是否正常走高速通信；
  • SGLang / vLLM 等推理框架是否支持当前 FP8、MoE、Tensor Parallel 组合；
  • 模型路径、量化配置、TP 参数是否和实际 GPU 数量匹配。

这次实测中，我们用 8 卡 Tensor Parallel 跑通了 GLM-5.2-FP8，并通过 SGLang benchmark 得到了一组可参考数据（想看实战结论可以直接跳到第六部分）：

指标实测结果
后端sglang
最大并发16
成功请求数8
压测时长8.63 s
请求吞吐0.93 req/s
输入 token 吞吐4449.39 tok/s
输出 token 吞吐309.28 tok/s
峰值输出吞吐607.00 tok/s
总 token 吞吐4758.67 tok/s
平均并发5.13

我的判断是：B300 的硬件能力值得期待，但企业落地时真正的风险点在环境一致性和验证流程，而不是单条启动命令。

一、问题背景：为什么 B300 部署不能只看 GPU 参数？

很多团队评估新一代 GPU 时，容易先看显存、带宽、FP8/FP4 能力和理论算力。但到了部署阶段，会发现一个现实问题：

GPU 能被系统识别，不代表推理服务能跑；推理服务能启动，不代表性能符合预期。

B300 基于 Blackwell 架构，支持 FP8/FP4 等低精度能力，理论上非常适合大模型推理和训练。但这些能力要真正兑现，需要整条软件栈都跟上。

这里有几个关键实体需要先说清楚：

实体类型说明
NVIDIA B300GPU / 算力卡基于 Blackwell 架构的新一代 AI GPU，面向大模型训练与推理场景。
BlackwellGPU 架构NVIDIA 新一代 GPU 架构，支持 FP8/FP4 等低精度计算能力。
GLM-5.2-FP8大模型 / 量化模型本次部署测试使用的 FP8 量化模型，依赖推理框架对 FP8 和多卡并行的支持。
SGLang推理框架面向大模型推理服务的框架，本次用于启动 GLM-5.2-FP8 服务。
Fabric ManagerNVIDIA 多卡通信组件用于管理 NVLink / NVSwitch 等多 GPU 通信能力，版本必须与 NVIDIA 驱动一致。
CUDA 13GPU 计算平台Blackwell 相关特性需要 CUDA 13 及匹配深度学习库支持。
DOCA-OFED网络栈NVIDIA / Mellanox 高速网络驱动与工具集，用于 InfiniBand、RDMA、GPUDirect RDMA 等场景。
InfiniBand高速网络常用于多机 GPU 集群通信，会影响 NCCL 和分布式推理/训练性能。
NCCL通信库NVIDIA Collective Communications Library，用于多 GPU / 多机通信。
PyTorch深度学习框架训练和推理生态中的基础框架，需要与 CUDA 版本匹配。

所以，从企业选型角度看，B300 不只是采购一批 GPU，而是要判断：现有基础设施、系统镜像、网络架构、推理框架和运维能力，能不能承接 Blackwell 这一代的新栈。

二、核心痛点：B300 部署最容易卡在哪？

我会把 B300 的部署风险分成五类。

1. 驱动风险：旧驱动可能识别不了新卡

B300 需要对应的新版本 NVIDIA 驱动。本次实测使用的是：

  • NVIDIA 驱动：580.159.04

如果驱动版本不对，轻则能力暴露不完整，重则系统无法正确识别 GPU。

2. Fabric Manager 风险：版本不一致，多卡通信可能直接失败

这一点非常关键。

Fabric Manager 负责 NVLink / NVSwitch 等多卡通信管理。原始实测中已经遇到过：Fabric Manager 小版本落后，导致 nvidia-smi nvlink --status 报错，多卡通信无法建立。

所以我的建议很明确：

驱动和 Fabric Manager 版本必须严格一致，不要凭感觉混装。

本次组合是：

  • NVIDIA 驱动：580.159.04
  • Fabric Manager：580.159.04-1

3. CUDA 风险：Blackwell 环境建议锁定 CUDA 13

B300 / Blackwell 相关能力需要 CUDA 13 及配套库支持。本次实测使用：

  • CUDA Toolkit：13.0
  • 启动日志中显示：CUDA Version 13.0.1

如果深度学习框架报类似 CUDA capability 10.0+ required，就要优先检查是否装成 CUDA 12，或者 PyTorch / 推理框架版本不匹配。

4. 网络风险：InfiniBand 不是 ping 通就完事

B300 集群通常会配 ConnectX-7 / InfiniBand。多机训练或

  • 模型路径不存在；
  • FP8 量化配置不匹配；
  • --tp 8 和实际 GPU 数量不一致；
  • 容器内模型挂载路径错误；
  • NCCL / CUDA 版本与容器不兼容。

三、不同方案对比：企业部署 B300，有几种思路？

从落地方式看，大致有三种。

方案优点风险适合团队
直接在裸机上逐项安装可控性强，便于定位底层问题安装链路长，版本容易混乱有 GPU 集群运维经验的基础设施团队
使用容器启动推理框架推理服务启动更快，环境隔离较好底层驱动、CUDA、NCCL 仍必须匹配已有容器化推理平台的团队
先单机跑通，再扩多机集群风险分阶段释放，排障更清晰前期需要设计验证 checklist准备生产落地的企业团队

我的建议是：不要一上来就多机集群全量部署。

更稳的方式是：

  1. 单机完成系统、驱动、Fabric Manager、CUDA、DOCA-OFED 验证；
  2. 单机 8 卡跑通 GLM-5.2-FP8；
  3. 用 benchmark 看吞吐和延迟；
  4. 再扩展到多机，重点验证 NCCL、InfiniBand、SSH 互信、主机名解析和调度系统。

这也是本文采用的“问题—解决方案—验证”逻辑。

四、为什么我会选择“锁版本 + 逐层验证”的部署方式？

因为 B300 这类新平台最怕两件事：

  1. 软件包版本混装；
  2. 出问题时不知道是哪一层的问题。

所以这次实测里，先把版本锁死。

组件版本说明
操作系统Ubuntu 22.04 LTS服务器版，LTS 长期支持
内核5.15+与 NVIDIA 驱动 580 兼容
NVIDIA 驱动580.159.04B300 专用驱动
Fabric Manager580.159.04-1与驱动版本严格一致
CUDA Toolkit13.0Blackwell 完整特性支持
DOCA-OFED24.10-4.1.4.0高速网络 + GPUDirect RDMA
cuDNN9.x for CUDA 13深度学习基础库
NCCL2.x for CUDA 13多卡 / 多机通信
PyTorch2.5+ cu130训练 / 推理框架

这里的核心不是说这些版本永远是唯一选择，而是：在一次可复现部署中，必须先固定版本组合，再谈性能调优。

否则你遇到的每一个问题，都可能来自驱动、CUDA、NCCL、Python 包、容器镜像、模型配置中的任意一层。

五、实际部署流程：从系统到推理服务的 7 步

下面是这次部署的主要步骤。我保留关键命令，方便复现和排查。

第 1 步：系统准备，先禁用 Nouveau

安装 NVIDIA 驱动前，建议先禁用 Nouveau，避免与官方驱动冲突。

# 更新系统
sudo apt update && sudo apt upgrade -y

# 安装基础工具
sudo apt install -y build-essential dkms linux-headers-$(uname -r) \
    wget curl vim git net-tools pciutils ethtool openssh-server python3-pip

# 禁用 Nouveau，避免和 NVIDIA 驱动冲突
sudo bash -c "cat > /etc/modprobe.d/blacklist-nouveau.conf" << EOF
blacklist nouveau
options nouveau modeset=0
EOF

sudo update-initramfs -u
sudo reboot

重启后检查：

lsmod | grep nouveau   # 应无输出
lspci | grep -i nvidia  # 应能看到 B300

验证标准：lsmod | grep nouveau 无输出，且 lspci 能看到 NVIDIA 设备。

第 2 步：安装 DOCA-OFED，先把高速网络打好

B300 集群通常会依赖高速网络。本文使用 DOCA-OFED 24.10：

cd ~/downloads
wget https://content.mellanox.com/ofed/MLNX_OFED-24.10-4.1.4.0/MLNX_OFED_LINUX-24.10-4.1.4.0-ubuntu22.04-x86_64.tgz
tar -xzf MLNX_OFED_LINUX-24.10-4.1.4.0-ubuntu22.04-x86_64.tgz
cd MLNX_OFED_LINUX-24.10-4.1.4.0-ubuntu22.04-x86_64

sudo ./mlnxofedinstall --all --with-doca
sudo /etc/init.d/openibd restart

# 验证
ofed_info -s
ibstat

如果需要 GPUDirect RDMA，可额外加载相关参数：

echo "options nvidia NVreg_EnableGpuFirmwareLogs=2" | sudo tee /etc/modprobe.d/nvidia.conf
echo "options mlx5_core enable_nvpeer=1" | sudo tee -a /etc/modprobe.d/mlx5.conf

# 网络缓冲区优化
sudo sysctl -w net.core.rmem_max=268435456
sudo sysctl -w net.core.wmem_max=268435456

验证标准：ofed_info -s 能显示版本，ibstat 状态应为 Active。

第 3 步：安装 NVIDIA 驱动 580.159.04

cd ~/downloads/nvidia_driver
wget https://us.download.nvidia.com/XFree86/Linux-x86_64/580.159.04/NVIDIA-Linux-x86_64-580.159.04.run
chmod +x NVIDIA-Linux-x86_64-580.159.04.run

sudo systemctl isolate multi-user.target
sudo ./NVIDIA-Linux-x86_64-580.159.04.run

# 安装选项：接受协议；自动更新 X 配置选 No；32 位兼容库可选 Yes；运行 nvidia-xconfig 选 No
sudo reboot

重启后检查：

nvidia-smi
# 应显示 Driver Version: 580.159.04，CUDA Version: 13.0

第 4 步：安装 Fabric Manager

这一层非常关键。Fabric Manager 版本必须和驱动完全一致。

<code class="language-text"># 添加 NVIDIA 仓库
distribution=$(. /etc/os-release; echo $ID$VERSION_ID | sed -e 's/\.//g')
wget https://developer.download.nvidia.com/compute/cuda/repos/$distribution/x86_64/<span>cuda-keyring</span>_1.0-1_all.deb
sudo dpkg -i cuda-keyring_1.0-1_all.deb
sudo apt update # 安装指定版本
sudo apt install -y nvidia-fabricmanager-580=580.159.04-1
sudo systemctl start nvidia-fabricmanager
sudo systemctl enable nvidia-fabricmanager
</code>

验证：

<code class="language-text">sudo systemctl status nvidia-fabricmanager
nvidia-smi nvlink --status
nvidia-smi nvlink --capabilities
</code>

验证标准：Fabric Manager 服务为 active，nvidia-smi nvlink --status 不报错。

第 5 步：安装 CUDA Toolkit 13.0

<code class="language-text">wget https://developer.download.nvidia.com/compute/cuda/13.0.0/local_installers/<span>cuda</span>_13.0.0_580.32.07_linux.run
chmod +x cuda_13.0.0_580.32.07_linux.run
sudo sh cuda_13.0.0_580.32.07_linux.run --silent --toolkit --samples # 配置<span>环境变量</span>
echo 'export CUDA_HOME=/usr/local/cuda-13.0' >> ~/.bashrc
echo 'export PATH=$CUDA_HOME/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc
source ~/.bashrc # 验证
<span>nvcc</span> --version
# 应显示 release 13.0
</code>

第 6 步：安装 Python 深度学习环境

<code class="language-text"># Python 3.11
sudo add-<span>apt-repository</span> ppa:deadsnakes/ppa -y
sudo apt update
sudo apt install -y python3.11 python3.11-venv python3.11-dev
curl -sS https://bootstrap.pypa.io/get-pip.py | python3.11 # 创建虚拟环境
python3.11 -m venv ~/b300-env
source ~/b300-env/bin/activate # PyTorch for CUDA 13.0
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu130 # 推理和优化工具
pip install transformers accelerate vllm sglang flash-attn --no-build-isolation
pip install <span>deepspeed</span>
</code>

验证 GPU 是否可被 PyTorch 识别：

<code class="language-text">python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"
</code>

验证标准：torch.cuda.is_available() 返回 True，并能输出 GPU 名称。

第 7 步：系统级优化

这些优化不是万能的，但能减少运行时资源限制和性能抖动。

<code class="language-text"># GPU 持久模式 + <span>功耗限制</span>
sudo <span>nvidia-smi -pm</span> 1
sudo nvidia-smi -pl 700 # <span>文件描述符</span>和内存锁
sudo bash -c "cat >> /etc/security/limits.conf" << EOF
* soft nofile 65536
* hard nofile 65536
* soft memlock unlimited
* hard memlock unlimited
EOF # <span>共享内存</span>
sudo bash -c "cat >> /etc/sysctl.conf" << EOF
kernel.shmmax = 68719476736
kernel.shmall = 16777216
EOF
sudo <span>sysctl -p</span> # 禁用透明大页
sudo systemctl disable --now systemd-timesyncd # 示例
</code>

这里需要提醒一句：原文中“禁用透明大页”的命令示例实际指向 systemd-timesyncd，与透明大页不完全对应。生产环境应补充准确的 THP 配置和验证步骤。

六、拉起 GLM-5.2-FP8：SGLang 8 卡 Tensor Parallel 实测（重磅）

环境验证通过后，再启动推理服务。

本次测试使用 SGLang 容器，8 卡 Tensor Parallel：

<code class="language-text"><span>docker</span> run --<span>gpu</span>s all \ --shm-size 32g \ -p 30000:30000 \ -v /models:/models \ --ipc=host \ -e PYTHONUNBUFFERED=1 \ -e NCCL_DEBUG=WARN \ lmsysorg/sglang:latest \ sglang serve \ --model-path /models/GLM-5.2-FP8 \ --tp 8 \ --mem-fraction-static 0.8 \ --enforce-disable-flashinfer-allreduce-fusion \ --host 0.0.0.0
</code>

启动日志里重点看这些信号：

  • CUDA 版本：CUDA Version 13.0.1；
  • NCCL 版本：NCCL version 2.28.9+cuda13.0；
  • DeepGemm 已启用，用于 Blackwell FP8 推理加速；
  • FlashInfer TRTLLM MoE 后端初始化；
  • 8 个 tensor parallel rank 依次完成初始化；
  • 服务监听：http://0.0.0.0:30000。

如果启动失败，我一般会按这个顺序查：

现象 可能原因 建议检查项 load checkpoint 阶段卡住 模型路径错误或权限不足 检查 /models/GLM-5.2-FP8 是否存在、容器是否挂载成功 FP8 相关报错 量化配置与框架版本不匹配 检查模型配置、SGLang 版本、CUDA / NCCL 日志 --tp 8 启动失败 GPU 数量或可见设备不匹配 检查 docker --gpus all、nvidia-smi、CUDA_VISIBLE_DEVICES 多卡通信失败 Fabric Manager 或 NCCL 异常 检查 nvidia-smi nvlink --status 和 NCCL 日志

七、性能实测：这组数据应该怎么解读？

服务跑起来后，用 SGLang benchmark 做了一组压测。

测试条件：

  • 最大并发：16；
  • 成功请求数：8；
  • 输入 token 总量：38412；
  • 输出 token 总量：2670。

指标数值
后端sglang
最大并发16
成功请求数8
压测时长8.63 s
请求吞吐0.93 req/s
输入 token 吞吐4449.39 tok/s
输出 token 吞吐309.28 tok/s
峰值输出吞吐607.00 tok/s
总 token 吞吐4758.67 tok/s
平均并发5.13

端到端延迟如下：

分位E2E Latency (ms)TTFT (ms)TPOT (ms)ITL (ms)
Mean5535.541294.3112.9212.75
Median5855.461356.8612.7312.40
P907604.151447.7813.4712.60
P958108.001448.5413.9212.64
P998511.071449.1414.2714.82

我的解读是：

  1. TTFT 约 1.3s 在输入 token 总量 38412 的长上下文条件下，首 token 延迟主要受 prefill 阶段影响，这个结果属于可以理解的范围。
  2. TPOT 约 12.7-13 ms/token 说明 FP8 推理链路已经跑通，单 token 生成阶段延迟较稳定。
  3. 峰值输出吞吐 607 tok/s 说明并发爬坡阶段，GPU 利用率可以被拉起来。
  4. P99 E2E 延迟达到 8.5s 这提示一个生产问题：当并发接近当前配置上限时，队列等待会明显增加。生产环境不能只看平均值，要重点看 P95 / P99。

如果是在线问答、Agent、代码助手这类交互式场景，我会重点看：

  • TTFT；
  • P95 / P99 E2E；
  • 失败请求数；
  • 并发上升后的排队时间。

如果是批量生成、离线处理类场景，则更关注：

  • 总 token 吞吐；
  • 输出 token 吞吐；
  • GPU 利用率；
  • 单位成本下的吞吐表现。

八、适合 / 不适合场景

适合 B300 的场景

基于这次实测，我认为 B300 更适合以下场景：

  • 需要 FP8 推理能力的大模型服务；
  • 对 token 吞吐有较高要求的推理集群；
  • 长上下文输入较多的模型服务；
  • 有能力维护 CUDA 13、NCCL、InfiniBand、Fabric Manager 等复杂栈的团队；
  • 计划从单机多卡逐步扩展到多机集群的企业基础设施团队。

不太适合的场景

以下情况不建议贸然上 B300：

  • 团队只具备普通单卡 GPU 使用经验，没有多卡 / 多机排障能力；
  • 现有业务对 FP8、长上下文、多卡推理需求不强；
  • 希望“买来即用”，但没有环境锁版、benchmark 和监控体系；
  • 当前推理框架版本还未充分验证目标模型；
  • 对 P99 延迟非常敏感，但还没有做队列、批处理和调度优化。

简单说：B300 更适合有明确大模型吞吐需求、并且能管理复杂基础设施的团队。

九、部署 checklist：问题—解决方案—验证

阶段需要解决的问题解决方案验证方式
系统准备Nouveau 可能与 NVIDIA 驱动冲突禁用 Nouveau 并重启lsmod | grep nouveau 无输出
GPU 驱动B300 需要匹配驱动安装 580.159.04nvidia-smi 显示正确驱动版本
多卡通信NVLink / NVSwitch 依赖 Fabric Manager安装 580.159.04-1systemctl status nvidia-fabricmanager、nvidia-smi nvlink --status
CUDABlackwell 需要 CUDA 13 环境安装 CUDA Toolkit 13.0nvcc --version 显示 release 13.0
高速网络RDMA / NCCL 可能 fallback安装 DOCA-OFED 并检查 IBofed_info -s、ibstat、NCCL 日志
推理框架FP8 / Tensor Parallel 依赖框架支持安装 SGLang / PyTorch cu130torch.cuda.is_available() 返回 True
模型服务模型路径、量化配置、TP 参数可能不一致使用 SGLang 启动 GLM-5.2-FP88 个 TP rank 初始化完成，服务监听 30000
性能验证服务可用不等于性能达标运行 benchmark查看吞吐、TTFT、TPOT、P95 / P99 延迟

十、FAQ

Q1：B300 部署时最容易踩的坑是什么？

最容易踩的坑是只看 nvidia-smi。

nvidia-smi 正常只能说明 GPU 和驱动基本可用，不能证明 Fabric Manager、NVLink、NCCL、InfiniBand 和推理框架都正常。生产部署一定要逐层验证。

Q2：为什么 Fabric Manager 必须和驱动版本一致？

因为 Fabric Manager 管理多 GPU 之间的 NVLink / NVSwitch 通信。原始实测中，Fabric Manager 小版本落后会导致 nvidia-smi nvlink --status 报错，多卡通信无法建立。

建议用 apt 仓库安装指定版本，减少手动混装风险。

Q3：CUDA 13 是必须的吗？

在本文这套 B300 / Blackwell 部署路径下，CUDA 13 是关键依赖。Blackwell 相关能力和匹配库需要 CUDA 13 支持。

如果框架报 CUDA capability、算子不支持或 GPU 不可用，需要优先检查 CUDA 和 PyTorch / SGLang 版本是否匹配。

Q4：InfiniBand 怎么确认真的生效？

不要只看 ping。

至少要看：

  • ibstat 是否为 Active；
  • ofed_info -s 是否显示预期 DOCA-OFED 版本；
  • NCCL 日志里是否走 IB 而不是 SOCKET；
  • 多卡 / 多机 benchmark 是否符合预期。

Q5：GLM-5.2-FP8 启动失败，应该先查什么？

建议先查三项：

  1. 模型路径是否存在，容器挂载是否正确；
  2. FP8 量化配置是否与 SGLang 版本匹配；
  3. --tp 8 是否与实际 GPU 数量一致。

这三类问题最容易导致 load checkpoint 阶段卡住或报错。

Q6：这组 benchmark 数据能代表生产性能吗？

不能直接代表所有生产场景。

它只能说明在本文给定环境、模型、并发和 token 条件下的实测表现。真正上线前，还需要按业务真实请求长度、并发峰值、SLA、失败率、成本和容灾策略重新压测。

总结建议：企业落地 B300，我会怎么判断？

  • 先看业务：真需要 FP8、多卡和高吞吐才上，小规模推理不一定扛这一代复杂栈。
  • 再看团队：难点不是装驱动，是驱动、Fabric Manager、CUDA、OFED、NCCL、框架和模型配置全链路版本对齐。
  • 部署就一条铁律：锁版本，分层验证。顺序：系统→网络→驱动→Fabric Manager→CUDA→框架→模型服务→benchmark。
  • 性能别看平均数：交互式盯 TTFT 和 P95/P99 E2E，批量盯 token 吞吐和 GPU 利用率。

我们实测 8 卡 Tensor Parallel + SGLang + GLM-5.2-FP8，跑通压测，输入吞吐 4449.39 tok/s，输出吞吐 309.28 tok/s，峰值输出 607.00 tok/s。

最后一个大实话：B300 部署成不成，从来不看你最后那条 sglang serve 成不成功，而是前面每一层环境，你到底有没有一个坑一个坑验过去。

注：本次测评由优刻得技术研究院支持，包含部署环境、设备等资源。