正文
InfoQ：当网关用于基于 AI 的交互时，它与我们传统的微服务程序交互有什么不同？
戴冠兰：
当 API 网关用于 AI 驱动的交互场景时，其与传统微服务架构下的差异体现在计量方式、数据流处理和性能要求等方面：
1. 计量单位的转变：
在传统微服务架构中，API 网关通常按请求次数进行计费和监控。然而，在 AI 应用中，尤其是涉及大型语言模型（如 OpenAI 的 GPT 系列）的场景中，计费和资源消耗的关键指标转向了“token”（标记）。每个请求的成本和资源使用量取决于输入和输出的 token 数量，而非仅仅是请求的次数。这种转变要求网关具备对 token 使用量的精确统计和控制能力，以实现成本管理和资源优化。
2. 数据流处理方式的变化：
AI 应用，特别是生成式模型的交互，常常采用流式（streaming）响应方式，以提升用户体验。这意味着网关需要支持实时的数据流处理，能够在接收到部分响应数据时立即转发给客户端，而不是等待完整响应生成后再进行转发。这种处理方式对网关的并发处理能力和数据传输效率提出了更高要求。
3. 性能和稳定性的挑战：
AI 模型的推理过程通常计算密集，响应时间可能较长，且对系统资源的消耗较大。网关在处理此类请求时，必须具备高并发处理能力和稳定性，以防止因单个请求的延迟或失败影响整体系统的性能。此外，网关还需具备智能的流量控制和异常检测机制，以应对可能的请求激增或异常行为。
4. 安全性和合规性的增强需求：
AI 应用可能涉及敏感数据的处理和传输，网关需要提供更强的安全控制措施，如细粒度的访问控制、数据加密、敏感信息过滤等。同时，为满足不同行业的合规要求，网关应支持多种认证和审计机制，确保数据处理过程的可追溯性和合规性。
总的来说，
AI 驱动的应用对 API 网关提出了新的挑战和要求，涉及计费方式的转变、数据流处理的复杂性、系统性能的提升以及安全合规性的加强。为应对这些挑战，API 网关需要不断演进，集成更多智能化和自动化的功能，以适应 AI 时代的需求。
InfoQ: Kong 在 AI/LLM 网关场景中通常会遇到哪些客户需求？
戴冠兰：
最为常见的需求是多 LLM provider 代理，当企业计划将 LLM 应用上线到生产环境时，一定是需要有 backup 的，这时候，很自然的就是当某一个 LLM provider 不可用的时候，能否在不做任何调整的时候，通过 Kong AI 网关继续将请求自动的转移到其他可用的 LLM provider。
其次就是基于 Token 的 ratelimit，这对于企业 LLM 应用控制成本等方面也是极其重要的。
当然除了这些，还有一些其他的，比如能否进行自动的 RAG，能否在 Kong AI 网关的层面进行 cache 以节约成本，以及是否可以通过 Kong AI 网关进行一些特定内容信息的过滤等。
InfoQ: 有很多工程师对 LLM 时代的网关会有疑问，比如“我为什么需要一个网关？我直接调用 API 就好了。”你如何解答这个问题？
戴冠兰：
正如前面提到的，通过 Kong AI 网关主要完成的是
对于 LLM 请求的治理
，这其中不只是包括对多个 LLM provider 的 fallback，也包括认证授权等能力。很多 LLM provider 其实会限制用户可创建的认证密钥的数量，而大多数情况下，我们希望可以知道我的 token 到底消耗在了哪里，是哪个应用发起的，在什么时间，消耗了多少。
通过 Kong AI 网关就很容易做到这些了，将 LLM provider 的认证密钥进行中心化管理，然后为不同的用户 / 应用创建各自的独立的认证密钥，这样可以避免密钥泄露的风险。借助于 Kong AI 网关强大的可观测能力，还可以了解到这些用户 / 应用的 Token 消耗情况等，这样就会很方便。
此外，集成 Kong AI 网关的另一大优势就是不需要自己额外开发重复的逻辑，将这些基础能力都下沉到 Kong AI 网关中，开发者只需要专注于自己的业务逻辑即可。
