• <xmp id="om0om">
  • <table id="om0om"><noscript id="om0om"></noscript></table>
  • 網絡安全

    構建應用程序以安全使用 KV 緩存

    在與基于 Transformer 的模型 (如 大語言模型 (LLM) 視覺語言模型 (VLM)) 交互時,輸入結構會塑造模型的輸出。但提示通常不僅僅是簡單的用戶查詢。在實踐中,它們通過動態組合來自系統指令、上下文數據和用戶輸入等各種來源的數據來優化響應。

    在多租戶環境中,多個用戶共享同一應用程序基礎設施,這種動態提示結構可能會帶來意外的安全風險。其中一個風險來自 prefix caching 優化,如果處理不當,可能會跨用戶邊界泄露信息。

    本文將探討提示結構與緩存的交集,以及它們的交互如何在 LLM 驅動的應用中造成細微漏洞。通過了解這些機制,開發者可以設計出更安全的系統。

    如何組合應用程序提示

    如果您僅以聊天機器人用戶的身份與 LLM 進行交互,您可能會將提示視為如下所示:

    Build me a vacation itinerary for Orlando in August.

    但在大多數真實應用中,此用戶查詢只是更大規模的動態構建輸入(即應用提示)的 一部分。此提示通常包括多個組件,旨在更有效地塑造模型的響應。

    例如,同一假期行程請求可能會轉換為如下內容:

    You are a helpful travel assistant. Be courteous and avoid any topics that aren’t related to travel and building itineraries. Here’s the user’s request:
    Build me a vacation itinerary for Orlando in August.
    Today’s date is March 1st, 2025.
    The following events are happening in Orlando in August:
    Marathon (August 1)
    Rock Concert (August 10)
    Silent Disco (August 14)

    在代碼中,這可能如下所示:

    application_prompt = f”{system_prompt}\n{user_prompt}\n{date}\n{context}”.

    在后臺,應用程序獲取當前日期和相關的本地事件,然后將它們拼接成語言模型的單個提示,如圖 1 所示。

    A sequence diagram showing a series of API calls and concatenations to build an application prompt from get_time, and get_local_events tools before passing the final prompt to the LLM
    圖 1。本系列 API 調用展示了假期規劃應用程序如何為應用程序提示提取數據

    在本示例中,prompt 組件使用換行符 (\n) 連接,但許多生產應用使用 <system><user><context> 等顯式標簽來分隔不同部分。無論您使用的是簡單的連接還是結構化標簽,其基本原理都是相同的:應用組裝為 LLM 量身定制的完整提示詞。

    有時,應用程序 (尤其是推理和規劃模型) 會在生成最終響應之前進行多次 LLM 調用。每個中間提示都可以使用先前的推理步驟、歷史背景、工具輸出或自動生成的子提示來動態構建。就本文而言,我們重點關注發送給 LLM 進行推理的任何字符串,而不是明確的用戶看到的內容。其中包括多步推理過程中的內部步驟,即模型在后臺通過幾個提示建立答案。

    用戶在提示中可以控制或影響的數據量取決于應用程序的架構方式。在之前的假期規劃示例中,用戶可能只影響用戶提示:“為我構建 8 月奧蘭多的假期行程”。但在其他設置中,例如檢索增強生成 (RAG) 應用,用戶還可能影響檢索并作為上下文包含的文檔,從而間接控制提示的其他部分。

    為什么 KV 緩存速度快

    前綴緩存 是 LLM 服務系統中使用的強大性能優化。其工作原理是將模型的內部狀態重復用于重復的提示前綴,使系統能夠跳過冗余計算并返回更快的響應。

    這實際上是使用 鍵值 (KV) 緩存 實現的。當模型處理輸入令牌 (token) 時,它會生成代表模型狀態的中間張量 (鍵和值) 。當新提示與前一個提示共享前綴時,系統可以重復使用這些緩存的 KV,而無需重新計算。

    例如,如果 model 已處理:

    The quick brown fox jumps over the lazy dog.

    接著會出現一個新的提示:

    The quick brown fox crosses the stream,

    系統可以跳過重新計算共享前綴 “The quick brown fox”,直接從 “crosses” 開始生成。當提示共享固定的系統指令時,這種優化尤其有效,例如旅行助手示例中的系統提示:

    You are a helpful travel assistant. Be courteous and avoid any topics that aren’t related to travel and building itineraries. Here’s the user’s request:

    由于每個查詢都以相同的 30 個 token 開始,因此可以在所有用戶請求中重復使用該前綴的模型 KV 緩存,從而大幅降低延遲和成本。在實踐中,這種緩存是在塊級別完成的,但為了說明目的,我們在這里進行了簡化。

    這種共享效率伴隨著多租戶環境中的權衡:prefixes 可能會在無意中成為 timing side-channel——一個用戶推斷其他用戶提示細節的微妙方式。

    Prefix 緩存信息泄露

    前綴緩存通過重復使用之前計算的內部狀態來縮短 LLM 響應時間。在多個用戶共享同一緩存的多租戶環境中,這種優化可能會引入基于時間的信息泄露。

    如果兩個提示共用一個長前綴,模型可以跳過重新計算這些初始共享令牌,從而加快第二個請求的速度。通過精心制作輸入和測量響應延遲,攻擊者可能會推斷其提示的初始部分是先前看到的,這可能會泄露其他用戶查詢的詳細信息。最近的研究已經探索了這種風險,該研究展示了 KV 緩存重用如何充當秘密信號,僅基于響應時間差泄露信息。有關詳細信息,請參閱 Auditing Prompt Caching in Language Model APIs

    示例:Inferring 位置和日期

    回到旅行助手示例,假設 User A 發送以下提示:

    Build me a vacation itinerary for Orlando in August.

    后來,攻擊者用戶 B 通過發出類似的查詢和測量響應時間來探測系統:

    • “為我制定一份 6 月亞特蘭大的假期行程。”
    • “為我制定 6 月的奧蘭多度假行程。” (由于用戶 A 為“Build me a vacation itinerary for 奧蘭多”緩存了 KVs,因此速度更快。)
    • “請為我安排 7 月去 Orlando 的假期行程。”
    • “為我制定 8 月的奧蘭多度假行程。” (由于用戶 A 緩存了 KVs,因此速度更快。)

    如果最終變體的返回速度明顯更快,則表明由于用戶 A 的請求,該確切措辭的緩存 KV 前綴已經存在。有了足夠的排列組合,攻擊者就可以推理原始查詢的內容,即使他們從未直接看到原始查詢。

    風險不僅限于用戶提示

    風險并不僅限于用戶輸入的查詢。許多 LLM 應用會動態地將數據附加到檢索到的文檔或工具輸出的提示中。這些增加雖然不受用戶直接控制,但仍然可以通過時間差異觀察到。

    例如,用戶 B 發送:

    Build me a vacation itinerary for Orlando in August.\nToday’s date is February 28th.

    以及

    Build me a vacation itinerary for Orlando in August.\nToday’s date is March 1st.

    如果只有第二個查詢導致緩存命中,用戶 B 可以推斷其他用戶 何時 提交了請求,即使日期是由應用程序附加的,而不是由用戶提供。用戶 B 的查詢隨后是否會由工具連接真實日期無關緊要;該信息不會影響前綴緩存的獲取。

    在基于用戶身份或基于角色的訪問控制獲取信息的應用程序環境中,這可能會泄露應用程序端敏感或特權系統級數據,而不僅僅是用戶輸入的數據。

    緩存配置如何影響可利用性

    攻擊者可以通過將此時序側信道與有關如何配置緩存的知識相結合,進一步利用該時序側信道。每個系統都必須決定為 KV 緩存分配多少存儲空間,而且大多數實現都使用 Least Recently Used (LRU) 驅逐策略。緩存不會在固定時間內保留條目,而是會保留一個固定大小的緩沖區,僅保留最近訪問的條目。隨著新條目的添加,使用較少的舊條目將被逐出。

    此配置為攻擊者控制和測量系統狀態提供了額外的上下文。例如,通過探測哪些輸入仍會導致緩存命中,攻擊者可能會推斷出給定提示 (或前綴) 的使用時間或訪問頻率。這可以被動完成,也可以通過主動操作來啟動或刷新緩存。

    從計時測量中提取有意義的信號并非易事。LLM 系統的實際性能受多個可變性來源的影響,包括:

    • 網絡延遲:可能會引入與緩存行為無關的噪聲。
    • 批處理:將多個請求分組在一起,以更大限度地提高吞吐量。批處理引入了不確定性,因為單個請求可能會在等待批量填充時延遲,從而模糊細微的延遲差異。
    • 工具和插件交互,在提示處理期間可能會調用外部 API 調用。這些調用的響應時間可能會因系統負載、數據復雜性或網絡條件而異。

    所有這些因素都使得很難確切地確定響應是否受益于 cache hit。不過,在合適的條件下,尤其是在較短、無需工具的提示或低流量環境中,timing signals 可能足夠強大,足以推理出有用的信息。

    設計更安全的系統

    前綴緩存帶來的風險直接產生于在生產環境中構建和使用 prompts 的方式。幸運的是,developers 可以在不犧牲性能的情況下采取切實可行的措施來降低曝光率。

    提示結構很重要

    最有效的方法之一是有意識地確定提示的組裝方式。通過串聯動態生成應用程序提示時,請考慮使用以下順序來更大限度地降低風險:

    1. 系統提示
    2. 唯一用戶或會話標識符
    3. 來自工具、插件或數據存儲的 Augmentation context
    4. 用戶提示 (sanitized 和 validated)

    結構化提示以減少跨用戶碰撞

    前綴緩存的工作原理是識別共享前綴,因此用戶提示之間的重疊越多,泄露的風險就越大。一種簡單的緩解措施是通過在提示詞的早期添加不可猜測的用戶特定標識符來分解用戶之間的常見前綴。

    例如:

    <system>
    You are a helpful travel assistant.
    <session> Session-ID: 2f3e1a...
    <context> ...
    <user> Build me a vacation itinerary for Orlando in August.

    這不一定是一個 secret token,但它應該是匿名的 (無法識別個人身份) ,難以猜測或難以強制,并定期旋轉。在提示詞的早期添加此功能會強制用戶之間進行緩存分離,從而顯著降低信息泄露的幾率。

    限制和驗證用戶控制的輸入

    開發者還應注意驗證和清理用戶輸入,然后再將其整合到提示中。這在基于用戶查詢獲取文檔、日期或上下文的 RAG 系統或應用中尤其如此。如果可能:

    • 設置最大長度以防止溢出攻擊。
    • 在用戶輸入之前放置工具增強上下文,以避免其被擠出模型的上下文窗口。
    • 避免在多個提示組件中不必要地重復用戶輸入。

    這些技術是更廣泛的提示強化策略的一部分。如果您希望獲得這些類型的對抗行為和防御的實踐經驗,請查看 探索對抗機器學習 NVIDIA 深度學習培訓中心課程。

    考慮 cache 分區或隔離

    如果基礎設施允許,請考慮在租戶之間完全隔離 KV 緩存。這可能意味著:

    • 按會話或租戶 ID 進行分區
    • 每個租戶使用不同的 cache keys
    • 在高風險環境中禁用 Prefix caching

    雖然這可能會降低一些性能優勢,但在受監管或敏感的環境中,這可能是一個值得權衡的問題。

    用于基于 Timing 的枚舉的 Monitor

    即使采取了緩解措施,也應監控系統是否存在可疑模式,這些模式表明存在列舉嘗試,例如細微變化的重復查詢、大量近乎重復的提示或延遲敏感探測。將速率限制與異常檢測配對有助于標記潛在的濫用情況。

    總結

    前綴緩存重用可為 LLM 應用帶來顯著的性能提升,但在共享環境中,這也會帶來細微的信息泄露風險。當從用戶輸入、工具輸出和上下文數據中動態組合提示時,該提示的結構是影響性能和安全性的設計選擇。

    共享緩存的緩存重用可能會讓堅定的攻擊者通過時間側信道推斷其他用戶的部分提示。當應用程序包含受用戶影響的敏感上下文或依賴身份的上下文時,這種披露的影響就會放大。

    通過隔離緩存使用情況、仔細構建提示詞并仔細驗證輸入,開發者可以在保持性能的同時降低風險。如需親身體驗這些威脅和相關威脅,請 探索 NVIDIA 深度學習培訓中心 (Deep Learning Institute) 課程 。要更深入地了解 AI 系統在現實世界中的紅色團隊見解和技術,請查看 相關的 NVIDIA 技術博客文章

    ?

    0

    標簽

    人人超碰97caoporen国产