多卡推理集群要面对一个现实模型权重散落在每台机器上节点越多越难管。A 节点还跑着上周的量化版B 节点已经换上新 checkpoint排查「为什么两台机器输出不一样」时第一反应往往是去比对本地缓存。扩容一台新机器光把几十 GB 的权重从 Hub 拉到本地盘就要等半天。把权重收进一个统一的对象存储桶让所有节点只读同一份源这个老问题其实有更省心的解法。权重留在节点本地代价是三件事传统做法里每台 GPU 机器先把模型权重下载到本地盘再起 vLLM表面上各管各的不互相打扰代价会随集群变大显出来。第一是空间浪费。真实 serving 的模型权重比 demo 大得多7B 模型半精度fp16一种用两个字节表示一个浮点的压缩精度约 14GB70B 约 140GB。十台机器各自存一份以 70B 计就是上 TB 的重复占用而且和对象存储、日志、临时文件抢同一块本地盘。第二是版本漂移。权重以文件形式躺在各节点本地没有统一的版本锚点谁先更新、谁没更新很难一眼看清。一次回滚要逐台机器去替换文件容易漏。第三是扩容慢。新节点上线第一件事是下载权重集群越大、模型越大冷启动时间越长。把权重放进 RustFS 这样的对象存储相当于给集群一个单一事实源权重只存一份所有节点以只读方式挂载同一份源换版本靠桶内前缀切换回滚就是换个前缀。在集群里每个 GPU 节点都跑一份只读挂载扩节点不再需要等下载新节点加入时只要挂上同一个桶就能立刻拿到完全一致的那份权重。顺序读大对象的吞吐没有公开基准数字要按自己集群的网络和磁盘去测但「一次上传、处处只读」的架构本身就把上面三件事消掉了。官方已经走通的验证路径RustFS 官方给出了 vLLM 接对象存储的验证流程RustFS 官方 vLLM 集成指南用的是vllm/vllm-openai-cpuvLLM 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-1rc 的命令假设同名别名已配好装好 rc 后先执行rc alias set rustfs http://your-rustfs-endpoint:9000 your-access-key your-secret-keyrc 的安装说明见官方 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-size2g\-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-size2g给 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-size2g或--ipchost。服务退出提示 CPU 内存不够默认的 KV cache推理时缓存的注意力键值预留占系统内存九成用--gpu-memory-utilization 0.15调低这个 flag 名字带 GPU在 CPU 后端同样生效。把权重收进对象存储之后扩容和回滚都从一个桶开始节点本地不再有会漂移的模型副本。RustFS 官方 vLLM 集成指南、S3 兼容性说明和 GitHub 仓库都在官方站点。RustFS 稳定线最新 1.0.42026-10-25Apache 2.0 许可。