本文为匿名化情境复盘。公司身份、客户数量、金额和模型名称均已脱敏不对应单一可识别客户。文中的“费用”默认指外部模型 API 账单网关软件、实施和基础设施成本在经营测算中另行列示。作为一家 B2B SaaS 创业公司的 CTO当投资人问我“AI 成本什么时候能进入可预测区间”时我知道问题已经不是再找一个更便宜的模型而是把整条调用链管起来。一、我们是谁问题是什么公司有 30 人产品是一套智能营销自动化平台服务约 40 家付费企业客户和 150 多个品牌或店铺账号。平台主要提供五类 AI 功能业务场景月均业务请求治理前单次账单均价月度费用客户问答80,000¥0.480¥38,400文案生成50,000¥0.492¥24,600用户画像分析30,000¥0.300¥9,000投放策略建议10,000¥0.600¥6,000数据报告生成5,000¥0.800¥4,000合计175,000¥0.469¥82,000这里统计的是“业务请求”不等于上游模型的 HTTP 调用次数。一次报告请求可能被拆成多次模型调用一次客服请求也可能直接命中知识库或缓存不再访问上游模型。我们通过请求 ID把检索、重试、模型调用和最终费用归到同一个业务任务下。当时公司月经常性收入约 48 万元外部模型 API 费用占收入的 17.1%。对于毛利率仍在爬坡的创业公司这个比例已经足以影响续费定价、销售折扣和下一轮融资时的单位经济模型。二、成本为什么会失控2.1 所有任务都走同一档高性能模型产品上线时团队为了抢进度把所有生成式任务都接到同一档高性能模型。这个决定帮助我们快速验证了产品但验证完成后调用策略一直没有拆分。实际上客服中的安装指引、账号绑定、数据导出等问题大多有稳定答案文案任务中也有大量标题改写、长度压缩和语气调整。这些任务并不需要与高创意文案、复杂投放分析使用同一档模型。2.2 FAQ 没有走“检索优先”大量客户问题本可以由知识库直接返回标准答案我们却把知识库片段、系统提示词和历史对话全部发给模型重新生成。相同问题每天重复发生相同的 Token 费用也在重复支付。2.3 Agent 在没有新数据时继续运行自动化营销 Agent 原本应在投放数据发生变化后生成建议但触发条件只检查定时任务是否到点没有核对数据版本。一个边界条件错误又让失败重试进入循环。某天夜间这个 Agent 累计产生约 2 万次上游模型调用费用约 3200 元。网关可以限制这类事故的损失上限却不能替业务代码修好循环。真正的修复必须包括数据版本检查、最大迭代次数、幂等键、指数退避和任务级超时。2.4 Key、预算和责任主体都没有收口供应商 Key 被写进环境配置少数测试代码中甚至保留了明文。不同功能共用同一把 Key供应商账单只能告诉我们总额无法回答是哪一个客户、项目、应用或自动化任务花了钱。我们也没有日限额、月预算和实时告警。异常发生后团队往往要到第二天看供应商控制台甚至月底对账时才发现。三、我们最终采用的架构改造后整条链路被分成三层业务应用层客服系统、文案服务、画像任务、投放 Agent 和报表服务负责业务判断包括意图分类、知识检索、数据版本检查、指标计算和上下文整理。MAI Gateway 治理层根据项目令牌、场景标签或虚拟模型名执行鉴权、预算与配额校验、RPM/TPM 限流、路由、缓存策略、故障切换、Token 计量、费用归集、日志和告警。模型与算力层连接国内外公共模型 API以及企业已经具备运维条件时的私有模型端点。这条边界很重要。网关是统一入口和治理控制面不是客服知识库、Agent 编排器、数据仓库或模型训练平台。它能执行策略、记录证据、限制损失但“什么是简单改写”“什么时候有新数据”“哪些指标应该进入报告”仍然要由业务系统决定。四、改造过程先止血再优化4.1 第一步盘点、切流和轮换 Key我们先为五个业务场景分别创建项目和应用令牌并绑定负责人、模型范围和费用归属。应用从密钥管理服务读取网关令牌不再保存供应商 Key。完成切流后团队在供应商控制台轮换了旧 Key。只改 Base URL 而不撤销旧 Key并不能消除历史泄露风险。网关开始记录切流后的请求、模型、输入输出 Token、延迟、状态和费用。历史账单只能用于核对总额无法凭空还原到项目级明细。第一版预算按月度目标 2.85 万元设置项目月预算日费用阈值达到上限后的默认动作客户问答¥8,000¥300标准答案或缓存优先复杂问题转人工文案生成¥10,000¥350简单任务降级批量任务排队用户画像分析¥4,500¥160暂停低优先级批次投放策略建议¥4,500¥160暂停自动建议保留人工触发数据报告生成¥1,500¥60延后非紧急报告合计¥28,500预算使用达到 80% 时通知项目负责人达到 95% 时同时通知技术和财务负责人。达到 100% 后不是所有业务都直接停服而是按照业务等级执行限流、降级、排队或阻断。客服等关键在线业务保留标准答案、经济型模型和转人工路径非关键批处理任务则可以直接暂停。异常 Agent 单独使用受限令牌设置 RPM、TPM、日费用上限和最大连续失败次数。业务代码同时增加数据版本检查、任务幂等和最大循环次数避免把网关熔断当成唯一防线。4.2 第二步业务先分类网关再执行路由我们没有让网关“猜”每个提示词属于什么业务而是在应用侧明确场景场景应用侧判断网关侧执行客服标准 FAQ知识库命中且答案置信度达标标准答案直接返回或由经济型模型润色客服复杂问题低置信度、投诉、权限或异常问题路由到高能力模型必要时转人工简单文案改写用户选择改写、压缩或更换语气路由到经济型通用模型创意文案用户选择创意生成或品牌规则复杂路由到高能力模型用户画像特征服务先聚合结构化字段使用批量、低成本模型输出标签说明投放策略数据版本变化且指标越过阈值保留高能力模型生成解释与建议数据报告代码先计算指标并形成摘要模型只负责叙述与结论组织为了避免业务代码绑定具体供应商我们在网关中配置了“客服经济型”“创意高质量”“报告生成”等虚拟模型或路由别名。业务系统只传递场景和任务参数实际使用的供应商、模型版本、主备链路和价格策略由网关维护。模型公开价格会随版本、区域、缓存和合同变化因此我们不再在业务文档中写一个长期不变的“每千 Token 综合单价”。团队按照实际输入 Token、输出 Token、缓存命中和供应商账单核对成本再折算成各场景的单次业务请求均价。4.3 第三步只缓存适合缓存的内容客户问答链路开启了受限的语义缓存。四周后约 35% 的客服业务请求不再触发生成模型。缓存只覆盖稳定、低风险、非个性化的帮助内容例如账号绑定、功能入口和导出步骤。订单状态、账单、客户权限、实时投放数据等请求必须绕过跨用户语义缓存先查询业务系统再由模型整理结果。缓存键至少包含租户、知识库版本、语言和策略版本并设置有效期。产品文档或业务政策更新时相关缓存会主动失效。这样做的目的不是追求最高命中率而是在不串租户、不返回旧规则的前提下减少重复生成。4.4 第四步把数据计算留在数据系统里报告服务过去会把 90 天明细直接塞进提示词。改造后SQL 和指标服务先完成数据聚合、同比环比、异常点识别和口径校验模型只接收最近 30 天的核心指标、必要的历史基线和已经压缩的事件摘要。报告场景的输入 Token 降低约 65%。这项优化发生在数据服务和应用编排层。网关负责记录压缩前后的 Token 与费用变化但不会自动理解企业的业务指标口径。4.5 第五步用质量门槛约束降本简单文案改写场景做了 200 组盲评。3 名运营人员随机查看两种模型的结果评分时不知道模型来源评估维度高能力模型经济型模型差异文案流畅度10 分制8.88.5-0.3营销吸引力10 分制8.58.2-0.3品牌调性匹配10 分制8.27.9-0.3平均人工编辑时长42 秒47 秒5 秒这组样本只能作为上线门槛不能证明两个模型在所有任务上等效。因此高创意文案仍保留高能力模型上线后继续观察采纳率、人工编辑时长、客户重试率和投诉情况。客服场景则重点观察一次解决率、转人工率、错误答案率和客户满意度。四周观察期内没有发现明显恶化后我们才扩大经济型路由的使用比例。五、效果数据5.1 外部模型 API 费用治理前后均按连续四周口径统计业务场景治理前治理后降幅主要原因客户问答¥38,400¥6,20083.9%检索优先、受限缓存、分层模型文案生成¥24,600¥8,40065.9%简单改写与创意生成分流用户画像分析¥9,000¥3,60060.0%结构化输入、批量处理、经济型模型投放策略建议¥6,000¥3,80036.7%数据变更触发保留高能力模型数据报告生成¥4,000¥80080.0%指标前置计算、上下文压缩合计¥82,000¥22,80072.2%这不是“网关自动省了 72%”。网关提供了统一入口、路由、缓存、配额和费用归因能力真正的节省来自业务分类、知识库直返、Agent 触发修复、模型重新选型和上下文治理。5.2 经营影响为了说明真实的经营影响我们把人力、其他云资源、网关软件与实施摊销、销售和办公费用都纳入同一张表月度经营项目治理前治理后营业收入¥480,000¥520,000外部模型 API-¥82,000-¥22,800人力成本-¥310,000-¥310,000云资源及软件-¥55,000-¥63,000销售、办公及管理-¥70,000-¥70,000经营利润-¥37,000¥54,200治理后“云资源及软件”增加的 8000 元是网关软件、监控和实施成本的月度摊销示例实际金额应以合同和部署方式为准。公司从亏损转为盈利并不全是 AI 降本的结果。外部模型 API 节省了 5.92 万元扣除新增治理成本 8000 元后月度净改善约 5.12 万元收入增长另外贡献了 4 万元。即使收入保持 48 万元不变按照上述成本结构计算经营利润也会从 -3.7 万元改善到约 1.42 万元。六、我们得到的几个教训6.1 可以先用高能力模型验证产品但要尽早拆分场景创业初期使用高能力模型快速验证产品没有问题。问题在于验证完成后仍然把所有任务永久绑定在同一档模型上。模型选型应该随着产品成熟度进入工程化阶段并由效果门槛而不是个人偏好决定。6.2 预算控制要有“降级路径”不能只会关停非关键批处理任务可以在超限后暂停客户在线服务却需要标准答案、经济型模型、排队和转人工等降级路径。预算不是简单的总闸门而是一套按照业务等级设计的处置规则。6.3 网关限制事故半径业务代码消除事故根因RPM、TPM、日预算和熔断可以防止一个 Agent 在夜间无限烧钱但循环、重试和数据版本问题仍然要在业务系统中修复。把所有责任都推给网关只会让同一个 bug 换一种方式出现。6.4 30 人团队不要轻率自建大模型“买一台 15 万元服务器自建完整 DeepSeek-V3边际成本几乎为零”并不符合生产现实。自建需要同时计算 GPU 折旧、电力、托管、备机、监控、模型升级、推理优化和运维人力。对于缺少专职 ML 或推理平台团队的创业公司优先选择公共 API、批量任务、上下文缓存和网关路由通常更加稳妥。只有在调用量长期稳定、数据合规必须本地化而且 2436 个月总拥有成本经过测算后自建较小的开源或蒸馏模型才值得进入评估。6.5 看“每个业务结果花多少钱”不只看 Token 单价便宜模型如果导致大量重试、人工返工或客户流失未必真的便宜。我们最终关注的是每条被采纳文案、每个成功解决的客服问题、每份有效报告和每个续费客户对应的 AI 成本。七、写在最后企业 AI 成本治理不是把所有请求都切到最便宜的模型也不是接入网关后等待账单自动下降。MAI Gateway 在这套架构中的作用是把分散的模型调用变成一个可执行的治理入口应用使用受控令牌费用可以归到项目和责任人预算在请求前校验路由和故障切换由统一策略执行异常调用可以被发现和限制。而真正决定成本与质量的仍然是业务团队如何分类任务、维护知识库、设计 Agent、整理上下文并建立质量门槛。网关是阀门也是仪表盘。它让企业看见并执行规则但不会替企业做完全部工程。魔芋AI注册https://www.moyu.info/register?affqBX9数据口径说明“月均业务请求”按连续四周折算不等于供应商侧原始 HTTP 请求数。费用按实际输入 Token、输出 Token、缓存和供应商账单归集。治理前后应使用相同统计窗口并同时检查业务量、成功率、质量和人工成本避免把流量下降误写成降本。72.2% 是该脱敏情境下的结果不是产品承诺。MAI Gateway 的具体缓存、压缩、路由、预算、告警和熔断能力以实际版本、授权范围、合同和项目验收结果为准。