如果你凑过两台以上带GPU的机器大概能体会那种状态驱动版本不一样CUDA小版本不一样Python环境谁都不服谁好不容易把服务都跑起来了请求又不知道该往哪台机器发。OpenRIG就是在这种背景下冒出来的一个开源项目它把散落在不同机器上的GPU统一暴露成一个逻辑资源池对外提供类似单机API的入口。我把它真正部署进实验室之后多机推理的维护量明显降了一截所以这篇把从选型到落地的完整过程整理出来给正在被多机异构GPU折磨的人做个参考。1. 为什么我会盯上OpenRIG多机异构集群的真实痛点1.1 单机跑推理和集群跑推理不是一回事在单台GPU服务器上做推理你只需要关心三件事驱动装没装对、CUDA版本和框架兼容性、显存够不够。这些坑虽然烦但基本是确定性的问题搜一搜就有答案。等到了多机阶段事情的性质就变了你需要处理节点发现、请求路由、健康检查、滚动升级、故障切换。这些问题在单机上完全不存在但在集群里每一个都可能让你半夜起来处理告警。我最初搭的是两台A100再加一张4090的混合池想着资源越多越好。真正用起来才发现最难受的不是机器性能不够而是调用方不知道应该连哪台连上了也不知道那台机器的显存还剩多少。很多请求打到已经满载的节点上排队排到超时另一台节点却在空转。OpenRIG解决的就是这一层问题——它不替代你的模型推理引擎而是把“一堆机器”包装成“一张资源表”。1.2 OpenRIG与K8s、Ray的分工这里我先说清楚一个容易混淆的点OpenRIG不是K8s的替代品也不是Ray那样的分布式计算框架。它更像一个位于客户端与推理实例之间的智能网关。K8s依然可以管你的容器生命周期Ray依然可以调度复杂的任务图但当你需要对外暴露一个稳定的、具有负载均衡和感知能力的推理入口时OpenRIG能补上这最后一段路。我个人的用法是底层用原生的Docker起推理服务上层通过OpenRIG做统一入口和按需分发。业务方只认一个HTTP地址完全不用关心背后到底有多少台机器。这样分工之后每个人的职责边界都清晰了做模型优化的人只管模型仓库做运维的人只管节点健康做后端的人只管调用协议。如果直接用K8s的Service加上Ingress也不是不行但你要额外写很多自定义调度逻辑而且GPU状态这类信息K8s默认并不暴露。工具主要职责在OpenRIG旁边扮演的角色K8s容器编排、资源调度管理推理实例的运行环境Ray分布式任务/数据流处理训练或复杂并行任务SLURM排队与作业调度面向传统HPC批任务OpenRIG多机GPU统一入口与路由对外暴露稳定推理API1.3 在什么场景下OpenRIG会变成刚需要用OpenRIG前提是你至少有2台以上的GPU主机。但它不仅是数量问题更重要的是异构和分散如果你的机器分布在不同网段或者不同人的手里你无法假设机器之间能互相直连。OpenRIG通过Agent主动回连控制面的方式把NAT后面的机器也能纳管进来这是它和一般负载均衡器最大的差别。此外如果你的业务对高可用有要求比如推理服务不能因为一台机器宕机就中断那么OpenRIG的健康检查和故障摘除功能就是刚需。它会在节点失去心跳之后自动将流量切换到活着的节点上。对我来说真正的触发点是那个周五下午——一台服务器因为内存固件更新静默重启我的推理API用到一个不可用的节点结果整个业务断了40分钟。从那之后我就决定把路由层抽象出来。2. 架构拆解OpenRIG的Control Plane、Agent和路由内核2.1 三个核心组件各自负责什么OpenRIG的架构并不复杂你可以把它拆成三块几乎马上就能记住。第一块是Control Plane也就是控制面它负责维护整个集群的节点清单、心跳信息、路由规则和配置下发。控制面通常是一个无状态服务配合etcd保存元数据这样即使控制面实例重启集群状态也不会丢。第二块是Agent每个GPU节点上跑一个它负责本地设备探测、健康上报、任务代理。Agent会收集显卡型号、显存总量、当前利用率、进程状态等信息以心跳形式上报。最后一块是Router也就是路由内核。它接收外部来的推理请求根据策略选出一个合适的后端节点然后建立一条数据通路完成转发。这些策略包括加权轮询、最少连接、基于标签的亲和路由。在我用的v0.4.x版本里Router是独立进程可以水平扩展多个Router实例共用一个etcd这样入口本身也不容易单点故障。2.2 一次推理请求从进到出的完整生命周期我拿一个真实请求来走一遍流程。业务方POST一个JSON到OpenRIG的HTTP入口Router先做协议解析拿到目标模型名和请求的预算字段接着向Control Plane询问当前可用节点Control Plane返回一个候选列表其中包含每个节点的实时占用率、显存余量、最近一次心跳时间戳Router根据加权最少连接策略选出节点并建立一个内网长连接隧道。隧道建立后Agent在目标节点上把请求转给本地推理进程本地推理进程处理完后原路返回。整个过程中业务方感知不到节点切换。如果节点在推理中途宕机Router会收到连接中断信号将请求快速重试到另一节点重试前会检查请求是否幂等避免重复扣费或重复生成。这套设计很像外卖平台用户下单后平台选店、派单、骑手取餐、送达全程对用户只暴露一个入口。2.3 路由策略与状态同步为什么不直接用NginxNginx当然可以做反向代理和负载均衡但它默认不感知GPU资源状态。你最多用静态权重或ip_hash来做流量切换一旦某个节点的显存已经打满Nginx依然会往上面转发直到请求超时。OpenRIG的优势在于它把“节点健康”和“资源水位”作为路由输入同时通过Agent的心跳信息保持准实时同步。具体到数据一致性Agent默认每5秒上报一次状态如果连续3次没有心跳Control Plane会把节点标记为“可疑”Router就不再派发新请求。相比Nginx需要在每台机器上配脚本去探测这种由Agent主动上报的模型更健壮尤其是在NAT环境下外部探针根本摸不进来。我自己试过用Nginx加健康检查脚本实现结果光维护脚本状态就折腾了很久。3. 从零部署OpenRIG环境、安装与首个节点注册3.1 硬件与软件准备清单先说一下最低配置。Control Plane节点不需要GPU2核4G内存就够但需要稳定的网络和一块SSD。Agent节点必须有NVIDIA GPU驱动版本建议不低于460因为低版本驱动对CUDA 11.x以上的容器运行不友好。操作系统我用的Ubuntu 20.04和22.04内核版本没有特别要求。另外需要Docker 20.10以上并装好nvidia-container-toolkit否则容器里用不了显卡。网络方面建议准备一个至少能容纳200个TCP端口段的地址范围因为OpenRIG会为不同节点的不同服务分配端口映射。如果你打算管理10台机器、每台跑10个模型服务那至少需要1000个端口可用区。第一次部署时我忽视了这个问题结果端口段冲突排查了一下午。3.2 部署Control Plane节点Control Plane我用docker compose直接起顺手把etcd也带上。下面是一个最小可用的compose文件version: 3.8 services: etcd: image: quay.io/coreos/etcd:v3.5.7 container_name: openrig-etcd command: etcd --advertise-client-urls http://127.0.0.1:2379 --listen-client-urls http://0.0.0.0:2379 restart: always control-plane: image: openrig/control-plane:v0.4.2 container_name: openrig-cp depends_on: - etcd environment: - OPENRIG_STORE_ADDRhttp://etcd:2379 - OPENRIG_ROUTER_ADDR0.0.0.0:8080 - OPENRIG_HEARTBEAT_TIMEOUT15 ports: - 8080:8080 router: image: openrig/router:v0.4.2 container_name: openrig-router depends_on: - control-plane environment: - OPENRIG_CP_ADDRhttp://control-plane:8080 - OPENRIG_LISTEN_ADDR0.0.0.0:9000 ports: - 9000:9000如果你打算生产使用建议把etcd部署成3节点集群control-plane和router也各拉一个副本并放到单独的端口和域名后面。如果你只是做验证上面这份配置足够跑通。我初期就是先用单节点确认日志和心跳正常后再加的高可用。3.3 在带GPU的机器上部署Agent并完成注册Agent部署一句话概括在GPU机器上拉容器、挂载Docker socket、跑起来就行。命令大概长这样docker run -d --name openrig-agent \ --gpus all \ --privileged \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /opt/openrig/state:/var/lib/openrig \ -e OPENRIG_CONTROL_PLANE192.168.1.10:8080 \ -e OPENRIG_AGENT_PORT7600 \ -e OPENRIG_NODE_NAMEnode-a100-01 \ -e OPENRIG_LABELSgpua100;archsm80 \ openrig/agent:v0.4.2注意OPENRIG_NODE_NAME要全局唯一建议和机器主机名保持一致。OPENRIG_LABELS是我非常推荐配置的一项它可以把A100、4090这种异构设备打上标签后面路由规则就能按标签精确选择。启动之后观察容器日志出现registered to control plane就说明成功。3.4 验证资源池让多块异构GPU出现在同一张清单里注册完所有节点后用OpenRIG自带的CLI查看集群状态openrig list nodes输出会类似NAME GPU VRAM STATUS LABELS node-a100-01 A100-80G 80G Ready gpua100,archsm80 node-a100-02 A100-80G 80G Ready gpua100,archsm80 node-4090-01 RTX4090 24G Ready gpu4090,archsm89看到三行Ready说明资源池已经建立。这一步很多人会卡在STATUS是Unreachable多半是Control Plane地址配错或者防火墙挡了Agent的TCP回连端口。用openrig inspect node node-a100-01能看到最近心跳时间排查起来比盲猜舒服很多。4. 实战通过OpenRIG统一对外提供vLLM推理服务4.1 配置后端服务与流量比例资源池建好以后接下来就是把实际的推理服务挂进去。以vLLM为例你可以先在每台节点上把vLLM容器跑起来然后通过OpenRIG创建服务并指定流量比例。命令风格大概如下openrig service create chat-llama3-8b \ --model /models/Llama-3-8B-Instruct \ --backend vllm \ --target node-a100-01:8000 \ --target node-a100-02:8000 \ --weights 1:1 \ --availability 0.99这样定义之后Router会把请求按照权重发给两个A100节点。4090的节点我没放进去因为它跑这个模型虽然也能跑但延迟明显比A100差混在一起反而拖慢P99。你可以通过--label gpua100做标签过滤更精确。4.2 动态下发模型参数的好处以前每台机器都要单独SSH进去配环境变量改个tensor_parallel_size都要小心翼翼。OpenRIG提供了service update和运行时参数覆盖你可以直接通过API把VLLM需要的参数下发到目标Agentopenrig service update chat-llama3-8b \ --set max_num_seqs128 \ --set gpu_memory_utilization0.90 \ --set tensor_parallel_size1Agent收到配置变更后会以优雅方式重启本地vLLM容器加载新参数。这个能力在批量替换模型版本时非常好用不用手工登录每台机器。对我这种管着两台A100一台4090的“小作坊”来说省下的时间非常明显。4.3 压测数据和日志解读跑通之后我用wrk做了一轮压测。单机A100直接跑的入口和通过OpenRIG进入的入口模型单次推理本身的延迟差别不大主要差别在高并发时的排队和失败率。我随便取了一组数据场景并发50 P50并发50 P99成功率直连单A100680ms1340ms97.2%OpenRIG-A100池690ms1120ms99.5%OpenRIG的优势不在单次推理变快而在于能把负载分散到两台A100减少单机排队成功率反而上去。日志里可以看到它记录每次请求的路由节点和等待时长这对调优非常有帮助。5. 一路踩过的坑从驱动可见性到长连接保活5.1 Agent容器看不到GPU第一次部署Agent起来后日志直接提示找不到NVIDIA设备。原因有两点一是容器里缺NVIDIA_DRIVER_CAPABILITIES默认只暴露了compute和utility如果你要跑CUDA进程可能需要补video,graphics二是没加--gpus all容器根本没有设备映射。加上之后还需要确认nvidia-container-toolkit是否装好用nvidia-smi在容器里验证一下。真实排查时我最常用的命令是docker exec openrig-agent nvidia-smi如果输出正常但OpenRIG日志还报错那就检查Agent版本和驱动版本的兼容列表。老驱动配新版Agent会偶尔出现显存读取错误但不会直接崩溃。5.2 异构GPU导致vLLM算子崩溃这个问题可能很多人会遇到。同一套vLLM镜像在A100上一切正常拿到4090上启动就报NotImplementedError或者直接段错误。原因是不同架构对FlashAttention的实现、xformers的算子支持不一样。我一开始在Agent启动参数里让所有节点共用一套后端结果4090节点一启动就崩。解决办法是对节点打标签然后给服务指定标签路由让4090和A100各跑各的兼容版本。具体来说我用两套镜像挂到不同标签的节点上即使都叫chat-llama3-8b但内部后端版本不同。OpenRIG服务端配置支持维护“同模型多后端”。5.3 长连接被防火墙掐断运行了大概两天后我发现在晚上某个时间段请求偶尔会超时过一会儿又自动恢复。查看Agent日志发现大量连接重连记录。原因是数据中心防火墙对空闲TCP连接有回收机制15分钟没有数据传输就会被干断。OpenRIG的Agent心跳虽然5秒一次但Router到Agent的长连接可能仍然被判定为“无效空闲连接”。解决方案把客户端和Router之间的TCP keepalive打开并将探活参数调到合理范围sysctl -w net.ipv4.tcp_keepalive_time120 sysctl -w net.ipv4.tcp_keepalive_intvl30 sysctl -w net.ipv4.tcp_keepalive_probes5同时把Agent的心跳间隔从默认5秒改成3秒连续3次丢失才摘除。别把间隔调太短否则流量大时心跳风暴反而会把Control Plane压垮我试过1秒间隔CPU直接飙升。5.4 端口段枯竭问题Agent默认会为每个服务实例占用一个监听端口如果你在3台机器上开了20个模型副本管理面分配的端口段很快就乱套。我第一次部署时没有规划端口结果两个Agent分配到了相同端口请求互相串。后来我统一规划了端口范围Control Plane分配段192.168.1.0/24每个Agent从独立段取端口。另外开启内核端口复用也能缓解压力但要谨慎它会影响本地调度。sysctl -w net.ipv4.ip_local_port_range20000 40000 sysctl -w net.ipv4.tcp_tw_reuse1如果你规划得更细致可以直接在Agent配置里指定port_range比如每个节点只分配7600-8600避免交叉。6. 进阶玩法与投入产出分析6.1 混合调度策略与故障自愈配置基础加权轮询够用但真实场景需要更聪明的策略。我建议在服务级别配置least_conn策略让Router优先选择当前活跃连接数最少的节点这样可以避免某台机器因为单一大请求而误判满载。配置文件大概是这样{ service: chat-llama3-8b, strategy: weighted-least-conn, health_check: { interval: 5, timeout: 2, unhealthy_threshold: 3, healthy_threshold: 2 } }故障自愈我同样打开。Control Plane发现节点心跳丢失后自动把该节点从服务列表中摘除当节点恢复并重新上报心跳后又会自动加回来。这意味着你可以放心踢掉一台机器做维护不需要手工改路由规则。实测下来我拔掉一台A100的网络线业务30秒内切换到了另一台日志只有一条“node removed”。6.2 加入离线批任务的能力扩展OpenRIG主要面向在线推理但我也尝试过把它扩展成批处理调度入口。方法并不复杂把批任务拆成一个个可重试的请求通过OpenRIG入口发送同时把某个节点设置成忙碌状态避免它与在线服务抢资源。这里需要你在后端里实现一个简单的队列OpenRIG负责分发和重试队列负责幂等。这个方案肯定不如Ray或Celery专业但优势是“一套入口同时服务在线推理和离线分析”运维简单。如果你的量没有大到需要独立批处理集群这个做法能省一整套基础设施。6.3 自建机架式GPU池 vs 直接买一台8卡机我的成本测算很多人听说OpenRIG第一反应是“我要不要组一台机架式的GPU池”。这里我给一个很现实的分析。假设你要买8块A100一台8卡服务器加高速NVLink背板整机价格约150万功耗和散热要求都很高而用OpenRIG接现有的2台A100和1张4090约80万硬件成本但重新布线、交换机、管理面节点也要花几万元。关键是OpenRIG能让你把手里已有的零散卡用起来而不是一次性掏大钱。方案硬件成本可扩展性运维复杂度8卡A100整机150万左右固定扩卡难低单机管理多机OpenRIG80万起(已有卡)随买随加零散卡也能用中需维护网关和Agent如果你预算充裕、业务单一不如直接买整机省心。如果你本来就散落了不少卡OpenRIG的“废物利用”价值就很高。这个结论不是劝退而是希望大家别为了用工具而用工具。6.4 给新手的建议哪些人不需要OpenRIG最后简单说个边界。如果你的GPU数量小于两台或者所有机器都部署在同一台K8s集群里且已经有成熟的GPU调度OpenRIG带来的额外收益不大。它是一个“偏门工具”在特定边界异构、异地、NAT、统一入口内特别香但越过这个边界只会增加需要维护的成分。新手入门建议先在两台机器上跑通最小实验不要一上来就规划十个节点。我在实际部署OpenRIG的过程中最大的体会是这类基础设施工具的价值不在于它有多少酷炫功能而在于它是否给你省掉了那些日复一日的重复劳动。多机推理最磨人的地方不是算力不够而是“不知道请求打到哪台机器、那台机器状态如何、挂了之后怎么办”OpenRIG正好把这三个问号一次性解决了。如果你也打算试我建议最开始一定要把节点标签和端口规划做好两小时搞定的事不能因为偷懒省成一个通宵的排查。最后再分享一个小技巧给每台机器写一个固定的“设备卡片”文件记录驱动版本、CUDA版本、可用显存和所属标签加新节点时直接照着填能少一半沟通成本。