# B300 部署 GLM-5.2-FP8 实测：这机器贵得离谱又难买，但我们真搞来一台 8 卡跑了一遍
> 作者/来源: UCloud 运营管理员
> 发布时间: 2026-08-17T07:04:46.195Z
> 分类: GPU
> 标签: FP8, B300, 部署实测, GLM-5.2, SGLang
> 原文链接: http://117.50.162.249:3000/yun/articles/2722
---
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。多机训练或
- 模型路径不存在；
- 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 |
我的解读是：
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.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` 成不成功，而是前面每一层环境，你到底有没有一个坑一个坑验过去。
***注：本次测评由优刻得技术研究院支持，包含部署环境、设备等资源。***