1. 大模型选型这件事为什么越来越像一门“运筹学”这两年跟不少团队聊下来我发现一个特别有意思的现象大家早就不纠结“要不要用大模型”了纠结的是“到底该用哪个、怎么用才不亏”。尤其是模型家族越铺越开之后选型从一道单选题变成了一道组合优化题。你手里可能有轻量版、标准版、增强版、推理增强版好几个档位每个档位的单价、上下文窗口、推理深度、响应延迟都不一样而你的业务里又混着“改个错别字”和“帮我从三十页合同里揪出风险条款”这种难度天差地别的任务。全用最强的账单能把你送走全用最便宜的效果又撑不住场面。这篇东西就是想把我在实际项目里踩过的坑、算过的账、搭过的流程完整地摊开讲一遍。核心围绕三件事模型家族怎么选型、成本怎么摁住、长任务工作流怎么管。适合正在做AI应用落地的开发者、技术负责人也适合刚接手相关项目、对着一堆模型档位发懵的新手。我不打算讲空泛的方法论而是把每一步的判断依据、参数计算、实操配置都写清楚你照着抄作业基本能跑通。先说一个我自己的结论选型的本质不是选“最好的模型”而是选“最匹配当前任务性价比的模型”。这句话听着像废话但真正落地的时候绝大多数团队都会不自觉地滑向两个极端——要么无脑上顶配图省心要么为了省钱把体验做崩。中间那条线得靠数据算出来不能靠感觉拍。2. 模型家族选型先搞清楚你手里有几张牌2.1 模型分档的底层逻辑能力、成本、延迟的三角博弈任何一家做模型家族的厂商本质上都在解一个三角方程能力Capability、成本Cost、延迟Latency。这三个指标很难同时拉满所以产品线一定会分层。常见的分层维度大概有这么几种按参数量/推理深度分轻量档主打快和便宜适合分类、抽取、改写这类“模式识别”任务标准档是万金油增强档和推理档则针对复杂逻辑、多步推理、长链条规划。按上下文窗口分有的档位窗口小但便宜有的窗口大但单价高。长文档处理必须看窗口不然你得自己做切片拼接反而更麻烦。按模态分纯文本、图文混合、音视频价格梯度通常很明显。我一般会先画一张表把候选模型的这几个维度列出来再对照自己的任务清单打分。这里的关键是不要用“平均难度”去选模型要用“任务分布”去选。一个业务里80%的请求可能是简单任务只有20%需要重推理那你的主力模型应该是那个能扛住80%的档位剩下20%走增强档。2.2 一张选型对照表把决策过程量化下面这张表是我在项目里常用的模板你可以直接拿去改。分数是1到5越高越好成本项反过来越高越贵所以打分时我习惯把“成本友好度”作为正向指标。维度轻量档标准档增强档推理增强档复杂推理能力2345长上下文支持2345响应延迟越低越好5432单次调用成本友好度5432指令遵循稳定性3445适合任务类型分类/抽取/改写通用问答/摘要多步分析/代码复杂规划/长链推理有了这张表选型就从“我觉得”变成了“算出来”。比如一个客服摘要场景任务难度集中在标准档那主力就用标准档遇到用户上传长合同要提炼风险点再路由到增强档。分层路由这个词后面还会反复出现它是成本控制的核心手段。2.3 别忽略“隐性成本”重试、纠错和人工兜底很多人算成本只算token单价这是最大的坑。我见过一个团队为了省单价选了轻量档做信息抽取结果准确率只有七成剩下的三成要么反复重试token翻倍要么人工返工人力成本远超省下的钱。真实成本 调用成本 重试成本 纠错成本 体验损失。我的经验是当一个任务的准确率低于某个阈值我一般定在90%省下来的单价根本不值得。因为低于这个线用户会明显感知到质量下降投诉、返工、流失接踵而至。所以选型时一定要做小规模A/B测试用真实数据测准确率而不是看宣传页上的跑分。3. 成本控制从“月底看账单心疼”到“每笔调用心里有数”3.1 成本结构拆解你的钱到底花在哪了先把成本拆开看通常有这么几块输入token成本你喂给模型的上下文包括系统提示、历史对话、检索到的文档。输出token成本模型生成的内容通常单价比输入贵。缓存成本/收益如果支持提示缓存重复的系统提示可以省钱。重试与失败成本超时、格式错误、内容不合规导致的重复调用。路由与编排成本如果你用了多层路由中间环节也有开销。我做过一个统计在一个典型的长文档问答场景里输入token往往占总成本的60%以上因为你要把大量文档塞进上下文。这就引出一个关键优化点能检索就别全塞能缓存就别重发。3.2 提示缓存被低估的省钱利器提示缓存Prompt Caching这个机制简单说就是如果多次请求的前缀部分完全一样系统可以复用之前的计算结果只对新增部分计费。对于那种“固定系统提示 固定知识库 变化用户问题”的场景省下来的钱非常可观。实操上要注意几点把稳定内容放前面系统提示、角色设定、固定规则、知识库片段这些尽量放在提示的开头且保持字节级一致。哪怕多一个空格缓存都可能失效。动态内容放后面用户问题、实时数据放末尾。注意缓存有效期不同实现的过期时间不一样长任务里要评估命中率。我实测过一个场景把系统提示和知识库固定下来后缓存命中率能到七成以上整体成本直接砍掉近一半。这个优化几乎零成本强烈建议优先做。3.3 分层路由让便宜的模型干便宜的活分层路由是我认为性价比最高的成本控制手段。思路很简单先用一个轻量模型判断任务难度简单任务直接处理复杂任务转交增强档。具体怎么落地我一般用一个“难度分类器”可以是一个轻量模型也可以是一组规则。比如def route_task(user_input): # 规则层明显的简单任务直接走轻量档 if len(user_input) 50 and is_simple_intent(user_input): return light # 模型层让轻量模型判断复杂度 complexity light_model.classify(user_input) if complexity high: return reasoning elif complexity medium: return standard else: return light这里有个坑分类器本身也有成本和延迟。如果分类器太重反而得不偿失。我的做法是规则优先规则覆盖不了的再上模型而且分类器用最便宜的档位。3.4 输出长度控制别让模型“话痨”输出token通常比输入贵而模型天生有“多说几句”的倾向。控制输出长度有几个实用技巧在提示里明确字数上限比如“用不超过100字回答”。用结构化输出要求返回JSON字段固定避免自由发挥。设置max_tokens参数硬性截断但要小心截断导致内容不完整。后处理压缩对摘要类任务可以再走一次轻量模型做精简。我踩过的一个坑是某次做批量摘要没限制输出长度模型每篇都写了三四百字账单直接翻倍。后来加了“每篇不超过80字”的约束效果没差多少成本降了六成。4. 长任务工作流管理把“一口气干完”拆成“分步推进”4.1 长任务的本质难点上下文膨胀与状态丢失长任务比如“分析一份50页的报告并生成结构化结论”难点不在单次调用而在多步之间的状态管理。你不可能把50页全塞进一次调用就算窗口够大成本和延迟也扛不住所以要拆步。拆步之后就会遇到两个问题上下文膨胀每一步都要带上之前的结果越滚越大。状态丢失中间某步的关键信息没传下去后面就断了。我的解法是显式状态机 外部记忆。不要指望模型自己记住而是把每一步的输入输出都落到外部存储里下一步按需取用。4.2 工作流拆解以长文档分析为例拿长文档分析举例我一般拆成这么几步文档预处理切片、去噪、建立索引。分片摘要每片走轻量或标准档生成局部摘要。摘要聚合把局部摘要合并走标准档。关键点提取从聚合摘要里抽结构化信息走增强档。结论生成基于结构化信息生成最终报告走增强档或推理档。每一步的产物都存下来形成一条可追溯的链。这样做的好处是任何一步出问题都能单独重跑不用从头再来。而且每一步可以用不同档位的模型成本可控。4.3 状态管理实操用外部存储做“记忆”具体实现上我会用一个简单的JSON结构来存状态{ task_id: abc123, stage: aggregate, chunks: [ {id: 1, summary: ..., tokens: 120}, {id: 2, summary: ..., tokens: 98} ], aggregated_summary: ..., key_points: [], final_report: null }每一步读取这个结构处理完再写回去。这样即使中间服务重启任务也能续上。长任务最怕的就是“跑到一半断了前面白干”外部状态就是你的保险。4.4 超时与重试给每一步都设好“安全网”长任务里单步超时和失败是常态。我的做法是每步设独立超时比如摘要步30秒聚合步60秒别用一个全局超时。重试要带退避第一次失败等1秒第二次等2秒第三次等4秒避免雪崩。重试上限要明确一般3次超过就标记失败走人工或降级方案。失败要可观测每步的失败原因、重试次数都记日志方便排查。我见过一个团队长任务没有分步超时结果一个卡住的请求拖垮了整个队列。分步管理之后问题定位快了很多。5. 常见问题与排查技巧实录5.1 选型相关的高频问题问题一轻量档效果不稳定是不是不能用不一定。轻量档在“模式固定、输出格式明确”的任务上表现很好比如分类、打标签、格式转换。它不擅长的是开放式推理。所以别拿它做它不擅长的事用对场景它很香。问题二增强档太贵能不能用标准档硬扛可以试但要测准确率。如果标准档在关键任务上准确率能到95%以上那就用标准档如果只有80%省下的钱会被返工吃掉。问题三多个模型混用维护成本高怎么办把模型调用封装成统一接口路由逻辑集中管理。别让业务代码直接调具体模型否则换模型时你会想哭。5.2 成本相关的高频问题问题一账单突然暴涨怎么快速定位先看三个维度调用量、平均输入长度、平均输出长度。通常是某个环节的输入变长了比如检索塞了太多文档或者输出没限制。我一般会加一个按任务类型分组的成本看板一眼就能看出是哪个任务在烧钱。问题二缓存命中率低怎么排查检查提示前缀是否字节级一致。常见原因是系统提示里带了时间戳、随机ID或者知识库片段顺序不稳定。把这些动态内容挪到后面命中率立刻上来。问题三路由分类器本身成本高怎么办用规则兜底规则覆盖不了的再用最便宜的模型。分类器的输出可以缓存相同输入直接复用判断结果。5.3 长任务相关的高频问题问题一任务跑到一半失败怎么续跑靠外部状态。每一步的产物都落盘失败后从最后成功的步骤继续。别把状态只放在内存里。问题二多步之后结果越来越偏怎么纠偏在关键步骤加“校验点”比如聚合摘要后让模型自检一遍或者用规则校验格式。发现偏差就回退到上一步重跑。问题三长任务延迟太高用户体验差怎么办把能并行的步骤并行比如分片摘要可以同时跑。另外给用户展示中间进度别让他干等。5.4 一张速查表收尾现象可能原因排查方向成本暴涨输入变长/输出失控/缓存失效看分任务成本看板效果下降模型档位不匹配做A/B测试对比准确率长任务中断状态未持久化检查外部存储写入延迟过高串行步骤太多评估并行化空间缓存不命中前缀不一致检查动态内容位置6. 一些掏心窝子的实操心得最后分享几个我在项目里反复验证过的经验都是文档里不会写的。第一先跑通再优化别一上来就搞复杂路由。我见过太多团队选型阶段就设计了三层路由结果业务还没跑起来维护成本先把自己拖垮了。先用一个标准档把流程跑通有了真实数据再谈优化。第二成本优化要算总账不能只看单价。便宜的模型如果导致重试和返工总成本反而更高。我一般会算一个“有效成本”即总花费除以成功任务数这个指标才真实。第三长任务的状态管理越简单越好。别搞复杂的分布式状态机一个JSON文件加一个数据库表就能解决大部分问题。过度设计是长任务最大的敌人。第四一定要有降级方案。增强档挂了怎么办推理档超时了怎么办提前想好降级路径比如降级到标准档或者返回部分结果加提示。没有降级方案的系统在高峰期一定会出事。第五把提示当成代码来管理。版本控制、变更记录、回归测试一个都不能少。提示改一个字效果可能天差地别没有版本管理你根本不知道是哪次改动导致的。这套东西我在几个项目里跑下来成本能压到最初的三到四成长任务的成功率也能稳定在九成以上。当然每个业务情况不一样具体参数得你自己调。但核心思路是通用的选型靠数据成本靠分层长任务靠状态。把这三件事想清楚剩下的就是耐心调优了。