重度用 AI 的人大概都有过这种时刻，月底一看账单，某个 key 烧掉一大笔，原因查不到，哪个客户端哪个模型哪次调用，订阅面板一概不给。十月十八日一篇个人博客把这股火发了出来，标题带粗口，HN 上收获小规模共鸣。我读了原文与全部跟帖，作者给的不只是情绪，有一套可以照抄的自建理由与参考路线。
争议从哪来
作者 Jared Siegel，个人博客长期写工程实践。论点一句话，订阅面板里那些分析页给不出工程决策依据，工程师要看的 token 时间序列缺失，供应商的可观测性导出也不够用，想知道调用层发生了什么，就得自己在调用路径上放一个代理。往前翻他十月七日那篇前作，因为拿不到直接 API 访问，他取消了 Claude 订阅，两篇连起来看立场一以贯之，要原始接口，要能自己看的数据路径，主张拥有你的基础设施、应用可见性、数据流向与存储。HN 上十一分四条评论，量不大，跟帖的人都在认真聊部署。话糙理不糙。
代理能看见什么
作者自述他那套代理记录的东西，哪个虚拟 key 发起的调用，来自哪个客户端，什么时间调了哪个模型，返回什么状态，再加上面向工程师的 token 用量时间序列与缓存命中情况。他给了一个具体场景，编码会话出现缓存未命中，他从自己的代理数据里大约二十秒定位到原因，这个数字按自称口径听，思路成立。再举个归因的例子，某个周五下午 token 突增，按 key 一查，是某个实验脚本忘关，这种问题在订阅面板里永远查不出来。数据在自己手里还有一层好处，请求发给过谁、模型回了什么、落到哪里存储，每一跳都能回答，排查不再靠猜。缓存命中率这个指标多数面板根本不给，见过一次就回不去了。
自建的五条理由
作者列的清单五条。多供应商多模型汇成单一端点，客户端配置一次不再改。完整调用日志随时可查。虚拟 key 代替主 key 散落各处，泄露面收窄。基础设施自主，环境自己选。切换模型供应商是分钟级操作。第五条在多模型并存的当下最实用，今天这家降价明天那家出新款，端点不动只换后端。作者特别说明他不荐具体代理软件，部署环境自己挑，理由包括能改代理代码做更深洞察、自定义 MCP 服务端点，代理自带的接口还能把洞察自动化，目前他仍手工排查。
动手参考
教学向给一条可落地的路线。HN 跟帖里唯一被点名的具体工具是 LiteLLM Proxy，开源，一条 Docker 命令起本地端点，跟帖者正用它编排沙箱代理，图的是虚拟密钥不进沙箱、全量监控与护栏能力。单人起步的做法，本地或内网起一个代理，把现有客户端的接口地址指过去，先攒两周完整日志，看清自己的真实用量结构，再决定要不要加虚拟 key、限额与告警。虚拟 key 的做法值得单独说，主 key 只留在代理侧，每个客户端发一把子 key，限额与过期随用随设，泄露了一把只废一把。日志留多久、按天滚动还是按量切割，提前定好，半年后再翻旧账不抓瞎。团队再往上走，多 key 分账、按项目出成本报表、异常调用自动拉黑，这些都建立在日志齐全这个前提上。作者的忠告可以抄录，先有可见性，再谈优化，看不见的东西优化不了。
解决了什么需求
三类人用得上。重度个人用户，解决账单归因与异常定位。小团队，解决密钥治理与成本分摊。做代理产品的开发者，真实调用数据就是需求清单。代价也直说，多一层组件就多一层运维，代理挂了所有客户端一起断，轻量用户订阅面板够用，别为了可见性把周末搭进去。这篇博客的价值在于把一句话喊响，数据路径的所有权与模型能力同样重要。
一句收尾，账本在别人手里，优化就只能靠猜。
来源
- 博客原文 https://jrdsgl.com/if-you-dont-run-your-own-llm-proxy-how-the-fuck-do-you-even-know-whats-going-on/
- HN 讨论帖 https://news.ycombinator.com/item?id=50145507
- LiteLLM Proxy https://docs.litellm.ai/docs/proxy/quick_start