OpenAI 订阅池化与绕过区域推理容量限制
到现在，大多数人应该都意识到了，我们正处在算力成本危机之中。CPU 和内存价格飞涨，根本不够用。与此同时，全球的 GPU 也绝对不够。如果你最近用过 ChatGPT，可能已经看到过圈子里流传的梗：OpenAI 的推理容量不够了。就连 Tibo 也公开承认他们存在算力问题。
算力已经烧穿了 —— Tibo (@thsottiaux)，2026 年 10 月 6 日
过去几周，我因为推理容量问题，花了大量时间盯着智能体干活，这让我不禁想：推理容量的限制，会不会是按区域划分的？
去年，在这场算力危机之前，即使是用 Anthropic 的模型，在澳大利亚的推理速度也明显更快，因为那时美国其他人都在睡觉。我日常在德国的裸金属机器上做开源软件开发，也开始注意到类似的规律：欧洲一到白天，推理性能就骤降，迎面而来的是一堵堵「模型已达容量上限，请重试」的错误提示。上面这张图就是我今早醒来看到的情况。想想看，我正处在会议演讲前必须把一切搞定并发布的严格时间表里，却浪费了这么多时间，多么沮丧。
你可以在网上随便抱怨，但我们是软件工程师。这些问题，我们能自己解决。
underclass
解决问题的第一块拼图，是我上个月写的一个软件，叫 Underclass。Underclass 把多个 ChatGPT 订阅池化到一起，作为一个代理来用。它可以自动领取重置额度，并正确处理提示缓存键，确保用量不被浪费。我之前没写过关于它的文章，但现在它已经满月了，我认为它足够稳定。
它已经开源在 GitHub 上。我自己用六个 ChatGPT 500 账户来跑它，不过你能配置的账户数量其实没有上限。
underclass 项目介绍
GitHub - ghuntley/underclass：underclass 是一个兼容 OpenAI 接口的池化代理。它会把会话固定到同一个账号上（让 prompt 缓存保持命中），对配额耗尽的订阅做冷却处理，等配额窗口重置后再启用，当整个账号池都耗尽时，它会用最早的 Retry-After 时间快速失败返回。
安装很简单，文档也写得清楚。它还提供 Nix Flake 形式。
preflight 项目介绍
上个月我还写了另一个软件，是一个本地 LLM 代理，会扫描请求和附件里有没有密钥等敏感信息，在请求真正发给模型之前主动清洗和脱敏。项目也在 GitHub 上：
GitHub - ghuntley/preflight：一个本地代理，在 LLM 请求和附件到达模型之前扫描其中的敏感信息。
用法是运行一个 Preflight 实例和一个 Underclass 实例，然后让 Underclass 指向 Preflight。Preflight 会清洗请求再发出去做推理，确保敏感内容永远不会到达推理服务商。
说回正题
看到这里，你大概在想“哇，两个挺酷的项目”，或者在想我为什么开头先讲地理路由。原因是——今天我发布一个新的实验性原型，叫 geoclass，它会把你的请求路由到全球不同的推理区域。
和 underclass、preflight 一样，它也是可组合的。你可以三个都用，也可以一个都不用，或者按你自己的想法任意组合，因为它们本来就是相互独立的软件，能很好地配合。
原理很简单：搭一个 Tailscale 网络，在世界各地部署虚拟机，给这些虚拟机打上 Tailscale 标签，GeoClass 就能通过标签识别它们。之后你只需要把 UnderClass 指向 GeoClass，剩下的就能跑起来（理论上如此！）。
我还不确定 geoclass 能否解决我的推理难题，但过去 30 天 OpenAI 在欧洲的表现实在糟糕，我总不能干坐着干着急。所以我打算试试地理路由（geo-routing）。如果下面的方案对你也管用，请告诉我；我很想和想法相近的朋友交流。不试怎么知道呢！
GitHub - ghuntley/geoclass：[实验性] 面向草根用户（underclass）的地理感知出口路由器：通过 Tailscale 网格网络在其他区域重试 OpenAI 的容量错误，让提示缓存保持温热
附：社交媒体
- 🗞️ 合并 OpenAI 订阅，绕过区域推理容量限制
- 🐦 @GeoffreyHuntley：今天发布 geoclass 实验原型——搭建 Tailscale 网络，把请求路由到全球不同的推理区域。推文配图