2.1 三个检查点各自的底座
2.1 三个检查点各自的底座
本节摘要：laya 不是单个模型，而是三个各管一摊的检查点。laya 421M 以 ModernBERT-large 为底座，是英语主力；laya-multilingual 322M 以 mmBERT 为底座，覆盖 100+ 语言；laya-typed-decisions 在 typed 决策上特化——参数量与底座均为官方 README 口径。本节先给一张对比表看清三者的参数量、语言覆盖与定位差异，再逐个讲「它为谁存在、什么时候选它」，然后给出显式选择检查点的代码入口（Router 的 preload 写法，写法示意），最后总结一套选择建议：默认交给 Router，语料单语就显式钉死，typed 任务特化优先。BERT 级参数量是三者共同的家底，也是「CPU 可跑」的物理基础。
学习目标
- 背出三个检查点的参数量、底座与语言覆盖（官方 README 口径）。
- 说出每个检查点「为谁存在」，以及对应的典型流量形态。
- 用 preload 写法显式选择检查点（写法示意，以官方文档为准）。
- 面对具体业务流量，给出一套检查点选择建议。
一、总览：一张表看清三个检查点
| 检查点 | 参数量（官方 README 口径） | 底座 | 语言 | 定位 |
|---|---|---|---|---|
| laya | 421M | ModernBERT-large | 英语 | 英语主力：英语流量上最快最强 |
| laya-multilingual | 322M | mmBERT | 100+ 语言 | 多语言覆盖：非英语流量的默认去处 |
| laya-typed-decisions | 官方未单列参数量（以模型页为准） | typed 决策特化底座 | typed 三原语强化 | 特化：choice / score / noul 决策头强化训练 |
看表的顺序建议从上往下：先确认流量语言（前两行二选一），再考虑任务特化（第三行）。很多读者的直觉是反过来的——被「特化」吸引直接跳到第三行——但语言辖区是地基，地基错了特化无从谈起。
三行三种逻辑：第一行按语言分工，第二行按覆盖分工，第三行按任务类型分工。前两个是「同一种能力的两个辖区」，第三个是「另一种强化方向」。官方对 typed-decisions 给过一组基准：微调后 0.362 升到 0.766（官方口径）——这组数字的意义在第 5 章展开，这里先记住它说明特化检查点的价值要在微调后兑现。
参数量的另一层含义是部署成本：421M 与 322M 都是 BERT 级，单卡不必，CPU 可跑（官方 README 口径）。这意味着三个检查点全部常驻内存的硬件门槛并不高，为 2.2 节「Router 自动分流」提供了现实可行性——换做三个十亿级模型，常驻就不现实了。
底座小识：编码器是什么。 laya 的检查点都立在「编码器」这种架构上：只读不写——把输入文本压成一串向量表示，不做逐 token 生成。这与生成式 LLM 的「解码器」相对。编码器天生适合打分与匹配类任务（分类、相似度、检索），laya 在编码器顶端加装「决策头」，把向量表示读成三种 typed 分布（第 1.2 节的形态）。ModernBERT-large 是 BERT 家族的现代化版本（背景知识，改进细节以原论文与官方文档为准）；mmBERT 一类多语言编码器用覆盖上百种书写系统的大词表训练，是多语言检查点的通行底座。理解到这一层就够用了：底座决定「读得懂什么语言」，决策头决定「答得出什么类型」。
二、laya 421M：英语主力
底座 ModernBERT-large 是英语编码器的现代版本，421M 参数量在 BERT 家族里属于大号。它存在的理由很朴素：英语是大多数系统的主流量，而「只会英语」在编码器上不是缺陷是优势——同样的算力不必分给上百种语言，全部用在英语语义上，换来英语任务上更准更快（方向性结论，量化的差距以官方基准为准）。
「更快」值得多说一句：更准通常来自容量集中，更快则来自「不必为大词表与大覆盖付出代价」——多语言模型的词表要容纳上百种书写系统，英语专用模型可以把序列建模的预算全部留给英语本身。两者的差距幅度属于实测范畴，方向是稳定的。
什么时候它是正确选择：流量基本是英语（内部工单、英文邮件管道）；或者你要的是单语场景下的最低延迟。注意「英语」的边界：它管英语不管「拉丁字母」——法语、德语、西班牙语文本不该默认送给它，那是多语言检查点的辖区（2.2 节的路由规则正是按这个逻辑设计的）。
顺带回答一个实际问题：「英语为主、夹少量其他语言」算英语流量吗？经验口径（示意建议）：九成以上纯英语就算。剩下不到一成的杂语流量交给 Router 兜底或直接承受多语言检查点的轻微降质，两害相权都远轻于「为了一成流量全员走多语言检查点」。
三、laya-multilingual 322M：100+ 语言的覆盖者
底座 mmBERT，322M 参数量反而比英语主力小，却要覆盖 100+ 语言。这是多语言模型的经典取舍：广度换深度——每种语言分到的模型容量更少，单语精度通常略逊于专用检查点（方向性结论），但换来的是「一套检查点接住全世界」的覆盖面。
什么时候它是正确选择：流量天然多语言（跨境客服、全球内容审核）；语言构成不可预测（公开输入入口）；或者你想先只用一个检查点把系统搭起来，之后再按语言分流优化。100+ 语言的具体清单以官方文档为准；判断「我的语言在不在里面」，最直接的办法是拿一批真实样本试测——2.3 节会讲怎么测。
一个常被问到的顺序问题：先选语言检查点还是先选 typed 特化？答案是先语言后特化——语言辖区错了，特化再好也是答非所问的特化（中文样本送进英语检查点，决策头再强也无从发挥）。先把流量送对门，再考虑换更强的脑袋，这个顺序在第 5 章微调时同样成立：先在正确辖城的检查点上微调，而不是跨辖区指望一个模型全包。
四、laya-typed-decisions：typed 决策特化
第三个检查点换了个分工维度：不做语言分工，做任务特化——针对 choice / score / noul 三种 typed 决策强化。它的存在回答了一个问题：当你的系统核心就是打分与选择（而不是理解语言本身），值得用一个专门优化过决策头的检查点。
什么时候它是正确选择：任务以 typed 三原语为主干（分类即业务，比如内容分级、批量打标）；计划走第 5 章微调路线，想从更贴近 typed 任务的起点开始训练。它与其他两个检查点不是互斥关系——官方生态里三者并存，具体组合方式（哪些流量走 typed-decisions）以官方文档的推荐用法为准。
五、显式选择检查点：代码入口
默认用法是交给 Router 自动分（2.2 节），但已知流量构成时，显式钉死检查点更稳：
# pick_checkpoint.py —— 显式选择检查点（写法示意，以官方仓库 README 为准） from laya import Router # 用法一：交给 Router，按输入的文字脚本自动分流（默认） auto = Router() # 用法二：流量基本是英语，预载英语检查点，跳过逐次路由 english = Router(preload="laya") # 用法三：流量多语言混杂，预载多语言检查点，覆盖优先 multi = Router(preload="laya-multilingual") # 预载的价值：检查点常驻内存，省去按请求切换的开销； # 代价：多份检查点同时占内存，按实际流量构成决定预载哪些。
预载（preload）与按需加载的差别在延迟与内存：预载把路由决策提前到启动时，请求路径上不再有切换动作；代价是内存里同时站着几个 BERT 级模型。流量构成稳定就预载对应的那个，构成混杂就交给 Router 现场分。
六、选择建议：一套可执行的决策顺序
这套顺序的设计原则只有一条：能用数据回答的问题，不用猜测回答。前两步用「已知的流量构成」，第三步用「任务的本质」，第四步干脆先收集数据再回来：
- 不知道流量构成、或构成混杂：什么都不指定，交给 Router（默认策略，2.3 节讲它的取舍）。
- 流量基本单语（英语或某非英语语言为主）：显式预载对应检查点——英语用 laya，非英语用 laya-multilingual。
- 任务主干是 typed 三原语打分选择、且计划微调：评估 laya-typed-decisions 作为起点（第 5 章）。
- 都拿不准：先用 Router 跑起来，收集 checkpoint 字段的分布（2.2 节的可观测性做法），按真实流量再回头优化预载策略。
执行时还有一条隐性纪律：改检查点配置要走与小配置变更相同的流程——留记录、能回滚。检查点一换，延迟、内存、路由行为三样同时变，出问题时没有回滚路径会非常被动。
七、参数量与部署成本速查
把「检查点放哪儿、占多少」折成一张部署视角的表（内存与体积为量级示意，以实际环境为准）：
| 检查点 | 参数量（官方口径） | 常驻内存量级（示意） | 下载体积量级（示意） | CPU 延迟量级 |
|---|---|---|---|---|
| laya | 421M | GB 级 | GB 级 | 官方口径 32.8 毫秒级 |
| laya-multilingual | 322M | GB 级 | GB 级 | 与上者同量级 |
| laya-typed-decisions | 以模型页为准 | GB 级 | GB 级 | 同量级 |
三条部署推论。其一，「全预载」意味着内存里同时站着多份 GB 级模型，小内存机器要按流量挑着载。其二，延迟差异主要来自输入长度而不是检查点之差（同为 BERT 级，量级判断），别指望换检查点换延迟。其三，磁盘要为「可能用到的每一个检查点」预留 GB 级空间（第 4.2 节容器化时这道题会再次出现）。
八、典型流量与检查点配对
| 业务流量形态 | 推荐配对 | 理由 |
|---|---|---|
| 英语内部系统（工单、告警） | 显式预载 laya | 单语纯净化，英语主力最准最快 |
| 跨境客服、全球社区审核 | Router 自动分或预载多语言 | 脚本混杂，覆盖优先 |
| 单一非英语市场（日语、葡语站点） | 显式预载 laya-multilingual | 语料稳定，钉死免去逐次路由 |
| 以批量打标为主的数据管道 | 按语料构成预载 + predict_batch | 批量场景路由开销可一次性摊平 |
| typed 决策为主干且计划微调 | 评估 laya-typed-decisions 起点 | 特化底座离目标更近（第 5 章） |
九、官方基准的正确读法
官方给过 typed-decisions 检查点的一组数字：微调前 0.362、微调后 0.766（官方口径）。读这组数字要抓三个要点，避免两个误读：
| 要点 | 含义 |
|---|---|
| 微调前 0.362 | 印证官方诚实声明：底座 zero-shot 接近随机猜——这不是缺陷披露的客套，是可复现的起点 |
| 微调后 0.766 | 价值在微调：同一底座，数据喂对了，能力翻倍量级 |
| 差值即杠杆 | 选型时该问的不是「它现在多强」，而是「我的数据能把它推多高」 |
误读一：拿 0.362 判死刑。如果你的业务能提供标注数据，起点低恰恰说明提升空间大。误读二：拿 0.766 当承诺。那是官方基准数据集上的口径，你的业务分布不同，数字必然不同——第 5 章微调后要用自己的回归集复测，第 7 章再校准它的概率。带着这两个免疫力，后面所有官方数字都可以放心读。
这张表也回答了一个团队协作问题：什么时候该把检查点选型写进文档？答案是「配对表（第八节）确定的当天」。检查点选择看起来像实现细节，实际上影响延迟预算、内存预算与微调路线，是架构决定——写下来、注明理由与数据依据，后来者才不会在半年后随手改掉。
本节要点回顾
- 三个检查点：laya 421M（ModernBERT-large，英语主力）、laya-multilingual 322M（mmBERT，100+ 语言）、laya-typed-decisions（typed 特化）——参数量与底座为官方 README 口径。
- 分工逻辑：前两个按语言分工，第三个按任务类型特化；typed-decisions 的价值要在微调后兑现（0.362 升到 0.766，官方口径）。
- BERT 级参数量是共同家底：CPU 可跑、多检查点常驻可行。
- 显式选择用 preload 写法；选择顺序：不知道交给 Router、单语钉死、typed 主干评估特化检查点。
- 官方基准的读法：起点低印证诚实声明，差值才是微调杠杆；0.766 不是对你业务的承诺。
队员认识完了，接下来看调度规则：Router 怎么用一次文字脚本检测把请求送到正确的检查点，以及为什么官方选择「路由」而不是「训练一个大一统模型」。