概念位置

常見的 sandbox 技術光譜（依隔離強度跟工程成本）：

Sandbox 在 LLM 場景的常見配置：

1. 個人 dev：用獨立 OS user 跑 MCP server、限制檔案存取到 workspace；或用 Docker。
2. production agent：每個 user / session 一個 ephemeral container、跑完就 destroy。
3. code execution tool：把 LLM 生成的 code 丟進 sandbox 跑（如 OpenAI Code Interpreter、Anthropic Claude Code Tool）。

設計責任

理解 sandbox 後可以解釋兩個現象：為什麼跑第三方 MCP server 前 sandbox 是基本配置（MCP 是可執行程式碼、權限上限是「跑該 server 的 user 的權限」）、為什麼 production 場景的 code execution tool 必定在 ephemeral sandbox 內跑（避免長期 state 跟跨 user 殘留）。

設計 LLM application 時、sandbox 跟 tool use 的白名單是兩個獨立的防護層、建議都做：白名單擋已知範圍、sandbox 擋未預期的副作用。詳見 6.2 tool use 與 MCP server 的權限模型。

隔離什麼

服務中的共享資源是 bulkhead 的隔離對象：

實作模式

獨立 Goroutine Pool

Go 中用有限容量的 channel 模擬 goroutine pool：

 1var (
 2    ingestPool = make(chan struct{}, 100)  // ingestion 最多 100 goroutine
 3    queryPool  = make(chan struct{}, 20)   // query 最多 20 goroutine
 4    rulePool   = make(chan struct{}, 10)   // rule engine 最多 10 goroutine
 5)
 6
 7func handleIngest(w http.ResponseWriter, r *http.Request) {
 8    select {
 9    case ingestPool <- struct{}{}:
10        defer func() { <-ingestPool }()
11        processIngest(r)
12    default:
13        http.Error(w, "ingestion overloaded", http.StatusServiceUnavailable)
14    }
15}

Ingestion 的 100 個 goroutine 全部被佔用時，新的 ingestion 請求被拒絕（503），但 query 和 rule engine 的 goroutine 不受影響。

獨立 Connection Pool

資料庫連線池按工作類型分開：

1// driver name 依實際使用的 driver 而定（modernc.org/sqlite 用 "sqlite"、mattn/go-sqlite3 用 "sqlite3"）
2ingestDB := sql.Open("sqlite", "events.db")
3ingestDB.SetMaxOpenConns(10) // ingestion 專用
4
5queryDB := sql.Open("sqlite", "events.db")
6queryDB.SetMaxOpenConns(5)   // query 專用

SQLite 的特殊情況：SQLite 是檔案級鎖定，多個連線池打開同一個檔案時仍共享 write lock。連線池隔離在 SQLite 上主要隔離的是 Go 層的 goroutine 等待，不是 DB 層的鎖定。PostgreSQL 的連線池隔離則是真正的資源隔離。

容量分配

Bulkhead 的每個隔艙分配多少資源是設計決策。分配依據是「這個工作負載的優先順序和預期併發量」：

分配比例不需要精確 — 重點是每個隔艙有獨立的上限，而非共享一個無差別的總上限。

監控系統的應用

Collector 同時承載 ingestion（接收事件）、query（dashboard 查詢）和 rule engine（規則評估）三種工作。不隔離時，一個複雜的 dashboard 查詢（full table scan）可能佔住所有資料庫連線，讓 ingestion 的寫入也排隊等待。

Bulkhead 設計讓 ingestion 和 query 各自的過載互不影響：

• Ingestion 的 goroutine pool 滿了 → SDK 收到 429 → 離線 buffer 接手
• Query 的 goroutine pool 滿了 → dashboard 暫時顯示 loading → 不影響 ingestion
• Rule engine 的 goroutine pool 滿了 → 規則評估延遲 → 不影響事件接收和查詢

下一步路由

• 背壓的流量控制 → 背壓機制
• 依賴失敗的快速失敗 → 熔斷器
• 突發流量時的綜合策略 → 模組七 突發流量

本文是 CockroachDB vendor overview 的 implementation-layer deep article。Overview 已界定 CockroachDB 的 PostgreSQL wire 相容定位、本文聚焦 serializable default 對 application transaction contract 的重塑。

Scope warning（最高、F4 Frame 2）：本篇整篇是跨 case 合成 frame、不是單一 case 揭露。3 個 CockroachDB direct case（9.C39 DoorDash / 9.C40 Netflix / 9.C41 Hard Rock Digital）對 application transaction retry contract 重塑的揭露 都偏弱 — DoorDash case 只寫 PostgreSQL wire protocol-level 相容、SQL 行為（serializable default / retry semantics / partial index）「仍要驗證」、沒直接寫 40001 serialization_failure / SAVEPOINT cockroach_restart / hot row contention / retry loop pattern。Netflix / Hard Rock case 完全沒寫 retry pattern。本章 retry pattern 議題從 Cockroach Labs 官方 SQL Layer docs + PG → CockroachDB 通用 contract 重塑視角合成、DoorDash 只作為 trigger context（撞牆訊號 + 觸發遷移）、不是 ground truth case study。讀者引用本章內容到實際系統前、應該 自己跑 application audit 而不是直接套合成的 pattern。

問題情境：從 PG READ COMMITTED 遷到 CockroachDB SERIALIZABLE 的 application 衝擊

團隊從 PostgreSQL（default READ COMMITTED）遷到 CockroachDB（default SERIALIZABLE）、上線後 application transaction retry 突然爆增、user-facing latency p99 高 5 倍、error rate 顯著上升。Driver 不會自動 retry — 應用層必須認得 40001 serialization_failure 並包 retry loop with exponential backoff。沒包就是直接拋例外給用戶。

讀者常問：

• 為什麼同樣的 transaction 在 CockroachDB 一直 retry、在 PostgreSQL 從來不會？
• 40001 serialization_failure error 怎麼處理、能不能直接 swallow？
• 我要把所有 application transaction 都改成 retry loop 包起來嗎？
• 能不能改 isolation level 回 READ COMMITTED、放棄 serializable 保證？

四題的回答都依賴一個前提：CockroachDB 的 application transaction contract 跟 PostgreSQL default 不一樣、必須重塑。

Scope warning explicit label：DoorDash case 沒揭露 retry pattern

DoorDash case 沒直接揭露 serializable retry contract / 40001 / SAVEPOINT pattern / hot row contention。case 只寫「PostgreSQL wire protocol 相容、實際 SQL 行為（serializable default、retry semantics、partial index）仍要驗證」（DoorDash 觀察段 / 策略段 3、F4.4）。

本章 retry pattern 議題是從 PG → CockroachDB 通用 contract 重塑視角合成、不是 DoorDash case 直接揭露。引用 DoorDash 時應該用：

• 正確口徑：「DoorDash 揭露 Aurora Postgres 1.636 M QPS 撞牆 → 引出 distributed SQL retry contract 需求、本章 retry pattern 議題是從 PostgreSQL → CockroachDB 通用 contract 重塑視角合成、不是 DoorDash case 直接揭露」
• 不要寫成：「DoorDash retry pattern」、「DoorDash 揭露 40001 處理」之類把合成包成 case fact 的語法

Case anchor（trigger context、不是 ground truth）

• 9.C39 DoorDash：提供「PG wire 相容、SQL 行為仍要 audit」的 case 警語（F4.4）、作為本章 為什麼 retry contract 要重塑 的觸發訊號。retry pattern 本體走 standard-driven（Cockroach Labs 官方 SQL Layer docs + Transaction Retry docs）

Sibling 對照 9.C4 DraftKings Aurora financial ledger 提供 PostgreSQL READ COMMITTED + Aurora 的另一條路徑 — 用 application-level sharding（200 個獨立 Aurora cluster）避開 retry、而不是處理 retry。Scope warning：DraftKings case 沒 寫 PostgreSQL READ COMMITTED retry pattern、case 是 Aurora 內 business sharding 路徑。本章引用 DraftKings 為「假想若把 DraftKings 遷 CockroachDB 會撞到 retry contract 重塑」合成對照、不是 case 直接揭露。

核心機制：serializable default 跟 PostgreSQL 的差異

來源分層：本段機制來源是 Cockroach Labs 官方 SQL Layer docs + Transaction Retry docs（standard-driven）、不是 從 case 抽取。3 個 direct case 都沒揭露這些機制細節。

Serializable 是 CockroachDB 的 default

CockroachDB 預設 SERIALIZABLE — 最強 isolation level、保證 transaction 結果等同某個 serial order（即所有 transaction 像逐個按順序執行）。對比：

Conflict detection：read / write set 衝突就 abort

CockroachDB 追蹤每個 transaction 的 read set 跟 write set。當兩個並行 transaction 的 read / write set 衝突、CockroachDB abort 後到的那個、發 Serialization Failure（40001 serialization_failure）。

對比 PostgreSQL serializable（SSI）：兩者都是「post-detect」、commit 時偵測 anomaly、不是 pre-lock。差別在 衝突偵測時機 跟 成本：

• PostgreSQL SSI：用 predicate lock 追蹤 query 條件、commit 時偵測
• CockroachDB：用 timestamp ordering + write intent、衝突 當下 就 abort

CockroachDB 的成本在「衝突立刻 abort 不等 commit」、好處是「retry window 較短、不會跑完整個 transaction 才發現衝突」。

Application 端 retry：driver 不自動處理

關鍵：CockroachDB driver 不自動 retry。application 收到 40001 serialization_failure 必須自己決定怎麼處理 — exponential backoff retry、circuit break、或拋給上層。

對比 PostgreSQL：PostgreSQL READ COMMITTED 幾乎不會丟 serialization failure（後 writer 等 lock 不 abort）、SERIALIZABLE 才會、但多數 application 沒走 SERIALIZABLE。CockroachDB 預設 就是 SERIALIZABLE、所以 retry loop 是 必要、不是 optional。

Savepoint pattern：官方推薦寫法

Cockroach Labs 官方推薦的 retry pattern 用 SAVEPOINT cockroach_restart：

 1BEGIN;
 2SAVEPOINT cockroach_restart;
 3
 4-- 做正常 transaction 工作
 5SELECT balance FROM accounts WHERE id = 1;
 6UPDATE accounts SET balance = balance - 100 WHERE id = 1;
 7UPDATE accounts SET balance = balance + 100 WHERE id = 2;
 8
 9RELEASE SAVEPOINT cockroach_restart;
10COMMIT;
11
12-- 如果中途 40001：
13-- ROLLBACK TO SAVEPOINT cockroach_restart;
14-- 重新跑 transaction body、再 RELEASE + COMMIT

cockroach_restart 是特殊保留 savepoint name — CockroachDB 認得這個名字、會把 ROLLBACK TO SAVEPOINT cockroach_restart 視為「重啟整個 transaction」而不是部分 rollback。

READ COMMITTED 是 v23.2+ 可選降級

CockroachDB v23.2+ 新增 READ COMMITTED isolation level — application 可選擇用 weaker isolation 換少 retry。但這是「降級」、失去 serializable 保證 — 對應的反例段在失敗模式段展開（金融 ledger 走 READ COMMITTED 可能讓 balance 變負）。

對應 isolation level 卡 跟 transaction boundary 卡。

DoorDash case 對接點（trigger context only）

DoorDash case 揭露 PG wire protocol-level 相容、明示 SQL 行為（serializable default / retry semantics / partial index）「仍要驗證」（F4.4）。本章機制段就是回答「audit 什麼」的具體展開 — 但 audit checklist 本體屬通用工程知識、case 沒 ground truth。

引用紀律：「DoorDash 揭露 PG wire 相容、SQL 行為仍要 audit、其中 serializable default 跟 retry semantics 是 application contract 重塑的核心議題」— 把 case 揭露的 fact 跟本章合成的 frame 分開講。

操作流程：retry loop 設計

Retry loop 偽碼

 1for attempt := 0; attempt < MAX_RETRIES; attempt++ {
 2    tx, err := db.Begin()
 3    if err != nil { return err }
 4
 5    _, err = tx.Exec("SAVEPOINT cockroach_restart")
 6    if err != nil { tx.Rollback(); return err }
 7
 8    // ... 跑 transaction body ...
 9
10    _, err = tx.Exec("RELEASE SAVEPOINT cockroach_restart")
11    if err == nil {
12        err = tx.Commit()
13        if err == nil { return nil } // 成功
14    }
15
16    if isSerializationFailure(err) { // SQLSTATE == "40001"
17        tx.Rollback()
18        backoff := time.Duration(math.Pow(2, float64(attempt))) * 10 * time.Millisecond
19        time.Sleep(backoff + jitter())
20        continue
21    }
22
23    tx.Rollback()
24    return err // 非 retry-able error
25}
26return ErrMaxRetriesExceeded

關鍵點：

• exponential backoff with jitter（避免 retry storm 同步）
• max retry 上限（避免無限 loop、要有 circuit breaker）
• 只 retry serialization failure、其他 error 直接拋
• transaction body 必須是 冪等 的（同樣 input 多次執行結果一致）

配置

1-- 改 transaction isolation level（v23.2+ 才支援 READ COMMITTED）
2SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
3
4-- 看當前 session 預設
5SHOW SESSION default_transaction_isolation;

驗證點

1-- 看 transaction retry 統計
2SELECT * FROM crdb_internal.txn_stats;
3
4-- 看哪些 query / table 衝突最多
5SELECT * FROM crdb_internal.cluster_contention_events ORDER BY count DESC LIMIT 10;

Idempotency 設計：transaction body 必須冪等

retry-safe transaction body 必須冪等 — 同樣 input 多次執行結果一致。這是 idempotency 在 distributed SQL retry contract 下的具體展開、不是 optional：

冪等性是 application 設計議題、不是 CockroachDB 配置可解的 — application contract 重塑的核心成本就在這。

Rollback 邊界

transaction 自身有 SAVEPOINT cockroach_restart 邊界、ROLLBACK TO SAVEPOINT 後可重試整個 transaction body。但：

• commit 後不可回滾 — 業務狀態還原只能新交易補償
• application 端如果在 transaction 外 cache state、retry 後 state 不一致（見失敗模式段）

失敗模式

Retry storm：contention 嚴重時 CPU 雪崩

當高頻寫入撞同一 row（例：全局 counter、熱門商品 inventory）、serializable 衝突率可能 100%、application 端 retry loop 不斷重跑、CPU 雪崩。

修法：

• Max retry 上限 + circuit breaker：超過就放棄、回 5xx 給 client、避免 retry storm 拖垮 cluster
• 改 schema 避開 hot row（partition by region、shard counter、用 sequence 代替全局 counter）
• 監控 crdb_internal.cluster_contention_events、針對 top-N table 改設計

非冪等 transaction 重試：double-count

最危險的 production bug：transaction body 不是冪等的、retry 後資料重複寫。ledger double-count、payment 重複扣款、log 重複記錄。

修法：

• transaction body 寫成 UPDATE balance SET balance = balance - X（相對運算）、不寫 UPDATE balance SET balance = Y（絕對賦值依賴 read 結果）
• INSERT 加 UNIQUE constraint + ON CONFLICT DO NOTHING
• 用 idempotency key（client 帶 UUID、server 端 dedupe）

Cross-statement state 假設

application 在 transaction 外 cache state（例：開 transaction 前 read 一個值、跑 transaction 期間用 cached 值）— retry 從 SAVEPOINT 重來時、cached state 不會重新讀、retry 後 state 不一致。

修法：

• 把 cached state 改成在 transaction 內 read
• retry loop 內 reset 所有 cached state
• 用 closure / scope 限制 cache 的生命週期到 transaction 內

Hot row contention

高頻 update 同一 row（例：全局計數器、熱門商品庫存、世界冠軍直播觀眾數）— serializable 衝突率接近 100%、無論 retry 多少次都繼續衝突。

修法（schema-level、不是 application-level）：

• 用 sequence 或 distributed counter（每節點本地 + 定期 aggregate）
• partition by hash key、把單一 row 拆成 N 個 sub-row
• 改 append-only + 定期 aggregate（事件流 + materialized view）

改 READ COMMITTED 後忘了驗證業務語意

v23.2+ 可改 READ COMMITTED、少 retry 但失去 serializable 保證。對金融 ledger：READ COMMITTED 可能讓 balance 變負（兩個並行 withdraw 都看到 balance=100、都扣 50、結果 balance=-50）。

修法：

• 金融 / 庫存 / 配額這類 strict consistency 場景必須留 SERIALIZABLE
• READ COMMITTED 只用在 容忍 stale read 的場景（搜尋結果 / 分析 dashboard）
• 改 isolation level 前 跑 application audit、確認業務語意能容忍

Long-running transaction：retry 機率隨時間線性上升

transaction read 開始時間早、commit 時 conflict window 大、retry 機率隨 transaction duration 線性上升。

修法：

• transaction scope 縮小 — 只包必要 read / write、不要把 RPC call / external API 放 transaction 內
• kill long-running query（SHOW SESSIONS + CANCEL QUERY）
• 把 batch update 拆成多個小 transaction、加 idempotency key

Distributed deadlock 跟 retry 互動

CockroachDB 用 distributed deadlock detection（每個 node 維護 wait-for graph、定期跨 node 交換）跟 PostgreSQL local lock 表的 deadlock detection 不同。一般情況下、被 detector 選為 victim 的 transaction 會直接 abort、application retry loop 應該收到 40001 後重跑。但在三種 corner case 下會跟 retry loop 形成雪崩 pattern：

• 多 transaction 同時撞同一組熱 row、deadlock detector 跨節點時間窗有 lag、多個 victim 同時 abort 後同時 retry、撞回同一個 deadlock window
• 跨節點的 distributed deadlock 偵測週期（預設 200ms+）放大 application retry latency、application 的 retry backoff 沒對齊偵測週期、形成「detect → abort → 快速 retry → 再 deadlock」迴圈
• Application 把 deadlock victim 當 40001 直接 retry、不分流出來看、就難以從 metric 區分「serialization conflict retry」跟「distributed deadlock retry」、調 schema / contention 的策略會用錯方向

修法（屬通用工程議題、case 未直接揭露）：

• Retry backoff 至少對齊 distributed deadlock 偵測週期、避免在偵測窗內快速 retry
• 加 jitter、不同 session 的 retry 不同步
• Application metric 分桶記錄 serialization_conflict_retry vs distributed_deadlock_retry、避免 contention 改善方向判錯
• Schema 設計階段避免「跨節點熱 row 環形依賴」（例：兩個服務交叉 update 對方的 counter row）

跨 case 合成 Scope warning：DraftKings 對照

DraftKings ledger 對照 — DraftKings case 沒寫 PostgreSQL READ COMMITTED retry pattern、case 內容是「Aurora 內 business sharding 路徑」、用 200 個獨立 cluster 解 Aurora single-primary 撞牆。本章把 DraftKings 拿來當「假想若遷 CockroachDB 需改 SERIALIZABLE + retry loop」的合成對照、不是 case 揭露的 fact。

實際 DraftKings 走 Aurora + application sharding 而非 CockroachDB、所以「DraftKings retry pattern」這個說法本身就是合成 — 應該寫成「DraftKings 走 Aurora sharding 避開 retry contract 重塑、若改走 CockroachDB 則需處理本章描述的 application 改寫」。

容量與觀測

必看 metric

• Transaction retry rate：per table、per session
• Serialization failure rate：絕對值 + ratio
• Transaction duration p99：long-running 是 retry 的根因之一
• Hot ranges by retry count：top contention 來源
• Application metric：retry count per request、retry-induced latency p99、circuit breaker trip count

容量公式

• 基底 QPS × (1 + avg retry count) = 實際 transaction load
• 例：1000 QPS、avg retry = 0.3 → 實際 cluster 處理 1300 transaction/s

retry rate 是 容量規劃必納入 的變數 — 沒算 retry 就會 underestimate 真實 load。

Tuning

• reduce transaction scope：transaction 越短、conflict window 越小
• kill long-running query：transaction 過長要主動截斷
• partition hot rows：schema-level 解 hot contention
• 改 isolation 到 READ COMMITTED（如果業務語意允許）

回路徑

• 9.5 瓶頸定位流程 判斷 retry-bound vs CPU-bound
• 9.6 容量規劃模型 retry rate × baseline QPS
• transaction boundary 卡
• isolation level 卡

邊界與整合

Sibling deep articles

• HLC + Raft consensus：為什麼 serializable 是 distributed SQL 的合理 default
• locality-aware schema：partition 降低 hot row contention
• survival goals：cross-region latency 加長 retry window

跟 PostgreSQL 對照

PostgreSQL READ COMMITTED 是 default、application 沒 retry loop 是 acceptable。遷 CockroachDB 必須 重塑 application transaction contract — 這是 migration 階段最容易 underestimate 的成本。

對應 PostgreSQL MVCC + SSI 機制細節、見 PostgreSQL MVCC + Lock Model。

Migration playbook

PG → CockroachDB 的 application audit 必看 transaction shape：

• 每個 transaction 的 read / write set 預估衝突率
• 是否冪等（retry-safe）
• transaction duration（long-running 是 retry 放大器）
• 業務語意能否容忍 READ COMMITTED（避開 retry 的 fallback）

1.x 章節互引

• 1.3 Transaction Boundary 上游 — distributed transaction 邊界
• isolation level 卡

何時不用本文

• 純 read-only workload、無 contention
• 已用 PostgreSQL serializable（application contract 相似、遷移衝擊小）
• 用 CockroachDB v23.2+ READ COMMITTED 且業務允許 stale read

相關連結

• CockroachDB vendor overview
• HLC + Raft consensus
• 9.C39 DoorDash（trigger context — PG wire 相容警語）
• 9.C4 DraftKings（合成對照 — Aurora sharding 路徑）
• PostgreSQL MVCC + Lock Model
• isolation level 卡 / transaction boundary 卡
• 官方：CockroachDB Transactions / Transaction Retry Error Reference / READ COMMITTED v23.2 announcement

本章寫作邊界

本章聚焦 production LLM 推論的多租戶 isolation 特殊性。team / 個人 dev 場景的「多人共用本地 server」見 llm/6.5 跨進 production 的 routing 中樞；通用 IAM / 服務間信任邊界見 7.2。

本章 threat scope

In-scope：KV cache 跨租戶洩漏、prompt log 隔離、模型 artifact 訪問權、batch 推論的順序敏感性、tenant-scoped rate limit、共用 GPU 上的記憶體殘留。

Out-of-scope（路由到他章）：

• 通用 IAM / 服務間信任 → 7.2 identity-access-boundary
• workload identity → 7.7 workload-identity-and-federated-trust
• log / PII 治理 → llm-log-and-pii-governance
• model artifact 供應鏈 → llm-deployment-supply-chain
• 入口治理 → 7.3 entrypoint-and-server-protection

從本章到實作

• Mechanism：問題節點表 → knowledge-card → 看具體機制。
• Delivery：交接路由 → 05-deployment-platform / 06-reliability / 08-incident-response。

LLM 多租戶隔離的三個 LLM-specific 層

跟一般 service 的多租戶隔離（compute / network / data）相比、LLM 推論服務多了三個層次：

1. KV cache 層：KV cache 是推論時的 attention 暫存、跨 request 可能重用（prefix cache、shared prefix optimization）；跨租戶共用 cache 是直接的資料洩漏面。
2. prompt log 層：production LLM 服務通常會 log prompt + response 用於 debug / billing / abuse detection；log 的隔離與保留期限直接影響跨租戶洩漏風險。
3. model artifact 訪問權：production 可能部署多個 fine-tuned 模型（如 customer-specific 模型）、模型本身是 sensitive artifact、訪問權要對齊 IAM。

分析模型

production LLM 推論的多租戶隔離依四個層次分析：

1. memory 層：GPU VRAM、CPU RAM 中的 KV cache 跟模型權重、跨 request / 跨租戶的殘留與共享邊界。
2. storage 層：模型 artifact、prompt log、context cache 在儲存層的隔離。
3. identity 層：tenant identity 怎麼帶到 inference call、rate limit / quota 怎麼按租戶分。
4. observability 層：metric / log / trace 中的 tenant tag、跨租戶分析的允許範圍。

判讀流程

判讀流程的責任是把「能服務多個租戶的 LLM 服務」轉成「租戶間資料不互相洩漏的 LLM 服務」。

1. 先確認 tenant identity 從 API gateway 到 inference call 的傳遞路徑。
2. 再確認 KV cache、prompt log、model artifact 各自的隔離邊界。
3. 接著確認 GPU 記憶體中的跨 request 殘留是否清理。
4. 最後交接到偵測流程、確認跨租戶異常能被識別。

問題節點（案例觸發式）

常見風險邊界

風險邊界的責任是界定何時 LLM 多租戶 isolation 已進入高壓狀態。

• KV cache 共用範圍跨越 tenant 邊界時、代表記憶體層 isolation 失效。
• prompt log 沒帶 tenant tag、或 tag 後仍可跨 tenant 查時、代表 log 層 isolation 不足。
• 模型 artifact 訪問權跟 IAM 解耦時、代表 identity 層 isolation 不足。
• 推論 batch 對 tenant boundary 不敏感時、代表 batch 層的 noisy-neighbor 風險上升。

LLM 場景的特殊判讀

LLM 多租戶 isolation 相對一般 multi-tenant 服務的特殊性：

1. KV cache 是有用但敏感的優化：shared prefix cache（如多 tenant 用同一 system prompt）能省大量 prefill 算力、但跨 tenant 共用就是洩漏。判讀：可以 share 同 tenant 內的 prefix、不能 share 跨 tenant。
2. prompt log 含豐富使用者意圖：相比一般 API log 主要記 endpoint / status code、LLM prompt log 記的是「使用者實際在問什麼」、隱私敏感度高得多。
3. GPU 是稀缺資源、共用比 CPU 多：production LLM 服務常多 tenant 共用同卡、isolation 比一般 multi-tenant 服務（每 tenant 跑獨立 pod）更難做、需要更細的 batch 跟 memory 管理。
4. fine-tuned 模型本身是 customer asset：模型訓練成本高、權重是客戶 IP、訪問權混亂直接是 IP 外洩。
5. 「LLM 記住 cross-tenant 資訊」的疑慮：使用者常擔心 LLM 把 A tenant 的 prompt「記住」洩漏給 B tenant；對 inference-only 服務（無 fine-tune）這不發生（模型權重 immutable）、有 fine-tune 時要看 training data 隔離。

案例觸發參考

LLM 多租戶 isolation 的公開案例累積中、本章先沿用通用 multi-tenant 案例：

• 一般 multi-tenant 隔離案例見 7.2 身分授權邊界。
• LLM-specific 案例累積後會補入 red-team/cases/llm-multi-tenant/。

事實查核註：LLM 多租戶 isolation 的公開事件案例還在早期、社群上有些「LLM A 的 system prompt 被 B 看到」等報告、多數屬 prompt injection 範疇而非 cache 洩漏。建議引用前以最新的 OWASP LLM Top 10 跟具體 vendor 的 incident 公告為準。

引用標準

引用版本與 cadence 規則見 security-citation-currency-and-precision。Last reviewed: 2026-05-12。

下一步路由

• 身份授權邊界：7.2 identity-access-boundary
• log 治理：llm-log-and-pii-governance
• agent prompt injection 後果：llm-prompt-injection-in-agent
• 部署平台：05-deployment-platform
• 可靠性：06-reliability