不自己跑一个 LLM 代理，账永远算不清

账单出来的时候，你只知道这个月花了两千美元。哪把密钥花的、调的是哪个模型、哪个客户端在半夜重试，一概不知道。控制台给你的是一张漂亮的用量曲线，不是能做决定的数据。

一、发生了什么

开发者 Jared Siegel 在 10 月 18 日写了一篇短文，标题很直白：如果你不自己跑一个 LLM 代理，你怎么知道到底发生了什么。他的核心论点不是省钱，是可见性。

他列了五条理由。第一，多个供应商、多个模型，收在一个自己控制的端点上。第二，有日志：哪把密钥、在什么时间、用哪个客户端、调了哪个模型、返回什么状态。第三，用虚拟密钥，不必把主密钥复制到每个项目、每个 agent、每个实验脚本里。第四，基础设施在自己手里。第五，换模型或换供应商时，不用把整条链路再搭一遍。

他提到一个具体场景：编程会话里出现缓存未命中，他能手动在 20 秒内定位原因。因为代理有接口，这件事理论上还能自动化，他只是没去做。他也说了自己不推荐具体产品，只建议自己找一处可控的地方跑起来，然后按需要改。他自己就改过，加了自定义的工具服务端点。

文章没有给成本数字，也没有跑分。它是一篇经验帖，不是评测。但五条理由都指向同一个判断：你管不了自己看不见的东西。

二、跟你有什么关系

一个人用几个模型、维护几个脚本的开发者。 你至少需要知道每月花在哪个模型上，也需要在某个早上所有任务都失败时，分清是密钥额度用完、模型名写错，还是上游真的在抖动。一个代理加一张按模型分组的账，比任何优化技巧都先见效。

带小团队的负责人。 主密钥散在七八个地方，离职一个人就得全换。虚拟密钥解决的正是这件事：吊销一把，不影响别人。

做产品的团队。 供应商限流、涨价、下线模型时，改一处配置和改二十处代码，是两种工作量。

三、怎么用

1. 选一个能自托管、能改代码的网关。不要选只能看面板、不能加字段的托管服务，那样问题只是从供应商那边挪到了服务商这边。
2. 所有客户端只配一个地址。编辑器、命令行 agent、脚本、内部工具，全部指向这个端点。有漏网的调用，账就永远对不上。
3. 一个项目一把虚拟密钥，按用途命名。别用"test1""key2"这种名字，三个月后你自己也认不出来。
4. 日志至少记五个字段：时间、密钥、模型、客户端、状态码。再加两个更有用：输入输出 token 数、是否命中缓存。
5. 每周看一次分布。哪个模型占了大部分调用、哪个项目在重试、缓存命中率是不是掉了。这三件事能解释大部分异常账单。看趋势，不要被某一天的尖峰带着跑。

四、三个别信的说法

"官方控制台的用量面板够用。" 面板是给付费用户看的，粒度通常到账号，不到密钥和客户端。它也不会告诉你这次调用是重试还是首次请求。做容量和成本决策，这个粒度不够。

"开了遥测导出就等于有了可观测性。" 导出只是把数据送出去。没有统一的请求标识，没有按密钥和项目的归属，导出的仍是一堆对不上号的记录。代理的价值在于它在链路上，能强制打标。

"自建代理是过度工程，还会加延迟。" 一个进程内转发的代理，延迟增量通常在毫秒级，相比模型本身几百毫秒到几秒的响应可以忽略。真正该担心的是它变成单点：要么部署两副本，要么接受它在挂掉时快速失败。

五、一句话结论

自己跑代理不是为了省那点转发费，是为了让每一次模型调用都留下能追责、能归因、能切换的记录。它不解决模型好不好用，只解决你有没有资格判断这件事。

信息来源

• If you don't run your own LLM proxy, how the fuck do you even know whats going on?，2026 年 10 月 18 日

功能与价格以官方公告为准。本文写于 2026 年 10 月 19 日。