ai垂类大模型落地解决方案

做行业大模型最容易卡在三处：数据到底够不够喂、该微调还是外挂知识库、算力和许可证怎么配才不返工。市面上讲概念的多，讲动作的少。这篇按落地顺序拆成可执行步骤，每一步给判断标准和不适用情形，涉及价格、显存、排名的具体数字一律指向站内对应页面，你在自己项目上对着填就行。

做行业大模型最容易卡在三处：数据到底够不够喂、该微调还是外挂知识库、算力和许可证怎么配才不返工。市面上讲概念的多，讲动作的少。这篇按落地顺序拆成可执行步骤，每一步给判断标准和不适用情形，涉及价格、显存、排名的具体数字一律指向站内对应页面，你在自己项目上对着填就行。

先说明一句立场：垂类大模型不是每个团队都该做的事，也不是做完就一劳永逸。下面这条路径假设你手里已经有一个明确的业务场景和能拍板的业务方。如果这两样还没有，先别往下读，回去把场景和验收人定下来，否则每一步都会返工。

先定边界：垂类模型到底解决哪一类问题

很多项目失败不是技术不行，是一开始就把不该上垂类的需求塞了进来。先把业务问题拆成三类：知识检索型、流程判断型、生成创作型。经验上看，只有前两类值得上专用模型，第三类往往通用模型加好提示词就够了，投入产出比不划算。

• 把「通用模型已经够用」的场景单独列一张清单，这些不做垂类，避免为不存在的收益付成本
• 确认垂类收益来自哪里：数据私有、术语专有、响应时延还是合规要求，四个来源至少要占一个
• 找业务方确认验收人是谁，谁签字谁负责，没有验收人的项目不要立项
• 什么情况下不适用：任务样本极少、判定标准还在变、下游没人愿意做验收，这三条占一条就先停

数据环节：先盘点再谈训练

数据是这类项目里最容易被高估的一块。团队常说我有很多文档，但一问验证集从哪来就卡住。正确顺序是先盘点再谈训练，按种子集、增强集、验证集三层来数，缺哪层补哪层。验证集必须人工标注，且来源要与训练数据隔离，否则你测的是记忆不是能力。

种子集

一小批高质量、标注一致、直接对应任务的核心样本，是全流程的基准

增强集

在种子集基础上扩充和改写出来的训练语料，规模大但质量参差

验证集

独立来源、人工标注、只用于评测，绝不能混进训练

给数据打分看四个维度：覆盖度、标注一致性、时效性、可授权性。四个维度任一不过关就先别往下走。清洗顺序建议是去重、脱敏、格式统一、抽样人工复核，每一步留可追溯记录。训练数据来源与授权边界的对照，去 /safety 核一遍，别等做完再补。

1. 盘点现有语料按三层分开统计，写清每层的条数和来源；验证集不够就先补验证集，不补就停。
2. 四维打分覆盖度、标注一致性、时效性、可授权性各打一档，任一档不及格先解决它。
3. 清洗留痕去重、脱敏、格式统一、抽样复核按顺序做，每步记下处理前后的条数。
4. 合规核对到 /safety 对照授权边界，确认哪些语料能训、哪些只能检索不能训。

路线选型：提示词、外挂知识库、微调怎么分工

外挂知识库适合知识频繁更新、答案需要引用来源的场景；微调适合输出格式固定、判断标准稳定的场景。两者可以叠加，但顺序很重要：先跑通知识库再做微调。顺序反了会浪费大量标注成本，因为标准还在变，标出来的数据很快作废。

怎么定？做一个小规模对照实验最靠谱：同一批测试问题，三种方案各跑一遍，比命中率和人工返工量。不适用情形也要说清楚：如果业务答案本身没有稳定的判断标准，这三条路都救不了，先回去对齐标准，别急着训模型。

基座怎么挑：按任务维度筛，不按名气筛

候选池从 /stacks/specialized-models 的垂类目录和 /models 模型库出。先按语言、上下文长度、是否可本地部署三个硬条件过滤，把候选压到两三个，再用自己的验证集跑一遍。公开榜单只能用来初筛，不能用来说服业务方，因为榜单任务和你的任务往往不是一回事。

• 先定硬条件：语言支持、上下文长度、能不能本地部署、许可证类型
• 候选压到两三个后，用自己验证集实测，别只看榜单结论
• 每个候选都确认许可证与商用边界，开源权重不等于可以随便商用
• 价格差异到 /official-api 和 /inference 看当时的数字，别用记忆里的旧价做预算
• 把实测结果整理成一页对比表，交给业务方一起定，别自己拍板

部署形态：私有化、托管还是混合

部署形态看三条判断线：数据能不能出内网、并发峰值有多高、团队有没有运维人力。三条线两两组合，答案基本就出来了。私有化要额外算的账包括电力、机房、备卡和值班人力，光算显卡会明显低估总成本，这一点在给决策层汇报时要说透。

混合方案在实践中很常见：敏感数据走本地小模型，复杂推理走托管接口，按请求类型分流。具体卡型与租用价格去 /compute/sizing 和 /compute/gpu-rental 对一遍，用当时的行情算，不要拿旧报价做预算。

量化档位与显存并发：先算容量再定档

顺序是先估并发峰值对应的显存需求，再倒推能不能降量化档，而不是反过来先降档再看跑不跑得动。降档位前必须做回归测试：用你的验证集对比降档前后的错误类型，有些任务对精度损失特别敏感，比如数值推理和长文档问答。

1. 估并发按业务峰值的并发请求数估算需要的显存，把参数量、量化位宽、上下文长度填进 /models/deploy 的换算工具。
2. 定档位从高精度档往下试，每降一档跑一次验证集，记录错误率变化。
3. 回归对比重点看错误类型有没有变，如果出现原来没有的错法，说明这一档不能接受。
4. 留余量给并发峰值留一定余量，别把显存算到刚好够用。

不适用的场景要说清楚：任务强依赖长上下文或高精度数值推理时，量化省下的那部分成本可能抵不过返工成本，这种场景宁可多加卡也别硬降档。

验收与上线：把「感觉不错」换成可测指标

上线前必须定义三类指标：任务命中率、拒答率、人工兜底率。每个都给出基线值和可接受区间，区间要业务方一起认。做一轮对抗测试：边界输入、模糊提问、越权请求，重点看模型是硬答还是拒答，硬答比拒答危险得多。

• 三类指标都要有基线值和可接受区间，不能只有目标值没有底线
• 对抗测试覆盖边界输入、模糊提问、越权请求三类，记录每次的答法
• 留一键回退开关，能切回上一版或切到通用模型，回退路径提前演练
• 把每次评测的输入输出留档，后续换模型时可以直接复用
• 模型换代后的迁移与验证思路参考 /tools/quality-monitor 的做法

预算与周期怎么拆才有说服力

把预算拆成四块：数据标注、算力、集成开发、上线后的持续运营。后两块最容易被漏算，而它们恰恰是上线后花钱最持续的部分。给决策层汇报时用分阶段投入加阶段验收门槛，不要一次性报总数，这样每一期都有停下来的机会。

训练成本口径看 /compute/training-cost，微调与托管推理的成本对比看 /compute/finetune。什么情况下不适用：如果业务方三个月内拿不到可验证的收益信号，建议先缩到单场景试点，别一上来就铺全线。