AI大模型实战企业搭建指南

模型与算力

给企业技术负责人一条从选型、算账、部署到上线验收的完整路径,每步给出判断标准和可执行动作。

企业要上大模型,最容易卡在两头:一开始不知道该选哪个模型,选完又不知道机器、许可证、上线标准怎么定。中间那堆细节没人给一条顺序。这篇按落地顺序拆成几段,每段只回答一件事:这一步该产出什么、什么条件算过关、什么情况下这套做法不适用。数字一律不写死,需要时去站内对应页面按当天口径核对。

企业要上大模型,最容易卡在两头:一开始不知道该选哪个模型,选完又不知道机器、许可证、上线标准怎么定。中间那堆细节没人给一条顺序。这篇按落地顺序拆成几段,每段只回答一件事:这一步该产出什么、什么条件算过关、什么情况下这套做法不适用。

数字一律不写死,需要时去站内对应页面按当天口径核对。整条路径的顺序是先定边界、再缩候选、然后算配置、最后定验收,任何一步想跳过去,后面都会以返工的形式补回来。

第一步:先把边界定死,再谈模型

这一步不选模型,只产出需求边界。很多团队一上来就拉对比测试,测完发现数据出不了内网,前面的功夫全废。先把三个问题问清楚,候选方案自然就少了一大半。

  • 数据能不能出内网:不能出就直接排除云端接口,能出但要脱敏则要额外定脱敏规则和责任人
  • 延迟能忍到多少:秒级响应和分钟级批处理,对部署形态的要求完全不同
  • 谁来维护这套东西:有没有专职人盯服务,决定了能不能选自建推理这条路
  • 把任务分级:问答/检索、文档处理、代码辅助、多模态理解,不同级别对模型能力的要求差得很远,别用最高标准套所有场景
  • 产出物是一页纸的需求边界:写清允许的调用方式、可接受的人工兜底比例、上线时间点,后续所有决策都对着这张纸
边界问题常见答案直接砍掉的方案
数据出不了内网只能本地部署所有云端接口
延迟要求秒级并发不能等超大批量离线推理
没人专职维护运维靠兼职需要长期调优的自建集群
任务还在探索期人工都不稳定高成本定制微调

第二步:缩到两三个候选,用真实任务卡一遍

从站内模型库按能力维度筛,不要直接照搬榜单名次。榜单和真实任务的差距,站内已有专文讲透,这里只把榜单当筛选起点:先按能力维度圈出十来个,再用下面这几条往下砍,砍到两三个就停手。

  1. 准备样本自己准备二十到五十条真实业务样本,覆盖高频问题、边界问题和容易出错的格式要求
  2. 跑一遍并分类错答重点看错答的形态是胡说、漏答还是格式不稳,不同错法对应不同的补救成本,格式问题能用提示词解决,胡说要靠检索或换模型
  3. 过许可证和商用边界权重能不能商用、有没有附加条款,是选型阶段就要定的事,不能等到部署时才发现
  4. 留一份对比记录每条样本记下候选模型的表现和失败原因,这份记录后来会变成验收时的基线

什么情况下不适用:如果任务本身还在探索期、连人工都做不稳定,这时候做对比测试意义不大,先做小规模人工验证更划算。等人工能稳定出结果了,再回来做模型对比。

第三步:按量算配置,别按感觉买卡

顺序不能反:先定量化档位,再算显存占用,再看并发下的吞吐,最后才决定是自建还是按量调接口。反过来做,通常会出现买完卡发现跑不动目标并发的情况。

量化档位
精度和体积的取舍,先定档再算显存,别先买机器再迁就
显存占用
要留出余量给上下文和并发缓存,按理论下限配机器在真实流量下容易崩
吞吐
看的是并发下的表现,不是单条测试的速度
三块成本
硬件或租金、电费与运维人力、上线后扩容,只算第一块是最常见的预算翻车点

成本这块建议到站内价格与配置相关页面核对当天口径,用站内工具把显存换算跑一遍再报预算。适用于业务量稳定可预测的场景;如果用量波动非常大或者还在验证阶段,先租后买比先买后退更稳。

第四步:上线标准与回退方案

上线前把验收线写下来,不要等出了问题再补。答对率下限、响应时间上限、以及出现错误时的兜底路径(转人工还是给固定话术),这三条缺一条都不算完成上线准备。

  • 验收线:答对率下限、响应时间上限、人工兜底比例上限,对着第二步的对比记录来定
  • 回退路:保留旧方案或官方接口做并行,新方案出问题能一键切回去,切换动作要提前演练过
  • 上线后盯三类指标:错答率变化、平均延迟、用量是否超预算,任意一项异常都触发复查
  • 不适用情况:业务对错误零容忍时,比如直接对外承诺的条款类问答,不该让模型直接出结论,只做检索和初稿
验收项判断标准不达标时的动作
答对率不低于对比记录基线回退并行方案,复查样本与提示词
响应时间不超过业务可接受上限查并发与量化档位,必要时降级
兜底比例人工兜底在设定范围内调整触发条件,收紧自动回复范围
用量不超预算区间到站内价格页面重核口径并调配置
下一步把需求边界那页纸带去站内模型库和价格追踪页面,按当天数字把候选和预算核一遍,再决定自建还是调接口。

常见问题

预算有限,是不是只能先用免费或开源模型?

不一定。先看任务错答的代价有多大:错了能人工兜回来的场景,低成本方案可以先跑;错了会直接造成损失的场景,省下的钱不够赔。建议先小范围并跑两种方案,用真实样本比错答形态,再决定钱花在哪。

选型阶段要不要做微调?

多数情况先别做。先把提示词和检索这套跑通,看错答是知识缺口还是格式问题;只有确实是模型风格和领域表达不到位,且手上有稳定标注数据时,微调才划算。微调的数据准备和成本另算一笔账,别和选型混在一起做。

怎么判断这套东西该继续投钱还是该停?

定一个观察周期和一条线:比如连续一段时间里错答率没往下走、人工兜底比例没降、用量也没增长,说明它没真正进入业务流。这时候要么换场景,要么缩规模,别靠加班硬推。

本文依据各平台公开文档与官方公告整理,只做中文归纳;具体做法、参数与限制以官方文档为准。