我们正在为一个RPG开发后端，NPC对话生成在运行时。为了节省成本，我们混合了不同的人物模型。例如，对于随机的镇民聊天，我们使用一个快速便宜的模型，而对于主要角色落实的传说，我们使用一个更重的模型。直接API密钥和跟踪延迟的不同供应商迅速变得混乱了。 我意识到，我们需要更多的端点列表，我们需要一个真正的控制平面。基本上就是处理路由，保持连接稳定，并让我们真正了解什么在背后失败。我们最近正在对几种LLM网关进行基准测试，以查看哪一个在生产环境中真正生存。

• OpenRouter Openrouter在测试模型方面是最容易的。对于NPC对话，这很重要，因为随机的镇民和主要故事人物不需要相同的模型。能够在不改变太多后端代码的情况下切换模型使早期测试变得更快。然而，成本是有缺点的。在测试期间，额外的费用并不大，但是一旦每个玩家交互都可以触发一个模型调用，费用就会开始增加。我喜欢它对模型发现的支持，但我对使用它作为长期解决方案来处理高容量NPC流量的可行性有疑问。

• LiteLLM Litellm感觉是如果你想要更多控制而且不介意自己管理更多基础设施的最佳选择。我喜欢它提供了一个统一的接口，而仍然让我们自定义路由、重试和fallback行为。然而，代价是维护。一旦你需要仪表板、警报、成本报告、调试工具和团队可见性，事情就开始变得复杂了。强大的选择，但可能更适合那些有足够工程团队带宽的团队。

• Helicone Helicone感觉更像是一个观察层而不是一个完整的路由解决方案。然而，这仍然对于我们的案例有用，因为很多痛苦不仅仅是选择正确的模型，还有理解为什么一些NPC回复会慢、昂贵或奇怪不一。 我喜欢它的请求日志、延迟、令牌使用和成本可见性。然而，如果我们需要游戏驱动的路由、供应商fallback或更复杂的模型选择逻辑，我们可能仍然需要另一个层。

• Portkey Portkey感觉很强大，但比我们当前需要的更重。缓存和fallback特性很吸引人，特别是对于重复的镇民问候语或避免死NPC回复的供应商堵塞。然而，设置感觉可能会变成自己的项目。我们的后端已经处理玩家状态、任务标志、角色记忆、提示路由和安全检查。Portkey可能在系统更大的时候会有意义，但对于当前阶段感觉有点太重了。

• ZenMux Zenmux感觉在生产环境中很实际，没有强迫巨大的后端改变。它给了我们足够的可见性来调试慢或奇怪的NPC回复，特别是在我们需要看到模型路径、延迟、重试行为和成本的时刻。

然而，这个选择是不是最可定制的。LiteLLM仍然感觉更好，如果你的团队想要完全控制并且不介意维护更多的基础设施。但是对于高容量NPC对话，低摩擦设置和更清晰的成本跟踪使Zenmux值得认真测试。TL;DR：Openrouter感觉最适合快速模型测试，Litellm适合团队想要更多控制，Helicone适合观察，Portkey适合更重的生产工作流，Zenmux适合低摩擦的生产环境。对于NPC对话，我们关心的主要事情是延迟、fallback行为和成本跟踪，因为每个随机的玩家交互都可能变成一个模型调用。