选大模型这件事，这两年越来越像选装修队。招牌上都是“全屋定制、高级工艺、超低报价”，可真等进场施工，能不能按你的户型落地、能不能在规定时间交付、后面出问题找不找得到人，才是真正决定成败的细节。我在过去一年多里参与了多条业务线的模型选型，最深的一个体会是：报价单和榜单最容易看，也最容易骗人。有一阵子团队内部只看公开评测分数，谁的分高就切谁，结果上线后真实请求一来，输出格式乱、长文本丢信息、在高峰期接口限流，问题一个接一个。后来我慢慢把选型流程收敛成了固定的五件事，每评估一个新模型，都会逐条过一遍：能力是不是真的匹配业务场景，上下文窗口的可用长度到底有多少，成本账能不能算得过来，部署和集成顺不顺，生态和社区值不值得长期押注。听起来都是最基础的维度，但每一条展开都有不少隐藏的坑。这篇文章就把我的检查清单完整讲一遍，适合正在做技术选型、准备替换模型，或者刚开始接触大模型项目的团队参考。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基本就要被排除，你必须转向支持私有化部署的开源模型。这个判断晚一天做，后面返工的成本就多一天。会有团队心存侥幸，觉得可以先拿公开数据测试，上线后再想办法过渡。但真实数据一旦接触了外部接口，再想说服所有人“只是测试用”，流程上会变得非常麻烦。所以这事没有那么多侥幸空间，老老实实按边界来，反而最快。每评估完一轮，我一般会给候选模型填一张固定的表。能力列发任务测试的结果，上下文列写有效窗口的实测结论，成本列写单日预算和重试损耗，部署列写网关改造的预估工时，生态列写文档、社区和工具链的评分。哪一项不达标就直接划掉，不搞加权平均，因为短板项往往会在上线后变成最大的事故源。根据我的个人经验，这种“一刀切”的粗筛选反而比综合打分更可靠，因为它逼着团队承认自己最不能容忍的是哪一块短板。如果实在哪个都舍不得，就再去确认一次业务边界，看那个让你舍不得的模型，是不是真的有你离不开的独家能力。选模型的活不是一次性工作。我现在养成了一个习惯，每季度把线上模型的私有测试集重跑一遍。没用半年就变差的模型、突然不稳定的输出格式，都会在这种复盘里提前暴露出来。与其等用户投诉了再换，不如把换模型的成本分散在每一个小周期里。这一套流程看起来不复杂，但能坚持下来，项目的模型选型就不再是一场赌博。
选大模型这件事，这两年越来越像选装修队。招牌上都是“全屋定制、高级工艺、超低报价”，可真等进场施工，能不能按你的户型落地、能不能在规定时间交付、后面出问题找不找得到人，才是真正决定成败的细节。我在过去一年多里参与了多条业务线的模型选型，最深的一个体会是：报价单和榜单最容易看，也最容易骗人。有一阵子团队内部只看公开评测分数，谁的分高就切谁，结果上线后真实请求一来，输出格式乱、长文本丢信息、在高峰期接口限流，问题一个接一个。后来我慢慢把选型流程收敛成了固定的五件事，每评估一个新模型，都会逐条过一遍：能力是不是真的匹配业务场景，上下文窗口的可用长度到底有多少，成本账能不能算得过来，部署和集成顺不顺，生态和社区值不值得长期押注。听起来都是最基础的维度，但每一条展开都有不少隐藏的坑。这篇文章就把我的检查清单完整讲一遍，适合正在做技术选型、准备替换模型，或者刚开始接触大模型项目的团队参考。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基本就要被排除，你必须转向支持私有化部署的开源模型。这个判断晚一天做，后面返工的成本就多一天。会有团队心存侥幸，觉得可以先拿公开数据测试，上线后再想办法过渡。但真实数据一旦接触了外部接口，再想说服所有人“只是测试用”，流程上会变得非常麻烦。所以这事没有那么多侥幸空间，老老实实按边界来，反而最快。每评估完一轮，我一般会给候选模型填一张固定的表。能力列发任务测试的结果，上下文列写有效窗口的实测结论，成本列写单日预算和重试损耗，部署列写网关改造的预估工时，生态列写文档、社区和工具链的评分。哪一项不达标就直接划掉，不搞加权平均，因为短板项往往会在上线后变成最大的事故源。根据我的个人经验，这种“一刀切”的粗筛选反而比综合打分更可靠，因为它逼着团队承认自己最不能容忍的是哪一块短板。如果实在哪个都舍不得，就再去确认一次业务边界，看那个让你舍不得的模型，是不是真的有你离不开的独家能力。选模型的活不是一次性工作。我现在养成了一个习惯，每季度把线上模型的私有测试集重跑一遍。没用半年就变差的模型、突然不稳定的输出格式，都会在这种复盘里提前暴露出来。与其等用户投诉了再换，不如把换模型的成本分散在每一个小周期里。这一套流程看起来不复杂，但能坚持下来，项目的模型选型就不再是一场赌博。