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 B300	GPU / 算力卡	基于 Blackwell 架构的新一代 AI GPU，面向大模型训练与推理场景。
Blackwell	GPU 架构	NVIDIA 新一代 GPU 架构，支持 FP8/FP4 等低精度计算能力。
GLM-5.2-FP8	大模型 / 量化模型	本次部署测试使用的 FP8 量化模型，依赖推理框架对 FP8 和多卡并行的支持。
SGLang	推理框架	面向大模型推理服务的框架，本次用于启动 GLM-5.2-FP8 服务。
Fabric Manager	NVIDIA 多卡通信组件	用于管理 NVLink / NVSwitch 等多 GPU 通信能力，版本必须与 NVIDIA 驱动一致。
CUDA 13	GPU 计算平台	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。多机训练或推理时，DOCA-OFED、RDMA、NCCL 任一环节出问题，都可能导致通信 fallback 到 SOCKET。

这类问题很隐蔽，因为服务可能不是完全起不来，而是性能明显低于预期。

判断时不要只看网络是否能 ping 通，还要看：

• ibstat 是否为 Active；
• NCCL 日志中是否走 IB，而不是 SOCKET；
• 多卡 / 多机 benchmark 是否符合预期。

5. 推理框架风险：FP8、MoE、Tensor Parallel 支持在快速变化

SGLang / vLLM 对 FP8、MoE、Tensor Parallel 的支持版本迭代很快。对于 GLM-5.2-FP8 这类模型，框架版本、模型量化配置和启动参数要一起看。

常见问题包括：

• 模型路径不存在；
• 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.04	B300 专用驱动
Fabric Manager	580.159.04-1	与驱动版本严格一致
CUDA Toolkit	13.0	Blackwell 完整特性支持
DOCA-OFED	24.10-4.1.4.0	高速网络 + GPUDirect RDMA
cuDNN	9.x for CUDA 13	深度学习基础库
NCCL	2.x for CUDA 13	多卡 / 多机通信
PyTorch	2.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 版本必须和驱动完全一致。

添加 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/cuda-keyring_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

验证：

sudo systemctl status nvidia-fabricmanager nvidia-smi nvlink --status nvidia-smi nvlink --capabilities

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

第 5 步：安装 CUDA Toolkit 13.0

wget https://developer.download.nvidia.com/compute/cuda/13.0.0/local_installers/cuda_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

配置环境变量

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

验证

nvcc --version

应显示 release 13.0

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

Python 3.11

sudo add-apt-repository 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 deepspeed

验证 GPU 是否可被 PyTorch 识别：

python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

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

第 7 步：系统级优化

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

GPU 持久模式 + 功耗限制

sudo nvidia-smi -pm 1 sudo nvidia-smi -pl 700

文件描述符和内存锁

sudo bash -c "cat >> /etc/security/limits.conf" << EOF

• soft nofile 65536
• hard nofile 65536
• soft memlock unlimited
• hard memlock unlimited EOF

共享内存

sudo bash -c "cat >> /etc/sysctl.conf" << EOF kernel.shmmax = 68719476736 kernel.shmall = 16777216 EOF sudo sysctl -p

禁用透明大页

sudo systemctl disable --now systemd-timesyncd # 示例

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

---

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

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

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

docker run --gpus 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

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

• 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) Mean 5535.54 1294.31 12.92 12.75 Median 5855.46 1356.86 12.73 12.40 P90 7604.15 1447.78 13.47 12.60 P95 8108.00 1448.54 13.92 12.64 P99 8511.07 1449.14 14.27 14.82

我的解读是：

• TTFT 约 1.3s在输入 token 总量 38412 的长上下文条件下，首 token 延迟主要受 prefill 阶段影响，这个结果属于可以理解的范围。
• TPOT 约 12.7-13 ms/token说明 FP8 推理链路已经跑通，单 token 生成阶段延迟较稳定。
• 峰值输出吞吐 607 tok/s说明并发爬坡阶段，GPU 利用率可以被拉起来。
• 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.04 nvidia-smi 显示正确驱动版本 多卡通信 NVLink / NVSwitch 依赖 Fabric Manager 安装 580.159.04-1 systemctl status nvidia-fabricmanager、nvidia-smi nvlink --status CUDA Blackwell 需要 CUDA 13 环境 安装 CUDA Toolkit 13.0 nvcc --version 显示 release 13.0 高速网络 RDMA / NCCL 可能 fallback 安装 DOCA-OFED 并检查 IB ofed_info -s、ibstat、NCCL 日志 推理框架 FP8 / Tensor Parallel 依赖框架支持 安装 SGLang / PyTorch cu130 torch.cuda.is_available() 返回 True 模型服务 模型路径、量化配置、TP 参数可能不一致 使用 SGLang 启动 GLM-5.2-FP8 8 个 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 成不成功，而是前面每一层环境，你到底有没有一个坑一个坑验过去。

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