企业要上大模型,最容易卡在两头:一开始不知道该选哪个模型,选完又不知道机器、许可证、上线标准怎么定。中间那堆细节没人给一条顺序。这篇按落地顺序拆成几段,每段只回答一件事:这一步该产出什么、什么条件算过关、什么情况下这套做法不适用。数字一律不写死,需要时去站内对应页面按当天口径核对。
企业要上大模型,最容易卡在两头:一开始不知道该选哪个模型,选完又不知道机器、许可证、上线标准怎么定。中间那堆细节没人给一条顺序。这篇按落地顺序拆成几段,每段只回答一件事:这一步该产出什么、什么条件算过关、什么情况下这套做法不适用。
数字一律不写死,需要时去站内对应页面按当天口径核对。整条路径的顺序是先定边界、再缩候选、然后算配置、最后定验收,任何一步想跳过去,后面都会以返工的形式补回来。
第一步:先把边界定死,再谈模型
这一步不选模型,只产出需求边界。很多团队一上来就拉对比测试,测完发现数据出不了内网,前面的功夫全废。先把三个问题问清楚,候选方案自然就少了一大半。
- 数据能不能出内网:不能出就直接排除云端接口,能出但要脱敏则要额外定脱敏规则和责任人
- 延迟能忍到多少:秒级响应和分钟级批处理,对部署形态的要求完全不同
- 谁来维护这套东西:有没有专职人盯服务,决定了能不能选自建推理这条路
- 把任务分级:问答/检索、文档处理、代码辅助、多模态理解,不同级别对模型能力的要求差得很远,别用最高标准套所有场景
- 产出物是一页纸的需求边界:写清允许的调用方式、可接受的人工兜底比例、上线时间点,后续所有决策都对着这张纸
| 边界问题 | 常见答案 | 直接砍掉的方案 |
|---|---|---|
| 数据出不了内网 | 只能本地部署 | 所有云端接口 |
| 延迟要求秒级 | 并发不能等 | 超大批量离线推理 |
| 没人专职维护 | 运维靠兼职 | 需要长期调优的自建集群 |
| 任务还在探索期 | 人工都不稳定 | 高成本定制微调 |
第二步:缩到两三个候选,用真实任务卡一遍
从站内模型库按能力维度筛,不要直接照搬榜单名次。榜单和真实任务的差距,站内已有专文讲透,这里只把榜单当筛选起点:先按能力维度圈出十来个,再用下面这几条往下砍,砍到两三个就停手。
- 准备样本自己准备二十到五十条真实业务样本,覆盖高频问题、边界问题和容易出错的格式要求
- 跑一遍并分类错答重点看错答的形态是胡说、漏答还是格式不稳,不同错法对应不同的补救成本,格式问题能用提示词解决,胡说要靠检索或换模型
- 过许可证和商用边界权重能不能商用、有没有附加条款,是选型阶段就要定的事,不能等到部署时才发现
- 留一份对比记录每条样本记下候选模型的表现和失败原因,这份记录后来会变成验收时的基线
什么情况下不适用:如果任务本身还在探索期、连人工都做不稳定,这时候做对比测试意义不大,先做小规模人工验证更划算。等人工能稳定出结果了,再回来做模型对比。
第三步:按量算配置,别按感觉买卡
顺序不能反:先定量化档位,再算显存占用,再看并发下的吞吐,最后才决定是自建还是按量调接口。反过来做,通常会出现买完卡发现跑不动目标并发的情况。
- 量化档位
- 精度和体积的取舍,先定档再算显存,别先买机器再迁就
- 显存占用
- 要留出余量给上下文和并发缓存,按理论下限配机器在真实流量下容易崩
- 吞吐
- 看的是并发下的表现,不是单条测试的速度
- 三块成本
- 硬件或租金、电费与运维人力、上线后扩容,只算第一块是最常见的预算翻车点
成本这块建议到站内价格与配置相关页面核对当天口径,用站内工具把显存换算跑一遍再报预算。适用于业务量稳定可预测的场景;如果用量波动非常大或者还在验证阶段,先租后买比先买后退更稳。
第四步:上线标准与回退方案
上线前把验收线写下来,不要等出了问题再补。答对率下限、响应时间上限、以及出现错误时的兜底路径(转人工还是给固定话术),这三条缺一条都不算完成上线准备。
- 验收线:答对率下限、响应时间上限、人工兜底比例上限,对着第二步的对比记录来定
- 回退路:保留旧方案或官方接口做并行,新方案出问题能一键切回去,切换动作要提前演练过
- 上线后盯三类指标:错答率变化、平均延迟、用量是否超预算,任意一项异常都触发复查
- 不适用情况:业务对错误零容忍时,比如直接对外承诺的条款类问答,不该让模型直接出结论,只做检索和初稿
| 验收项 | 判断标准 | 不达标时的动作 |
|---|---|---|
| 答对率 | 不低于对比记录基线 | 回退并行方案,复查样本与提示词 |
| 响应时间 | 不超过业务可接受上限 | 查并发与量化档位,必要时降级 |
| 兜底比例 | 人工兜底在设定范围内 | 调整触发条件,收紧自动回复范围 |
| 用量 | 不超预算区间 | 到站内价格页面重核口径并调配置 |
常见问题
预算有限,是不是只能先用免费或开源模型?
不一定。先看任务错答的代价有多大:错了能人工兜回来的场景,低成本方案可以先跑;错了会直接造成损失的场景,省下的钱不够赔。建议先小范围并跑两种方案,用真实样本比错答形态,再决定钱花在哪。
选型阶段要不要做微调?
多数情况先别做。先把提示词和检索这套跑通,看错答是知识缺口还是格式问题;只有确实是模型风格和领域表达不到位,且手上有稳定标注数据时,微调才划算。微调的数据准备和成本另算一笔账,别和选型混在一起做。
怎么判断这套东西该继续投钱还是该停?
定一个观察周期和一条线:比如连续一段时间里错答率没往下走、人工兜底比例没降、用量也没增长,说明它没真正进入业务流。这时候要么换场景,要么缩规模,别靠加班硬推。