2.1 模型权重上线：PVC、本地盘与镜像预热的完整取舍

2.1 模型权重上线：PVC、本地盘与镜像预热的完整取舍

读者读完这节能带走什么：你会知道 GLM-5.2 这几十 GB 的权重到底该放在 Kubernetes 的哪里、为什么绝不能让 Pod 每次启动都去联网下载，以及 PVC、节点本地盘、共享文件系统三条路各自的代价，最后能亲手写出一套「权重就位 → 容器只管加载」的部署骨架。

上一章我们把集群、GPU、框架都盘点清楚了。现在进入真正动手的部分。很多人一上来就想着写 Deployment、拉镜像、跑起来，结果第一个卡点根本不是模型能不能推理，而是几十 GB 的权重放哪、怎么被 Pod 稳定读到。这一节我们就把这个「地基」问题彻底讲透，因为它决定了后面所有部署动作是顺滑还是处处踩雷。

为什么权重存储是第一个必须想清楚的问题

先建立一个基本认知：Kubernetes 里的 Pod 是「临时的、可被随时销毁重建的」。这是它的设计哲学——Pod 挂了就重新拉一个，节点故障就漂移到别的节点。这对无状态的 Web 服务是天大的好事，但对推理服务是个隐藏陷阱：如果你的模型权重跟着 Pod 走，那每次 Pod 重建就意味着一次几十 GB 的重新准备。

GLM-5.2 的权重规模不小。假设它是一个动辄几十 GB 甚至上百 GB 的模型文件集合（具体体积以官方模型卡公布为准），你会立刻面对几个现实问题：

• 如果让容器启动时才去 Hugging Face 或 ModelScope 联网下载，那么一次冷启动可能要等十几分钟甚至更久，且完全受制于网络带宽和境外连接质量。
• 一旦 Pod 因为探针失败、节点维护、扩容缩容而重建，这个漫长的下载过程会重复上演，服务可用性直接崩塌。
• 多副本场景下，每个副本都独立下载一遍，既浪费带宽又浪费磁盘，还可能触发下载源的限流。

所以第一条铁律必须刻在脑子里：权重是「准生产资产」，要提前放到持久化存储里，让容器只负责加载，不负责获取。想明白这一点，后面的方案选择就是在「怎么持久化」上做权衡。

三条主流路径：PVC、节点本地盘、共享文件系统

在 Kubernetes 里把权重持久化，主流有三条路。它们没有绝对的优劣，只有适不适合你的场景。我先把结论摆出来，再逐条拆解代价。

路径一：PVC 持久卷——最通用的起点

PVC（PersistentVolumeClaim，持久卷声明）是 Kubernetes 抽象存储的标准方式。你向集群「申请」一块存储，底层可能是云盘、Ceph、本地 PV 等，具体由 StorageClass 决定。

对权重存储来说，典型用法是：申请一块 ReadWriteOnce（单节点读写）的卷，第一次用一个准备任务把权重下载或拷贝进去，之后推理 Pod 以只读方式挂载这块卷，直接加载。

它的优点非常突出：简单、通用、与具体节点解耦。你不用关心权重到底躺在哪台物理机上，Kubernetes 帮你处理挂载。对于刚上手、单副本或副本数不多的场景，PVC 几乎是默认最优解。

它的缺点也要看清楚：ReadWriteOnce 意味着同一时刻只有一个节点能挂载读写。如果你想让分布在多个节点上的多个副本同时读同一块卷，就需要 ReadWriteMany，而这依赖底层存储支持（很多块存储并不支持多写）。另外，如果底层是网络云盘，读取带宽可能不如本地 NVMe，模型加载会慢一些。

路径二：节点本地盘——追求极致加载速度

第二条路是把权重直接放到 GPU 节点的本地磁盘（尤其是本地 NVMe SSD）上，Pod 用 hostPath 或 Local PV 挂进去。

它的核心优势是读取速度最快。本地 NVMe 的顺序读带宽通常远高于网络存储，几十 GB 的权重加载能明显缩短。对启动速度极度敏感、或者模型特别大的场景，这是最优体验。

但代价同样明确：Pod 和节点被强绑定了。如果一个 Pod 被调度到没有预放权重的节点，就会加载失败。要解决这个问题，通常有两种手段：一是用 nodeAffinity（节点亲和性）把 Pod 牢牢钉在放了权重的固定节点上；二是用 DaemonSet 或预热任务，提前在所有候选 GPU 节点上都分发一份权重。前者牺牲了调度灵活性，后者增加了磁盘占用和分发成本。

我的判断是：如果你的 GPU 节点数量固定、且追求最佳加载体验，节点本地盘 + 节点亲和是很实在的方案；但如果你的集群节点经常变动、需要灵活漂移，本地盘的绑定就会成为运维负担。

路径三：共享文件系统——为多副本横向扩展铺路

第三条路是用 NFS、CephFS、云厂商的共享文件存储（如 EFS 类产品）等，天然支持 ReadWriteMany，多个节点上的多个 Pod 可以同时挂载、同时读。

它的价值在横向扩展场景下才真正显现：当你要跑很多个副本来扛并发时，共享文件系统让所有副本共用一份权重，既省磁盘又省下重复分发的麻烦，扩容一个新副本几乎是「即插即读」。

但它的软肋是网络带宽可能成为加载瓶颈。所有副本同时冷启动、同时从共享存储拉几十 GB 权重时，网络和存储后端会承受巨大压力，加载反而变慢。因此共享文件系统更适合权重不算特别巨大、且副本数较多的场景，同时最好配合错峰启动或本地缓存来缓解带宽压力。

我的建议：从 PVC 或本地盘 + 亲和起步

讲了三条路，读者最想要的其实是一句可执行的主张。我的建议很明确：生产环境优先选 PVC，或者「节点本地盘 + 节点亲和」，先把单副本稳稳跑通，再谈横向扩展。

原因也很朴素。推理服务对两件事最敏感：一是「加载延迟」，决定了你的服务重启后多久能恢复；二是「读取带宽」，决定了大模型加载会不会拖成几分钟的等待。本地盘在这两点上体验最好，PVC 则胜在通用和运维简单。共享文件系统虽然优雅，但它的价值只在多副本时才兑现，过早引入反而会被带宽问题反咬一口。

换句话说，不要为了还没到来的扩展性，牺牲现在就能拿到的稳定性。90% 的人在这一步会犯的错，是一上来就照搬网上「高可用多副本 + 共享存储」的架构图，结果单机都没跑顺，就被网络存储的冷启动带宽问题卡在门外。

关键实现：让容器只管加载，不管获取

无论选哪条路，都有一个共同的工程原则必须坚持：不要在推理主容器里写下载逻辑。原因是主容器应该职责单一——它只负责「把已经就位的权重加载进 GPU、对外提供推理」。下载、校验、解压这些「准备动作」应该交给专门的角色。

在 Kubernetes 里有两种干净的做法：

第一种是用 Init Container（初始化容器）。它在主容器启动前运行，负责把权重从远端拉取或校验到共享的卷上，完成后自动退出，主容器再启动挂载。这样即使准备逻辑复杂，也不会污染主容器。

第二种是用独立的 Job。你单独跑一个一次性任务，把权重灌进 PVC 或本地盘，跑完就结束。之后所有推理 Pod 都直接以只读方式挂载这块已经就位的存储。这种方式特别适合「权重准备一次、长期复用」的生产场景。

这里再补一个容易被忽略的细节：权重和推理镜像是两回事，都要预热。权重解决的是数据就位问题，镜像解决的是运行环境就位问题。vLLM 官方通常提供自带 CUDA 的镜像（如 vllm/vllm-openai），这个镜像体积不小。如果 GPU 节点第一次拉这个镜像，ImagePull 阶段就可能耗掉十几分钟。建议提前在 GPU 节点上 docker pull 或配置镜像预热策略，别让首次调度卡在拉镜像上。

一份可参考的存储骨架

把上面的原则落成一段可读的配置骨架，帮助你建立直观印象。下面这段以 PVC 挂载为例，展示推理容器如何以只读方式使用已经就位的权重目录（模型 repo 名和路径请以官方模型卡为准，示例仅表意）：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: glm52-weights
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 200Gi        # 依据实际权重体积留足余量
---
# 推理 Deployment 片段: 只读挂载权重卷
spec:
  template:
    spec:
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args:
            - "--model"
            - "/models/glm-5.2"   # 指向已就位的本地路径, 而非远端 repo
          volumeMounts:
            - name: weights
              mountPath: /models
              readOnly: true
      volumes:
        - name: weights
          persistentVolumeClaim:
            claimName: glm52-weights
​

注意这里的两个关键点：一是 --model 指向的是容器内的本地路径 /models/glm-5.2，而不是远端仓库名，这正是「只加载不下载」的体现；二是权重卷以 readOnly: true 挂载，防止推理进程意外写坏权重。这两个小习惯能帮你省掉大量线上事故。

一个真实会遇到的对比：三种方案的启动耗时直觉

光说原理不够直观，我给你建立一个「量级直觉」，帮你在选型时心里有数。注意这里给的是相对量级的思维方式，不是精确数字，实际值取决于你的硬件和权重体积。

假设权重是几十 GB 这个量级。如果走联网下载，冷启动可能是「十几分钟」这个量级，且极不稳定——境外网络一抖动，时间还会翻倍，这是最糟的选择。如果走共享文件系统，多副本同时冷启动时，网络带宽被瓜分，加载可能落在「数分钟」这个量级，单副本时会好一些。如果走 PVC 云盘，读取受云盘带宽限制，大致在「一到数分钟」量级，胜在稳定可预期。如果走节点本地 NVMe，顺序读带宽最高，通常能压到「一分钟以内」这个量级，是体验最好的一档。

把这个量级表记在心里，你就明白为什么我反复强调「别让容器联网下载」——它比最差的持久化方案还要慢一个数量级，而且不可控。而在几种持久化方案之间做选择时，本质上是在「加载速度」和「运维灵活性」之间做权衡：越快的方案（本地盘）绑定越紧，越灵活的方案（共享存储）速度越受带宽制约。没有免费的午餐，只有适合你场景的取舍。

容易被忽略的三个运维细节

除了主线的存储选型，还有三个实操细节，踩过一次就再也不会忘。

第一，权重目录的完整性校验。几十 GB 的文件在下载或拷贝过程中可能损坏、可能只传了一半。如果不校验就直接让 vLLM 加载，你会得到各种莫名其妙的加载错误，还很难定位。建议在准备阶段（Init Container 或 Job 里）对关键文件做一次校验，比如比对文件大小或哈希，确认完整后再放行主容器加载。这个动作花不了多少时间，却能省掉大量排查成本。

第二，存储容量要留足余量。申请 PVC 或规划本地盘时，不要卡着权重体积的精确大小去申请。模型加载、日志、临时文件都会占空间，而且你可能后续还要放多个模型版本做对比。一个经验值是：至少按权重体积的 1.5 到 2 倍来规划存储容量，避免上线后因为磁盘写满导致服务异常。

第三，只读挂载是一种保护。前面示例里权重卷用了 readOnly: true，这不是可有可无的装饰。推理进程理论上不应该修改权重，但一旦某个 bug 或误操作写坏了权重文件，所有挂载这块卷的副本会一起中招。只读挂载相当于给权重加了一道保险，成本几乎为零，收益却很实在。这类「零成本的防御性习惯」，正是区分业余和专业部署的细节。

本节小结

• Pod 是临时的，权重必须提前落到持久化存储，绝不能让容器每次启动都联网下载几十 GB。
• 三条路径各有取舍：PVC 通用解耦、本地盘极速但绑节点、共享文件系统利于多副本但受带宽制约。
• 我的主张是：生产优先 PVC 或「本地盘 + 节点亲和」，先把单副本跑稳，再谈横向扩展，别为未到来的扩展性牺牲当下的稳定性。
• 工程原则：主容器只管加载，用 Init Container 或 Job 完成权重准备；权重和镜像都要预热，避免首次调度卡在下载和 ImagePull 上。

想清楚了「权重放哪」，我们下一节就正式动手写 Deployment，把 vLLM 真正跑起来——并逐行拆解那几个最容易埋雷的参数。