为了在公司内部彻底解决大模型 API 账单混乱且无法使用第三方网关的问题，我尝试部署了一套名为 Millwright 的自建 LLM 路由器。在实际运行了一段时间后，我想分享一下这个方案在成本管控和链路稳定性上的具体表现。
Millwright 最吸引我的点在于它用 Rust 编写，运行效率极高，且部署极其简单。它本质上是在你的业务代码和模型供应商之间加了一个“智能分流阀”。
在配置过程中，我重点使用了它的三档定价策略（Cheap, Mid, Frontier）。通过交互式 CLI，我可以为每个模型定义一个成本档位。比如，将简单的文本格式化任务通过策略路由到 Cheap 档位（如 GPT-4o-mini），而将核心逻辑推理交给 Frontier 档位（如 Claude 3.5 Sonnet）。这样在不牺牲最终结果质量的前提下，能显著降低整体 Token 消耗。
这里有一个细节值得关注：Millwright 实现了所谓的 Cache Affinity（缓存亲和力）。在处理高并发的 Session 请求时，它能确保同一会话的请求走相同的通道，有效避免了因为请求分发到不同节点而导致的缓存失效问题，这对于需要维持上下文一致性的 Agent 场景非常关键。
从技术兼容性来看，它支持 OpenAI Chat Completions 和 Anthropic Messages 协议，这意味着你不需要在业务代码里写复杂的适配层。如果你使用的是 Amazon Bedrock，它也能直接对接。最让我放心的是，它不需要将 API Key 永久存储在其内部系统中，这规避了许多安全审计时的潜在风险。
在稳定性保障方面，我重点测试了它的熔断机制（Circuit Breakers）。在一次供应商 API 出现波动、响应时间陡增的情况下，Millwright 触发了超时限制并迅速将请求切到了备用供应商，整个工作流没有出现卡死现象。同时，它支持将统计数据导出为 HTML 或 JSON 格式，我们可以直接按团队维度核算费用，解决了之前账单乱成一团的局面。
对于想要尝试的开发者，部署流程非常精简。你不需要配置复杂的 K8s 环境，直接运行一个 Docker 容器即可。
# 快速启动 Millwright 实例
docker run -d --name millwright -p 8080:8080 millwright/millwright启动后，你需要通过 CLI 完成供应商的定价配置，然后将你的 Coding Agent 或业务端点（Endpoint）从原来的 api.openai.com 修改为 Millwright 的本地 8080 端口。
总的来说，如果你面临公司内部 LLM 调用链路混乱、成本失控，且对数据私有化有刚需，Millwright 这种轻量级的 Rust 路由方案比自己从零写一个分发层要高效得多。它将模型选择的逻辑从业务代码中解耦出来，让我们可以通过简单的策略配置，在成本、性能和稳定性之间找到平衡点。
