99POS

一个很常见的局面

一家二十来家店的连锁，陆陆续续接了三个 AI 功能：称重台的商品识别、门店的语音问询、总部市场部用的文案生成。

三个功能，三个供应商，三套账号，三张账单。

于是出现了这些事：

• 市场部做活动那天，文案生成跑了一整天，把整个账号的额度用掉大半，晚上门店的识别开始报错——因为额度是共享的。
• 其中一家供应商涨价，要换另一家，结果发现调用逻辑写死在三个系统里，改一处不够。
• 月底财务问「AI 这部分钱花在哪」，只有一张总额账单，说不清是哪个功能、哪个区域。
• 某天门店说「识别没反应」，总部不知道是网络、是设备、还是上游服务，因为没有任何一处记录了请求和耗时。

这些问题不是模型的问题，是调用没有被管起来的问题。

网关这一层管什么

AI 网关的位置很单纯：所有 AI 调用先经过它，再由它转发出去。业务系统只认一个地址、一套接口，剩下的差异在这一层消化。

它做的事，对应上面四个麻烦：

按维度限流。 可以给市场部设一个上限、给门店识别设一个上限。一个功能跑量，不会把另一个功能挤掉。粒度最好能细到门店——某家店设备异常反复重试时，只影响它自己。

供应商可换。 上游接口差异在网关内部适配，业务系统不用改。主供应商超时或报错时切到备用，这件事在网关做一次，比在每个系统里做三次可靠。

按维度记账。 每次调用记下是谁、哪个功能、用了多少 token、花了多久。月底能出「按门店」「按功能」的账，而不是一个总数。

留痕可查。 出问题时能查到那一刻的请求、状态码、耗时。只记平均值不够，要看长尾——顾客抱怨的永远是慢的那几次。

门店场景里两个容易忽略的点

多了一跳，就多了一个故障点。 网关在调用链路上，它挂了，所有 AI 功能一起不可用。上之前要想清楚兜底：是保留一条应急直连通道，还是降级到规则方案（比如识别不可用时先走人工输入）。这一条必须在方案里写出来，不能等出事再想。

日志里不要落顾客的东西。 排查问题需要请求记录，但门店的请求里可能带图片、带语音、带会员信息。日志该记的是耗时、状态、模型名、token 数这类元数据，原始内容要么不落盘，要么设很短的保留期并限制访问。这一点和「数据不出店」是两件事，别混为一谈。

另外，多一跳带来的延迟通常不大（毫秒级），但如果网关部署在异地，或者要串行做内容审核，累积起来就会体现在顾客的等待上。这一点在语音问询这种长交互里比较明显。

什么规模值得上

不是所有门店都需要这一层。判断标准大致是三条，中两条以上才值得考虑：

还有一种中间状态：暂时不上网关，但先把两件事做好——密钥集中管理（不要每个系统一份）、调用记录统一（至少能查到最后一次失败是什么）。这两件事做到，将来接网关会顺很多。

上之前要问的六个问题

1. 网关自己挂了怎么办？ 有没有直连兜底，切换是自动还是人工。
2. 密钥谁管？ 应用拿到的是网关签发的凭证，还是直接拿到上游密钥。
3. 限流粒度到哪一级？ 能不能按门店设，超限时是排队还是直接拒绝。
4. 日志记什么、留多久？ 有没有可能落进顾客的图片和语音。
5. 换供应商要不要改应用？ 这是上这一层最主要的理由，要当场验证。
6. 账单按什么维度出？ 门店、功能、时间段，能不能对上财务的口径。

这六条里有两条答不上来，这一层上了也只是多一跳延迟。

小结

AI 网关不改模型效果，它解决的是「调用怎么被管住」：谁能用、用多少、出问题查哪里、钱算在谁头上。

功能少、供应商单一的时候，把密钥和日志集中起来就够了。等到功能变多、开始按门店核算成本、或者需要留一手随时换供应商，这一层的价值才真正出现。