★ FEATURED ARTICLE 手里几台带 GPU 的服务器用不起来是件挺让人头疼的事。AI 组的同事天天喊要卡可显卡买回来之后利用率长期在 20% 上下打转训练脚本一跑就是好几个小时轮到推理任务又没人用。我那时候被折腾得没脾气后来盯上了 VMware BitFusion 这套 GPU 池化方案。它能在不拆物理机、不改业务代码的前提下把分散在 ESXi 主机上的 GPU 资源集中成“资源池”谁要用谁去池子里取用完自动释放。这篇文章是“初探”的第一篇只聊环境搭建把我们从零到能跑通bitfusion list这个过程的坑和心得都摊开讲。如果你也在做 AI 基础设施或者手里有虚拟化平台想塞进 GPU 算力这篇应该能帮你少走不少弯路。我不会抄文档就把实际操作时那些版本对了、网络通了、驱动装上之后才跑得起来的关键点讲清楚。基础概念我会用大白话带一下老手可以直接跳到第 3 节看搭建步骤。1. BitFusion 到底解决什么问题1.1 GPU 资源用不起来的老大难传统 GPU 服务器用法很简单显卡插在谁的主板上谁就能用。这在单机场景下没问题但放到虚拟化环境里就很尴尬。虚拟机要 GPU 算力通常只有两条路一是整个显卡直通给某台虚拟机独占所有显存和算力二是走 vGPU 切分把一张卡切成几份每份给一台虚拟机。独占浪费钱切分又太刚性——切出来的份额是死的业务高峰低谷没法互相调剂。BitFusion 的思路不太一样。它把 GPU 从“物理资源”变成“池化资源”。物理显卡还是插在 ESXi 主机上但通过 Bitfusion Server 把算力和显存抽象成可以按需分配的额度。客户端机器不装 GPU 也能跑 CUDA 程序运行的时候通过网络把计算请求转发给远端真正的 GPU。对跑程序的容器来说就像本机插了一张卡nvidia-smi看到的设备是真的但物理硬件在别处。1.2 它和直通、vGPU 有什么本质区别直通是把整卡绑死给一台虚拟机vGPU 是把卡切开固定分配。BitFusion 则是在两者之上加了一层“逻辑调度”。比如池子里有 4 张 A 卡每个卡有 32GB 显存你可以给某个训练任务分配 16GB 显存加部分算力任务结束就回收下一任务接着用。这种粒度比整卡直通细又比 vGPU 静态切分灵活。还有个容易被忽略的点BitFusion 能跨主机池化。一台 ESXi 上的 GPU 不够用了池子里其他主机的卡可以顶上。客户端不用关心自己的请求被调度到了哪台物理机只要池子里有资源就行。这对搞 K8s 或是多租户 AI 平台的同学来说意味着“GPU 资源清单”从“哪台机器有几张卡”这种物理台账变成了“池子里还剩多少可用算力”这种逻辑信息。1.3 这个东西适合谁用我自己总结下来两类场景收益最大。一类是公司里有多台 GPU 服务器但利用率参差不齐有的项目疯狂抢卡有的项目长期闲置另一类是虚拟化平台已经跑了很多虚拟机但个别 VM 偶尔需要 GPU 加速又不想为这“偶尔一次”单独买物理卡。BitFusion 可以在不改业务代码的程度上满足这种需求因为 CUDA 层面的接口被透明接管了。不过它也不是万能药。如果只有一台孤零零的 GPU 服务器那直接用直通更省事没必要引入额外组件。如果你的业务对 GPU 延迟极其敏感、每次推理都压着微秒级算走网络转发的那一跳延迟可能让你难受。先把适用边界搞清楚后面搭建才不会有“我是不是做错了”的困惑。2. 环境规划与前置准备2.1 版本矩阵对不上号是最容易翻车的地方搭建 BitFusion 环境第一道坎不是命令是版本排列组合。我刚开始就吃了这个亏整套环境都装完了客户端list命令一执行就报协议版本不兼容。排查半天才发现是 vCenter 插件和 Bitfusion Server 的版本差了一个小版本接口对不上。我把我这套可用组合列一下供参考vCenter 用 7.0 Update 2 及以上ESXi 也用 7.0 Update 2 及以上版本。Bitfusion 插件版本和 Bitfusion Server Appliance 版本必须严格一致客户端版本可以略低一点但最好也保持一致省得后面测试的时候出现“明明资源有但客户端就是连不上”这种诡异问题。提示如果你所在环境里还有其他虚拟化组件比如 vSAN 或 NSX建议先查一下官方互操作性列表。我遇到过一次 vSAN 集群和 Bitfusion 的存储策略冲突虽然不致命但多花了一下午排查没必要。2.2 硬件层面的硬性要求先说 GPU。Bitfusion Server 对物理 GPU 有要求NVIDIA 的卡基本都能用但驱动必须装在 ESXi 主机上让显卡以直通模式或者 vGPU 模式呈现给 Bitfusion Server 虚拟机。我个人推荐直通模式配置简单直白出问题好排查。vGPU 模式虽然能让一张卡服务更多虚拟机但叠加 Bitfusion 之后再叠加 vGPU 切分排障链路太长不适合第一次上手。内存方面别抠门。Bitfusion Server 虚拟机本身不直接跑大模型推理它只做资源调度和显存映射但因为有页表缓存和内存映射表的开销8GB 内存起步16GB 更稳。我见过有人在 4GB 内存的 Server 上硬跑结果同时挂两个客户端Server 直接把 CPU 打满然后整池子的任务全部超时。网络这里重点说两句。BitFusion 的 GPU 调用走网络客户端和 Server 之间要传输 CUDA 调用和显存数据。千兆网络理论够实际用起来明显卡顿训练类任务会拖慢好几个数量级。有条件直接上万兆至少也要 10GbE 或者 25GbE。没有万兆网络别对 BitFusion 的推理延迟抱太大期望物理规律绕不过去。2.3 许可和账号准备BitFusion 的 license 是和 vCenter 绑定的需要一个有效的 vSphere Enterprise Plus 许可或者单独的 Bitfusion 许可文件。安装插件的时候会让填 license 文件路径我当时图省事没导入结果插件界面能看到但创建池子的时候一直报授权不足。所以第一件事就是先准备好 license别等界面都点开了再回头找。账号权限也得提前划好。安装插件需要 vCenter 管理员权限部署 Server 需要能在目标 ESXi 主机上创建虚拟机的权限客户端接入需要知道 Server 的 IP 和认证方式。BitFusion 客户端默认用的是基于用户名的认证Server 上要提前加好用户并分配额度不然客户端连上了也申请不到 GPU 资源。最后说一个经常被忽略的东西NTP 时间同步。BitFusion 的客户端和 Server 之间通信带时间戳校验如果两边时间差超过一定范围握手会直接失败。我遇到过两次一次是客户端跑在笔记本上没开时间同步一次是 Server 虚拟机忘了配 NTP报错信息还特别隐晦只说“connection failed”。所以环境规划阶段就把 NTP 配好能省不少事。3. 服务器端搭建全流程3.1 安装 vCenter 里的 BitFusion 插件整个过程的第一步是在 vCenter 上注册 Bitfusion 插件。简单说就是把下载到的插件包通过 vCenter 的“更新”或“插件管理”入口导入进去。不同版本入口名字可能不一样但逻辑相同上传插件 zip 包填 vCenter 地址等它部署完成。我建议用 vCenter 自带的插件管理功能来装不要手工往目录里拷文件。手工拷容易漏文件而且版本控制会乱。插件装好之后vSphere Client 界面的左侧导航栏或者“主机和集群”里会多出 Bitfusion 相关的菜单项如果没看到多半是插件服务没起来去 vCenter 的“服务”里把 Bitfusion 相关服务状态确认一下。注意插件安装和 Server 部署是两个动作别混在一起。插件只是让 vCenter 具备管理 Bitfusion 资源的能力真正提供服务的是后面部署的 Server 虚拟机。3.2 部署 Bitfusion Server 虚拟机Bitfusion Server 是以 OVA 模板形式提供的。在 vSphere Client 里找到 OVA 文件用“部署 OVF 模板”向导导入。这一步和部署普通虚拟机差不多但有几个坑需要注意。存储位置别选共享存储太满的数据存储Server 虚拟机会有一些小的状态写入需求存储满了会导致调度服务直接挂掉。网络这里必须选对端口组Server 虚拟机的 IP 要能和客户端互通而且最好用静态 IP。我当初图省事用了 DHCP后来重启了 Client 或者 ServerIP 变了客户端配置里面的 Server 地址就失效了排查半天才想起来是地址变了。部署完成后虚拟机的配置不用太豪华。CPU 4 核左右、内存 8GB 起步硬盘默认给的 30GB 够用。如果后续想把 Bitfusion 临时缓存放大可以再加一块数据盘。启动虚拟机后需要通过控制台访问它的管理界面做初始化设置管理员密码、时区、NTP 服务器地址这些基础参数。初始化完成之后虚拟机会给你一个管理 IP用浏览器访问这个 IP 的管理界面能看到 Bitfusion Server 的状态面板。在这个面板里核对一下版本号和 vCenter 插件版本是不是一致不一致就先升级一方的版本再继续别抱着“先跑起来后面再说”的心态后面报错更难查。3.3 ESXi 主机 GPU 配置与识别Server 虚拟机起来之后最核心的一步是把物理 GPU 挂给它。我先在 ESXi 主机上通过直通设置把网卡和显卡都设为直通模式然后关机状态编辑 Server 虚拟机的设置添加 PCI 设备选择那张 NVIDIA 显卡。这里有个经验添加完 PCI 设备后启动虚拟机前一定要去 BIOS 级别确认直通已经生效。不同 ESXi 版本对直通卡的呈现方式有点不一样有的在虚拟机设置里能看到“NVIDIA”字样有的只看得到 PCI 地址。如果虚拟机启动后依然看不到/dev/nvidia0这种设备节点或者lspci没有输出 GPU 信息说明直通没成功重启主机之后再看。还有个常被忽略的点物理显卡直通后ESXi 主机上的vmkernel就不能再使用这张卡了。如果这台主机上有其他虚拟机也依赖同一张卡输出显示那它们会受影响。我在实验室里无所谓但如果你们的生产环境里有 VM 用显卡做虚拟显示就要提前协调好。GPU 识别成功后在 Bitfusion Server 虚拟机里跑一次nvidia-smi能看到显卡型号和显存大小说明物理链路已经通了。注意nvidia-smi显示的 GPU 是在 Server 虚拟机内部看到的这是正常的。Bitfusion 池化后客户端看到的会是虚拟出来的“GPU 设备”而不是物理卡的型号。3.4 初始化资源池与用户权限Server 虚拟机起来、GPU 识别正常接下来就是在 vCenter 的 Bitfusion 管理界面里创建资源池了。说白了就是把哪些 ESXi 主机上的哪些 GPU 纳入池子统一管理。创建池子的时候会让你填 GPU 设备的维度比如每张卡分配给几个实例、每个实例占多少显存。我建议第一次实验先不要切太细一个池子对应一张物理卡然后给单个任务分配 16GB 显存这样更容易验证链路是否通畅。等后面熟悉了再去调整切分比例。用户权限管理这块Bitfusion 支持从 vCenter 同步用户也支持在 Server 本地建用户。我推荐用本地用户做初期测试命令简单、依赖少。在 Server 管理界面里添加一个测试用户给一个默认的显存配额比如 8GB。这个额度就是客户端申请 GPU 时的上限给太小了后面跑模型容易直接 OOM。配置完可以在管理界面看到池子里 GPU 的总计、已分配、剩余情况。我当时截了个图对比客户端看到的列表发现两边显示一致就说明服务端配置基本到位了。4. 客户端安装与配置4.1 客户端安装的必要条件客户端要访问 BitFusion 池子并不需要本机插 GPU但需要装 Bitfusion Client 软件包。这个包在 Bitfusion Server 的下载页面或者 vCenter 的 Bitfusion 插件界面里能找到。支持的系统主要是 Ubuntu 和 CentOS 系Windows 不原生支持想用的话得绕道 Linux 容器。安装过程很简单解压 tar 包执行里面的 install 脚本。脚本会检查内核模块、安装命令行工具、配置服务自启动。装完之后执行bitfusion version能输出版本号就说明客户端壳子装好了。这里有个关键环境CUDA 驱动不需要装但 CUDA toolkit 还是需要的。因为 BitFusion 接管的是 CUDA 运行时层面的调用上层业务代码还是需要本地有 CUDA 相关的库来编译和加载。我当时图省事全都不装结果客户端程序编译的时候直接找不到cuda_runtime.h白瞎了一个小时。4.2 配置 Server 地址与认证信息客户端装好后第一件事是配置 Server 地址。这个配置在/etc/bitfusion/bitfusion-client.conf文件里内容大致是server 10.0.0.20:5544这种格式。如果有多个 Server可以写多行客户端会自动负载均衡或者按顺序连接。然后是认证。BitFusion 客户端连接 Server 需要用户名和密码这个密码是 Server 上创建用户时设置的。初次配置可以用bitfusion auth add --server ip --username user命令把凭据保存起来输入密码后会自动写入密钥文件。提示密钥文件权限要注意默认是 600 权限如果权限不对客户端连接时会直接拒绝读取凭据。我当时不小心chmod 777了这个文件结果所有连接动作都报“permission denied”一度以为 Server 挂了。配置完成后执行bitfusion list --show-all看看能不能拿到池子信息。如果能列出 GPU 的型号、显存大小和状态说明客户端和服务端的通信链路已经通了。我第一次看到列表刷出来的时候挺兴奋的说明环境搭建这一步算基本走通了。4.3 用一条命令验证整条链路环境通没通最终要看能不能真的跑 CUDA 程序。BitFusion 的用法是在正常命令前加bitfusion run后面跟上--server ip --gpu-count 1这种参数。比如bitfusion run --server 10.0.0.20 --gpu-count 1 -- nvidia-smi这条命令会把nvidia-smi的调用转发到远端的 GPU 上。如果输出显示的是远端卡的信息那链路就是通的。更魔幻一点的验证是用 Python 调 PyTorchbitfusion run --server 10.0.0.20 --gpu-count 1 -- python -c import torch; print(torch.cuda.is_available())正常输出是True这表示 PyTorch 能通过 BitFusion 看到虚拟 CUDA 设备。这一步通过后环境搭建就算真正完成后面可以拿真实的模型脚本做迁移测试了。有个容易踩的坑--gpu-count不能超过池子里单个虚拟 GPU 实例的显存配额。如果你在 Server 端配的是 16GB 一个实例那客户端请求 2 个 GPU 就意味着要 32GB 显存池子里没有这么多就会申请失败。我第一次跑的时候忽略了这点报错还特别隐晦老让我去看网络配置后来才发现是资源申请超了。5. 踩坑排查与常见问题实录5.1 三张毛病表对照自查搭建过程中遇到的坑我整理成三张自查表按层归类排查的时候从下往上筛效率高很多。第一张表是关于网络与连通性的现象可能原因排查方向客户端连接 Server 超时Server IP 配置错误或网络隔离先pingServer IP再telnet ip 5544测试服务端口连接成功但列表为空池子里没有可分配的 GPU 实例登录 Server 管理界面检查池子状态和 GPU 是否识别命令执行缓慢节点间走千兆网络确认客户机和 Server 在同一个二层网络或低延迟链路中第二张表是关于 GPU 与驱动的现象可能原因排查方向Server 虚拟机nvidia-smi无输出直通未生效或驱动未装检查虚拟机 PCI 设备列表确认驱动安装日志无报错池子状态显示 GPU 异常ESXi 主机重启后直通配置丢失到 ESXi 主机硬件配置里再次确认直通状态并重新添加设备nvidia-smi 显示的卡和物理卡不一致多个直通卡被认成同一设备用lspci核对 PCI 地址与物理插槽的对应关系第三张表是关于认证与权限的现象可能原因排查方向报 authentication failedServer 上用户不存在或密码错到 Server 管理界面重置用户密码确认客户端用户名一致查询列表提示 no permission用户没有关联到资源池在 Server 管理界面给用户绑定池子并分配配额配额不足申请失败用户额度小于客户端请求显存调大用户配额或者减少--gpu-count请求数量5.2 一个真实的排查案例莫名连接失败说一个我印象很深的案例。环境全都搭好了头一天还能正常跑通第二天一上班发现所有客户端都连不上 Server。ping通了端口也通日志里没有任何错误。最后发现是 Server 虚拟机的时钟漂了NTP 服务没起来客户端和 Server 的时间差超过了安全范围直接拒绝握手。这个案例提醒我一件事BitFusion 环境里的时间同步不是“锦上添花”而是“底层要求”。现在我在部署 Server 虚拟机时初始化环境就强制配置 NTP并且在 ESXi 层面也统一时间源避免因为宿主机时间不准导致虚拟机和外部时间不对称。另一个我记得挺牢的小问题升级 vCenter 或 ESXi 后Bitfusion 插件可能失效。一旦 vCenter 侧升级了插件也要跟着升不然管理界面里 Bitfusion 菜单会消失或者点了没反应。我在实验室里经历过一次升级 vCenter 后整个 Bitfusion 菜单消失当时以为环境被销毁了查了一圈才发现是插件版本不匹配。5.3 绕开这些坑的独家技巧排查顺序这事值得单独说因为很多人习惯先从报错信息下手但在 BitFusion 这种多层架构里报错信息往往只是“结果”不是“原因”。我自己的排查顺序是网络层ping/telnet→ 服务层服务状态/版本匹配→ 资源层GPU 识别/池子状态→ 认证层用户名/配额→ 应用层CUDA 库/业务代码。每一层确认无误再往上走能少走很多弯路。还有个小技巧实验阶段给 Server 虚拟机做快照。每次调整完配置、验证通过之后拍一张快照后面无论是升级还是误操作回滚都很快。尤其是刚接触的时候一天改十几次配置出问题直接恢复快照比自己一点一点排查快得多。日志位置也要有数。Server 管理界面能导出的日志包括调度服务的运行记录客户端的日志则在/var/log/bitfusion目录下。遇到连接问题先看客户端日志里面会把握手失败的原因写得相对清楚。比看 Server 日志效率高。6. 环境搭完之后的一些体会环境跑通之后我心里其实挺感慨的。原来觉得 GPU 池化是个很玄的东西真搭一遍才发现只要版本对上、网络通、直通卡认出来后面的池化调度反而是最顺滑的环节。集群里那几张闲置卡的利用率经过这轮搭建明显上了一个台阶后续再跑模型也不用天天去问“这张卡是谁在用”了。如果试着给准备上手的朋友一个建议那就是第一次做环境越简单越好。一台 vCenter一台 ESXi一张 GPU一台 Server 虚拟机一台客户端机器跑通之后再往上加。别一上来就搞多集群、多主机、多 GPU 的复杂拓扑任何一个环节出问题排查的复杂度都会指数级上升。我一开始就是贪多三台主机同时配结果出问题时候根本分不清是哪个节点的配置不对。再分享一个后来觉得特别有用的做法把所有版本、IP、账号密码、GPU PCI 地址都记录在一个文档里每次变更都同步更新。听起来像土办法但就是因为 BitFusion 涉及的组件太多一个源头的错位会引发一连串莫名其妙的报错有份记录能省下大把时间来排查“到底是谁变了”。下一篇等我实际跑几个训练和推理任务之后再写写 BitFusion 的算力分配、显存配额和性能损耗这些更贴近业务的东西。环境搭建到这里算是有个能继续往下折腾的地基了。
阅读完成 · 觉得有帮助？
