S4 Firewall
LLM token budget 與 runaway-loop control
何時收回成本？
回收週期取決於成本項目和替換範圍
該產品的回收週期取決於您目前的 AWS 支出、替換範圍和執行環境。請使用帳單模擬器識別符合的成本項目並取得粗略的節省估算。
一個運行在你 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 指向防火牆即可。
為什麼更便宜
假設一個團隊的 LLM API 每月預算為 $5,000，偶爾因 agent 迴圈或重複呼叫而超支。
- 預算支出
- $5,000 / 月
- 暴走超支 (50%)
- $2,500 / 月
- 月度合計
- $7,500 / 月
- 上限內 LLM 支出
- $5,000 / 月
- S4 Firewall 實例 (m5.large + 軟體費)
- $120 / 月
- 月度合計
- $5,120 / 月
按 RPS 選擇 S4 Firewall 實例
| 請求負載 | 推薦執行個體 | S4 Firewall 實例費用 | 防止的暴走超支 (假設值) |
|---|---|---|---|
| ~10 RPS | t3.medium | $45 / 月 | $500–$2,000 / 月 |
| ~100 RPS | m5.large | $120 / 月 | $2,000–$10,000 / 月 |
| ~1k RPS | m5.2xlarge | $310 / 月 | $10,000–$50,000+ / 月 |
僅供參考。LLM token 計費遵循 OpenAI / Anthropic / Bedrock 各家公開價格, 隨輸入/輸出比例變化。50% 的暴走超支為中位估計, 實際事故可能達到預算的數倍 (參見公開 post-mortem)。S4 Firewall 透過替換 base_url 即可串接, 同步執行 attribute / reserve / decide 管道, 從源頭防止超支。
計費模式
按小時收取軟體費用 + EC2（c6g 級，Arm）。按執行個體類型計量。
