说明本文讨论的是端侧小模型与云端大模型之间的任务分工属于大模型工程架构话题不涉及具体模型版本与价格。AI 领域版本迭代极快凡涉及版本号、价格、可用性请以你阅读时的官方页面为准。文中代码为结构示意请按自己的技术栈调整后再上生产。一、为什么下放重新变成一道是非题2026 年年中把线上任务从云端大模型挪到端侧或自建推理的讨论又多了起来。它重新回到架构评审桌上原因不是某个模型忽然变强而是三类压力同时压了过来且方向并不一致。三类压力方向相反第一类是调用频次驱动的成本结构。账单等于单次成本乘频次决定量级的是后者。更要看成本在输入侧与输出侧的分布高频任务的钱几乎全花在系统提示、上下文、历史轮次上输出侧只占很小一块。裁剪输入因此比裁剪输出更值钱。第二类是交互链路对延迟的敏感。用户感知的不是总耗时而是首字节延迟。把一次跨网络往返换成本地计算省下的是一段固定开销任务本身计算越短这段开销占比越高收益越大任务越长则被摊得越薄。第三类是数据边界与合规要求。有些输入不允许离开设备或内网这不是成本问题是能不能做的问题换一个更便宜的云端接口解决不了。三类压力的适用范围并不相同成本看频次延迟看输出长度数据边界只约束输入侧混成一句都该下放就是第一类错判。两个站不住的判据“小模型变强了。”这是横截面比较结论。从某项能力追近推不出某条业务线该下放因为错误代价没进入这个判据——错误代价是重试一次还是一笔错账同样的能力差距落在两者上意义完全不同。“大模型太贵了。”成本是相对量而且省下的钱会被路由层吃掉一部分。路由层自带复杂度判据要维护、判错要兜、两条路答案要一致、灰度要双跑、兜底通道要常驻这些是固定成本不随流量下降消失。分错的代价常比不分更大。换成任务分级视角把问题从选哪个模型换成任务属于哪一级分级靠四个可测维度输入长度、输出确定性、错误代价、调用频次。四项都指向下放的可以下放出现否决信号的先不动。任务难不难不在其中——难度没有稳定的观测口径用它当判据只会停在争论上。二、先做任务分级不要先选模型选模型的顺序在不少团队里是反的先看模型列表再想办法证明某个能跑。这让人只找能跑的证据忽略不该下放的理由。正确顺序是先分级。四个维度与判读方式四个维度都能从线上流量里统计出来不需要额外标注。维度怎么测高危信号适合下放的取值输入长度统计真实请求的输入 token 分布同时看 P50 与 P95P95 远高于 P50或关键判据落在正文中段长度短且分布集中判据集中在开头输出确定性同一输入重跑多次看结论是否落在同一枚举内同一输入多次运行结论不一致输出落在固定枚举或结构化字段错误代价追问一句输出错了下游会发生什么涉及金额、权限、对外承诺错了只需重跑一次无外部副作用调用频次统计该任务的日均调用量频次高但每次都带一长段上下文高频且单次输入短输出小输入长度最容易被误判它不是难度的代理而是独立变量长输入本身就会改变模型的判断质量。输出确定性决定能不能用规则兜住——固定枚举可以设置信阈值把不确定的样本踢回云端自由文本则没有低成本的自动判对错手段。错误代价是唯一否决项其余三项都要让路。从分级结果到路由策略分级结果落到路由上通常是四档而不是下放 / 不下放两档中间两档用于多给一次验证机会。档位判据默认走向兜底直接下放四项全符合端侧或自建端侧失败即升云端记一次降级影子观察三项符合频次或长度存疑云端端侧双跑结果不返回无只记录分歧保持云端存在错误代价否决项云端无禁止下放长链路规划、无检索兜底的新近知识云端无实现可以很简单一个打分函数即可。注意错误代价要单独前置判断、不参与加权否则其余三项都漂亮的任务会把它的分数平摊掉。⚠️ 代码待验证# 任务分级四个维度各自归一化到 0~1错误代价作为唯一否决项前置WEIGHTS{input_len:0.3,determinism:0.3,error_cost:0.25,frequency:0.15}defgrade(task:dict)-dict:# error_cost 不参与加权高代价直接淘汰避免被其他维度平摊掉iftask[error_cost]0.7:return{tier:keep-cloud,reason:错误代价否决}scoresum(WEIGHTS[k]*task[k]forkinWEIGHTS)ifscore0.75:tieroffloadelifscore0.5:tiershadow# 只双跑结果不返回给用户else:tierkeep-cloudreturn{tier:tier,score:round(score,3)}一个反例错误率反升原因在输入长度有个客服团队把工单分类下放了。这任务在分级表上几乎是标准答案固定枚举、代价低、频次高。上线一周准确率反而低于云端方案。原因不在难度在输入长度。工单正文平均两三千字关键判据却写在正文中段——客户要的是退款还是换货常出现在第三段之后前面是订单信息、历史沟通这类无关内容。小模型在中长上下文里对中段信息的利用明显变弱而判据恰好落在中段。修法不是换更大的模型是改输入切分段落按关键词筛出候选片段只把候选片段按原序拼起来其余部分保留首尾各一段作为语境。输入从两千多字压到几百字判据重新落到开头附近准确率回到与云端相当。代价是新增一条切分逻辑与一类新失败模式切分错了模型会在正确的推理下给出错误结论且错误看起来很合理所以切分环节必须留下命中了哪几段的记录。这个反例说明的是——输入长度不是难度难任务配短输入可以下放简单任务配长输入反而不能。三、适合下放的四类任务按第二章的口径筛下来能留在下放档的任务集中在四类。分类与路由、抽取与格式化分类任务适合下放的根本原因是它能输出我不确定。分类输出是分数分布可以设阈值把置信度不足的样本退回云端端侧只处理有把握的部分生成任务没有这个出口——一段生成的文本说不出自己有多大把握。同类条件下分类和抽取因此比自由生成更适合下放。抽取和格式化的差别在可校验性。字段抽取的输出是结构化数据可以逐字段校验类型、取值枚举、必填项。校验不过的退回云端端侧只接住能过校验的部分错误因此可见。风险在于格式正确但内容错——模型填了一个合法却与原文不符的值schema 校验拦不住。文本清洗与改写去噪、切分、口语转书面这一类不要求逐字正确但要求守恒可以容忍措辞漂移不能容忍丢句、改序更不能把否定的意思写丢。所以验收标准不是和参考文本一致而是几条守恒约束——句数是否守恒、长度比是否落在合理区间、否定词与数量词有没有被改动。常见的坑是拿逐字相似度当指标相似度高的版本往往什么都改不动相似度低的反而更流畅两头的表现都被这个指标奖惩反了。可行做法是把关键实体、数量、否定词抽出来做集合比对这部分必须一字不差其余部分只查守恒。本地预处理脱敏、去重、敏感词标注属于本地预处理。这三类在本地做完出域的只是处理后的结果输入侧的数据边界问题被一并解决——它把能不能做变成了怎么做。难点不在模型能力在掩码规则的可逆性。人名、号码、地址的识别可以用小模型或规则做但掩码之后要能还原回原文否则人工复核和审计没法做。所以掩码要用可定位的占位符映射。任务类型输出空间错误代价下放要点分类与路由固定枚举低可拒识用置信阈值把不确定样本退回云端抽取与格式化结构化字段低可校验用类型与枚举校验另加字段对照原文清洗与改写自由文本但有守恒约束中需保序校句数守恒与长度比关键实体逐字比对本地预处理标注与掩码低掩码用可定位占位符映射表不出本地四、不该下放的四类任务分级的价值一半在筛出该下放的另一半在守住不该动的。不该下放的任务有四类共同点不是模型做不到而是失败形态无法收拾。长链路规划与广泛世界知识的开放问答规划类任务的误差是累积的。单步准确水平是九成五时十步链路走完整体落在正确路径上的比例只剩约六成——每一步的小偏差都在改变后续可用信息而任务不允许中间出错后重来。更麻烦的是断裂位置不可预测前三步正常第四步开始偏偏的那一步在日志上与正常步骤长得一样。开放问答的问题在覆盖面。参数规模偏小的模型长尾知识缺失是结构性的靠提示词补不上。这类任务里回答的流畅程度与正确程度几乎不相关——错的那部分往往措辞更自信因为它在补全一个模式而不是回忆一个事实。高错误代价的判定与无检索兜底的新近知识涉及金额计算、权限判定、对外合规结论的任务问题不在准确率高低而在没有重试机会。正确做法是把判定放在确定性的代码分支里模型只负责把结构化输入抽出来不下结论。新近知识的坑更隐蔽权重里不存在这类信息系统又没有检索通道时模型会稳定地编造每次编的内容都很像真的。判断标准很简单——问一句这个信息有没有可能存在于训练数据里。答案是否定的就必须有检索或者不下放。强行下放会出现的症状四类任务的失败形态各不相同但都会在观测指标上留下特征。把症状认出来比事后争论是不是模型不行有用。任务类型为什么不适合强行下放的症状长链路规划误差逐步累积中断点不可预测前几步正常中段开始跑偏开放知识问答长尾知识覆盖不足容量受限回答流畅但事实错误错误集中在冷门实体高代价判定单次错误不可接受没有重试机会偶发但每次都算事故复现困难无检索兜底的新近知识权重中不存在该信息稳定编造换种问法答案还会变五、下放之后架构上必须补的三件事下放不是把一次调用换个地址是新增一条并行路径。凡是新增路径就会新增不一致的可能三件事缺一件省下的收益都会变成新的负债。路由层判据怎么定判错了怎么办判据必须来自可观测的请求特征不能来自模型自评。请求里能直接读到的量——任务类型标记、输入长度、字段是否齐全——都是好判据让一个小模型先判断该不该交给大模型这类自评式判据等于把不确定性又叠了一层判错概率是两次判断的叠加。判据在配置里显式写出默认走向必须是安全侧判据缺失、字段异常、匹配不上任何规则时统一走云端。⚠️ 代码待验证router:default_route:cloud# 判据缺失时的走向必须落在安全侧rules:-name:ticket_classifyroute:edgesignal:task_typematch:[ticket_classify,intent_label]max_input_tokens:512# 超过阈值则回落云端fallback:cloud-name:doc_scrubroute:edgesignal:data_boundarymatch:[pii,internal_only]fallback:cloudon_error:cloud# 端侧异常统一升云端不在端侧重试判错有两个方向该走端侧却走了云端代价是没省到钱观测上是下放比例低于预期该走云端却走了端侧代价是质量问题观测上是下放路径失败率抬升。第二种才需要立即处置所以两个方向的量必须分开统计否则一份下放比例正常的报表会把第二种错误盖住。发现判错只有一个可靠手段抽样人工复核加分歧日志。端侧置信度低的样本、两条路结论不同的样本都要落盘并定期人工看一批——只看聚合指标判据的退化会一直藏着。一致性两条路答案不同时以谁为准以谁为准按错误代价分侧代价高的一侧为准通常是云端。端侧结果只在更可信的场景下优先采用比如任务被标注为只做本地处理云端看不到原文此时端侧是唯一答案。分歧必须留痕而且要落到样本级别。留痕有两个用途一是回灌评测集分歧样本天然是边界样本比随机抽样价值高二是算分歧率它突然抬升通常意味着某条路的输入分布变了。对不可逆动作要额外加一道二次确认。凡是会写库、会对外发通知、会改权限的判定无论走哪条路都不直接执行先产出待确认内容由确定性的代码完成落库或发送——这把模型判错从事故降级成一次错误的候选结果。⚠️ 代码待验证IRREVERSIBLE{refund,permission_grant,external_notify}defresolve(edge_out:dict,cloud_out:dict,action:str)-dict:ifnormalize(edge_out)normalize(cloud_out):return{answer:edge_out,source:edge,conflict:False}# 分歧一律以云端为准同时把分歧样本落盘供回灌评测集record_conflict(edge_out,cloud_out,action)ifactioninIRREVERSIBLE:return{answer:cloud_out,source:cloud,need_confirm:True}return{answer:cloud_out,source:cloud,conflict:True}灰度与影子流量双跑对比怎么做影子流量是下放前的标准动作端侧照跑但结果不返回给用户返回的始终是云端结果。跑一段时间后拿到的是一份真实对照数据而不是评测集上的数字——评测集的输入分布和线上差得很远很多问题只有输入真的长成线上那样才会出现。⚠️ 代码待验证importlogging loglogging.getLogger(shadow)defshadow_compare(payload:dict,edge_fn,cloud_fn)-dict:端侧结果只记录、不返回对外始终返回云端结果。result{answer:cloud_fn(payload),source:cloud}try:edge_outedge_fn(payload)log.info(shadow,extra{task:payload[task],agree:normalize(edge_out)normalize(result[answer]),input_len:len(payload[text]),})exceptExceptionasexc:# 端侧失败不影响主路径log.warning(shadow_edge_failed,extra{err:repr(exc)})returnresult比对指标定义怎么读一致率两条路归一化后结论相同的比例需按输入长度分桶看分歧率归一化后结论不同的比例突增说明上游输入分布变了端侧异常率端侧报错或超时的比例与业务质量无关反映资源约束端侧延迟分布端侧首字节与总耗时与云端同期对比看延迟收益是否存在分歧样本构成分歧样本的任务类型分布集中在某类任务时改判据而非改模型分歧样本本身就是资产按第二章的分层规则归档重点进边界与异常层。完整版资料清单本文用到的任务分级打分表与路由配置模板都整理在里面了扫码即可获取六、端侧与自建推理的现实约束下放的收益在账面上很清楚约束却常常到上线后才暴露。这一章讲三条必须在设计阶段算进去的约束。资源约束并发与内存相互挤压端侧推理的瓶颈不在算力峰值在内存的分配方式。模型权重常驻占用固定随并发变化的是每个请求各自的上下文缓存它随并发数近似线性增长。于是形成互相挤压并发数上去缓存占用跟着上去可用空间变小能同时处理的请求反而受限裁短单条请求的上下文能缓解但会伤到需要长输入的任务。直接推论是端侧同时处理的请求数必须由路由层显式限制而不是让它自然堆到排队。队列一旦形成延迟会非线性恶化用户感知的不是慢一点而是这条链路不可用。可行做法是给端侧设一个硬并发上限超出的部分直接走云端——宁可多花钱也不要让请求排队。量化的质量代价与验证方法量化是端侧部署绕不过去的一步代价也很明确精度下降不是均匀分布的。它在两类任务上放大得最快——长输出误差在逐 token 生成中累积和数值敏感任务金额字段的抽取与归一。短输入、固定枚举的分类任务受影响很小这也是前面筛出的四类任务更抗量化的原因。验证方法只有一条量化前后跑同一套评测集样本一个都不换。换样本之后两边分数不可比量化后反而更好可能是换了一批更简单的题。评测必须分层看总分相同、分层差异很大在量化上很常见。⚠️ 代码待验证# 同一评测集、同一随机种子量化前后各跑一次只改权重文件set-eEVAL./evalset/main-2026H1.jsonl python run_eval.py--model./weights/base--eval$EVAL--out./report/before.json python run_eval.py--model./weights/quantized--eval$EVAL--out./report/after.json python compare_report.py ./report/before.json ./report/after.json\--group-by intent,length_bucket# 必须分层看总分相同不代表没退化凭感觉判断量化后差不多是这类事故的常见起点退化往往集中在低频输入上日常手工试用碰不到只有分层跑评测集才会暴露。运维责任转移自建那一刻起三件事的责任全部转到自己这边。可用性。云端推理的抖动由服务方承担自建之后进程崩溃、内存不足、权重损坏、磁盘写满全都直接变成线上故障。端侧还多一层设备型号与系统版本分散同一份权重在不同设备上的表现不一致排查时先确认问题出在哪一层。版本升级。模型换版本、量化方案换、推理运行时升级任何一项都可能让小比例样本的输出变化所以升级必须走和代码一样的流程影子验证、灰度、可回滚。故障排查。云端方案出问题能拿到服务方状态页和日志自建的日志得自己设计。最少留三类路由判定记录、端侧耗时与异常、两条路的分歧样本。少任何一类问题都会停在用户说不对但复现不出来。七、迁移路线与观测前面六章解决该不该下放和下放要补什么这一章解决顺序问题以及什么时候该退回去。推进顺序四个阶段每阶段有明确的进入与退出条件不满足就不进下一阶段。影子流量是第一段。端侧照跑不返回只收集一致率与延迟分布。退出条件是按输入长度分桶看各桶一致率达到预期且端侧异常率稳定。没达到就停在原地查原因不要因为整体数字还行就放行——整体一致率容易被短输入样本拉高。小比例灰度是第二段。端侧结果开始对用户生效但只切一小部分流量且必须按会话或用户切。按请求切的代价是同一会话里来回换路径用户看到口径不一致的回答日志上也无法归因。分场景全量是第三段。逐类任务放开每放开一类重新看一遍失败率与降级触发率——不同任务的长尾输入占比不同会把整体指标带偏。兜底通道常驻是最后一段也是唯一没有退出条件的一段。云端通道不能因为已经全量下放就下线它要一直留着当降级目标。该看的四个指标指标定义异常读法路由判定准确率抽样人工判定中路由选择正确的比例下降说明判据与线上输入分布脱节下放路径失败率端侧结果未通过校验或异常的比例按任务分桶看集中在某类任务时改判据降级触发率端侧失败后转云端的请求占比持续抬升是回退的前兆先查资源约束单任务成本结构单次任务在两条路上的成本构成端侧省下的钱被路由与运维吃掉时下放不成立四个指标要一起看只看失败率会漏掉成本只看成本会漏掉质量。降级触发率最灵敏——它上升的早期失败率往往还没动因为失败被兜底通道悄悄接住了。⚠️ 代码待验证THRESHOLDS{route_acc:0.95,offload_fail:0.02,degrade_rate:0.05}defshould_rollback(metrics:dict,window:int3)-bool:连续 window 个观测窗口越界才回退避免被单点抖动触发。breaches[]forname,limitinTHRESHOLDS.items():seriesmetrics[name][-window:]iflen(series)window:continueifnameroute_acc:ifall(vlimitforvinseries):breaches.append(name)elifall(vlimitforvinseries):breaches.append(name)returnbool(breaches)回退设计什么时候果断退回全云端回退不该等到指标崩掉才做。以下四种情况出现任意一种就该把这条任务整体切回云端而不是继续调参。判据与线上分布脱节——路由判定准确率跌破阈值且连续几个窗口不回升说明判据本身要重做失败类型里出现了新类别——老的失败是格式问题新的失败是事实或金额错误说明任务已越过下放档运维投入超过省下的成本——账要按固定成本算不能只算调用费上游输入分布结构性变化——比如正文整体变长原长度阈值已失效要重新分级而不是调阈值。回退之后要做两件事把回退期间的样本按分层规则收进评测集特别是因为路由判错才走到端侧的样本给这类样本加一条回归用例明确触发条件与判定标准纳入必跑集合。只放着不跑同一个判据下次还会犯同样的错。完整版资料清单本文用到的迁移阶段检查表与四个观测指标的采集口径都整理在里面了扫码即可获取附表 A关键取舍一览下放相关的工程判断集中在这里方便按需回看。工程决策原因依据章节用任务分级代替模型选型难度不可测四个维度可在线上统计第一章错误代价设为唯一否决项其他维度再优也补不了单次事故第二章规划类任务保留在云端多步误差累积且断裂点不可预测第四章高代价判定交给确定性代码模型只负责抽取字段不下结论第四章判据取自可观测请求特征模型自评会把错误概率叠加两层第五章路由默认走向设为云端判据缺失时必须落在安全侧第五章不可逆动作强制二次确认把模型判错降级为一次候选结果第五章量化前后跑同一套固定样本换样本后前后分数不可比第六章兜底通道长期常驻它是降级目标不是过渡设施第七章灰度按会话切而不按请求切请求级切换会造成会话内口径断裂第七章附表 B术语速查表术语含义任务分级按输入长度、输出确定性、错误代价、调用频次对任务分档错误代价输出出错时下游后果的严重程度分级中的唯一否决项影子流量端侧照跑但结果不返回仅用于与云端结果对照路由判据决定请求走哪条路线的可观测请求特征分歧样本端侧与云端结论不一致的记录用于回灌评测集兜底通道云端的常驻降级路径不随下放完成而下线写在最后这篇用到的资料写这篇文章时我把几个模型的官方文档、参数表和实测记录都对了一遍顺手整理成几份配套的东西大模型学习路线图从 LLM 基础到 Agent 开发各阶段该学什么、用什么资料大模型全套教程按主题分好的视频与文档清单大模型实战好书24 本附每本适合的阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「大模型」优先通过。拿到之后建议先看学习路线图那一份先定位自己在哪个阶段再决定学什么比一上来就啃框架效率高得多。