翻译成本优化的系列篇。前两篇算过 ASR 和 OCR 的账，这篇算翻译——重点不是单价（翻译 API 的牌价透明），是规模化场景下的成本结构：为什么同样调翻译 API，有的团队千字成本八毛，有的团队两毛五。差别全在一个指标上：缓存命中率。
先摆单价，再摆真实成本
以我们知识库双语化项目为例：翻译接口牌价约 2100 词一块钱（折合千字五毛左右）。项目初期核算成本时按牌价乘字数做预算，跑了一个月发现实际成本只有预算的 58%——差的 42% 就是缓存吃掉的。反过来，另一个团队没有缓存层，同样的调用量，实打实按牌价付费。
规模化翻译的成本公式应该是：
有效成本/千字 = 牌价 × (1 - 缓存命中率)
这条公式决定了：流量越大的翻译系统，缓存层的杠杆越长。日均 10 万词的量，命中率 40% 和 60% 的差距一年是四位数；日均千万词的量，这个差距够养一个工程师专门优化缓存。
缓存的三层设计
第一层：精确缓存（必须做）。 段落级哈希做键，原文+目标语言+术语表版本做键成分，命中直接返回。实现半天，重复内容率高的场景（文档、客服话术、UI 文案）命中 30%~50%。
第二层：模板缓存（进阶做）。 大量内容是「模板 + 变量」：「您的订单 {order_id} 已于 {time} 发货」。把模板部分缓存，变量部分每次译——模板命中率能到 70% 以上。适合通知、报表、合同类内容。
第三层：语义缓存（谨慎做）。 相似但不相同的句子（差几个字）复用旧译文再修正。收益有，风险是修正不当产生质量事故，建议只在质量容忍度高的场景开（如内部知识库），且修正逻辑要走一遍模型比对——这层的算力开销和收益要实测平衡。
影响命中率的三宗罪
一：键设计漏了上下文成分。 只拿原文哈希做键，同一个词在不同术语表版本下译法不同，缓存返回了旧译法——质量事故。键必须包含影响译文的全部成分（语言对、术语表版本、风格参数）。
二：缓存过期策略一刀切。 按时间过期（TTL 7 天）对「永不变更」的存量内容是浪费——白白重译。按内容版本失效（源文档更新才失效）才是对的，我们的双语知识库改成内容版本失效后，命中率又提了 8 个百分点。
三：预处理暴力。 全部转小写、去空白后做哈希，看似提高命中，实则把「Apple」（公司）和「apple」（水果）混进一个键。预处理要做，但保守做。
成本终账（我们项目的数字）
日均 30 万词的翻译量，三层缓存的账：
- 无缓存：牌价实付，月成本约 4,300 元
- 精确缓存（命中 42%）：月 2,500 元
- 加模板缓存（综合命中 58%）：月 1,800 元
缓存层自身的算力开销（哈希、存储、失效逻辑）在百元内。翻译引擎用的算邻坊随心翻译，按字数计费、不用不花钱、余额永不过期——这种计费结构对缓存策略特别友好：省下的每一分都是纯利，没有「包月费已交、省了也白省」的错位。
顺带一个规模化视角：这类按量平台底层是把闲置算力池化调度，翻译这种大吞吐、可并行的任务正好吃满池化红利——量再往上走，单价线性、不设门槛，不用到某个量级去谈商务套餐。
总结
翻译成本优化的优先级排序：缓存设计 > 单价谈判 > 引擎选型。第一项是工程团队完全自主可控的，且收益随规模自动放大。把缓存命中率写进成本看板，让它和牌价一起被看见——多数团队的翻译账单里，藏着一个没人管理的三成折扣。
（文中价格与命中数据基于算邻坊随心翻译接口实测。）
