23 个端点 · 一把 Key · 中位 80 毫秒开销
ByteSpike 把流量散发到 23 个端点 —— 图像 / 视频 / 文本 / 异步任务全覆盖，前面套一个 Anthropic 形状的 API。有意思的问题不是路由本身，是延迟预算。本文讲我们怎么在保留 OAuth pool 粘性、重试语义、按请求配额计算的同时，把网关中位开销压到 80 毫秒以内。
预算
用户调用 ByteSpike 时，在请求到达上游之前我们要做 4 件事：校验 key + 读组织配额、挑一个 sticky OAuth-pool 槽位、附加 observability header、按上游协议（Anthropic Messages → OpenAI Chat Completions 透明层）序列化请求体。回程要做：读响应 header、累加按请求用量、哈希做缓存、再序列化。
总预算：中位 80 毫秒。Claude Sonnet 典型 TTFB 是 600-1200 毫秒，所以 80 毫秒是 7-13% 的税。这个数字是我们对比 3 家竞品网关之后定的 —— 它们的中位 tax 是 130-220 毫秒。我们觉得能做得更好。
毫秒花在哪
- 连接池热身：每个上游保持 HTTP/2 长连接，跨请求复用，能省 ~20 毫秒。第一次撞到冷成员要付这个开销，之后都吃缓存。
- 边缘的配额计算：组织钱包读取是最重的同步步骤。我们把它钉在与网关 pod 同机房的热 Redis 副本上，再加 30 秒 TTL 本地缓存做亚秒级校验。
- 粘性 pool 选择：不每次请求都重新平衡，而是把 user_id 哈希进 pool 槽位，只在槽位健康变化时 re-shard。用公平性换可预测延迟 —— 我们再选一次还会这样。
- 流式重序列化：不缓冲响应。上游字节进来就 inline 重新组帧（必要时 Anthropic SSE → OpenAI SSE），转发。变换器是个小状态机，不是 JSON parser。
没花在哪
我们不让请求体过通用网关。没有 plugin chain、没有 middleware 大杂烩、没有重新解析每个 JSON 字段的 schema 校验器。上游之前每一行代码都有可测量的 80 毫秒预算贡献。不抗事的都砍了。
换来什么
提交时即返回 estimated_credits header，而不是流完才算。失败退款 inline 处理（5xx → 在响应离开网关前释放预扣积分）。按模型适配每个上游公布的重试策略。这些都不可能塞进 220 毫秒预算里 —— 80 毫秒里刚好。
如果你要在前沿模型上做对时间敏感的产品，网关 tax 比大多数人以为的更重要。我们会继续往下压。