版权与内容来源声明
本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容，均在附表 A 中标注来源；引用官方原文保持原样，不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准，标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式，也不对任何收益结果作承诺。转载请注明出处。

1. 你在鸿蒙里早就做过一次「分工」，只是没把它当成模型问题

1.1 一个具体的需求：相册里的「智能整理」

假设你在给鸿蒙应用做一个「智能整理」功能，它要干三件事：给本地几百张截图打上「票据 / 证件 / 聊天 / 网页」的标签；挑出账单截图抽成一条摘要；回答用户随口问的「我上个月订阅上花了多少，比前一个月多吗」。

三件事都叫「让模型干活」，约束却完全不同：打标签要在几百张图上循环跑、还要毫秒级返回，而相册里可能夹着身份证照片；出摘要可以等两三秒，但金额一个字都不能错；最后那个问题虽然低频，却要跨月对比和多步推算。全丢给云端最大的模型，既慢又贵还有隐私风险；全放在手机本地，第三个问题本地模型做不动。你要解决的不是「端侧模型好不好」，而是「哪一类请求交给谁」。 这个问题做过鸿蒙的人已经答过一次。

1.2 「一次开发，多端部署」的内核是分工

华为开发者联盟对「一次开发，多端部署」的官方表述是：通过统一开发范式与自适应框架，实现「一套代码一次开发上架，应用在手机、平板、智慧屏、手表、车机等终端按需部署运行」。它的分层架构分三层：产品定制层、基础特性层、公共能力层。

这里最关键的是**「按需」两个字。它不是「同一份界面在手机和平板上等比拉伸」，而是同一套代码里按设备能力把请求分给不同实现层**。端云模型分流是同一件事，只是把「设备」换成了「请求」，把「分层」换成了「定档」：分流依据应该是请求的约束，而不是模型的规模。

1.3 把模糊的直觉改写成三个能填数字的问题

动笔前先把「该不该放端侧」拆成三问：输入能不能离开设备？用户能等多久？这条请求一天跑多少次？三个答案直接决定它在第 2 章的分流表里落在哪一档。先定档，再选模型——顺序反了，后面全是返工。

2. 三级分流表：先把请求定档，再谈模型

2.1 三档分别是什么

档位	谁执行	典型请求	换到什么	付出什么	典型失败方式
一级 · 端侧直答	端侧小模型独立完成	图片分类打标、固定字段抽取、短文本意图判别	低延迟、可离线、数据不出设备	单条能力上限低	硬扛复杂问题，输出通顺但错
二级 · 端侧出草稿 + 云端复核	端侧生成候选，云端校验或改写	账单摘要、结构化抽取、回复草稿	延迟与成本折中，质量接近纯云端	多一次往返，要维护契约	草稿与复核格式不一致
三级 · 直接上云	云端大模型完整执行	跨文档多步推理、多轮规划、代码生成	质量上限高，能力全面	延迟高、单次成本高、数据离开设备	本可本地解决的请求也送上去

三档不是精度高低的关系，是约束不同。

2.2 三条判据线：隐私、延迟预算、单次成本

判据线	取值口径	高敏感 / 高要求时	低敏感 / 宽松时
隐私等级	按输入字段分级：可公开 / 有限敏感 / 强敏感（证件、生物特征、健康、私密通信）	强敏感 → 只能一级	可公开 → 三档都可选
延迟预算	用户可接受的首字返回与整体完成时间，按交互形态定	百毫秒级 → 只能一级	可等数秒 → 可上二、三级
单次调用成本	单条可摊到的云端调用预算 × 日调用频次	高频低预算 → 优先一级	低频 → 三档不受限

三条线里只要有一条是「必须端侧」，这条请求就是一级，不再权衡。隐私是硬约束，不是能拿成本去换的软指标——华为公开的隐私原则就写着「数据端侧处理：坚持尽可能在用户的设备上完成个人数据的处理和分析」，消费者侧说明也写明声纹、语音指令这类敏感信息「只会在设备端侧进行处理」。落到工程上，等价于「强敏感输入不进入分流表的二、三级」。 三条线都不强制端侧时，再按成本与质量取舍：低复杂度加高频走一级，中等复杂度加高频走二级，高复杂度加低频走三级。

2.3 把定档规则写成一个纯规则函数

第一版路由层不需要机器学习，一个规则函数就够。下面这段只是示意结构，没有在鸿蒙设备上跑过。

⚠️ 代码待验证

LEVEL_EDGE = "edge_direct"        # 一级：端侧直答
LEVEL_DRAFT = "edge_draft_cloud"  # 二级：端侧出草稿 + 云端复核
LEVEL_CLOUD = "cloud_only"        # 三级：直接上云
SENSITIVE = {"id_card", "health_record", "private_chat", "voiceprint"}

def decide_route(req) -> str:
    if req.fields & SENSITIVE:            # 隐私硬拦截优先
        return LEVEL_EDGE
    if req.latency_budget_ms <= 200:      # 延迟硬约束
        return LEVEL_EDGE
    if req.tasks_per_day < 50_000 and req.complexity == "high":
        return LEVEL_CLOUD                # 低频 + 高复杂度
    return LEVEL_DRAFT if req.complexity == "medium" else LEVEL_EDGE

def fallback_chain(level: str) -> list[str]:
    return {                              # 降级只允许往端侧退
        LEVEL_CLOUD: [LEVEL_CLOUD, LEVEL_DRAFT, LEVEL_EDGE],
        LEVEL_DRAFT: [LEVEL_DRAFT, LEVEL_EDGE],
        LEVEL_EDGE:  [LEVEL_EDGE],        # 一级失败不做云端兜底
    }[level]

一级的降级链里没有云端——「端侧跑不动」不构成「那就上云」的理由。

3. 端侧模型到底「跑得动」吗：三个必须算的数

3.1 参数量只是起点，决定体积的是量化位宽

选端侧模型最常见的误判是「只看参数量」。参数量决定算力需求，但装不装得下看的是量化后的权重体积。

模型（官方名）	参数量（官方）	上下文（官方）	官方量化方式	量化后权重体积
Qwen3-0.6B	0.6B（非嵌入 0.44B），28 层	32,768	支持思考 / 非思考双模式；量化版本由官方 GGUF 仓库与社区量化提供	按 4 比特折算约 0.30 GB
Gemma 3 270M	270M（嵌入 170M + 块 100M）	32K（1B 与 270M 为 32K）	随附量化感知训练（QAT）检查点，可用 INT4 精度运行	按 4 比特折算约 0.14 GB

「量化」第一次出现，需要一句人话解释：把原本用 16 或 32 位小数表示的模型权重改用更少的位数表示，体积和内存因此成比例缩小，代价是精度轻微下降。「4 比特量化」就是一个权重平均只占半个字节；「量化感知训练（QAT）」则是在训练阶段就模拟低精度计算，让模型在低精度下尽量不掉质量。选型顺序建议是：先看官方模型卡有没有 QAT 检查点，再看折算体积能不能塞进预算，最后才看评测成绩。

3.2 内存占用口径：权重只是三份账里的第一份

真机吃内存的不是「文件多大」这一个数，而是三份账。权重占用约等于量化后的权重体积，另加少量对齐开销，这是一条水平线。KV 缓存是模型记住当前上下文用的中间结果，估算方式是 2（键与值）× 层数 × KV 头数 × 每头维度 × 序列长度 × 每元素字节数，它随上下文变长线性增长——很多人算完权重觉得「还有富余」，一压长上下文就被它吃穿。 剩下的运行时开销（推理引擎、算子库与缓冲区）是纯工程账：公式只用来初筛，最终必须以真机常驻内存实测为准。另外，层数与 KV 头数可以查官方模型卡，但每头维度这类参数官方卡通常不列，需回模型自身的配置文件确认，本文未实测，此处标待验证。

3.3 鸿蒙侧公开的能力边界（不猜 API）

截至 2026-10-13，华为开发者文档里公开的端侧 AI 能力方向主要有两条，都写明了边界。MindSpore Lite Kit 的官方定位是「HarmonyOS 内置的轻量化 AI 引擎」，支持模型量化压缩；约束是适用于手机、平板、PC/2in1、电视与穿戴设备，其中在穿戴设备上仅支持 CPU 推理，且使用 .ms 格式模型。Neural Network Runtime Kit 的官方定位是「面向 AI 领域的跨芯片推理计算运行时」；强依赖硬件，只适用于支持 NPU 的设备，且截至 2026-10-13 官方文档写明支持常用算子 56 个、仅支持同步推理、不支持多线程并发构图、暂不支持模拟器。两条能力可以配合：官方写明两者共享同一份模型图格式；ArkTS 侧的公开接口方向是创建上下文、加载模型、取输入、执行推理。

最后强调一条纪律：鸿蒙侧的接口名与能力开关会随版本变化，本文只写官方文档中可见的能力方向，不猜任何一个 API 名字。 落代码前请以你本地 DevEco Studio 对应版本的官方文档为准。

4. 分流怎么落地：路由层要有的四件事

4.1 路由层放在哪一层

路由逻辑有两个可放的位置。放在应用内，决策在本地、敏感请求可以完全不联网，代价是每次改规则都要发版，适合隐私要求高、规则稳定的场景；放在云端网关，改规则不用发版、能统一看指标，代价是请求已经出了设备、隐私硬拦截失效。务实的做法是**「端侧做硬拦截，云端做软优化」**：端侧只判断这条请求能不能出设备，能出的才交给云端网关做精细取舍。

4.2 怎么让路由层选模型：规则打底，学习型路由做补充

如果只有「一个便宜、一个强」两个模型可选，「这条请求该给谁」已经有比较成熟的答案。LMSYS 团队开源的 RouteLLM 就是专门做这件事的框架，它的官方 README 给出：用它预训练的路由器，在 MT Bench 这类常用基准上最高可把成本降低约 85%，同时保持约 95% 的强模型表现（原文为 reduce costs by up to 85% … while maintaining 95% GPT-4 performance）。机制很简单，值得抄：每个路由器对「这条请求强模型会不会明显做得更好」算一个概率，官方称之为 strong win rate，再把它与一个成本阈值比较——超过阈值才走强模型，这个阈值就是你要的分流开关。

但有两点要注意：其一，它官方给的是「一个强模型 + 一个弱模型」的二选一，不是三档，你要做三级分流，等于把「弱模型」再拆成「端侧直答」和「端侧草稿」，这是原文没覆盖的部分；其二，阈值必须用你自己的请求样本重新标定——官方标定脚本用的公开对话数据，分布跟你相册里的请求不是一回事。所以落地顺序是：第一版先用纯规则函数，把定档结果和实际效果记下来；攒够几百条真实样本后，再用学习型路由替代规则里最难判断的那一段。

4.3 降级表必须和分流表一起写

定档讲「正常情况下走哪条路」，降级讲「这条路走不通时退到哪」。两张表不一起设计，线上第一次超时就会乱套。

⚠️ 代码待验证

routes:
  level_edge:
    engine: on_device
    timeout_ms: 300
    on_timeout: fail_soft            # 一级不做云端兜底，只如实告知
    on_error: fail_soft
  level_draft:
    engine: on_device
    timeout_ms: 1500
    on_timeout: level_edge           # 端侧草稿超时 → 退到端侧直答
    on_error: level_edge
    verifier:
      engine: cloud
      timeout_ms: 4000
      on_timeout: accept_draft_local # 复核超时 → 接受草稿并标记未复核
      on_error: accept_draft_local
  level_cloud:
    engine: cloud
    timeout_ms: 20000
    on_timeout: level_draft          # 退到二级不丢质量档次
    on_error: level_draft

三条规则值得单独说：一级没有云端兜底（一旦配了兜底，隐私硬拦截就重新变成软目标，某次超时就会把敏感数据送出去）；二级复核超时选择「接受草稿并标记未复核」而不是失败（二级本就是折中档，带标记的可用结果比错误更符合用户预期）；降级只能「往端侧退」，不能「往云端升」。

5. 二级档才是最难做的一档：草稿与复核之间的契约

5.1 二级为什么翻车：没有契约，两边各自为政

一级和三级都只有一方干活，责任清楚。二级有两方：端侧出草稿、云端做复核。几乎所有的二级档线上事故，都不是模型不行，而是两边对「什么叫一份合格的草稿」理解不一致。

事项	端侧草稿的职责	云端复核的职责
输出结构	严格按约定结构产出	只接受合法输入，不猜意图
缺失信息	标出「字段缺失」，不许编造	只补自己有依据的字段
数值类字段	只做提取，不做换算与推理	做换算与校验，冲突时以自己为准
置信度	标出自己「没把握」的字段	只重点复核被标记过的字段
失败时	报「做不到」，不返回半成品	报「无法确认」，不粉饰

最重要的一行是第三行。端侧小模型最危险的行为不是「不知道」，而是「猜一个看起来合理的数字」——只能靠「端侧只提取、不换算」这条职责划分从结构上堵死。

5.2 用约束解码把「草稿」的格式钉死

端侧小模型比大模型更容易在格式上跑偏。解决办法不是「写更长的提示词求它」，而是在采样阶段就把不合法的输出屏蔽掉。本地推理生态里有成熟做法：llama.cpp 的官方文法文档介绍了 GBNF（一种描述输出格式的形式文法），并写明它可以把 JSON Schema 的一个子集自动转成文法来约束输出。文档里有一条极易被忽略的警告：JSON schema 只用于约束输出，不会被注入提示词；模型看不到这份 schema，所以如果你希望它理解期望的结构，必须在提示词里另外说明。 也就是说，结构说明和结构约束是两件事，两件都要做。

⚠️ 代码待验证

{
  "type": "object",
  "properties": {
    "doc_type": { "type": "string", "enum": ["bill", "receipt", "ticket", "other"] },
    "amount":   { "type": ["string", "null"] },
    "merchant": { "type": ["string", "null"] },
    "date":     { "type": ["string", "null"] },
    "low_confidence_fields": { "type": "array", "items": { "type": "string" } }
  },
  "required": ["doc_type", "amount", "merchant", "date", "low_confidence_fields"],
  "additionalProperties": false
}

这份结构里有两个刻意设计：金额写成字符串而不是数字，是为了让端侧做纯粹的「照抄」，避免它在字符串转数字这一步做隐式换算；low_confidence_fields 强制端侧把「我不确定」显式说出来，云端复核才有抓手。

5.3 草稿到底被采纳了多少，要能被度量

二级档上线后一定会被问「端侧草稿到底有没有用」。这必须用数字回答，且要拆到字段级：草稿通过与云端复核结果完全一致的条数、被云端改写的字段集中在哪几个、标记为低置信后被确认错误的占比。如果某个字段长期高比例被改写，说明它不该由端侧出——删掉它比反复调提示词有效得多。

这份资料是什么：「AI 大模型知识库」里有一份 Agent Skills 从入门到落地的专题，讲的是怎么把一件事拆成有明确职责边界的步骤——和本章「草稿与复核分工」是同一种拆法。放在资料包里，扫码即可获取：

6. 怎么证明分流之后质量没掉：离线评测集 + 端云对照

6.1 先有一份自己的离线评测集

分流最大的风险是「感觉没变差」，而感觉不可回溯。所以第一件事是建一份离线评测集：一批固定的输入，配上人工确认过的标准答案，每次改路由规则前后各跑一遍。四类样本缺一不可——正常样本确认改动没把好结果改坏；边界样本覆盖空输入、超长输入、字段全缺；异常样本覆盖模糊图片、乱码文本、格式不合法；长尾样本把线上真实案例回灌进来。前三类每类至少十余条，长尾按线上量补。这套逻辑和学术界的离线评测框架一致，可以借现成工具省掉造轮子的时间——EleutherAI 的 lm-evaluation-harness 官方 README 写明它提供「统一的框架来测试生成式语言模型」，并且所有任务都带版本号，用于保证可复现。这条机制值得抄进自建评测集：评测集本身也要打版本，因为它改了，前后分数就不可比。

6.2 端云对照：不能只看最终对错

「端侧行不行」的答案不在「对 / 错」这一个维度上。建议同时看三个维度，任何一个恶化都算回归。

对照维度	具体看什么	判定为「没掉」的口径
结果一致性	端侧直答与「同一条请求交给云端」的结果是否一致	不一致的样本逐条有人工结论
字段级差异	二级档里云端改写集中在哪些字段	改写落在允许改写的字段内，且无新增错误
延迟分布	三条路径各自的整体耗时分布	按 95 分位看，不按平均值看

第三行值得单独解释一句：延迟看平均值等于什么都没看——用户记住的永远是慢的那一批。

6.3 回归门禁：什么时候可以继续放量

把上面三个维度压成一条可执行的纪律：每次改路由规则，先在离线评测集上跑完整对照；任意一个维度恶化就回滚，不放量；三个维度都没恶化，才允许把线上的分流比例往前推一档。

⚠️ 代码待验证

def gate(baseline: dict, candidate: dict) -> tuple[bool, list[str]]:
    reasons = []
    if candidate["mismatch_count"] > baseline["mismatch_count"]:
        reasons.append("结果不一致样本数增加")
    if candidate["new_wrong_edits"] > 0:
        reasons.append("出现新的错误改写字段")
    if candidate["p95_ms"] > baseline["p95_ms"] * 1.2:
        reasons.append("95 分位延迟恶化超过两成")
    return (len(reasons) == 0, reasons)

这段代码只有三行判断，但它把整篇文章的逻辑收了口：分流不是一次设计，而是一套「改了就比、比完再放量」的循环。

7. 鸿蒙开发者转这条线，哪些能力可以直接搬

7.1 你已有的技能，一半以上能直接对上

这是本文最想传达的一点：转 AI 应用岗不是把过去的技术积累清零，而是把同一套工程直觉换一个作用对象。

你原来的能力	在端云分流里的对应物	迁移成本
断点与响应式布局的分支设计	按请求特征做多档路由分支	低
多设备能力集判断	端侧能力探测（有无 NPU、可用内存多少）	低
分层架构与模块解耦	路由层与业务层解耦，路由可独立替换	低
端侧性能调优（启动时间、内存占用）	端侧推理的内存与延迟预算管理	中
多端一致性保障与回归测试	离线评测集与回归门禁	中

「迁移成本低」的那三行，恰恰是很多纯算法背景的人缺的：他们很会训模型，但不擅长把一个能力稳定地、可降级地交付到几千万台设备上。 这正好是你手里的牌。

7.2 需要补的三样，按这个顺序补

一是把「约束」讲清楚的能力。 你要能说清一条请求的隐私等级、延迟预算和成本预算各是多少——填不出来，分流表就是空的。补法：拿任意一个真实功能，把它的请求列出来逐条填。

二是读懂模型规格的能力。 你要能看懂官方 model card 里参数量、上下文长度、量化方式这几栏意味着什么，而不是只记住一个模型名字。补法：找一个官方模型卡逐栏读完，再回答「这个模型在我这台设备上装得下吗」。

三是度量输出的能力。 你要能把「模型答得好不好」变成「我的评测集上哪几类样本出了什么问题」。补法：为你做过的任意一个 AI 功能，手写二十条带标准答案的评测样本。

顺序不能反：没有第一样就没有判断标准；没有第二样，选型只能靠听来的结论；没有第三样，前面所有工作都无法验证。

7.3 第一个可交付物长什么样

不要一上手就做「端侧跑大模型」这种炫技目标。第一个可交付物建议是一个只有一级和三级两档的最小分流器：输入是一条请求的结构化描述（含字段清单、延迟要求、日频次），输出是档位结论加判定理由；验证方式是拿三十条真实请求跑一遍，把结论与人工判断逐条对比。二级档先不要做：它的成本几乎全在「契约设计」上，而契约设计只有在你稳定说清一级和三级边界之后才有意义。

这份资料是什么：「大模型学习路线图」把从零基础到能自己动手做 Agent 的路径按阶段拆开了，正好可以对照本章的三样补课顺序挑起点。放在资料包里，扫码即可获取：

附表 A：本文引用事实与出处对照表

序号	事实	出处（文档名 + 发布方 + 链接）	本文位置
1	「一次开发，多端部署」官方表述：一套代码一次开发上架，在手机、平板、智慧屏、手表、车机等终端按需部署运行；分层架构含产品定制层、基础特性层、公共能力层	《HarmonyOS 多设备开发最佳实践》，华为开发者联盟，https://developer.huawei.com/consumer/cn/best-practices/multidevice	第 1.2 节
2	华为隐私原则之一：「数据端侧处理：坚持尽可能在用户的设备上完成个人数据的处理和分析」；声纹、语音指令等敏感信息「只会在设备端侧进行处理」	《个人信息收集清单》，华为开发者联盟，https://developer.huawei.com/consumer/cn/doc/quickapp-icp-collect-message-0000001853007021 ；《隐私》，华为消费者业务官网，https://consumer.huawei.com/cn/privacy/	第 2.2 节
3	Qwen3-0.6B 官方规格：参数量 0.6B（非嵌入 0.44B），层数 28，GQA 注意力头 Q 为 16、KV 为 8，上下文 32,768	《Qwen3-0.6B》模型卡，Qwen（阿里云），https://huggingface.co/Qwen/Qwen3-0.6B	第 3.1 节
4	Gemma 3 官方规格：270M 参数（嵌入 170M + 块 100M），256K 词表，270M 与 1B 上下文为 32K；随附量化感知训练（QAT）检查点，可用 INT4 精度运行	《Gemma 3 model card》，Google DeepMind，https://huggingface.co/google/gemma-3-270m-it	第 3.1 节
5	INT4 量化的 Gemma 3 270M 在 Pixel 9 Pro 上 25 轮对话仅耗约 0.75% 电量；该模型定位为任务级微调基座	《Introducing Gemma 3 270M》，Google DeepMind 官方博客，https://deepmind.google/blog/introducing-gemma-3-270m-the-compact-model-for-hyper-efficient-ai/	第 3.1 节
6	折算体积约 0.30 GB（Qwen3-0.6B）与 0.14 GB（Gemma 3 270M）	本文按官方模型卡参数量与位宽折算，非官方数字；第三方社区 GGUF 仓库另有实测体积，均为社区量化仓库、非官方发布	第 3.1 节
7	KV 缓存估算公式与「权重、KV 缓存、运行时开销」三份账口径；每头维度需回模型配置文件确认	为本文归纳的通用估算口径，未在鸿蒙真机实测，待验证	第 3.2 节
8	MindSpore Lite Kit 为 HarmonyOS 内置轻量化 AI 引擎，支持模型量化压缩；适用于手机、平板、PC/2in1、电视与穿戴设备，穿戴设备上仅支持 CPU 推理；使用 .ms 格式模型。ArkTS 侧公开接口方向为创建上下文、加载模型、取输入、执行推理	《MindSpore Lite Kit 简介》，HarmonyOS 设备开发官网，https://device.harmonyos.com/cn/docs/apiref/harmonyos-guides/mindspore-lite-kit-introduction ；《使用 MindSpore Lite 实现图像分类（ArkTS）》，华为开发者联盟，https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/mindspore-guidelines-based-js	第 3.3 节
9	Neural Network Runtime Kit 为跨芯片推理计算运行时；强依赖硬件，只适用于支持 NPU 的设备；截至 2026-10-13 官方文档写明支持常用算子 56 个、仅支持同步推理、不支持多线程并发构图、暂不支持模拟器	《Neural Network Runtime Kit 简介》，华为开发者联盟，https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/neural-network-runtime-kit-introduction	第 3.3 节
10	RouteLLM 为强弱双模型路由与评测框架；官方 README 称预训练路由器最高降低成本约 85%，同时保持约 95% 强模型表现	《RouteLLM》README，LMSYS 组织（lm-sys/RouteLLM，Apache-2.0），https://github.com/lm-sys/RouteLLM	第 4.2 节
11	GBNF 为 llama.cpp 用于约束模型输出的形式文法，支持把 JSON Schema 的一个子集转成文法；官方文档明确「JSON schema 仅用于约束输出、不注入提示词」	《GBNF Guide》，ggml-org/llama.cpp，https://github.com/ggml-org/llama.cpp/tree/master/grammars	第 5.2 节
12	lm-evaluation-harness 为统一的生成式模型测试框架，所有任务带版本号以保证可复现	《Language Model Evaluation Harness》README，EleutherAI，https://github.com/EleutherAI/lm-evaluation-harness	第 6.1 节
13	本文的路由判定函数、路由配置、JSON Schema、回归门禁代码，以及离线评测集与 95 分位口径取值	均为示意性设计，未在鸿蒙设备或实际服务上运行，待验证	第 2.3、4.3、5.2、6.3 节

附表 B：术语速查表

术语	一句话解释	在本文哪里用到
端云分流	按请求的约束把请求分给端侧模型或云端模型处理	第 1.2、2 节
量化	用更少的位数表示模型权重，体积与内存成比例缩小、精度轻微下降	第 3.1 节
KV 缓存	模型记住当前上下文用的中间结果，随上下文变长线性增长	第 3.2 节
降级链	某条路径走不通时按顺序退到哪条路径的规则	第 4.3 节
strong win rate	路由器估计「强模型在这条请求上明显更好的概率」，用于决定路由	第 4.2 节
约束解码	在生成每一步屏蔽掉不符合目标格式的候选，从源头锁住输出格式	第 5.2 节
离线评测集	一批固定输入加人工确认答案，用来在改动前后对比质量	第 6.1 节
回归门禁	每次改动先跑对照、恶化就回滚、不恶化才放量的规则	第 6.3 节

---

写在最后：这篇用到的资料

写这篇文章时，把相关的官方文档和源码又翻了一遍，顺手也整理了几份配套的东西：

• 大模型学习路线图：从零基础到能自己动手做 Agent，按阶段说明每一步该学什么、哪些可以先跳过
• 《LangChain + LangGraph + MCP 智能体开发实战》视频课：7 个模块，从私有化部署、Embedding+RAG 到 MCP+Agent 全流程
• AI 大模型知识库（在线可查）：Agent Skills 从入门到落地、Claude Skills 完全指南等专题，按目录浏览即可
• 640 套 AI 大模型行业报告 + 经典 PDF 书籍：看行业落地案例和别人怎么做的时候用得上
• 大模型零基础到精通教学视频：跟着敲一遍，比只读文档快得多

资料是我自己整理的，放在下面这个码上，扫码即可获取：

添加时备注「AI」，优先通过。

资料按「先路线、再动手、最后查漏」的顺序整理好了，建议先看学习路线那一份，照着它挑一条适合自己当前基础的路径再往下看。