600块钱的「过气」显卡，跑 35B 大模型 32 tokens/s，香疯了

譚策2026年07月25日约 9 分钟

写在前面

“
300块这是我淘一张 Tesla P100 的价格。两张600 块——不到一张 RTX 4090 的70分之一。但就是这两张「爷爷辈」的卡，在我的 R730XD 上，把 qwen3.6:35b 跑到了 32.77 tokens/s ，个人够用~甚至可以说，很爽。

最近在折腾本地大模型部署，手头正好有一台 Dell R730XD 服务器，配了两张 600元淘来的 Tesla P100（16GB × 2）P100 是 2016 年的架构，放在 AI 领域算是"爷爷辈"了——但 32GB 总显存加上双卡协同，跑 35B 级别的量化模型，居然绰绰有余。

本文记录了从零到跑通的完整流程：ESXi 8.0 虚拟化配置 → GPU 硬件直通 → AlmaLinux 10 系统部署 → NVIDIA 驱动安装 → Docker 运行 Ollama → 加载 qwen3.6:35b 模型。

如果你手里也有一台吃灰的旧服务器和几张老卡，这篇就是为你写的。

📋 基础环境一览

层级	配置 / 软件	关键信息
硬件	Dell R730XD + 双 Tesla P100（16GB × 2）	可选 NVLink 桥接器优化跨卡通信
虚拟化层	ESXi 8.0 宿主机	提供 GPU 硬件直通能力
操作系统	AlmaLinux 10.2（Lavender Lion）	兼容 RHEL 生态，适配 NVIDIA 驱动
应用层	Docker + Ollama	部署大模型推理服务，端口 11434
目标模型	qwen3.6:35b 等大模型	依赖双 GPU 分摊显存 / 算力

📋 虚拟机系统信息（单U4核+16G内存）

Linux B-M-ollama 6.12.0-211.22.1.el10_2.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jun 11 08:11:48 EDT 2026 x86_64 GNU/Linux[root@B-M-ollama ~]# cat /etc/os-releaseNAME="AlmaLinux"VERSION="10.2 (Lavender Lion)"RELEASE_TYPE=stableID="almalinux"

一、ESXi 8.0 宿主机与虚拟机配置

1. 开启 PCI 设备直通

依次点击 管理 → 硬件 → PCI 设备，搜索 "NVIDIA"。

选中两块 Tesla P100，点击 切换直通，然后重启 ESXi 宿主机使直通状态生效。

2. 虚拟机硬件设置

创建虚拟机后，进行以下关键配置：

添加 PCI 设备

编辑虚拟机设置 → 添加其他设备 → PCI 设备，依次添加两块 P100。

内存设置

⚠️ 必须勾选"预留所有客户机内存（全部锁定）"，防止内存被抢占导致 PCIe 寻址崩溃。

启动引导，选择 UEFI，并关闭 UEFI 安全引导（Secure Boot）。

高级参数配置

进入虚拟机选项 → 高级 → 编辑配置，添加以下 4 条关键参数：

参数名	值	作用说明
`pciPassthru.use64bitMMIO`	`TRUE`	启用 64 位 MMIO 地址空间，支持大显存 GPU 寻址（必加）
`pciPassthru.64bitMMIOSizeGB`	`64`	双 P100 共 32GB 显存，按 4 倍计算为 128GB，实际配置 64GB 已足够
`hypervisor.cpuid.v0`	`FALSE`	隐藏虚拟化标识，避免部分驱动检测异常
`latency.sensitivity`	`high`	告诉 ESXi 整个虚拟机对延迟零容忍，优化调度

“
⚠️ 注意： 配置了 PCI 直通的虚拟机不支持快照、挂起、vMotion 热迁移，这是 ESXi 的硬限制，务必提前知晓。

二、AlmaLinux 10 系统初始化与内核升级

“
💡 小建议： 安装 NVIDIA 驱动前，先将系统内核升级到最新，避免后续内核更新导致驱动掉线。这是很多新手踩过的坑。

# 安装 EPEL 仓库（包含 dkms 等扩展工具）sudo dnf install -y epel-release
# 开启 CRB 开发者仓库（AlmaLinux 10 必做）sudo dnf config-manager --set-enabled crb
# 将系统内核及基础软件升级到最新sudo dnf update -y
# 重启使新内核生效sudo reboot

三、禁用 Nouveau 开源驱动

重启进入新内核后，执行以下操作彻底禁用系统自带的 Nouveau 驱动：

# 1. 安装编译依赖dnf install -y gcc make kernel-devel-$(uname -r) kernel-headers-$(uname -r) elfutils-libelf-devel dkms
# 2. 写入黑名单配置cat <<EOF | tee /etc/modprobe.d/blacklist-nouveau.confblacklist nouveauoptions nouveau modeset=0EOF
# 3. 重新生成 initramfs 镜像dracut --force
# 4. 重启系统reboot

重启后执行 lsmod | grep nouveau，如果没有输出，说明禁用成功。

四、安装 NVIDIA 官方驱动

下载并安装驱动

以 580.105.08 版本为例：

cd /tmp
curl -L -o NVIDIA-Linux-x86_64-580.105.08.run \  https://us.download.nvidia.com/tesla/580.105.08/NVIDIA-Linux-x86_64-580.105.08.run
chmod +x NVIDIA-Linux-x86_64-580.105.08.run
# 静默安装（跳过 OpenGL 和 X11 检查，启用 DKMS）sudo ./NVIDIA-Linux-x86_64-580.105.08.run --no-opengl-files --no-x-check --dkms -s

验证驱动

nvidia-smi

输出应正确识别两张 Tesla P100。

配置 GPU 持久模式

“
GPU 持久模式可以防止空闲休眠导致的唤醒延迟，生产环境建议务必开启。（systemd，crontab 二选一就好）生产还是建议systemd，可以在后台回复「GPU直通」获取《ESXi GPU 直通避坑清单》，这里使用 crontab 方案，简单可靠：

# 开启持久模式sudo nvidia-smi -pm 1
# 设置开机自启 + 每小时巡检一次echo -e "@reboot /usr/bin/nvidia-smi -pm 1\n0 * * * * /usr/bin/nvidia-smi -pm 1" | crontab -

验证：

crontab -lnvidia-smi -q | grep "Persistence Mode"

五、安装 NVIDIA Container Toolkit

“
这是让 Docker 容器能够调用宿主机 GPU 的核心桥梁，缺一不可。

# 1. 添加 NVIDIA 仓库源curl -s -L https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo | tee /etc/yum.repos.d/nvidia-container-toolkit.repo
# 2. 安装 Toolkitsudo dnf install -y nvidia-container-toolkit
# 3. 自动配置 Docker，注入 nvidia 运行时sudo nvidia-ctk runtime configure --runtime=docker
# 4. 重启 Docker 服务sudo systemctl restart docker

验证容器内双卡识别

docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi

✅ 成功标准： 终端输出中清晰列出 0 号和 1 号两张 Tesla P100。

宿主机层面：  ├── crontab: nvidia-smi -pm 1（开机+每小时）✅  ├── NVIDIA Container Toolkit v1.19.1 ✅  └── Docker nvidia 运行时 ✅
容器层面：  ├── Ollama 镜像: ollama/ollama:latest ✅  ├── --gpus=all 透传 ✅  ├── OLLAMA_SCHED_SPREAD=1（双卡分布）✅  └── qwen3.6:latest 模型已加载 ✅

六、部署 Ollama 双卡服务

1. 创建专属目录

mkdir -p /opt/ollama && cd /opt/ollama

2. 编写 docker-compose.yml

services:  ollama:    image: ollama/ollama:latest    container_name: ollama    restart: unless-stopped    ports:      - "11434:11434"    volumes:      - /opt/ollama/data:/root/.ollama    environment:      - OLLAMA_HOST=0.0.0.0      - NVIDIA_VISIBLE_DEVICES=all      - NVIDIA_DRIVER_CAPABILITIES=compute,utility      - OLLAMA_KEEP_ALIVE=-1          # 模型常驻显存      - OLLAMA_MAX_LOADED_MODELS=1    # 仅加载单模型      - OLLAMA_NUM_PARALLEL=1         # 单路并发      - OLLAMA_FLASH_ATTENTION=1      # 启用 Flash Attention      - OLLAMA_KV_CACHE_TYPE=q4_0     # KV 缓存 4bit 量化      - OLLAMA_TIMEOUT=600      - OLLAMA_CONTEXT_LENGTH=16384   # 双 P100 安全上下文长度      - OLLAMA_SCHED_SPREAD=1         # 强制模型均匀分摊到双卡    deploy:      resources:        reservations:          devices:            - driver: nvidia              count: all              capabilities: [gpu]    shm_size: '16gb'    logging:      driver: "json-file"      options:        max-size: "100m"        max-file: "3"

3. 启动服务

docker compose up -d

“
第一次运行会拉取 Ollama 官方镜像，约 1-2GB，请耐心等待。

七、验证与模型测试

拉取模型

# 拉取目标模型（35B，约 23GB）docker exec ollama ollama pull qwen3.6:35b

运行推理

docker exec ollama ollama run qwen3.6:35b "请简要介绍一下你自己"

查看已下载的模型

docker exec ollama ollama list

双卡负载监控

推理时另开一个终端执行：

watch -n 1 nvidia-smi

正常情况下，两块 P100 的显存均会被占用，模型层已自动跨卡分摊。

🛠️ 补充使用技巧

退出交互模式： 输入 /bye 回车，或按 Ctrl+D

单次测速： 直接把问题跟在命令后面，跑完自动退出：

docker exec ollama ollama run qwen3.6:latest --verbose "用100字介绍一下大语言模型"

检查双卡配置是否生效：

docker exec ollama env | grep OLLAMA_SCHED_SPREAD

输出 OLLAMA_SCHED_SPREAD=1 即为配置生效。

📊 实测性能对比（重点来了）

💡 一句话结论：

MoE 架构下，35B 模型跑得比 14B 还快——架构的进步，比堆参数重要得多。

以下是三个模型在同一台机器上的实际测试数据：

对比维度	qwen2.5-coder:14b	qwen3.6:27b	qwen3.6:35b
模型架构	稠密模型（Dense）	稠密模型（Dense）	混合专家模型（MoE）
总参数量	140 亿	278 亿	360 亿
单次推理激活参数量	140 亿（全量）	278 亿（全量）	约 120 亿
模型文件体积	约 13 GB	约 17 GB	约 23 GB
双卡显存总占用	约 13 GB（单卡可跑）	约 24 GB（双卡分摊）	约 24.3 GB（双卡分摊）
生成速度（eval rate）	16.68 tokens/s	10.41 tokens/s	32.77 tokens/s 🔥
预填充速度（prompt eval）	9.34 tokens/s	0.39 tokens/s	195.37 tokens/s 🔥
默认上下文窗口	32768（32K）	262144（256K）	262144（256K）
最佳适用场景	代码编写、调试	高稳定性长文本场景	日常对话、推理总结

关键发现

“
qwen3.6:35b 虽然是参数量最大的模型，但由于采用了 MoE（混合专家）架构，每次推理只激活约 1/3 的参数，实际速度反而是最快的——32.77 tokens/s，体验非常惊艳。
而 qwen2.5-coder:14b 作为代码专项模型，16.68 tokens/s 的速度也足够日常编码辅助使用。qwen3.6:27b 虽然是稠密模型，但在长文本场景下有其独特优势。

🔗 关于 NVLink

如果 R730XD 安装了 NVLink 桥接器，两块 P100 可通过 NVLink 直接通信，跨卡推理性能会显著高于 PCIe 总线。不过没有 NVLink 也不影响正常运行，双卡照样能协同工作。

检查 NVLink 状态：

nvidia-smi nvlink --status

查看 GPU 连接拓扑：

nvidia-smi topo -m

如果两块 P100 通过 NVLink 相连，矩阵交汇处会显示 "NVLink" 字样，而不是 "PHB"（PCIe 桥连接）或 "PIX"（PCIe 总线连接）。

🔒 防火墙配置

如果需要从外部访问 Ollama 服务：

sudo firewall-cmd --permanent --add-port=11434/tcpsudo firewall-cmd --reload

📝 环境总结

宿主机层面：

✅ crontab 定时巡检 GPU 持久模式
✅ NVIDIA Container Toolkit 已安装
✅ Docker nvidia 运行时已配置

容器层面：

✅ Ollama 最新版镜像
✅ 双 GPU 透传
✅ OLLAMA_SCHED_SPREAD=1 双卡分布
✅ qwen3.6:latest 模型已加载运行

最后说几句

这套配置跑下来，最让我惊喜的是 qwen3.6:35b 的表现。作为一款 MoE 架构的模型，它在双 P100 上跑出了 32+ tokens/s 的速度，日常对话几乎感觉不到延迟，完全达到了可用的水平。

说实话，折腾这一套的过程中踩了不少坑——从 ESXi 的 64 位 MMIO 配置，到 Nouveau 驱动的反复纠缠，再到 Docker 里 GPU 透传的种种细节。但当终端里跳出第一条流畅的回复时，那种成就感，是调用任何云端 API 都给不了的。

接入其它AI工具：

「OpenAI 兼容接口」模式，配置非常简单，核心只需要 3 个信息：

API 基地址（Base URL）：`http://192.168.31.15:11434/v1`
API Key：随便填（比如 `sk-ollama`），Ollama 默认无鉴权
模型名称：`qwen3.6:latest`（必须和本地 `ollama list` 里的名称完全一致）

接入 hermes 试了下，后续打算用云端大模型来指挥本地模型进行Agent协作，这样可以节省点 token 经费。

如果你手头也有旧服务器和 Tesla P100 这类"过气"计算卡，不妨试试这套方案。在 AI 算力昂贵的今天，让旧硬件继续发光发热，本身就是一件很酷的事情。