AI 功能落地时如何控制成本

去年帮一家跨境 SaaS 客户做 AI 商品描述生成，Demo 阶段单次调用成本不到两分钱，全量上线后第一个月账单直接飙到三万多。问题不在模型选错，而在产品链路把「每次请求都调大模型」当成了默认路径。AI 功能最危险的不是效果一般，而是演示很好、账单很炸。ERP 和 Shopify 类应用尤其容易踩坑：批量导入、定时翻译、客服草稿都会把调用量放大几个数量级。产品负责人往往只盯转化率，直到财务问为什么毛利率被 API 账单吃掉。

先异步，再谈实时

用户提交商品信息后，不要同步阻塞等待结果。我们改成写入 Redis 队列，Worker 按租户配额限流消费，生成完成后通过 WebSocket 或轮询回写。这样既能压住并发峰值，也能在供应商限流时自动退避重试。ERP 场景里批量导入上千 SKU 时，异步还能做进度条和失败明细导出，运营体验比转圈十分钟后超时好得多。PostgreSQL 记录任务状态 pending、processing、done、failed，方便售后按店铺追溯。同步路径只保留「单条预览」这类低流量功能，且单独设更严格的速率限制。

能缓存就缓存，能小模型就不用大模型

相同标题和类目下的摘要、标签分类结果，用 tenant_id 加 input_hash 做 Redis 缓存，TTL 设 24 小时。实测重复率约 40%，月调用量直接砍三分之一。结构化任务如提取订单字段、判断退款理由，优先用轻量模型或规则引擎，只有长文案生成才走 GPT-4 级别。Prompt 里去掉冗余上下文，把商品属性 JSON 压缩成表格格式，token 数通常能降 20% 以上。对跨境 ERP，同一 SP 在不同店铺的类目描述高度相似，缓存收益更明显。还可以对「标题加类目」做 embedding 近似匹配，相似度高于阈值直接复用历史结果，进一步省调用。

人机边界清晰，成本与风险一起控

高风险动作——批量改价、自动回复客户邮件、修改库存——必须人工确认。AI 负责起草和推荐，人负责放行。我们在 PostgreSQL 里记录每次调用的 model、token、tenant_id 和场景标签，按店铺出周报。某租户用量异常时自动降级到模板或关闭功能，避免一个滥用账号拖垮整体毛利。SaaS 定价里应包含 AI 额度，超额按量计费，把成本透明化才能长期运营。客服场景里，AI 只生成草稿不自动发送，既控风险也控成本，因为发送动作往往触发更长上下文拼接。

监控、降级与定价联动

按场景统计单次成本、P95 延迟和失败率，Grafana 看板按 tenant 下钻。大促前预扩容 Worker，设置单店日调用上限和全站预算熔断。供应商 outage 时切换备用模型或排队延迟，绝不在主交易链路同步等待 AI。套餐设计时把 AI 额度写进价卡：基础版每月五百次，专业版五千次，企业版另议。销售演示用固定样本池走缓存，避免现场烧 token。把成本与体验一起设计，AI 才像功能，而不是实验。回顾那个跨境客户的案例，第二轮改造后月 API 费用降到四千以内，缓存命中率和异步批处理贡献各占一半。技术负责人应和财务约定「单店 AI 成本上限」，超线自动告警，产品迭代才有可持续的预算空间。

小结

AI 功能的成本控制要和产品设计一起做：缓存命中、模型分级、超时降级都能直接省钱。把每次调用的用途与费用打到可观测面板，讨论「要不要开新能力」时才有依据。别等账单爆炸再回头加限流。

实践中把上述清单变成可勾选的发布门禁，比事后补救更省时间。