LLM 產品裡的多租戶支援可以歸結為四個問題：誰在呼叫（憑證）、他們能用多少（配額）、誰為哪些用量付費（成本歸屬），以及誰能看到誰的資料（隔離）。平臺為前三個問題提供了基礎原語。第四個問題，也就是資料隔離，完全是你自己的責任：沒有任何配額設定或請求頭能阻止某個租戶的文件出現在另一個租戶的搜尋結果裡。本文把平臺原語對映到這四個問題上，用最多的篇幅討論真正會讓生產宕機的兩類成本相關故障模式，最後給出本站處理租戶工作時採用的檢查清單。
先界定你的租戶邊界
在動手改控制台之前，先確定在你的產品裡租戶是什麼：一個付費客戶、某個客戶內部的一個團隊，還是你自己的一個環境？這個對映很重要，因為平臺物件是用來隔離你的應用例項和環境的，而不是用來把每個客戶一對一建模。把租戶到例項的對映留在你自己的服務層裡，你就能自由地把租戶在例項之間遷移、把兩個小租戶合併到一個例項上，或者把一個大租戶拆出去，而無需重整你的平臺賬號結構。
如果你確實要一個平臺物件對應一個租戶，要知道你會繼承一個並非由你選擇的上限。Anthropic 的文件說明預設每個組織最多 100 個 workspace（已歸檔的 workspace 不計入，文件還提到可以聯絡客戶團隊申請更多；請查閱官方頁面確認當前上限）。這個上限對環境和大產品線來說夠用；對註冊流程來說不夠用。所以對映應該存在你的資料庫裡，而不是存在你的 workspace 組織圖裡。
憑證：每個租戶一把金鑰，還是每個租戶組一把
預設的反模式是所有租戶共用一把金鑰：這會讓一次洩露的影響範圍等於你的整個業務，讓按租戶吊銷變得不可能，也讓歸屬統計變成猜謎。給每個租戶，或者每個信任級別相同的租戶組，分配自己的憑證，並按平臺允許的範圍儘可能收窄許可權。完整的安全操作手冊，包括輪換以及懷疑洩露時的處理方式，見金鑰安全指南。
在 OpenAI 上，自然的單位是專案 API key，管理員可以在組織或專案級別強制設定金鑰的最長生命週期。在 Anthropic 上，金鑰可以限定到單個 workspace：workspace 金鑰只能訪問該 workspace 內的資源，而在建立額外 workspace 時，你可以為每個 workspace 分配成員、服務賬號、API key 和資源限制。有些金鑰可以跨多個 workspace，這種情況下 workspace 是在每次請求裡指定的，而不是固化在金鑰裡。
無論你的端點背後是哪個平臺，都要核實請求實際落在哪個上下文，而不是相信配置。Anthropic API 的響應會包含一個anthropic-workspace-id響應頭，其取值是請求所用的 API key 或訪問令牌解析到的 workspace ID，文件還指出即使該 workspace 是預設 workspace，這個頭也會出現。按請求記錄這個響應頭，事後你就能還原任意一次呼叫是由哪個租戶的上下文服務的。
配額：兩個層次，兩個不同的控制面
配額工作有一個組織層和一個 workspace 層。正如 Anthropic 限流文件所說：“API 在組織級別執行由服務端配置的限制，但你也可以為組織的 workspace 設定使用者可配置的限制。”換句話說，平臺執行的是一條底線；你在它之上執行各租戶各自的份額。
陷阱在於以為這兩個數字在同一處配置。它們不在同一處，文件也直說了：“你在不同的地方設定 workspace 的限流和消費上限。”限流從 Rate limits 頁面的 workspace 選擇器按 workspace、按模型配置，涵蓋每分鐘請求數、輸入 token 或輸出 token。消費上限從 Workspaces 頁面的 workspace 面板配置。配了一個而忘了另一個，你要麼有一個沒有被執行的預算，要麼有一個沒有被計量的租戶。
在 OpenAI 這邊，同樣的兩個層次以不同的形態存在：專案的限流和消費告警可以通過平臺的專案管理端點以程式設計方式管理，而生產最佳實踐建議在限額頁面設定消費告警，讓用量越過閾值時發出通知，並把硬性消費上限作為執行手段（在生產環境啟用硬性上限之前，先讀一讀消費上限的指引）。你不應該做的是把今天的限額當成方案來引用：限額會變，按標準做法，始終以你部署時官方文件的當前內容為準。
兩種“你無法使用 API”
這一節值得細讀。當一個租戶超出自己的額度時，平臺可能以兩種截然不同的方式失敗，分不清這兩者的客戶端要麼永遠重試，要麼過早放棄。
第一種失敗是限流：一個 429，說明超出的是哪一項限制，並且在存在時附帶一個retry-after響應頭，告訴你需要等待多久。退避並重試；這就是本站此前講過的重試預算紀律。
第二種失敗是消費上限。它看起來像限流，但並不是。錯誤型別依然是同一種rate_limit_error，但響應裡不帶retry-after那個響應頭，而在 Messages API 中error.details.error_code欄位則給出額度耗盡的取值enforced_spend_limit_reached。文件對運維後果說得很直接：重試，包括 SDK 的自動重試，都會失敗，直到訪問恢復。沒有足夠長的等待，也沒有足夠大的指數；預算已經用完了。
你的客戶端程式碼必須在這裡分支。凡是帶有enforced_spend_limit_reached這類標識的響應，或者一個缺少retry-after的、形態像消費上限的 429，都應該停止重試迴圈，向租戶和你的團隊發出可操作的告警，並讓你的錯誤分診流程決定接下來怎麼處理。把它當作臨時限流來處理，就是一個租戶預算耗盡變成一整面無意義請求牆的原因。
成本歸屬：到底是誰花的錢
歸屬要回答一個簡單的問題，但 API 給出的答案很瑣碎：對每個租戶來說，我們花了多少？在 Anthropic 上，工具是 Usage and Cost Admin API，它的報表引數與租戶核算對得上：group_by[]有一個引數用於拆分結果（例如按模型），bucket_width另一個引數用於選擇按天還是按小時的粒度，還有針對特定 API key 或 workspace 的過濾條件。用量與成本文件：這些端點支援以細粒度、程式設計方式訪問組織的歷史用量和成本資料。
憑證要求是最容易絆倒人的部分，文件也直接點出了這一點。這些端點不接受限定到 workspace 的金鑰。你需要 Admin API key、帶有org:admin相應作用域的 OAuth token，或者一個未限定到 workspace 的個人賬號金鑰或服務賬號金鑰。頁面還指出 Admin API 不適用於個人賬號。為此規劃一個專用的報表憑證，它故意不是你的任何一個租戶金鑰，並用你手上最高等級的防護來儲存它。
有一個歸屬上的細節值得在設計中考慮：用量和成本報表對預設 workspace 以及跨所有 workspace 的金鑰會顯示為空的workspace_id workspace 取值，而金鑰的scope歸屬相關欄位則能把兩者區分開。如果你打算按 workspace 計費，確保你關心的流量確實跑在限定到 workspace 的金鑰下，否則你的報表裡會有一個沒有標籤的桶。
在 OpenAI 這邊，歸屬有一個請求頭的故事：API 參考的請求頭章節展示了請求中攜帶組織標識請求頭OpenAI-Organization和專案標識請求頭OpenAI-Project的情形，並指出這些請求產生的用量計入指定組織和專案的用量。如果你的架構通過共享基礎設施轉發租戶流量，確保這些請求頭反映租戶指定的專案，否則一切都會落進同一個桶裡。更廣泛的埋點紀律，包括每次呼叫要記錄哪些欄位，見用量追蹤指南。
資料隔離：平臺不會替你做的部分
現在是第四個問題。上面講的都是錢和訪問許可權；隔離講的是內容，沒有任何平臺能替你執行你的資料模型。平臺可以按 workspace 隔離檔案、批處理和快取，但它無法知道租戶 A 的支援對話記錄絕不能出現在租戶 B 的查詢結果裡。這條邊界存在於你的技術棧裡：
- 儲存分割槽。每一行包含租戶內容的記錄都帶有租戶標識，並且每個查詢都在資料層按它過濾，而不是在應用層——在應用層，一個被遺忘的
where子句離一次重構只有一步之遙。 - 日誌分割槽。日誌把租戶標識作為一等欄位攜帶，這樣除錯、匯出和保留策略都能按租戶限定。本站推薦的欄位清單，以及完全不應進入日誌的欄位，見可觀測性指南。
- 快取鍵字首。快取的補全結果、embedding 和檢索上下文都必須把租戶身份放進鍵的字首。一個沒有按租戶限定的共享快取，就是一次帶效能預算的跨租戶資料洩露。
- 模板與配置。prompt 模板、模型設定和功能開關按租戶限定，改動一個租戶的配置不能滲到另一個租戶。
- 匯出與刪除路徑。當租戶匯出或刪除自己的資料時，該操作要對照租戶邊界進行校驗，而不是由一個“應該沒問題”的管理指令碼執行。
要防範的失敗模式
同樣的失敗在多租戶評審中反覆出現，所以要刻意在設計上把它們排除掉：
- 所有租戶共用一把金鑰，讓吊銷和歸屬變成全有或全無。
- 只在組織級別配置限額，於是一個吵鬧的租戶就能吃掉所有人的餘量。
- 把消費上限的停止當作可重試的限流，把精力耗在一個不會按你的節奏恢復的預算上。
- 用限定到 workspace 的金鑰去呼叫用量和成本端點，而文件說明這樣行不通。
- 隔離了平臺資源，卻讓自己的資料庫、快取和日誌保持全域性。
- 沒有按租戶對賬：發票說的是一回事，用量報表說的是另一回事，沒人能解釋這個差額。
檢查清單
- 定義租戶邊界，並把租戶到例項的對映留在你自己的服務層。
- 按租戶或租戶組發放憑證，並按平臺允許的範圍儘可能收窄許可權。
- 在兩個層次、兩個控制面上都配置配額，並記錄每一處放在哪裡。
- 讓客戶端行為按兩種失敗型別分支：限流走重試預算，消費上限走告警。
- 用專用的、非租戶的報表憑證生成按租戶的成本報表。
- 按租戶對你的儲存、快取和索引做分割槽。
- 給每一行日誌打上租戶標識。
- 演練只針對單個租戶的輪換和吊銷，而不影響其他租戶。
- 加上按租戶的告警，讓第一個訊號是一條通知，而不是一張支援工單。
四個問題，三個平臺原語，一件仍然屬於你的工作。把對映和失敗分支做對，多租戶就不再是架構問題，而變成了一個計費細節。你呼叫的任何相容服務的端點級細節都在該平臺自己的文件裡，並且一如既往，請對照你構建時官方頁面的當前內容核實每一處引用到的行為。