大模型业务落地的成本失控，往往不是来自可见的功能开发，而是藏在调用链路的隐性损耗里。龙虾体系内的大模型调用场景，普遍存在超时重试的默认配置，多数团队只关注重试能否保障业务成功率，却忽略了一个核心计费规则：绝大多数大模型服务商按输入Token计费，请求一旦发出，无论最终是否成功返回结果，都会产生全额费用。一次超时触发一次重试，就意味着相同的输入Token被重复计费两次，高并发场景下叠加多轮重试，单月Token消耗可能超出预期数倍，形成看不见的成本黑洞。这类损耗在Demo阶段体量小时毫不起眼，一旦业务规模化放量，账单数字会以超出预期的速度增长，等到发现时已经形成了高额的沉没成本。不少团队直到季度复盘时才发现，大模型调用成本远超预算，排查后才知晓近三成消耗来自无效重试，而这类损耗本可以通过架构设计提前规避。
多数团队的重试策略沿用传统接口调用的惯性思路，采用固定次数加指数退避的通用配置，没有针对大模型的计费特性做差异化设计。传统接口重试的成本主要是网络开销和计算资源，重试几次的边际成本几乎可以忽略，但大模型调用的边际成本是实打实的Token费用，每一次重试都对应着真金白银的支出。更关键的是，很多超时场景本身并不适合重试，比如请求内容过长导致的推理超时、参数格式异常引发的服务端错误，这类问题重试多少次都不会成功，只会平白消耗Token。在龙虾的业务链路里，这类无效重试占比并不低，部分长尾场景的无效重试率甚至能达到三成以上，相当于每月有近三分之一的大模型费用，花在了永远不会成功的请求上。更隐蔽的是，重试还会放大并发压力，高峰期大量重试请求涌入，会进一步加剧服务端负载，引发更多超时，形成成本和性能的双重恶性循环。破解无效重试的第一步，是建立分级重试准入机制，给每一次重试设置门槛，而不是所有超时都触发重试。核心思路是先对超时原因做细粒度分类，不同类型对应不同的重试策略：网络传输层面的超时，比如连接超时、路由波动，可以进行有限重试；服务端临时性的负载过高引发的超时，适合配合退避策略少量重试；而请求本身的问题，比如输入长度超限、指令格式不符合要求、内容合规拦截，必须直接终止，绝对不能触发重试。在此基础上，还要给单条请求设置严格的最大重试次数上限，通常不超过两次，避免极端情况下无限重试造成成本雪崩。同时要引入请求幂等标识，同一个业务请求无论重试多少次，都只对应一次业务语义，避免因为客户端重复提交引发的重复调用。这套机制落地后，不需要改动任何业务逻辑，只需要在调用网关层做拦截判断，就能先砍掉最没有价值的那部分无效重试，成本通常能有立竿见影的下降。对于已经识别出的高失败率请求，还可以提前拦截，直接返回降级结果，根本不发往大模型服务端，从源头杜绝无效消耗。
在控制住无效重试之后，下一步要做的是压缩单次请求的Token基数，让每一次调用都用最少的Token完成任务。行业实测数据显示，未经优化的原始请求，无效Token占比普遍在三成以上，这些消耗完全可以在不影响输出效果的前提下提前剔除。最直接的手段是上下文滑动窗口，对于多轮对话类的场景，不需要把完整的历史对话全部带上，只保留最近的三到五轮交互即可，更早的历史对话可以用轻量模型生成摘要后替代，既能保留上下文语义，又能大幅压缩Token长度。其次是系统指令的精简，去掉所有修饰性、铺垫性的话术，直接给出核心任务要求和输出规则，不必要的举例说明和解释性内容全部移除，固定的系统指令反复打磨，用最少的字符传递完整的指令语义。还要做输入内容的去重处理，相同的公共背景信息、重复的格式说明，只在请求里出现一次，避免同一段内容被反复计费。这类优化属于零成本改造，不需要额外投入资源，只需要优化Prompt的组织方式，就能在不影响输出质量的前提下，把单次请求的输入Token消耗压缩两到四成，而且重试次数越多，压缩带来的成本节约就越明显。
对于重复度较高的业务场景，缓存是成本收益比最高的优化手段。龙虾的业务场景里，有相当比例的请求是高频重复的，比如固定格式的单据解析、常见业务问题解答、标准化内容生成，这类请求的输入相似度极高，每次都调用大模型完全是资源浪费。传统的精确缓存只能匹配完全相同的输入，适用范围非常有限，语义缓存则可以对输入内容做向量化匹配，当新请求和历史请求的语义相似度达到设定阈值时，直接返回历史生成结果，不需要再调用大模型。缓存的有效期可以根据业务场景灵活设置，事实类内容可以设置较长的有效期，时效性强的内容则缩短缓存周期。除了单请求缓存，还可以做批量请求合并，把同一时间窗口内的多个同类型小请求合并成一次大模型调用，共享相同的系统指令和背景信息，只需要在输入里区分不同的任务项，一次调用就能完成多个任务，大幅减少重复的公共Token消耗。合并请求的输出再做拆分返回，业务侧完全感知不到底层的合并逻辑，不会影响原有业务流程，还能同时降低连接开销和推理等待时间。
成本治理不能只盯着单一模型，建立分级模型调度体系，才能从根本上控制单位调用的成本。不是所有业务场景都需要能力最强的主力模型，简单的分类、摘要、格式转换类任务，用轻量模型完全可以满足效果要求，而成本只有主力模型的几分之一甚至十分之一。在调用网关层搭建智能路由，先对请求的任务复杂度做快速判断，简单任务直接分发到轻量模型，复杂任务才走主力模型，从源头上降低平均单次调用的成本。与此同时，还要建立降级容灾机制，当主力模型的超时率持续升高、重试成本开始失控时，自动触发降级策略，把非核心场景的流量切换到备用轻量模型，或者切换到本地规则引擎兜底，而不是在主力模型上持续重试。这种方式既保障了核心业务的效果，又避免了高超时阶段的成本飙升，还能提升整体系统的可用性。多模型路由的关键在于路由判断的准确率，不能把复杂任务错发到轻量模型影响业务效果，也不能把简单任务发给主力模型浪费成本，需要通过历史数据持续优化路由判断的阈值，找到效果和成本的最佳平衡点。所有的优化策略，都要建立在可观测的基础上，看不到成本的分布，优化就只能靠猜。很多团队做大模型成本治理，只盯着月底的总账单，知道花了多少钱，却不知道钱具体花在了哪个业务场景、哪个接口、哪类请求上，优化完全没有方向。必须搭建细粒度的成本观测体系，按业务线、接口、场景、模型四个维度做统计，记录每一次调用的输入Token数、输出Token数、是否重试、重试次数、调用耗时、是否命中缓存，实时计算单位请求的成本。在此基础上做成本排行，找到消耗最高的Top热点场景，针对性地做优化，往往优化一两个核心场景，就能带动整体成本大幅下降。还要设置异常告警，当某个接口的重试率、单位成本突然升高时，立刻触发告警通知，及时排查异常原因，避免持续的无效消耗。成本观测不是一次性的工作，要形成常态化的巡检机制，定期复盘成本结构，发现新的损耗点及时优化，才能长期把成本控制在合理范围内。观测数据还可以反向指导业务设计，对于成本过高但业务价值有限的场景，可以调整产品方案，用更低成本的方式实现需求。
这套五层治理体系，不需要一次性全部落地，也不需要对现有系统做大规模重构，可以按照收益优先级逐步推进。最优先落地的是重试准入机制和细粒度成本观测，这两项投入最小、见效最快，通常一两周就能完成，先把最明显的无效消耗砍掉，同时摸清楚成本的真实分布。在此基础上，再针对Top热点场景做Token裁剪和语义缓存优化，逐个场景突破，每优化一个就落地一个，快速看到优化效果。模型分级和降级路由可以放在第三阶段，等前面的优化都跑通之后，再逐步引入多模型体系，避免初期复杂度太高影响业务稳定性。整个落地过程要坚持小步快跑的原则，每一项优化都先做灰度验证，确认不影响业务效果之后再全量推广，不能为了降本牺牲业务体验。落地过程中还要同步沉淀标准化的调用规范，新业务接入大模型时直接遵循规范，从一开始就避免无效消耗，不用等成本失控了再回头治理。成本治理的核心是平衡，不是无底线地压缩成本，而是在保障业务效果的前提下，消除不必要的浪费。所有的优化策略都有边界，比如上下文裁剪不能过度，否则会影响多轮对话的连贯性；语义缓存的相似度阈值不能设得太低，否则会出现答非所问的情况；模型降级不能波及核心场景，否则会影响用户体验。最优的状态不是成本最低，而是投入产出比最高，每一分钱的Token消耗都能产生对应的业务价值。很多团队在做成本优化的时候容易走向极端，为了降本而降本，最后导致业务效果下降，反而得不偿失。判断优化是否合理的标准很简单：用户感知不到变化，但成本实实在在降了下来，这才是成功的治理。如果优化之后业务效果打了折扣，哪怕成本降得再多，也是本末倒置，失去了大模型赋能业务的本来意义。
