44:第n小的质数
2026/10/21 20:13:18
版权与内容来源声明
本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容，均在附表 A 中标注来源；引用官方原文保持原样，不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准，标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式，也不对任何收益结果作承诺。转载请注明出处。
一、内网里，「模型」从来不是一个文件
1.1 同一句提问，隔一周答得不一样
先说一个信息中心常见的场景。内网的知识问答里，问「出差住宿标准是多少」，三周前答得对，这周答成了改之前的旧标准，还答得挺自信。
运维查了三天：服务没重启过，加速卡没掉，磁盘没满，日志里一条异常都没有。最后发现上周做「例行优化」时动了两处：提示词里那句「以现行文件为准」被删掉，权重换成了一份量化版。两处都不大，都被当成「调优」，都没进变更记录。
这个场景之所以典型，是因为它同时踩了两个坑：改动被当成优化，没有被当成版本变更；而系统里没有任何一处记录「现在跑的这一版，到底由哪几样东西组成」。
在机房里，「模型」不是一个文件，也不是一个镜像。它是几样东西的组合，缺一样都跑不起来，换一样行为就可能变。本文把它拆成五件套——这是工程上的划分，不是任何官方术语：
- 权重：模型本体的参数文件，就是那个几十 GB 的大文件。
- tokenizer（分词器）：把文字切成 token 的词表和规则。token 是模型处理文本的最小单位，可以粗略理解成「字块」。
- 生成配置：temperature、top_p、上下文长度、随机种子这一类「怎么生成」的参数。
- 提示词与工具定义：系统提示、对话模板，以及给模型看的工具（函数）名称与参数说明。
- 依赖镜像：推理框架、运行库、驱动所在的那个镜像或环境。
1.2 五件套里，只有一件是「一眼能看出大小」的
五件套有个很别扭的特点：权重几十 GB，谁动它都看得见；另外四件都很小，小到可以随手改、随手覆盖。而恰恰是这四件，改完最不容易被发现。
| 组成 | 它具体是什么 | 悄悄变了以后最先出现的现象 |
|---|---|---|
| 权重 | 参数文件本体 | 同一问题的用词、语气、知识边界一起变 |
| tokenizer | 词表与切分规则 | token 数变，长文档被截断的位置跟着变 |
| 生成配置 | 采样参数、上下文长度、随机种子 | 答案更发散或更死板，同问不同答 |
| 提示词与工具定义 | 系统提示、模板、工具名与参数说明 | 输出格式不对，该调工具时不调 |
| 依赖镜像 | 推理框架与运行库 | 截断行为、并发表现、输出格式变 |
同一批现象在故障单上会被写成五个标题——「答非所问」「长文档读不全」「回答不稳定」「格式乱了」「性能下降」。排查的人若不知道这五样是一体的，就会把同一个原因查成五个问题。
1.3 为什么日志帮不上忙
日志记的是运行状态：谁在什么时候调了接口、耗时多少、用了多少 token、返回成功还是失败。这些信息足以判断「服务好不好」，但不足以判断「跑的是哪一版」。
版本信息只有在被主动写进日志时才会存在。常见的内网部署里，模型名只是配置文件里的一行字符串，不会随权重替换而变化。于是出现一种很难受的局面：你知道它变了，却不知道变在哪，因为系统里没有字段用来回答这个问题。
更麻烦的是三类「不需要发版就能发生的变更」：
- 同一个镜像 tag 被重新推送过，内容不是最初那份；
- 权重文件被同名覆盖，文件名和目录结构全没变；
- 提示词存在配置中心，改一句话就生效，连重启都不用。
三类变更合起来，构成内网模型治理的主要难点。所以第一步不是买工具、上平台，而是先把「哪五样」定下来，再规定这五样只能整包替换，不能单独动。
二、权重：名字相同，内容可以不同
2.1 仓库侧的版本：revision 与 commit
内网的模型多半来自公开仓库，Hugging Face Hub 是最常见的那个。它的官方文档讲下载时写得很明确：默认下载的是main分支上的那一版；要以特定版本下载（某个分支、某个 PR、某个 tag 或某个 commit hash），用revision参数。文档另有一句注解：用 commit hash 时必须是全长哈希，不能是 7 位缩写。
这两句话对做内网的人意味着两层事。
第一，main是会动的。你本月拷进去的main，和三个月前同事拷的main，可以不是同一份东西，而且两边都拿不出证据说自己那份才是「标准的」。
第二，tag 可以移动到别的提交上，只有 commit hash 不会自己挪动。
还有一个细节很实用：整仓库下载时，本地缓存目录里会带上一段snapshots/<commit 哈希>这样的路径。当你需要证明「我手里是哪一版」时，这段路径比任何文件名都可靠，因为它就是内容指纹。
核验方式如实交代：截至 2026-10-20，本机直连 huggingface.co 超时（命令行请求 20 秒无响应），本节改从官方仓库 huggingface/huggingface_hub 的文档源文件核到，引文与原文一致，链接见附表 A。
2.2 运行侧的版本：tag 与 digest
内网真正跑起来的，往往不是仓库原样，而是打包后的推理服务。以 Ollama 为例，官方 Modelfile 文档里FROM的写法就是FROM <模型名>:<tag>——冒号后面那段就是 tag。
同名模型的不同 tag 是不一样的东西。ollama.com 的库页面按 tag 列体积，本机抓到的某个模型 tags 页上，同一模型名下出现了 4.6GB、6.6GB、9.5GB 三种体积。体积不同，文件就不可能相同。
更硬的证据在接口里。官方/api/tags的返回结构里，每个模型都带digest（64 位十六进制摘要）、size，以及details里的quantization_level（量化档位）、parameter_size。而ollama show --modelfile打印的FROM会直接指到本地 blobs 下一个以 sha256 命名的文件。
把这三处放在一起，结论就很清楚：tag 是给人读的别名，digest 才是内容本身。别名可以重新指向别的内容，摘要不会。
2.3 判据：按摘要认，不按文件名认
| 你在验收单上写的东西 | 能否证明内容相同 | 适合用在哪 |
|---|---|---|
| 文件名（带日期、带版本字样） | 不能。改名不改内容，改内容也不必改名 | 只当人类可读的备注 |
| tag / 分支名 | 不能。名字可以被移到别的提交上 | 日常沟通、口头指代 |
| commit hash（全长） | 能。指向仓库里一次确定的提交 | 记录「来自哪个仓库的哪一版」 |
| 内容摘要（64 位十六进制） | 能。改一个字节，摘要就变 | 入库、摆渡、上线前验收 |
据此可以写下三条硬判据，直接抄进验收单：
- 入库登记记摘要，不记文件名；
- 同一个 tag 在两次检查里摘要不同，按「换了模型」处理，走变更流程；
- 文件名里那串日期和版本字样，只能当注释看，不能当证据。
⚠️代码待验证
# 只读：列出本机每个模型的摘要、体积、量化档位curl-shttp://localhost:11434/api/tags# 只读：看某个模型最终是由哪个本地 blob 组出来的ollama show--modelfile<模型名>:<tag>|head-3两条命令都是查询，不改任何东西，适合放进交接班巡检清单。判断只有一条：摘要变没变。
三、中间三件：最安静的几处改动
3.1 tokenizer：切词一变，长度和命中一起变
tokenizer 决定一句话被切成多少个 token。它通常和权重在同一个仓库，但内网打包时经常被拆开：权重拷进模型目录，tokenizer 由打包脚本从别处带进来。两边对不上，服务照样启动、照样回答，只是答得不对。
变化是这样传导的：切分规则变了 → 同一段资料的 token 数变了 → 上下文窗口能塞进去的条数变了 → 检索拼进去的材料少了一段 → 答案看起来还行，但依据不全。
这个过程没有一步会报错，也没有一步会被日志记下来。所以判据得自己做：固定十段有代表性的文本（长表格、带编号的条款、中英混排、大段数字），把 token 数记成基线。升级后重算，数字不等就先查 tokenizer，别先查模型。
3.2 生成配置：默认值不是中性的
很多人以为「没改过参数」等于没设置。默认值不是中性的，它是别人替你做的选择，还会随框架版本变。
官方 Modelfile 文档列出的默认值：num_ctx2048、temperature0.8、top_k40、top_p0.9、seed0。2048 这个上下文长度对今天的知识问答往往不够——没显式设置，长文档就会被截断，而截断是静默的。
文档对seed的说明是：设成特定数字，可以让模型对同一提示生成同样的文本。这是「可复现」的开关，前提是解码路径一致。换了框架版本、量化档位或 batch 拼法，同一个种子未必给出同一段文字。种子让复现变容易，不等于保证复现。
内网还有个高频坑：服务端配置覆盖了 temperature，打包脚本里也写了一份，两份不一致时以哪份为准取决于加载顺序。判据两条：配置只有一个来源；启动时把生效值打进日志，一行就够。
3.3 提示词与工具定义：标点也是配置
提示词通常存在数据库或配置中心，改它不用发版、不用重启、不用审批。这三点加起来，使它成为五件套里最容易被改、最难被发现的一件。
工具定义同理。工具名、参数名、参数说明的文字，都会改变模型的调用选择。「查制度」和「检索制度库」在模型眼里不是一回事；参数说明里多一句「按部门过滤」，调用行为就会变。
所以这两样必须当代码对待：进版本库，改动走同一条变更流程，每次调用把提示词哈希写进日志。判据是：一个人能在不改文件、不发版的情况下改变模型行为，这条路径就必须留痕。
四、给五件套打一个内部版本号
4.1 命名规则：可排序、可指认、不带形容词
内部版本号的作用是让两个人在电话里确认「说的是同一版」。形状推荐业务域-场景-日期-当日序号，例如biz-qa-20261020-1：biz业务域，qa问答场景，20261020打包日期，1当天第几个包。
| 常见写法 | 问题 | 改成 |
|---|---|---|
| latest / main | 名字不变而内容会变，事后无法指认 | biz-qa-20261020-1 |
| 模型名-最终版 | 「最终」之后通常还有第三版 | 日期 + 当日序号 |
| 模型名-新 / 模型名-旧 | 谁新谁旧全靠记忆 | 日期在前，天然可排序 |
| 模型名-优化后 | 优化了什么没写，等于没记 | 变更单里写清动了五件套的哪几件 |
三条附加规则比格式更重要：日期放前面，按名字排序就是按时间排序；序号只增不减，回滚时重新指向旧目录；同一版本号发出后内容不许再改，要改就出下一个号。
4.2 清单文件：标签给人看，清单给机器比
版本号是标签，标签本身证明不了任何事。真正能比对的是清单——一份把五件套逐项写清、每项都带指纹的文件。
⚠️代码待验证
version:biz-qa-20261020-1created_at:"2026-10-20"scene:qaweights:name:<权重目录名>digest:<64 位十六进制摘要>quantization:<量化档位>tokenizer:files:[tokenizer.json,tokenizer_config.json,special_tokens_map.json]digest:<三个文件按固定顺序拼接后的摘要>generation:num_ctx:8192temperature:0.2top_p:0.9top_k:40seed:20261020prompts:repo:<提示词库地址>commit:<提交号>tools_digest:<工具定义文件的摘要>runtime:image:<镜像名>image_digest:<镜像摘要>清单有三个设计要点：每一项都有可校验的指纹，没有指纹的项等于没写；generation里写的是生效值，不是「默认没改」；清单自己也算一个摘要写进发布记录，否则别人可以改清单去迁就现状。
4.3 一个场景一条线，不共用目录
多场景共用一份权重目录，是内网常见的省空间做法。省下的空间会在第一次回滚时还回去：回滚 A 场景，B 场景跟着变。
判据是：一个场景一条独立的版本目录，可以共用镜像，不能共用权重目录和提示词库。磁盘不够就少留几个历史版本，不要靠共用目录省。
五、哈希校验：进机房之前先对摘要
5.1 为什么不用文件大小和时间戳
大小相同不代表内容相同，这个道理都懂，但搬运环节仍大量依赖「大小对不对」。时间戳更不可靠：拷贝工具会保留或改写它，重新打包一次，整包文件的修改时间全变。用时间戳判断新旧，等于用包装盒判断里面装了什么。
sha256 是内容摘要：输入变一个字节，输出完全不同。Python 官方文档里，sha256 属于「始终存在」的那组哈希构造器，不用额外装依赖，这点对离线环境很重要——你不可能为了算摘要去联网装包。
一个反直觉的细节：算摘要的工具本身也会变。官方文档记录，hashlib.file_digest从 Python 3.11 起提供；3.14 起文件以非阻塞模式打开会抛BlockingIOError，此前会把多余的空字节算进摘要。所以校验脚本也要固定版本和算法入口。
5.2 一份能跑的校验脚本
⚠️代码待验证
importhashlib,json,pathlib,sysdefsha256_of(path:pathlib.Path)->str:# file_digest 需要 Python 3.11 及以上withpath.open("rb")asf:returnhashlib.file_digest(f,"sha256").hexdigest()manifest=json.loads(pathlib.Path("manifest.json").read_text(encoding="utf-8"))bad=[]foriteminmanifest["files"]:p=pathlib.Path(item["path"])ifnotp.exists():bad.append((item["path"],"缺失"))continueifsha256_of(p)!=item["sha256"]:bad.append((item["path"],"摘要不一致"))ifbad:forname,whyinbad:print(name,why)sys.exit(1)print("全部一致")这段代码刻意朴素：不并发、不重试、不自动修复。校验脚本只干一件事——给出「一致」或「不一致」，然后让人决定下一步。让它自动「修正」清单，等于把唯一防线也交了。
5.3 搬运环节的三条硬规则
第一，清单随包走，但清单本身要单独核一遍。清单和包放在一起，如果两者都被换过，一起校验就永远一致。做法是清单先在另一台机器上算摘要，记进变更单，进机房后先对清单、再对文件。
第二，校验失败一律不收，不现场修。现场重拷、改名、再算一次，都会让搬运失去证据。正确动作是退回上一环节重新出包。
第三，分卷包先合并再校验。分卷摘要只能证明「这一段没坏」，证明不了「拼起来就是原文件」。
离线环境的模型版本清单模板与校验脚本：把本章的清单字段、命名规则和校验脚本做成了可直接改的模板，另附一份变更单的必填字段。放在资料包里，扫码即可获取：
六、先灰度一台，留好回滚位
6.1 灰度选哪一台
灰度不是「随便找台机器先上」，选错了机器，跑通也说明不了什么。
选机器看两条：最像生产（同样的加速卡、镜像基线、网络位置），有真实但低风险的流量（有人用，出问题不影响对外）。只能满足一条时优先「像生产」——不像生产的机器跑通了等于没跑。
灰度也不是「跑起来没崩就算过」。要有一批固定问题，新旧两版各跑一遍，人看差异。
| 看什么 | 怎么比 | 什么时候停手 |
|---|---|---|
| 固定问题集的答案 | 同一批题在新旧两版上各跑一遍 | 出现事实性答案变化就停 |
| token 数基线 | 同一段文本在两版上算 token 数 | 数字不等就停，先查 tokenizer |
| 工具调用 | 需要调工具的问题里，调没调、参数对不对 | 该调不调或参数错位就停 |
| 延迟与显存占用 | 同一批问题的耗时与峰值占用 | 明显变差就不要放量 |
| 拒答与兜底 | 问边界外的问题，看它是否老实说不知道 | 开始编造就停 |
6.2 回滚位：旧版本不删，切换走指针
回滚的速度取决于有没有提前留位置。如果回滚意味着「把旧权重再拷一遍」，内网就是几十分钟起步，还不算审批时间。
可行的做法是按版本号建目录，服务配置只指向一个固定的软链，切换和回滚都只是改这个指针。
⚠️代码待验证
BASE=/opt/models/biz-qaNEW=biz-qa-20261020-1# 上线：指针指向新版本（前提是清单校验通过）ln-sfn"$BASE/$NEW""$BASE/current"systemctl restart biz-qa# 回滚：指针指回上一版，再重启，不重新拷文件ln-sfn"$BASE/biz-qa-20261012-2""$BASE/current"systemctl restart biz-qa三条配套规则：旧版本至少留两个，按磁盘容量定；回滚命令写进值班手册并演练过一次；回滚后补一张变更单，写清回到哪一版、为什么回。
6.3 变更单：留痕不是签字，是能复现
很多单位的变更单上写着「优化模型效果」，签了三个人的字。三个月后出了问题，这张单子证明不了任何事。
有用的变更单要能回答四个问题：
- 改了什么——动了五件套哪几件，版本号从哪到哪；
- 为什么改——解决什么问题，不改会怎样；
- 怎么验证的——哪批问题、谁看、结论是什么；
- 怎么退——回到哪个版本，谁执行。
第四项最容易被省略，也最应该在动手之前写。写不出回滚方案的变更，不该批准。
七、反查：任何一条旧回答都要能对回五件套
7.1 回答日志里必须有的字段
前面六章做的事，最终都为了一件事：任意抽一条历史回答，能查出它当时用的是哪一版五件套。做不到，前面全是文档，不是治理。
| 字段 | 记什么 | 缺了会怎样 |
|---|---|---|
| version_tag | 内部版本号，如 biz-qa-20261020-1 | 只能靠时间猜当时是哪版 |
| manifest_digest | 清单文件的摘要 | 分不清「标签对但内容被换」 |
| weight_digest | 权重的 64 位摘要 | 换权重这类改动查不出来 |
| prompt_commit | 提示词库提交号或提示词哈希 | 提示词在库里被改，无从追 |
| gen_params | 生效的采样参数与上下文长度 | 同问不同答时无法排除参数 |
| seed | 随机种子 | 无法复现同一条回答 |
⚠️代码待验证
{"request_id":"req-0001","version_tag":"biz-qa-20261020-1","manifest_digest":"<清单文件摘要>","weight_digest":"<权重摘要>","prompt_commit":"<提示词库提交号>","gen_params":{"num_ctx":8192,"temperature":0.2,"top_p":0.9,"top_k":40},"seed":20261020,"question":"<用户原问题>","answer_sha256":"<回答正文摘要>","retrieved_docs":["<文档标识>"]}这份日志会多占一点空间，但它是唯一能让「上周那个回答为什么是对的」变成可查问题的东西。answer_sha256用来证明这条记录对应的就是那段文字。
7.2 一次十分钟的反查演练
不要用「我们有文档」来证明治理有效，用一次演练。
随机抽十条一个月前的回答，不问任何人，十分钟内答出每条对应的版本号，并说出至少两件的摘要。做不到，说明断点在这几处之一：
- 日志保留期太短，一个月前的记录被滚掉；
- 版本号只写在发布单里，日志里没有；
- 提示词没有历史版本，改完只剩现在这一份；
- 交接时只交了机器密码，没交版本目录结构。
四个断点里，前三个靠「日志多写六个字段」就能解决，第四个只能靠制度。演练的价值不在查出多少问题，而在让「能不能查」变成有答案的问题。
7.3 你要补的不是部署，是版本治理
信息中心的岗位背景，在这件事上有被低估的优势。
| 你现在做的事 | 版本治理里对应什么 | 复用程度 |
|---|---|---|
| 管机房、管账号、管权限 | 谁能改哪一版、改动要不要审批 | 直接复用 |
| 写变更单、走审批 | 五件套整包变更留痕 | 直接复用，但要改字段 |
| 做备份、做容灾 | 旧版本保留与一键回滚位 | 直接复用 |
| 排查「昨天还好好的」 | 反查日志与版本对齐 | 需要补字段 |
| 用移动介质摆渡文件 | 摘要校验与清单随包 | 需要补流程 |
| 写部署脚本 | 版本目录与指针切换 | 需要补一点 |
要补的技术只有四样：Git（管提示词与清单）、摘要（认内容不认名字）、清单（把五件套写成可比的文件）、灰度（先一台再一批）。一周能上手。
难的是另一件事：守住「整包替换」这个约束。只要允许「这次就换个权重试试」，五件套就会退化成各自为政的文件，标签、清单、校验全部失效。这条靠技术守不住，只能靠流程和习惯。
对想往大模型方向走的运维和开发来说，能把这件事讲清楚，比会背几个模型名字有用。面试问「你怎么保证线上模型可复现」，能答出「整包版本化 + 摘要验收 + 灰度回滚 + 日志反查」这四步，比说出十个框架名更有分量。
离线模型版本治理的自查清单：把第 4 章的命名规则、第 5 章的校验流程、第 6 章的灰度判据、第 7 章的反查字段合成了一页可打勾的清单，适合直接拿去和主管对流程。放在资料包里，扫码即可获取：
附表 A：本文引用事实与出处对照表
| 事实 | 出处（文档名 + 发布方 + 链接） | 本文位置 |
|---|---|---|
Hugging Face 下载默认取main分支上的那一版；要以特定版本下载（来自某个分支、某个 PR、某个 tag 或某个 commit hash）时使用revision参数 | 《Download files from the Hub》，Hugging Face（huggingface_hub 官方文档源文件），https://github.com/huggingface/huggingface_hub/blob/main/docs/source/en/guides/download.md | 第 2.1 节 |
| 官方注解原文：「When using the commit hash, it must be the full-length hash instead of a 7-character commit hash.」 | 同上 | 第 2.1 节 |
snapshot_download按给定 revision 下载整仓库，本地缓存路径形如snapshots/<commit 哈希> | 同上 | 第 2.1 节 |
| 核验方式：huggingface.co 本机直连超时（20 秒无响应），改从官方 GitHub 仓库文档源文件核到，未用二手转述 | 本机实测（截至 2026-10-20） | 第 2.1 节 |
Modelfile 中FROM的语法为FROM <模型名>:<tag> | 《Modelfile Reference》，Ollama 官方文档，https://docs.ollama.com/modelfile | 第 2.2 节 |
/api/tags返回的每个模型包含name、model、size、digest（64 位十六进制）与details（含quantization_level、parameter_size） | 《List models》，Ollama 官方文档，https://docs.ollama.com/api/tags | 第 2.2 节 |
ollama show --modelfile输出的FROM指向本地blobs/sha256-...文件 | 《Modelfile Reference》，Ollama 官方文档，https://docs.ollama.com/modelfile | 第 2.2 节 |
| 同一模型名下不同 tag 的体积不同：本机抓取某模型 tags 页时，页面列出 4.6GB、6.6GB、9.5GB 三种体积（页面内容会更新，数值仅代表抓取时点） | Ollama 模型库 tags 页，https://ollama.com/library | 第 2.2 节 |
Modelfile 参数默认值：num_ctx2048、temperature0.8、top_k40、top_p0.9、seed0；seed设为特定数字可让模型对同一提示生成同样文本 | 《Modelfile Reference》，Ollama 官方文档，https://docs.ollama.com/modelfile | 第 3.2 节 |
hashlib.file_digest(fileobj, digest)返回已喂入文件内容的摘要对象；fileobj须以二进制、阻塞模式打开 | 《hashlib — Secure hashes and message digests》，Python 官方文档，https://docs.python.org/3/library/hashlib.html | 第 5.1 节 |
file_digest标注「Added in version 3.11」；「Changed in version 3.14」起非阻塞模式打开会抛BlockingIOError，此前会把多余的空字节算进摘要 | 同上 | 第 5.1 节 |
sha256 属于模块中「始终存在」的哈希构造器（对应algorithms_guaranteed） | 同上 | 第 5.1 节 |
| 「五件套」划分（权重 / tokenizer / 生成配置 / 提示词与工具定义 / 依赖镜像）是本文的工程归纳，未见对应官方术语 | 本文归纳（非官方定义） | 第 1.2 节 |
| 各推理框架的默认参数是否会随版本变化 | 待验证：只核到某一时点官方文档列出的默认值，未逐版本比对 | 第 3.2 节 |
| 常见内网部署的日志是否记录模型版本字段 | 待验证：无公开统计，表述基于岗位经验，不对应任何具体单位 | 第 1.3、7.1 节 |
| 分卷压缩包合并后与整包摘要是否必然一致 | 待验证：取决于打包工具与分卷方式，未在本机实测 | 第 5.3 节 |
| 具体单位的变更审批流程与表单字段 | 待验证：属内部制度，本文只给通用字段建议，不引用任何单位制度名称 | 第 6.3 节 |
| 本文全部代码块均未在真实内网环境执行，仅按官方文档接口编写，用于说明结构与判据 | 本机说明（如实标注，供读者复核） | 第 2.3、4.2、5.2、6.2、7.1 节 |
附表 B：术语速查表
| 术语 | 一句话解释 | 在本文哪里用到 |
|---|---|---|
| 五件套 | 权重、tokenizer、生成配置、提示词与工具定义、依赖镜像的合称，本文的工程叫法 | 第 1.2 节起 |
| 权重 | 模型本体的参数文件，决定模型「知道什么」 | 第 1.2、2.1 节 |
| tokenizer | 把文字切成 token 的词表与规则，决定「怎么读」 | 第 1.2、3.1 节 |
| 生成配置 | temperature、top_p、上下文长度、种子等「怎么生成」的参数 | 第 1.2、3.2 节 |
| tag | 给某一版本起的别名，可被重新指向别的内容 | 第 2.2、4.1 节 |
| commit hash | 仓库中一次提交的全长哈希，指向确定内容 | 第 2.1、2.3 节 |
| revision | 下载时指定版本的参数，可填分支、PR、tag 或 commit hash | 第 2.1 节 |
| digest | 内容摘要，改一个字节就会变，用来认内容不认名字 | 第 2.2、5.1 节 |
| sha256 | 一种哈希算法，输出 256 位摘要，常用于文件完整性校验 | 第 5.1、5.2 节 |
| 清单（manifest） | 把五件套逐项写清、每项带指纹的文件 | 第 4.2 节 |
| 灰度 | 先在一台或一小批上跑新版本，对比通过再放量 | 第 6.1 节 |
| 回滚位 | 提前留好的旧版本目录与切换指针，让回滚变成一条命令 | 第 6.2 节 |
| 反查 | 由一条历史回答回溯到当时使用的五件套版本 | 第 7.1、7.2 节 |
写在最后：这篇用到的资料
写这篇文章时，把相关的官方文档和源码又翻了一遍，顺手也整理了几份配套的东西：
- 大模型学习路线图：从零基础到能自己动手做 Agent，按阶段说明每一步该学什么、哪些可以先跳过
- 《LangChain + LangGraph + MCP 智能体开发实战》视频课：7 个模块，从私有化部署、Embedding+RAG 到 MCP+Agent 全流程
- AI 大模型知识库（在线可查）：Agent Skills 从入门到落地、Claude Skills 完全指南等专题，按目录浏览即可
- 640 套 AI 大模型行业报告 + 经典 PDF 书籍：看行业落地案例和别人怎么做的时候用得上
- 大模型零基础到精通教学视频：跟着敲一遍，比只读文档快得多
资料是我自己整理的，放在下面这个码上，扫码即可获取：
添加时备注「AI」，优先通过。
资料按「先路线、再动手、最后查漏」的顺序整理好了，建议先看学习路线那一份，照着它挑一条适合自己当前基础的路径再往下看。