模型权重散落在每台 GPU？用 RustFS 给 vLLM 做共享权重库-育师

多卡推理集群要面对一个现实：模型权重散落在每台机器上，节点越多越难管。A 节点还跑着上周的量化版，B 节点已经换上新 checkpoint，排查「为什么两台机器输出不一样」时，第一反应往往是去比对本地缓存。扩容一台新机器，光把几十 GB 的权重从 Hub 拉到本地盘就要等半天。把权重收进一个统一的对象存储桶，让所有节点只读同一份源，这个老问题其实有更省心的解法。

权重留在节点本地，代价是三件事

传统做法里，每台 GPU 机器先把模型权重下载到本地盘再起 vLLM，表面上各管各的不互相打扰，代价会随集群变大显出来。

第一是空间浪费。真实 serving 的模型权重比 demo 大得多：7B 模型半精度（fp16，一种用两个字节表示一个浮点的压缩精度）约 14GB，70B 约 140GB。十台机器各自存一份（以 70B 计），就是上 TB 的重复占用，而且和对象存储、日志、临时文件抢同一块本地盘。

第二是版本漂移。权重以文件形式躺在各节点本地，没有统一的版本锚点，谁先更新、谁没更新很难一眼看清。一次回滚要逐台机器去替换文件，容易漏。

第三是扩容慢。新节点上线第一件事是下载权重，集群越大、模型越大，冷启动时间越长。

把权重放进 RustFS 这样的对象存储，相当于给集群一个单一事实源：权重只存一份，所有节点以只读方式挂载同一份源，换版本靠桶内前缀切换，回滚就是换个前缀。在集群里，每个 GPU 节点都跑一份只读挂载，扩节点不再需要等下载，新节点加入时只要挂上同一个桶就能立刻拿到完全一致的那份权重。顺序读大对象的吞吐没有公开基准数字，要按自己集群的网络和磁盘去测，但「一次上传、处处只读」的架构本身就把上面三件事消掉了。

官方已经走通的验证路径

RustFS 官方给出了 vLLM 接对象存储的验证流程（RustFS 官方 vLLM 集成指南），用的是vllm/vllm-openai-cpu（vLLM 0.30.0）镜像、RustFS 侧用rustfs/rustfs-x86-musl:v2.3.1部署，在纯 CPU 主机上对facebook/opt-125m跑通。思路是：权重留在 RustFS，各节点把桶只读挂载成本地目录，vLLM 当作本地文件读，容器本身无状态。

先把模型上传到 RustFS。用 rclone（一个能把对象存储桶挂成目录的工具）配置指向 RustFS 的 S3 端点，再建桶、拷文件：

[rustfs] type = s3 provider = Other access_key_id = <your-access-key> secret_access_key = <your-secret-key> endpoint = http://<your-rustfs-endpoint>:9000 region = us-east-1

rc 的命令假设同名别名已配好，装好 rc 后先执行：rc alias set rustfs http://<your-rustfs-endpoint>:9000 <your-access-key> <your-secret-key>（rc 的安装说明见官方 rc 手册）。

rc mb rustfs/vllm-models rclone copy ./opt-125m rustfs:vllm-models/opt-125m--transfers4

--transfers 4开四个并发拷贝，文件多的 HuggingFace 目录能明显快一些。每个模型占一个独立前缀（目录），多个模型可以共用同一个桶。

然后在跑 vLLM 的机器上把桶只读挂出来，供其它用户访问：

mkdir-p/mnt/vllm-models rclonemountrustfs:vllm-models /mnt/vllm-models\--allow-other--daemonls/mnt/vllm-models/opt-125m/

最后起 vLLM，把挂载目录以只读方式映射进容器，让它按本地路径读权重：

dockerrun-d--namevllm-p8000:8000 --shm-size=2g\-v/mnt/vllm-models:/models:ro\vllm/vllm-openai-cpu:latest\--model/models/opt-125m --served-model-name opt-125m\--dtypefloat32 --max-model-len256--gpu-memory-utilization0.15

--shm-size=2g给 CPU 引擎的共享内存留出空间，否则张量交换会报/dev/shm不足。等服务就绪，用 OpenAI 兼容接口就能直接打推理请求，Python 客户端不用改一行。

为什么走挂载，而不是直接 s3:// 读

vLLM 0.30 通过内置的 RunAI model streamer（一个负责流式拉取权重的组件）去读s3://路径，但它对自定义 S3 端点的分段读取目前有个硬限制：任何非零偏移的读取都会报File access error，模型权重又正好是分段大文件。于是把桶挂成文件系统、让 vLLM 按本地文件读，成了经过验证的方式。

代价是多了 FUSE（用户态文件系统，把对象存储映射成目录的那一层）这一道。对模型加载这种「一次读一个大文件」的场景，开销基本可以忽略；但如果是极高 QPS 的小文件反复读，FUSE 层会吃一部分性能，那时候该考虑在节点本地加一层缓存，避免反复穿对象存储。

上生产还要补的四件事

官方示例是 CPU 主机的本地集成测试，不面向生产，真要上 GPU 集群还得补几块。

只读挂载加缓存。反复加载同一个模型时，给 rclone 加--vfs-cache-mode full（缓存全部文件内容，重复读不再穿对象存储）和较短的--dir-cache-time，能让节点复用本地缓存、减轻对象存储压力；缓存只是读加速，权威源仍在桶里，换前缀后旧缓存会随目录缓存过期自然失效。调试阶段加--dir-cache-time 10s能避免挂载目录缓存过期导致 vLLM 找不到权重。

先算带宽账。十台节点并发首次加载，入站流量是「模型大小 × 节点数」。一个 70B 模型约 140GB，十台同时冷启动就是 1.4TB 量级的对象存储出口流量，节点网卡和对象存储侧带宽要扛得住，否则首发延迟被下载拖死。

IAM 凭证收窄到只读。给挂载用的 access key 授权vllm-models桶内指定前缀的只读，照官方前缀限权示例的结构写两条语句：s3:ListBucket那条挂Condition的StringLike，把s3:prefix限到opt-125m/*；对象级操作（s3:GetObject）的Resource写成arn:aws:s3:::vllm-models/opt-125m/*。注意内置的readonly策略不含s3:ListBucket，直接拿它挂载会列不出目录，要按这个结构建自定义策略。千万别拿管理员 key 去挂。

多模型靠前缀版本化。一个桶里每个模型一个前缀，发新版本就换新前缀，回滚就是切回旧前缀，天然带版本能力，不用额外数据库记版本。

试完想拆，按官方给的三步走

保留桶、只拆演示环境：docker rm -f vllm停掉容器，再fusermount -u /mnt/vllm-models卸载 rclone 挂载点，不卸的话它会一直挂在目录上。要连桶内模型一起清，最后rclone purge rustfs:vllm-models。

排障顺序与决策清单

真到现场，按这个顺序查：

权重到底传进去了没有：rclone copy之后先rc object list rustfs/vllm-models/opt-125m确认对象在桶里。
挂载点有没有文件：起 vLLM 之前ls /mnt/vllm-models/opt-125m/确认 config、tokenizer、safetensors 都在。
报Unsupported CPU attention configuration: head_dim=...：vLLM 的 CPU 内核只支持有限的 head_dim 集合，hf-internal-testing/tiny-random-*这类微型测试模型会在请求阶段失败，换成真实的小模型，比如facebook/opt-125m。
报Cannot find any model weights with /models/...：挂载目录缓存过期，或权重根本没传，重传一次，并把--dir-cache-time调短到 10s。
报Insufficient space in /dev/shm：容器加--shm-size=2g或--ipc=host。
服务退出提示 CPU 内存不够：默认的 KV cache（推理时缓存的注意力键值）预留占系统内存九成，用--gpu-memory-utilization 0.15调低，这个 flag 名字带 GPU，在 CPU 后端同样生效。