大模型和小模型管理的区别

很多人选型时把大小模型当成同一件事，只是参数多少的区别，真到部署环节才发现：一个大模型要占一整张卡、并发上不去、升级还得停机；而一堆小模型分散在边缘和业务侧，没人统一管版本，出了问题找不到是哪台机器上的哪个权重。这篇不谈哪个模型更强，只按运维视角把两类模型的管理动作拆开：资源怎么算、更新怎么做、监控盯什么、什么规模下不该硬凑。

选型会上大家聊的是效果，落到运维手上其实是两套完全不同的活。大模型常见形态是几张卡跑一个实例、流量从服务端统一进来、管理面集中在少数人手里；小模型则往往是一份权重复制到很多节点、边缘盒子或者客户端里，管理对象是几十上百份副本。前者的问题集中在显存和并发，后者的问题集中在版本和分发。

这篇不讨论谁更强，只按运维视角把两类模型的管理动作拆开：先怎么判断自己属于哪一类，再分别看资源测算、量化格式、更新回退、许可证来源、监控值班，最后说清哪些前提下这套分法不成立。核心是一句话：分界线不是参数量，而是「一个实例能不能被你一个人看完」。

先分清两者在部署形态上的根本差别

集中式和分散式带来的管理动作差别，比模型本身的能力差别更影响日常工作量。集中式下出问题，你只需要登录有限的几台机器、看同一个服务的日志；分散式下出问题，第一件事是要先定位是哪一台设备、哪个版本的权重在报错。所以判断走哪套流程，看的不是模型多大，而是副本形态。

• 实例数少、配置集中、能一个人看完：按大模型那套集中式流程管；
• 副本多、现场没人懂模型、更新需要下发：按小模型那套分散式流程管；
• 混合场景很常见，核心链路用大模型做主力，前置分类、改写、脱敏用小模型，两边要用不同的监控口径和发布节奏，别共用一套流程；
• 同一个业务里两类模型同时存在时，先写清谁负责哪些请求，否则出了故障会互相甩锅。

资源测算：一个按卡算，一个按份数算

大模型的账从显存开始：权重占用、KV 缓存、框架自身的开销三块叠起来，量化档位一变，能同时塞下的并发数就跟着变。小模型的账从份数开始：单份权重不大，但乘以几十上百个节点之后，磁盘、内存、装机耗时和更新时的下发带宽才是主要成本。两边的估算入口不一样，不能互相套用。

1. 第一步，先确定形态列出实例数量和副本数量，落到哪一类就用哪一类的估算表，别用大模型的并发公式去推小模型。
2. 第二步，跑一遍当时的参数大模型到 /models/deploy 用当时的量化档位、上下文长度和并发目标跑一遍估算；小模型按单份体积乘以节点数，再加上更新时的下发量。
3. 第三步，留余量并写清依据大模型按峰值并发留，小模型按节点扩容和灰度批次留；余量比例由业务能容忍的降级程度决定，写进容量备忘而不是拍脑袋。
4. 第四步，定期复算流量结构、量化档位或节点数任一变化，重新跑一遍，不要沿用上季度的结论。具体数字都到站内页面核对当时的数值。

量化与外发格式：一个省显存，一个省分发

大模型做量化，动机主要是装得下、跑得动，代价通常体现在长尾任务上的稳定性下降，所以换档之后必须拿自己的业务集做回归。小模型的格式选择更多是「目标环境能不能加载」的问题，有的运行时只吃特定格式，选之前先确认现场环境，再决定导出成什么。

回归基线

量化前后各跑一遍同一批样本，记录差异，否则出问题时无法判断是量化引起还是流量变了。

固定样本集

维护一份不随业务波动的回归样本，每次换档、换格式都跑同一份，结果才可比。

格式确认

小模型导出前先问清目标运行时支持什么，避免导出完才发现加载不了。

• 换量化档位前，先跑固定回归样本并留存结果；
• 确认该档位下的并发上限，是否满足当前峰值；
• 小模型要先确认目标设备的运行时和存储格式；
• 记录量化前后的对照基线，随权重一起归档，方便事后追溯。

更新与回退：集中式一次搞定，分散式才是硬仗

集中式的更新相对好管：新实例起好、健康检查过了再切流量，回退就是切回旧实例，代价是更新期间双份资源占用，机型不够时只能排期停机。分散式的更新是长尾问题，要控制下发批次、支持断点续传和失败重试，还要防止半新半旧导致同一输入在不同设备上给出不同结果。

1. 定回退触发条件把错误率、延迟、抽样质量的阈值写清楚，先定条件，再定谁来按这个按钮。
2. 大模型走切换新实例验证通过后切流量，旧实例保留一段时间；预留双份资源，不够就排期停机。
3. 小模型走分批按批次下发，允许失败重试和断点续传；明确「哪些节点允许落后一个版本」，避免口径不一致。
4. 验证后再全量灰度批次的节点上跑合成请求验证，通过后再扩大范围；具体阈值和节奏到 /tools/verify 参考当时的检查项。

许可证、来源与可替换性

大模型选型时，权重许可能不能支撑你的商用形态是硬条件，很多条款的边界需要逐条读，光看仓库首页那一句往往不够；遇到不熟悉的术语，到 /ai-dict 对照解释。小模型经常被打包进硬件或客户端一起分发，再分发条款更容易被忽略，做产品化的团队尤其要提前确认。

两类都建议提前保留一个可替换的第二选择，并把切换工作量估出来写进选型备忘：改配置、重新压测、还是需要重走下发热更新，差别很大。等真断了再找，代价会明显更高。

监控与值班：盯的指标不一样

大模型要盯延迟分位、排队长度、显存占用和输出长度分布，短时间的抖动往往来自流量结构变化，而不是模型本身退化；看指标时要连着流量一起看。小模型要盯副本存活率、版本分布、单机资源和静默失败，本地跑挂了不一定有人上报，只能靠探针合成请求主动去探。

• 大模型：延迟分位、排队长度、显存占用、输出长度分布；
• 小模型：副本存活率、版本分布、单机资源、探针成功率；
• 两类都要把告警阈值和业务降级动作绑在一起写清楚：触发了是自动降级、排队，还是返回兜底话术；
• 值班手册里写清每个告警对应的第一动作，避免现场临时商量。

监控不是把指标画在面板上，而是让值班的人知道触发之后先做什么。

这些判断在什么情况下不成立

上面这套分法建立在「实例形态决定管理动作」的前提上，有几类场景会把这个前提推翻，遇到了就要单独评估，不要硬套。

• 模型自带超长上下文或多模态输入时，小模型的资源账会被输入长度重新拉开，不能按参数多少凭直觉估；
• 合规要求数据不出内网、节点又极多时，分散部署带来的审计面反而更大，集中式管理更省事；
• 业务量很小、只跑一个验证性场景时，两套流程都不用搭，先用托管接口把事跑通，等量起来再谈分层；
• 团队里没人专职做运维时，优先把流程简化到一个人能维护的程度，再考虑分层。