推論最佳化攻擊
Advanced4 min readUpdated 2026-03-13
推測解碼攻擊、批次處理漏洞、持續批次利用,以及速度最佳化如何於 LLM 推論中造就安全缺口。
生產 LLM 部署為吞吐量與延遲積極最佳化。推論最佳化——推測解碼、持續批次處理、flash attention、張量並行——各引入獨特之攻擊面。核心張力是跨請求共享運算改善效率,但造就跨請求干擾通道。
推測解碼攻擊
推測解碼 使用小型 draft 模型預測 token,再由大型目標模型驗證。被接受之預測跳過昂貴之目標模型前向傳遞。
架構
┌──────────────┐ 候選 token ┌──────────────┐
│ Draft 模型 │ ──────────────────────── │ 目標模型 │
│ (1-3B) │ "The quick brown fox" │ (70B+) │
│ 快速、便宜 │ ────────────────────────│ 慢、準確 │
└──────────────┘ 接受/拒絕 └──────────────┘攻擊向量:Draft 模型操弄
Draft 模型較小、較不穩健,且常較目標模型更不對齊。若攻擊者可操弄 draft 模型(經供應鏈或模型替換),被接受之 token 繞過目標模型之安全屬性:
| 情境 | 攻擊 | 影響 |
|---|---|---|
| 被入侵之 draft 模型 | 以產生有害 token 之模型取代 draft | 若有害 token 通過目標驗證則被接受 |
| Draft 模型蒸餾 | 經 API 擷取 draft 模型行為 | 揭露內部生成模式 |
| 接受率利用 | 打造最大化 draft 接受之輸入 | 降低目標模型監督 |
# 推測解碼驗證
def speculative_verify(draft_tokens, target_model, prompt):
"""目標模型並行檢查 draft 預測。"""
target_logits = target_model(prompt + draft_tokens)
accepted = []
for i, token in enumerate(draft_tokens):
draft_prob = draft_model_prob(token, context=prompt + accepted)
target_prob = target_logits[i].softmax(-1)[token].item()
# 若目標模型同意則接受(修改之拒絕取樣)
if random.random() < min(1, target_prob / draft_prob):
accepted.append(token)
else:
# 自調整後之分布重新取樣
corrected = resample(target_logits[i], draft_logits[i])
accepted.append(corrected)
break # 拒絕剩餘 draft token
return accepted持續批次處理漏洞
持續批次處理(亦稱 iteration-level batching)動態自執行批次加入與移除請求。這造就數個跨請求通道。
跨請求干擾
於持續批次中,所有請求共享相同之模型前向傳遞。雖然請求使用獨立 KV 快取與 attention 遮罩,但它們共享:
| 共享資源 | 干擾通道 | 可觀察訊號 |
|---|---|---|
| GPU 運算 | 依批次組成之延遲變化 | 時序側通道 |
| 記憶體頻寬 | 大請求減慢批次中所有請求 | 吞吐量相關 |
| 批次排程 | 優先度/順序影響生成品質 | 佇列位置資訊 |
| Tensor core | 共享矩陣乘法硬體 | 功率/熱側通道 |
經由批次處理之時序側通道
import time
import asyncio
async def probe_batch_occupancy(api_url: str) -> dict:
"""量測延遲變異以推論批次佔用率。
高變異 = 具可變負載之動態批次。
一致快速 = 低佔用。
一致緩慢 = 高佔用。"""
latencies = []
for _ in range(50):
start = time.perf_counter()
await send_request(api_url, "Hello", max_tokens=1)
latencies.append(time.perf_counter() - start)
await asyncio.sleep(0.1)
return {
"mean": sum(latencies) / len(latencies),
"variance": variance(latencies),
"min": min(latencies),
"max": max(latencies),
}Flash Attention 安全考量
Flash Attention 計算精確 attention 但改變記憶體存取模式。雖然它產生與標準 attention 相同之數學結果,但實作 bug 可造就漏洞:
| 關切 | 風險層級 | 緩解 |
|---|---|---|
| 數值精度差異 | 低 | Flash Attention 數學上精確 |
| 客製 CUDA kernel bug | 中 | C++/CUDA 程式碼中之記憶體安全問題 |
| Tiling 邊界效應 | 低 | 區塊邊界之邊緣案例 |
| 遮罩處理 | 中 | 不正確之 attention 遮罩可洩漏跨序列 attention |
張量並行側通道
張量並行 將模型層分散於 GPU 間。GPU 間通訊(經 NVLink 或 InfiniBand)造就網路可觀察之側通道:
可利用訊號
- 通訊量 —— Activation 張量大小與輸入序列長度相關
- 時序模式 —— AllReduce 同步造就可觀察延遲模式
- 記憶體配置 —— GPU 記憶體使用於共享系統上經 NVIDIA 管理 API 可見
# 於共享 GPU 系統上,監控對等 GPU 記憶體使用
# 以推論其他租戶之推論模式
import pynvml
pynvml.nvmlInit()
def monitor_peer_gpu_memory(gpu_indices: list, duration_s: float):
"""取樣 GPU 記憶體使用以偵測推論活動。"""
samples = []
start = time.time()
while time.time() - start < duration_s:
snapshot = {}
for idx in gpu_indices:
handle = pynvml.nvmlDeviceGetHandleByIndex(idx)
info = pynvml.nvmlDeviceGetMemoryInfo(handle)
snapshot[idx] = info.used
samples.append(snapshot)
time.sleep(0.01)
return samples最佳化安全取捨矩陣
| 最佳化 | 吞吐量增益 | 安全風險 | 建議緩解 |
|---|---|---|---|
| 推測解碼 | 2-3x | Draft 模型操弄、降低驗證 | 驗證 draft 模型來源、監控接受率 |
| 持續批次處理 | 3-5x | 跨請求時序、資源干擾 | 對敏感工作負載請求隔離 |
| Prefix 快取 | 2-4x | 跨租戶快取洩漏 | 租戶範疇快取 key |
| 量化 | 2-4x 記憶體 | 安全退化 | 於目標精度基準安全 |
| 張量並行 | 啟動大型模型 | GPU 間側通道 | 網路隔離、加密通訊 |
| Flash Attention | 2-4x 速度 | 極少(精確運算) | 驗證整合中之遮罩處理 |
評估方法論
繪製推論堆疊
辨識哪些最佳化被啟用:推測解碼、持續批次處理、prefix 快取、量化層級、並行策略。
測試跨請求干擾
送出具已知內容之並行請求並量測一個請求之特徵(長度、內容、時序)是否自另一者可觀察。
側寫時序側通道
於變動伺服器負載下量測延遲分布以刻畫經時序之資訊洩漏。
驗證 draft 模型完整性
若使用推測解碼,獨立驗證 draft 模型之來源與安全屬性。
記錄取捨
對部署之特定威脅模型,回報哪些最佳化造就何種風險層級,並附建議。
相關主題
- 模型架構攻擊向量 -- 架構攻擊面概觀
- KV Cache 投毒 -- 快取特定攻擊
- 量化攻擊 -- 精度降低風險
- API 安全 -- 應用層推論安全
Knowledge Check
LLM 推論中推測解碼之主要安全關切為何?