权重与镜像怎么铺到集群：分发、校验、缓存与回收

说明本文讨论的是模型权重与运行时镜像这类大体积制品怎么分发到集群各节点、怎么校验、怎么缓存与回收属于 AI 运维话题不涉及具体模型版本与价格。AI 领域版本迭代极快凡涉及版本号、价格、可用性请以你阅读时的官方页面为准。文中代码为结构示意请按自己的技术栈调整后再上生产。一、权重体积带来的三类问题权重和运行时镜像是同一类东西体积大、内容固定、被反复读且是节点驱动而非请求驱动——每多一个节点就多一份完整拷贝。普通应用的代码包在 MB 级、每次发布都换这两类制品在 GB 级示意值一个版本要在集群里活很久。由此带来三类问题各有独立处置手段。1.1 传输耗时把带宽吃满一次拉取的时间由三件事决定制品体积、链路可用带宽、并发拉取的节点数。内网出口带宽是固定的示意值节点少时每个都能跑满自己的链路节点数增加后出口成为公共资源每个节点分到的带宽下降单节点耗时随之上升。耗时曲线因此不是线性的节点数从 8 增到 32单节点分发时间可能不止涨 4 倍——这也是第 2 章要引入内网缓存层的原因。1.2 多版本共存把存储水位推高一次发布不是一个版本在动至少两个版本并存新版本铺开旧版本留给回滚。灰度期间还要再叠一层可能三到四个版本同时在盘上。每个版本占一份完整体积再乘节点数量单机盘容量不变版本数上升就意味着水位上升。而权重目录是启动依赖不会被就近清理——删错一个目录节点重启就起不来。所以水位不是被用满的是被「不敢删」堆满的。1.3 同一版本在多个节点上不一致分发天然不是原子的节点 A 已开始服务节点 B 还在拉节点 C 拉了一半失败退回旧版本。混合状态本身不一定是故障滚动发布就是要混合。问题在于它对集群外不可见没有地方记录「哪个节点跑哪个版本」出问题只能逐台上机翻目录。所以版本一致性不是消灭混合而是让混合可查询、时间窗口有上界。问题触发条件直接代价常见误判带宽被吃满多节点同时拉取出口带宽固定单节点耗时非线性上升业务侧延迟被牵连以为耗时只和制品体积有关存储水位偏高多版本并存回滚版本不敢删盘容量放不下下一个版本把水位问题当成容量问题版本状态不可见分发无统一记录节点各自为政故障排查只能逐台上机以为滚动发布本就混合不必管三类问题的解法不同分别靠分发拓扑、回收策略、状态记录。二、分发路径选型四条路径不是互斥选项是同一条链路上的四段多数集群同时用其中两到三段。选型看边际成本第一个节点拿到制品要多久第 N 个节点要额外付多少。2.1 四条路径各自在做什么对象存储直拉节点启动时从对象存储或镜像仓库的 blob 接口直接拉取。链路是存储到节点每个节点独立拉互不共享。实现最简单代价是每个节点都从同一出口取一份。打进镜像层把权重烘焙进容器镜像的某一层节点拉镜像时权重随之落地。它把分发并进镜像分发路径省掉一套拉取逻辑代价是镜像体积暴涨每次权重更新都要重推一个大镜像层且缓存策略不由你控制。内网分发与分片共享集群内先落一份或几份节点从内网节点取或把制品切成分片、由多个节点互相交换。出口带宽被摊薄成内网带宽边际节点耗时明显下降代价是多一层要维护的服务多一份内网缓存占的盘。预置盘装机时或节点空闲窗口把权重预先写入本地盘启动时直接挂载。分发耗时对启动路径为零代价是版本更新滞后盘上是什么版本就是什么版本。2.2 四条路径对照路径首节点耗时新增节点边际耗时带宽去向版本切换代价主要代价对象存储直拉由体积与链路定高与节点数近似线性出口带宽被 N 份占满低换路径即可出口成为瓶颈打进镜像层由镜像层大小定高且受镜像层缓存影响镜像分发通道中要重推一层镜像体积膨胀缓存不可控内网分片共享略高于直拉低分片并行摊薄出口少、内网多低多一层服务内网缓存占盘预置盘近零近零不走运行时链路高要重写盘版本滞后需维护写入流程表里耗时方向是结构性的数值随体积与链路变化均为示意。2.3 选型判据与组合选型看三件事的组合节点规模、版本切换频率、能否预置。节点少、版本切换频繁时对象存储直拉最省事节点多又没有内网缓存层时直拉会把出口打满要在前面加一层内网分发或分片共享。预置盘适合节点多、版本几个月才动一次的场景它把版本更新成本推进发布流程。常见组合是两段外层拉到每个机架或可用区一份内层在该机架或区内做分片共享出口只承受机架数量级的并发。⚠️ 代码待验证# Two-stage distribution: pull once per rack, then share shards inside the rack.# Keep every version directory read-only after it lands on disk.ARTIFACTmodel-weights# artifact name, not a model nameDEST/srv/artifactsRACK_SEEDrack-seed-node# the node that pulls from the object store first# stage 1: the rack seed pulls the whole manifest and all shardspull_manifest--artifact$ARTIFACT--dest$DEST/$ARTIFACT/manifest.jsonpull_shards--artifact$ARTIFACT--dest$DEST/$ARTIFACT--concurrency8# stage 2: other nodes in the same rack fetch shards from the seed, not the object storeshare_shards--source$RACK_SEED--artifact$ARTIFACT--dest$DEST/$ARTIFACT# after verification, freeze the directory: chmod -R a-w keeps writers out三、完整性校验分发路径解决「到哪里取」校验解决「取到的对不对」。权重是二进制大文件一次静默损坏就可能让模型加载成功、推理结果异常且不报错。校验要回答两件事怎么在分发时发现损坏以及发现不了的损坏何时暴露。3.1 摘要比对与分片校验摘要比对是最基础的一层制品发布时算一份整体摘要节点拉完后本地重算不一致就判失败。它开销低但只能在全部拉完后给结论——拉到九成才发现不对前面九成时间已经花掉。分片校验把粒度下放制品按固定大小切分示意值例如每片若干百 MB每片各有一份摘要制品本身再有一份清单摘要。好处是三件事同时成立拉取过程中就能发现坏片不必等整体拉完坏片可以单独重拉不用整个文件重来分片摘要可以并行计算校验耗时随核数摊薄。片太大坏了重传代价高片太小摘要与清单本身的开销占比上升。经验做法是让单片重传控制在一分钟内。3.2 断点续传与恢复语义断点续传依赖分片下好的分片留在本地临时目录重试时只拉缺失分片。它要解决的关键不是重传而是恢复时的判定——上一轮留下的分片可信吗判据是临时分片落了盘不等于完整。进程被杀、机器断电都可能留下长度对、内容错的片所以续传前必须重算摘要不能只看长度。这一步让续传的重启成本高于期望但省掉它就会把损坏带进正式目录。临时分片还要落在与正式版本目录不同的位置并带上目标版本标识否则两个版本同时拉取会互相覆盖。3.3 损坏在什么时候才会被发现损坏形态首次暴露的环节兜底手段兜不住的时候传输位翻转分片摘要比对单分片重拉分片摘要本身算错极小概率拉取中断留残片续传前的分片重算丢弃残片重拉只看长度不看内容时漏过存储介质静默损坏无直到巡检定期重算摘要巡检间隔内一直带病服务发布时就错源头坏了发布流程的摘要比对发布门禁拦住源头与清单一起算错表里最后两行是重点分发链路的校验拦不住落盘之后的损坏也拦不住源头就错的制品。前者靠定期巡检重算后者靠发布流程在源头记录摘要。⚠️ 代码待验证# Fetch one artifact shard by shard, verify each shard before it is kept.# Retry only the shards that failed; never retrust a leftover shard by length.importhashlibimportosdefshard_digest(path,chunk120):hhashlib.sha256()# digest algorithm, swap if your store uses anotherwithopen(path,rb)asf:forblockiniter(lambda:f.read(chunk),b):h.update(block)returnh.hexdigest()defverify_existing(tmp_dir,manifest):Leftover shards are re-hashed; length alone is not trusted.good,bad[],[]forname,wantinmanifest[shards].items():pos.path.join(tmp_dir,name)ifnotos.path.exists(p):continue(goodifshard_digest(p)wantelsebad).append(name)returngood,baddeffetch_and_verify(tmp_dir,manifest,fetch_one,max_retry3):missing[nforninmanifest[shards]ifnotos.path.exists(os.path.join(tmp_dir,n))]# fetched shards are hashed once; failed ones go back to the retry queueforattemptinrange(max_retry):fornameinmissing:fetch_one(name,os.path.join(tmp_dir,name))_,badverify_existing(tmp_dir,manifest)ifnotbad:breakmissingbad# only re-fetch the shards that failedelse:raiseRuntimeError(shard fetch failed after retries)# the shard set must match the manifest exactly before it becomes a versionifshard_digest(os.path.join(tmp_dir,manifest.json))!manifest[manifest_digest]:raiseRuntimeError(manifest digest mismatch)四、缓存与预热缓存解决重复分发同一版本在同一节点被拉第二次是浪费在相邻节点各拉一次也是浪费。缓存分两级——节点本地缓存与集群级缓存失效模式与预热方式不同。4.1 节点本地缓存节点本地缓存的形态是一个只读目录加一个版本索引。版本目录按内容寻址或版本标识命名落盘后不再修改缓存命中就成了「目录是否存在、摘要是否匹配」的判断不需要加锁。判据命中率不能按访问次数算要按避免的分发字节数算。小体积旧版本被频繁命中和大体积新版本被命中一次对带宽的意义完全不同用字节口径才看得出省了多少出口流量。缓存不免费它占的盘和正式版本目录一样多所以要设水位上限超出后按最近最少使用淘汰且只能淘汰缓存副本不能淘汰被引用的版本目录。4.2 预热时机冷启动的耗时几乎全在分发上而分发可以提前做。预热有三个可选触发点预热时机触发点覆盖到的场景代价发布时预热新版本发布后、扩容前常规发布与计划扩容要提前知道目标节点集合扩容前预热扩容动作发起、节点就绪前弹性扩容扩容决策到执行之间的窗口要够长节点加入时预热节点注册时主动拉故障替换、意外扩容拉取与业务同时进行有争抢三个时机取决于扩容是否计划内。计划内扩容能在扩容前把权重推到目标节点扩容动作只做注册与挂载计划外扩容没这个窗口只能在节点加入后拉这时要接受一段冷启动或限制新节点先只接少量流量。4.3 缓存击穿时的连锁反应缓存击穿指的是一批节点同时请求同一个还没被缓存的版本发生后会串成一条链所有请求同时打到上层对象存储或缓存层上层出口被打满每个请求都变慢变慢触发客户端超时超时触发重试重试再次打到上层出口更满。这个循环的破坏力在于重试放大了原始请求量。中断它只有两个位置出口侧限制单版本并发或客户端侧给重试加退避与上限。两头都要做只做一头另一头失效。⚠️ 代码待验证# Prewarm policy: fill the local cache before the node is asked to serve.prewarm:triggers:# any of these can start a prewarm run-on_release# right after a new version passes the release gate-before_scale_out# while the scale-out decision is still being executedtarget_scope:[rack,zone]# prewarm per rack/zone, not per single nodeconcurrency_per_source:4# cap concurrent pulls against one sourceon_node_join:lazy# a node that joins late pulls on its own, with backoffcache:eviction:lruwatermark_high:0.80# indicative ratio, start eviction above thiswatermark_low:0.65# indicative ratio, stop eviction below thisnever_evict:[referenced]# version dirs with a live reference are not cache五、版本目录与回收前几章讲怎么把制品铺下去这章讲铺下去之后怎么在盘上组织与清理。对象是模型制品权重目录、运行时镜像层、配套清单文件。不是用户产物也不是执行环境的临时目录那两类的生命周期与此不同。5.1 版本目录布局与不可变目录按「制品名 / 版本标识 / 内容」三层组织清单与摘要文件跟版本目录同级。不可变是唯一的硬规则版本目录落盘后不许原地修改否则摘要失效、缓存失效、已挂载它的进程会读到半新半旧的内容。换版本就落新目录、切指针。5.2 引用计数与在跑任务能不能删一个版本目录取决于有多少东西还在用它正在运行的任务进程打开了目录里的文件删掉目录进程读取时可能失败正在启动的任务启动流程还没走完分发刚完成指向的还是这个版本回滚窗口内的版本最近一次发布对应的上一个版本要保留到回滚窗口结束。所以删除判据不能是「磁盘满了」或「版本太旧」必须是「引用计数归零且过了回滚窗口」。引用计数要由运行时上报不能靠扫描时间戳推测时间戳反映不了谁在用。5.3 磁盘水位的清理判据判据能否单独作为删除依据原因正确用法目录修改时间过久不能只读目录的时间戳不随使用更新作为巡检输入不作为删除开关版本号不是最新不能回滚窗口内的版本必须留与回滚窗口联合判断引用计数归零不能归零后可能仍有挂载或缓存引用与回滚窗口、挂载状态联合判断磁盘水位超阈值不能水位是信号不是授权触发清理评审不直接删计数归零 过窗口 无挂载可以三个条件合起来排除了在用与可回滚自动清理的唯一放行条件清理还有一层防误删删除要走「改名到回收目录、冷却、真正删除」三步中间任一步发现引用重新出现就回滚。回收目录本身占空间却把误删从不可逆变成可逆。⚠️ 代码待验证# Version layout on a node: one immutable directory per version, one manifest beside it. /srv/artifacts/ model-weights/ manifest.json # shard list shard digests manifest digest versions/ version-id/ # read-only after landing shards/ # the actual weight shards README.digest # digest of the directory contents .tmp/ version-id.part/ # partial shards, separate from versions/ .trash/ version-id.ts/ # renamed-but-not-deleted, cooled down before rm完整版资料清单本文用到的分发路径对照表与回收判据清单都整理在里面了扫码即可获取六、与启动流程的衔接分发是启动流程的第一个前置步骤。这章只讲分发这一环与启动流程的接口什么时候算分发完成、失败怎么处置、多个发布任务撞在一起怎么排队。探针分层与就绪判定属于另一篇这里只说到依赖关系。6.1 分发完成才算就绪启动流程要有明确的相位划分分发、加载、服务。相位之间是硬边界——分发相位没结束不进加载相位。这让「就绪」有可解释的含义。若允许边分发边加载节点报告就绪时目录可能完整也可能恰好差最后一片分开之后就绪的语义就变成「制品校验完成且可读」对应一个确定状态。接口上分发相位结束时提交一份凭据版本标识加制品摘要后续相位只认它。这也顺手解决了第 1 章第三类问题——每个节点跑什么版本查凭据即可。6.2 分发失败的处置与重试分发失败的处置分两步分类再选动作。一类是可重试失败网络超时、分片摘要不符、上层限流。这类要在客户端按退避重试只拉缺失分片并对同一版本设次数上限。另一类是不可重试失败清单与制品对不上、制品在存储侧不存在、磁盘空间不足。这类重试多少次都一样应立刻终止并上报。判据两类混淆会出两种毛病。把可重试的当不可重试节点白白下线把不可重试的当可重试节点在重试循环里空转占着并发名额拖慢别的节点。分发失败最终必须让启动失败不能降级成「用旧版本先起来」——那会得到一个看起来健康、实际版本错误的节点比直接失败更难发现。6.3 发布窗口的排队一次发布里同时分发的节点数有限超出分发能力的部分要排队而不是并发。排队粒度按批次。批次大小由出口带宽与单节点耗时定让一批在目标时间内拉完剩下的排下一批批次内按机架或可用区分组尽量落同一段内网链路。分发队列与启动队列分开。节点先排分发队列完成后才进启动队列混在一起会让启动队列堆满还在分发的节点水位失真。发布窗口要有独占期。两个版本同时发布时后发布的等前一个的批次走完不设独占期两条分片流交叉出口被加倍占用。⚠️ 代码待验证# Retry and batching policy for the distribution phase.distribution:phase_order:[fetch,verify,load,serve]# fetch must finish before load startsbatch:size_by:exit_bandwidth# batch size derives from available exit bandwidthgroup_by:[rack,zone]# keep one batch on the same internal pathretry:retryable:[timeout,shard_digest_mismatch,upstream_throttle]fatal:[manifest_mismatch,artifact_missing,disk_full]max_attempts:4# indicative, per version per nodebackoff:exponential# jittered backoff, capped by max_delaymax_delay:60s# indicative capon_exhausted:fail_startup# never fall back to an older versionrelease_window:exclusive:true# one version distributes at a time七、观测与巡检前六章是设计这章把设计变成可检查的信号。分发这套东西平时安静、出事集中只靠出错时的日志不够要有常态化指标与巡检。7.1 分发耗时按分位看分发耗时用分位不用均值原因和多数耗时指标一样少数慢节点被大量快节点摊平。这一项还有特殊之处——慢的节点可能不是「慢」而是在反复重试。50 分位常态分发耗时反映体积与链路的基本盘95 分位主要目标值覆盖到批次里的大部分节点最大值不分位直接看。批次完成时间由最慢的那个决定最大值才是批次的真实耗时。耗时上升时是体积变了、链路变了还是重试变多靠分发字节数、重试次数、单批次节点数三个量区分。7.2 校验失败率与磁盘水位趋势校验失败率按失败分片数除以总分片数算。它有两种形态含义相反零星失败偶发的位翻转或网络抖动重试即可恢复看趋势不看单点。成片失败某个来源的分片集中失败通常指向存储侧的一份副本损坏或制品在发布时就坏了这种要立刻停发布并回查源头。磁盘水位要看趋势不看瞬时值。分发与回收都是批次动作水位在批次结束时会跳变瞬时值噪声大。做法是每天固定时刻取一次画 30 天曲线看斜率斜率持续为正说明回收跟不上分发该查回滚窗口是否设得太长而不是加盘。7.3 缓存命中率与巡检节奏缓存命中率按字节口径算并要按版本分层看。只报一个整体命中率会掩盖问题整体好看可能只是被高频小版本拉高而真正需要缓存的大版本一次都没命中。观测项口径看什么频率异常时的第一动作分发耗时50/95 分位与最大值每次发布比对体积、重试数、批次节点数校验失败率失败分片数除以总分片数每次发布区分零星与成片成片先停发布磁盘水位每日固定时刻的占用比每日查回收是否停滞再看回滚窗口缓存命中率按避免的分发字节数分版本每周查大版本的缓存是否生效版本分布各版本在集群中的节点数每日旧版本长期残留说明回收漏了节奏按三级每次发布跑分发耗时与校验失败率每日看磁盘水位与版本分布每周复盘缓存命中率与回收日志。判据版本分布是最有用的信号它同时覆盖分发、缓存与回收三条线——旧版本长期不消失要么回收判据没放行要么缓存副本被算进了正式版本要么某批节点分发失败后没恢复。⚠️ 代码待验证# Signals to keep for the distribution path; names follow your own metrics system. dist_duration_seconds{quantile0.5} # typical fetch time, the baseline dist_duration_seconds{quantile0.95} # main target, per release dist_duration_seconds_max # batch completion is bounded by the slowest node dist_bytes_total{artifact, version} # volume drives the duration floor dist_retry_total{artifact, version, reason} # separates slow from stuck retrying verify_failed_shards_total{artifact, version} # split sparse vs bursty failures version_replicas{artifact, version, stateserving} # version spread across the fleet cache_avoided_bytes_total{artifact, version} # hit rate measured in bytes, per version disk_used_ratio{mount} # sample once a day, read the 30-day slope # Check cadence: per-release for duration and verify; daily for water level and spread; # weekly for cache effectiveness and the recycle log.完整版资料清单本文用到的观测指标口径与巡检节奏表都整理在里面了扫码即可获取附表 A关键取舍一览取舍本文结论判断依据位置分发耗时是否只由制品体积决定不是节点并发也决定出口带宽是公共资源第一章四条分发路径是否互斥不互斥按链路分段组合各段解决不同层的带宽问题第二章权重是否应打进镜像层仅在版本稳定、镜像层缓存可控时用镜像膨胀且缓存策略不可控第二章校验用整体摘要还是分片摘要分片摘要整体摘要只做兜底整体摘要在拉完后才给结论第三章续传时能否按文件长度判断分片可用不能必须重算摘要断电或杀进程会留下长度对内容错的片第三章分发链路的校验能否覆盖落盘后损坏不能需定期巡检重算介质静默损坏不在链路内第三章删除版本目录能否只看水位不能水位只是触发信号水位是信号不是删除授权第五章引用计数能否靠扫描时间戳推测不能要运行时上报只读目录时间戳不随使用更新第五章分发失败能否降级用旧版本启动不能必须让启动失败版本错误的节点比失败更难发现第六章分发耗时是否只看 95 分位不是还要看最大值批次完成时间由最慢节点决定第七章附表 B术语速查表术语含义模型制品权重目录、运行时镜像层与配套清单的统称区别于用户产物版本标识一个制品版本在分发与引用中的唯一名字制品摘要对整个制品内容算出的摘要用于拉取结束后的整体比对分片把制品按固定大小切开后的一个片段是校验与续传的最小单位清单文件记录分片列表、各分片摘要与整体摘要的文件是校验的依据分片校验对每个分片单独比对摘要能在拉取过程中发现坏片断点续传只拉缺失分片、复用上一轮成果续传前须重算摘要静默损坏不产生错误提示的内容损坏只能靠摘要重算发现分发相位启动流程中专门做拉取与校验的阶段结束后才进入加载相位分发凭据分发相位结束时提交的版本标识加摘要后续相位只认它可重试失败超时、分片摘要不符、被限流等重试可能成功的失败不可重试失败清单不符、制品不存在、磁盘满等重试无意义的失败节点本地缓存节点上用于复用已拉取制品的只读副本目录可被淘汰缓存击穿一批节点同时请求未缓存版本引发出口拥塞与重试放大预热在节点被要求服务之前主动把制品填进缓存或本地盘引用计数记录某一版本正被多少任务、启动流程或回滚窗口引用回滚窗口最近一次发布对应的旧版本必须保留的时间范围回收目录待删除版本先改名进入的冷却目录用于把误删变成可逆磁盘水位盘占用比例按每日固定时刻采样看 30 天斜率版本分布各版本在集群中各占多少节点的统计用于发现分发与回收异常写在最后这篇用到的资料写这篇文章时我把几个模型的官方文档、参数表和实测记录都对了一遍顺手整理成几份配套的东西大模型学习路线图从 LLM 基础到 Agent 开发各阶段该学什么、用什么资料大模型全套教程按主题分好的视频与文档清单大模型实战好书24 本附每本适合的阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「大模型」优先通过。拿到之后建议先看学习路线图那一份先定位自己在哪个阶段再决定学什么比一上来就啃框架效率高得多。