选大模型这件事这两年越来越像选装修队。招牌上都是“全屋定制、高级工艺、超低报价”可真等进场施工能不能按你的户型落地、能不能在规定时间交付、后面出问题找不找得到人才是真正决定成败的细节。我在过去一年多里参与了多条业务线的模型选型最深的一个体会是报价单和榜单最容易看也最容易骗人。有一阵子团队内部只看公开评测分数谁的分高就切谁结果上线后真实请求一来输出格式乱、长文本丢信息、在高峰期接口限流问题一个接一个。后来我慢慢把选型流程收敛成了固定的五件事每评估一个新模型都会逐条过一遍能力是不是真的匹配业务场景上下文窗口的可用长度到底有多少成本账能不能算得过来部署和集成顺不顺生态和社区值不值得长期押注。听起来都是最基础的维度但每一条展开都有不少隐藏的坑。这篇文章就把我的检查清单完整讲一遍适合正在做技术选型、准备替换模型或者刚开始接触大模型项目的团队参考。1. 能力评测基准分数说了不算业务场景说了算1.1 通用能力和场景能力的差距比你想象中大得多开始选型之前我一直建议团队先做一件看起来和技术无关的事把自己业务里的真实任务写下来按类型归类。是写文案、做长文档摘要还是从对话里抽结构化的关键信息是给代码纠错还是根据规则生成合乎格式的报表因为大模型的“能力”从来不是一个统一的标量。一个模型在文本创作上表现出色不代表它在复杂指令跟随的情况下也能稳定输出。同样的道理代码能力强的模型不见得能做好医疗问答或电商客服擅长中文的模型也不代表它在英文材料翻译上能和一线产品持平。公开榜单的分数是一个综合值综合值的问题恰恰在于掩盖了长短板。以前带过一个项目团队把所有模型都跑了一遍通用评测某个候选者分数最高大家正准备切过去我拿销售工单丢进去一测结果它给出的情绪分类完全不符合业务规则原因是没有把“输入归一化”这类公司特有的业务细节包含在测试里。从那以后我们把“能不能回答好公开问题”和“能不能在我要的使用场景里干活”彻底分开。1.2 我常用的三档测试法微测、场景流、对抗输入能力评估我习惯分成三档来做。第一档叫“微测”就是拿二三十条能代表你核心业务的小样本快速跑一遍。这一档的目的不是给出精确排名而是把明显不合适的候选者先淘汰掉。第二档叫“场景流测试”要模拟用户真实使用时整个环节。以客服场景为例用户输入一句口语化描述模型需要先判断意图再抽取用户信息再输出一个特定字段才能对接下游系统。如果模型在单一步骤做得很好却在连贯的几步中丢失了前文或格式不受控那依然不合格。“单独问题都答对了连起来全乱了”是场景流测试里最常遇到的翻车点。第三档叫“对抗输入”刻意用一些边界样本去试探模型。比如超长文本、夹杂错别字的用户输入、恶意诱导、与业务规则冲突的指令。这一档最能看出一模型到底有没有把业务规则真正学进去还是只是看起来很懂。三轮测试跑完我会把所有结果记录在同一个表格里标注“通过”“基本通过”“不通过”并要求测试集固定版本、固定模型的温度参数和提示词前缀。否则下次复查时结果不可比你根本不知道是模型变强了还是上次提示词没写对。1.3 私有测试集要长期沉淀评分标准要提前定每个团队都应该有自己的私有测试集这件事不光选型时有用后续每次版本升级都要复用。测试集不用很大三五十条高质量样本远比五百条低质量样本有用。关键是每条样本都要能回答出标准的输出是什么否则你只是用感觉在打分。评分标准也要提前定好。如果业务要求结构化输出就在答案里规定字段名、字段类型、可选枚举值如果业务要求摘要忠实原文就要明确规定禁止添加原文没有的信息。这样跑出来的差异才是可量化的差异而不是“我感觉这个模型好像更好”的感觉。跑测试时要固定随机种子和采样参数。同一个模型用不同温度跑出来的结果差异可能很大如果测试时模型参数和上线时不一致这个测试结果参考价值就打了折扣。2. 上下文窗口参数再大能用多长才是真的2.1 上下文窗口的“参数幻觉”和“中间丢失”现象上下文窗口是选型中被夸得最多的参数。厂商宣传动不动就是几百万token听起来像什么资料都能整篇塞进去。可真实业务里上下文窗口大远不等于效果就好。原因很朴素绝大多数模型在长文本上的注意力分布并不均匀对长文中间部分的记忆明显弱于开头和结尾这叫“中间丢失”现象。你可以把模型理解成一个开会精力有限的人一场会议开始和结尾的内容记得最清楚中间别人随口说的几句话很容易被漏掉。上下文窗口只是设置了它的座位上限不保证每个座位的使用者都认真听讲。此外上下文窗口的单位是token不是字数。中文一个字可能对应一个或多个token看起来给你两万token的窗口实际装下的中文内容通常只有一万字出头。如果业务里有大量表格、代码和网页结构实际能容纳的还会更少。2.2 用可控测试把真实上下文上限测出来在选型时我不会只看宣传的窗口上限而是会做一个固定的可控测试方法非常简单构造一个大段占位文本把一段需要模型记住的关键指令分别放在开头、中间、结尾三个位置然后让模型回答一个只有依赖关键指令才能答对的问题看看它在哪个位置开始答错。测试文本的长度也要逐级增加比如从两千token测到五六千甚至上万每次单独记录结果。# 示意逻辑把关键信息埋到不同位置再分别发请求 def build_prompt(base_text, target_text, position): if position 开头: return target_text base_text if position 结尾: return base_text target_text if position 中间: mid len(base_text) // 2 return base_text[:mid] target_text base_text[mid:]这是很实用的办法。我们曾经测过两个宣称同样窗口大小的模型实际表现差距明显其中一个把关键信息放到中段后还能正确提取另一个在占位文本超过一半时就开始胡编乱造。如果你只想凭感觉判断大概率会被相似的参数规格迷惑。测试方法不需要特别复杂手动构造文本也能做如果想批量测写一个简单脚本就行把关键信息埋进不同位置再循环发请求最后统计正确率。本质都是一样的不要把“最大窗口”当作“有效窗口”。2.3 长文本场景的工程补偿策略如果你的业务确实有大量长文档处理需求选型时除了看模型能力还要提前想好工程侧怎么做。最常见的做法是检索增强把长文档切成若干块先通过向量检索或关键词匹配找到相关段落再把段落拼进提示词发送给模型而不是整篇原文都塞进去。这样做的好处是节省token、降低延迟更重要的是能回避“中间丢失”带来的质量下降。代价是引入了一整套检索链路需要维护向量库每次问答都要多一跳查询。另一个方向是摘要压缩长文档先交给模型做分层摘要再把摘要作为上下文。这种方案适合对局部细节要求不高的场景比如整月销售数据的趋势分析。如果要求精准引用原文某个条款压缩摘要就可能扛不住了。我在选型时一般会同时准备这两套思路然后看候选模型对“段落级输入”“结构化摘要输入”分别的表现。别把这个环节拖到上线后否则你会发现真正拖垮系统的不是模型推理速度而是提示词越拼越长成本越滚越大。3. 成本账别只盯着单价要算总账3.1 token价格不是全部拆开算才算得清很多团队选型时第一件事就是比每百万token单价这当然重要但不能只看这个数。真实账单由多个成本项组成输入tokens、输出tokens、缓存命中tokens以及失败重试带来的额外请求。输出tokens往往比输入tokens贵得多所以在同样业务里一个输出简短但答案覆盖率低的模型可能比一个单价更贵但输出精炼的模型整体成本更高。因为一旦答案不合格业务就要重发请求重试的成本就是原请求成本的乘法。成本项计算方式示例单价输入tokens输入token数 × 输入单价2元/百万tokens输出tokens输出token数 × 输出单价8元/百万tokens缓存命中命中token数 × 缓存单价0.5元/百万tokens失败重试失败率 × 原请求成本总和视场景而定举个简单的数字例子。假设某个客服助理平均每次请求输入1000 token、输出300 token单日20万次请求。输入按每百万token 2元、输出按每百万token 8元计算单日的原始成本约等于20万乘1000除以100万再乘2加20万乘300除以100万再乘8合计400元加480元共880元一个月光是这句请求的API费用就超过2.6万元。如果其中有10%的请求因为超时或格式不对需要重试还要再叠加10%的成本。聊到这一步很多最初觉得“便宜”的方案就变得没有那么便宜了。3.2 API调用和本地部署的分水岭在哪里要不要自己部署一直是选型里最纠结的问题。我的经验是分三种情况看。第一如果项目处于探索期流量小、需求还在频繁变直接用API是性价比最高的选择因为你不用为GPU硬件和运维人员提前买单。第二如果业务已经稳定、调用量大长期跑下来API费用会超过自己部署的费用。这时候引入私有化部署才值得认真核算。部署不只是买一张卡那么简单还要把部署、监控、告警、模型更新、硬件维护这些都算进总账别只看GPU价格。第三假如对数据有强约束不允许文本出内网那即使API再便宜也不需要考虑私有化开源模型基本是唯一选择。私有化部署有一个最典型也最常见的坑立项时按GPU价格算了一笔账觉得肯定划算结果忽略了运维工程师的工时和模型迭代时重新部署的工作量。GPU是一次性成本但人的时间和试错成本是持续发生的这部分往往两三个月就追平了原本省下的API费用。3.3 吞吐量和延迟是成本里最隐蔽的两项同样的模型放在不同的推理框架上吞吐量可能差好几倍。吞吐量上不去的模型在高并发场景下就要加机器加机器就是加钱。延迟也一样如果一次请求要多等两三秒很多实时业务就直接不可用只能被迫切换更贵的加速方案。我筛选模型时会格外关注两个指标首token延迟和每token输出速度并且会要求用接近生产环境的提示词长度来测而不是拿一个短问题就糊弄过去。因为提示词越长预填充阶段耗时越长首token延迟会明显变大。同一个模型输入是200 token和输入是3000 token的首token延迟可能差出一倍不止这个差异在选型测试中很容易被漏掉。如果候选模型本身吞吐不够就要看推理环境有没有提供连续批处理、量化、张量并行这类优化能力。这些信息在宣传页未必写得清楚选型时要主动问。4. 部署与集成模型很强接不进业务就是白搭4.1 开源模型与闭源API的边界判断开源和闭源不是简单的哪个更好而是不同约束条件下的选择。如果你所在的团队有足够的模型调优经验对算力成本敏感并且业务对数据边界的要求高开源模型会给你最大的自由度因为模型权重掌握在自己手里想怎么微调都可以。反过来如果团队规模小、上线时间紧、又不想养模型运维的人闭源API的成熟度和稳定性就是更大优势。还有一个边界很容易被忽略你的业务到底是偏通用还是偏垂直。垂直业务依赖大量私有知识和业务规则闭源API可以通过提示词和缓存来适应但要做得更深入往往还是得自己微调模型。选型时把这个边界想清楚比争论谁的技术更强有意义得多。我见过不少团队一开始因为某个开源模型的效果不错就直接切到了私有化结果上线后模型尺寸太大、推理速度不够又回头重新选API一来一回浪费了小一个月。选型不是选完就结束还要为你团队的工程能力买单。4.2 版本升级、接口变动和输出漂移模型选型时很少有人会把“半年后的维护”放进去但这件事恰恰最影响长期体验。闭源API版本升级是常态升级后同一个提示词的输出可能发生变化有时候感觉更好有时候反而开始答非所问。这叫输出漂移。如果业务对输出格式有严格要求升级前必须重新跑一遍自己的私有测试集确认没有回归才允许切换。开源模型的版本迭代同样有风险新版本模型微调后可能在某个任务类别上变强在另一个类别上偷偷变弱。这也是我把私有测试集当作长期资产的原因只要模型版本有变动就得重新跑一遍测试集再决定要不要升。接口层面还要考虑限流、超时、并发上限这些细节。有的API虽然效果好但高峰期并发一上来就频繁限流下游任务只能重试用户体验直接下滑。选型时最好调取短期的压力测试数据别只听口头保证。4.3 私有化部署的最小可行架构如果你决定私有化部署我建议先搭建最小可行架构而不是一开始就追求复杂的分布式集群。所谓最小就是一台推理服务加上一套模型存储和一个简单的访问入口先让业务能跑起来再逐步补监控和弹性扩缩容。硬件上部署多大模型直接决定了你需要多少显存。大致可以这么估算参数级数在70亿上下的模型量化后通常需要16到24GB显存单张普通显卡能勉强跑起来130亿参数级别的模型一般需要32到48GB显存700亿参数级别的模型往往要120甚至160GB以上显存需要多卡互联。这只是很粗略的估算同一级别的不同模型架构差异很大但可以帮你在预算还没批下来时先形成一个数量级概念。更重要的是推理吞吐。同样的模型用不同框架跑吞吐可以相差数倍。选型时我建议把候选模型的部署方案也纳入考核无论是自己部署还是交给第三方托管都要实测QPS和响应延迟而不是只看能跑通。4.4 在架构上给自己留一条退路模型这个领域迭代非常快今天的最优解半年后可能就成了平庸选项。因此不管选了哪家我都会在架构层面对模型做一层抽象也就是模型网关。简单说就是业务只面向一个统一接口不直接绑定具体模型产品模型网关负责根据路由规则把请求调度到具体模型并在模型升级或替换时对业务透明。这样一来哪天需要切换到新模型业务代码不用大改只需要调整网关配置。很多人会觉得自己团队小、项目也小不需要这么复杂的抽象。但实际经验是这套抽象越早做越好等几百个调用点都写死了模型名再去改造成本要高得多。网关一开始可以很轻只要能转发、能记录日志、能统计token消耗就够了后面再慢慢加缓存、限流和权限控制。5. 生态与社区决定长期维护成本的是周边配套5.1 文档质量、版本迭代节奏和更新维护一个模型能力再强如果没有清晰的文档团队接手时也会痛苦万分。我见过最典型的反面例子某个开源模型能力很不错但文档只有一页简单的说明跑通一个基本推理流程都要靠猜最后只能放弃。选型时我会专门花半天时间按文档走一遍从安装到调用的完整流程重点看几个方面有没有可复制的示例代码版本更新时有没有变更日志有没有讨论常见问题的专区。这些体验会直接影响你后续维护模型的成本。文档这块宁可多花时间也不要抱着“能力强就行文档不重要”的想法。版本迭代节奏也值得关注。一个长期不更新的模型往往意味着社区已经不太活跃遇到问题只能自己修而更新太频繁的模型又要担心兼容性和回归问题。最理想的是稳定维护、节奏清晰的模型说升级就升级说停更就停更团队心里有数。5.2 社区活跃度和工具链成熟度社区活跃度很难直接量化但同样一个问题活跃社区可能搜一下就有解决方案冷门项目就得自己从零排查。说实话这个差距对开发效率的影响往往比模型本身几个百分点的评测差都大。除了社区还要看配套工具链。模型能不能和现有的编排框架、函数调用工具、向量检索库方便地对接直接决定了你的开发工作量。有些模型接口设计得很特别集成时得自己写一堆适配层这类额外成本虽然不会出现在模型报价里但会真实地出现在你的排期里。所以我选型时一定会把“横向对比工具链兼容性”列进清单。举个例子同一个函数调用协议有的模型支持得很完美有的模型支持得七零八落。如果业务重度依赖结构化输出这个差异比微弱的评测分差更值得你倾斜。5.3 数据不出内网的硬性要求要提前确认最后这条看起来不像技术问题却经常是最大的限制条件。有些业务场景比如金融、医疗和企业内部的知识问答对数据流向有严格限制非结构化的用户输入和业务文档不允许传到外部服务。这不是模型好坏的问题而是一票否决项。我建议在选型的第一天就和业务方确认数据边界哪些数据可以出内网哪些绝对不能又有哪些只做过脱敏处理后才能出内网。只要有一条硬边界碰不得闭源API基本就要被排除你必须转向支持私有化部署的开源模型。这个判断晚一天做后面返工的成本就多一天。会有团队心存侥幸觉得可以先拿公开数据测试上线后再想办法过渡。但真实数据一旦接触了外部接口再想说服所有人“只是测试用”流程上会变得非常麻烦。所以这事没有那么多侥幸空间老老实实按边界来反而最快。每评估完一轮我一般会给候选模型填一张固定的表。能力列发任务测试的结果上下文列写有效窗口的实测结论成本列写单日预算和重试损耗部署列写网关改造的预估工时生态列写文档、社区和工具链的评分。哪一项不达标就直接划掉不搞加权平均因为短板项往往会在上线后变成最大的事故源。根据我的个人经验这种“一刀切”的粗筛选反而比综合打分更可靠因为它逼着团队承认自己最不能容忍的是哪一块短板。如果实在哪个都舍不得就再去确认一次业务边界看那个让你舍不得的模型是不是真的有你离不开的独家能力。选模型的活不是一次性工作。我现在养成了一个习惯每季度把线上模型的私有测试集重跑一遍。没用半年就变差的模型、突然不稳定的输出格式都会在这种复盘里提前暴露出来。与其等用户投诉了再换不如把换模型的成本分散在每一个小周期里。这一套流程看起来不复杂但能坚持下来项目的模型选型就不再是一场赌博。