S4 Firewall
LLM token budget 与 runaway-loop control
一个运行在你 VPC 内的 forwarding proxy，在 LLM traffic 前放置 pre-emptive spend firewall。你的 app 只需修改 base_url（OpenAI-compatible、Anthropic Messages-compatible 或 Bedrock-compatible）；每个 request 都同步经过 attribute → reserve → budget/anomaly → forward → reconcile pipeline。它的核心任务是 runaway-loop circuit breaker：一旦某个 budget 会被超出，就在 relay 前确定性地 block request。
S4 Firewall 是一个 forwarding proxy，在你的 LLM token spend 前放置 budget 和 circuit breaker，并如实区分两层。Layer 1 hard cap 是确定性且 pre-emptive 的：由于 cumulative spend 已知，任何 reservation 会让 running total 超过 configured hard cap 的 request 都会在 relay 前被 block — 对 over-cap requests 进行 100% pre-emptive block，并由 chaos tests 固定验证。Layer 2 loop block 是 best-effort 且基于行为：检测 agent loops、near-duplicate call chains 和 in-session amplification，以限制影响范围。Spend 按 feature / tenant / customer 归因，streaming responses 逐 chunk 透传，因此保留 time-to-first-token。
面临挑战
LLM 代币（token）支出特别容易发生失控事件：智能体循环（agent loop）、近似重复的调用链或会话内放大可能会在有人注意到之前就烧光一个月的预算。因为在响应返回之前输出的代币数量是不可知的，如果没有在账单产生前阻止支出的机制，您只能在事后重构是哪个功能、租户或客户推高了成本。您的支出追踪的是一个失控的循环，而不是您实际预期的工作。
工作原理
- 1
只需将您的 base_url 指向它
S4 Firewall 是一个在您自己的 Amazon VPC 内运行的转发代理。您的应用程序只需更改其 base_url：防火墙即可接收兼容 OpenAI、兼容 Anthropic Messages 或兼容 Bedrock 的入口流量，并将每个请求转发给您已在使用的上游提供商。流式响应会逐块通过而不进行缓冲，因此可以保留首字延迟（time-to-first-token）。
- 2
在单个同步流水线中进行归因、预留和决策
在转发之前，每个请求都会运行一个同步的 attribute -> reserve -> budget/anomaly -> forward -> reconcile 流水线。It attributes the request to a feature, tenant, and customer, reserves the worst-case cost (input tokens counted now, output priced at max_tokens times the output rate), checks the reservation against the hierarchy of budgets, then either forwards or blocks.
- 3
双层拦截，然后与实际使用量进行对账
第一层（Layer 1）硬限制（hard cap）是确定性且抢占式的：任何预留成本超出配置上限的请求都会在转发前被 100% 阻止（超出上限请求的 100% 抢占式阻止，相同的输入状态会产生相同的决策结果，已通过 chaos test 验证）。第二层（Layer 2）循环阻止是尽力而为且基于行为的：它通过检测智能体循环、近似重复的调用链和会话内放大来限制影响范围。当响应返回时，提供商报告的使用量将作为唯一事实来源，并与预留进行对账。
产品亮点
确定性 hard cap：在 over-budget request 被 relay 前将其 block（tenant / feature / customer budget hierarchy）。
失控循环断路器：检测 agent 循环和近重复调用链，以限制影响范围。
即插即用：兼容 OpenAI / Anthropic / Bedrock 的 base_url，流式透传（保持 TTFT），运行在你自己的 VPC 内。
包含内容
- 基于 Amazon Linux 2023 的 arm64 AMI（运行在 c6g / c7g Graviton 实例上，按实例小时计量计费）
- 具有兼容 OpenAI、兼容 Anthropic Messages 和兼容 Bedrock 入口流量的转发代理（应用程序只需更改其 base_url；流式传输逐块通过，保留 TTFT）
- Layer 1 硬限制 — 一种确定性、抢占式的断路器，在转发前阻止任何超出预算的请求（对超出上限的请求进行 100% 抢占式阻止，已通过 chaos test 验证）
- Layer 2 循环阻止 — 一个尽力而为、基于行为的层，用于检测智能体循环、近似重复的调用链和会话内放大，以控制爆炸半径（不提供 100% 保证；随附 dry-run 阴影模式）
- 先预留后对账（reserve-then-reconcile）的 token 会计 — 预留使用最坏情况下的成本（输入立即计算，输出按 max_tokens 乘以输出费率进行定价），然后与作为唯一事实来源的提供商报告使用量进行对账
- 按功能/租户/客户进行的 token 支出归因，发送到 Amazon CloudWatch（命名空间为 S4/Firewall）以及可选的仅计数审计账本（绝不记录提示词或响应正文）
- 一键式 CloudFormation 模板（针对单个实例的 cfn-single.yaml，以及针对内部负载均衡器后冗余集群的 cfn-ha.yaml），带有最小权限的 IAM 角色，无需独立的控制平面或数据库
适用场景
在失控的智能体烧光当月预算之前，使用确定性的硬限制抢占式地阻止它
需要按功能、租户或客户归因 token 支出（粒度细于 IAM 主体），并据此分配预算的团队
在不将提示词或响应正文交给第三方的情况下管理 LLM 流量 — 仅记录 token 数量而非内容的账本
通过将应用程序的 base_url 指向代理，在您自己的 VPC 内对兼容 OpenAI、Anthropic 和 Bedrock 的流量进行统一的预算管理
常见问题
它能 100% 阻止失控的智能体吗？
我们坦诚地将这两层区分开来。第一层（Layer 1）硬限制是确定性且抢占式的：任何预留成本超出配置上限的请求都会在转发前被阻止，即对超出上限的请求进行 100% 抢占式阻止（输入状态相同，决策结果相同，已通过 chaos test 验证）。第二层（Layer 2）循环检测是尽力而为的：失控状态只有在几次调用之后才能被发现，而这几次调用已经产生了账单，因此它的作用是控制爆炸半径，将其限制在少量的请求或小额资金内，而不是保证 100% 预防。它随附了 dry-run 阴影模式，因此您可以在强制执行前测量误阻止率。
如果事先无法得知输出 token 数量，如何在产生账单前阻止支出？
这是通过先预留后对账（reserve-then-reconcile）实现的，而不是简单的估算。在转发前，预留会使用最坏情况下的成本 —— 输入 token 立即计算，输出按 max_tokens 乘以输出费率进行定价 —— 来做出硬限制决策。当响应返回时，提供商报告的使用量将作为唯一事实来源，并与预留进行对账。Token 数量会在不同提供商之间进行标准化，并拆分为输入、输出、缓存读取（cached-read）和缓存写入（cache-write），以便记账能反映每家提供商的真实费率卡。
我的提示词保存在哪里，发送到哪里？
S4 Firewall 本身不会持久化或传输您的提示词或响应。其唯一的出站调用就是您的应用程序原本就会向提供商发起的请求 —— 防火墙不会增加额外的 egress（出站流量）。账本和指标仅携带 token 数量，不包含内容（counts-not-content，已通过 property test 验证）。提示词流向哪里取决于您选择的上游：通过 VPC 接口端点（AWS PrivateLink，该 AMI 可选择性配置）路由到 Amazon Bedrock 可以将这些调用保留在您的 AWS 边界内；而路由到公共互联网上的第三方提供商，流量则会流出 VPC 并进入互联网。
它需要独立的控制平面或数据库吗？
不需要。没有独立的控制平面，也没有外部数据库。预算状态在每个实例 of 内存中保存，并在重启时从零重新推导。数据平面是一个运行在加固的 systemd 单元下的单一静态二进制文件，不具备任何提权 capability，并被赋予了最小权限的 IAM 角色（包括上游模型调用、限定于 S4/Firewall 命名空间的 CloudWatch PutMetricData，以及只写到账本存储桶的 PutObject）。没有遥测呼回（telemetry home-call），也没有许可证密钥检查。
它是如何计费的，我该如何部署它？
计费采用 AMI 按小时计费（按实例小时计量），并提供年约合同选项，运行在 c6g / c7g（Arm）实例上。您可以使用包含的 CloudFormation 模板进行部署 —— 单个实例使用 cfn-single.yaml，内部负载均衡器后的冗余集群使用 cfn-ha.yaml —— 这些模板可以有选择地创建 Bedrock VPC 接口端点。然后，您只需将应用程序的 base_url 指向防火墙即可。
计费模式
按小时收取软件费用 + EC2（c6g 级，Arm）。按实例类型计量。
