跳到正文
原文
arXiv· arXiv:2608.25431· Jiacheng Shi, Xunjie Wang, Cheng Tan, Jinyu Gu·本站收录· 原文发表

GIFT：通过 GPU 信息流追踪在 LLM 服务中实现用户数据隔离

Here is a GIFT: Enforcing User Data Isolation in LLM Serving via GPU Information Flow Tracking

论文速读

防御

据论文 PDF 整理（AI 生成），以原文为准

GIFT用加密与GPU信息流跟踪，在vLLM/DistServe隔离用户数据；A800上vLLM吞吐开销至多4.1%。

威胁模型GIFT不信任serving框架，信任OS、hypervisor及VM隔离和monitor。

问题
LLM serving在共享设施上处理敏感用户数据。框架漏洞或GPU内confused-deputy可能跨用户泄露KV cache，传统IFT又难适配快速演化的多语言代码。
方法
框架只处理按用户密钥加密的数据。monitor独占GPU，用离线kernel规则在CPU上更新所有权，混合则拒绝启动；回传前再加密。GIFT-CC把monitor与GPU计算放进TEE，以对抗不可信的OS和hypervisor。
实验与结果
作者在A800上报告GIFT相对未改框架的吞吐开销至多4.1%（vLLM）和2.3%（DistServe）。H100上GIFT-CC在推测解码中相对Baseline的吞吐开销至多10.7%；安全章节是机制分析，没有成功率表。
局限与可以继续做的
作者在§6写了三条局限：CPU不改数据内容，否则操作须交给monitor；无法预先分析的kernel只能黑盒近似，可能牺牲soundness；规则生成半自动。结果只给出Qwen2.5与OPT的若干配置，未报告样本量与重复次数。
实验设置Qwen2.5-14B、Qwen2.5-32B 等 · ShareGPT、HumanEval 等 · TTFT、TPOT 等
威胁模型
GIFT不信任serving框架，信任OS、hypervisor及VM隔离和monitor。攻击者可经RCE或confused-deputy在GPU内混用他人数据。GIFT-CC另不信任OS/hypervisor，对抗内存检查、DMA与cold boot。侧信道、DoS、结果完整性在范围外。
被测模型
Qwen2.5-14BQwen2.5-32BQwen2.5-72BOPT-13BOPT-30BOPT-66B
基准
ShareGPTHumanEvalLongBench
指标
TTFTTPOTthroughputmaximum request rate under latency SLO
AI 导读论文提出 GIFT，一个 GPU 信息流追踪系统，用于在 LLM 服务中强制用户数据隔离，已在 vLLM 和 DistServe 上实现，吞吐开销为 4-10.7%，延迟保持不变。设计基于两点：CPU 组件只编排数据流而不处理内容，因此按用户加密即可实现隔离，无需修改服务逻辑；GPU kernel 的信息流有限且可预测，可做静态流分析。GIFT 为每个 kernel 预计算信息流规则并采用解耦的流追踪，避免插桩和 GPU 停顿。其扩展 GIFT-CC 集成机密计算，用于防御不可信的操作系统与 hypervisor（即 LLM 服务提供商）。

论文提出 GIFT，一个 GPU 信息流追踪系统，用于在 LLM 服务中强制用户数据隔离，已在 vLLM 和 DistServe 上实现，吞吐开销为 4-10.7%，延迟保持不变。设计基于两点：CPU 组件只编排数据流而不处理内容，因此按用户加密即可实现隔离，无需修改服务逻辑；GPU kernel 的信息流有限且可预测，可做静态流分析。GIFT 为每个 kernel 预计算信息流规则并采用解耦的流追踪，避免插桩和 GPU 停顿。其扩展 GIFT-CC 集成机密计算，用于防御不可信的操作系统与 hypervisor（即 LLM 服务提供商）。

深度解读

6个问题，点开问题读完整回答

  1. 这篇论文试图解决什么问题？

    共享 LLM serving 上，用户数据可能跨用户泄露，GIFT 用 GPU 信息流跟踪强制按用户隔离。

    共享 LLM serving 上，用户私有数据可能经框架漏洞或 GPU 内 confused-deputy 进入其他用户的响应。

    • 场景：作者称提示常含敏感信息，并举 2023 年 ChatGPT 因缓存 bug 出现跨用户记录泄露。CPU 只调度和发 kernel，GPU 做计算，KV cache 等主要在 GPU。
    • 不足：Table 1 中 vLLM 为 146K 行、31 个 CVE，PyTorch 为 2.4M 行、18 个 CVE。作者称这类多语言框架（vLLM 过去一年 7.5K commits）难以做传统 IFT，从业者也不会用慢 3× 的 GPU kernel。
    • 观察：CPU 不改数据内容，只负责放到正确 GPU 地址，故 CPU 内存可只存密文。serving 的 kernel 预先固定、分支少，信息流可离线写成规则。
    • 方案：作者提出 GIFT（按用户加密加解耦的 GPU 所有权跟踪）和 GIFT-CC（再加机密计算），实现于 vLLM 与 DistServe。
    • 威胁模型：
      • 目标：挡住他人读到提示、KV cache、中间 token 或输出。受害系统是共享的 LLM serving。
      • GIFT：外部攻击者与有 bug 的代码；框架不可信，可把一用户计算重定向到另一用户数据。作者用 CVE-2025-24357 做 confused-deputy 示例，并称另一用户的响应含第一用户的名字。
      • 信任边界：GIFT 信任 OS、hypervisor 及独立 VM 中的 monitor（Rust，5.6K 行）。GIFT-CC 不信任 OS/hypervisor，对抗可查 CPU 内存、DMA 读 GPU 或 cold boot 的特权管理员。
      • 范围外：侧信道、DoS、结果完整性。作者称用户能发现明显错误的输出。

  2. 有哪些相关研究？

    论文将本文放在 GPU 上的 IFT：相对指令级污点跟踪和整框架进 TCB 的方案，用加密边界与离线规则做隔离。

    论文按信息流跟踪、GPU kernel 分析、隐私保护的 LLM serving 来组织相关工作。

    信息流跟踪

    • CPU 上的 IFT：论文将其描述为运行时跟踪数据如何传播的通用方法，用于泄漏检测或识别异常行为，并引用一批 CPU 系统。
    • 另开线程：先前工作把跟踪卸载到单独的 CPU 线程。作者称 GIFT 的解耦跟踪与此相近，但是针对 GPU serving。
    • GPU taint tracking：论文引用的这项工作插桩 kernel 来监控显存数据流，应用性能变慢 2.5–5.7×。作者称 GIFT 针对 LLM serving 的 GPU IFT，并称运行时开销接近零。

    GPU kernel 分析

    • 已有分析：论文称已有静态或动态 kernel 分析，但都没有做 GPU IFT 所需的所有权跟踪。
    • POS 与 Honeycomb：分析 kernel 的内存访问，分别服务于容错或阻止非法访问。作者称 GIFT 构造的是信息流图，用来传播所有权。

    隐私保护的 LLM serving

    • 密码学方案：同态加密、多方计算、函数秘密共享和差分隐私。作者称性能开销大，模型改动可能影响精度，而且现有研究主要在较小模型（例如 7B）上评估。
    • TEE：论文列举把 AI 或 LLM 放进 TEE 的工作，并称近期 TEE 上的 LLM serving 性能可接近非机密基线。作者称 GIFT 与这些系统正交，组合后即 GIFT-CC。
    • Apple PCC：与 GIFT-CC 的安全目标相同，做法不同。作者称 PCC 绑定 Apple 的软硬件，用户需信任包括推理框架在内的整套设施，TCB 大于 GIFT-CC；GIFT-CC 更可移植。

    基线与基准

    • 基线：未修改的 vLLM 和 DistServe。评 GIFT-CC 时另设 Baseline-TEE，即在 NVIDIA-CC 中运行原框架。
    • 基准：ShareGPT（ChatGPT 对话）、HumanEval（编程任务）、LongBench（长文摘要）。

    作者把本文定位为 LLM serving 的 IFT：不在快速变化的框架里做指令级跟踪，而用加密边界加上离线 kernel 规则；并称这是该场景的首个此类设计。

  3. 论文如何解决这个问题？

    GIFT 让框架只处理密文，由 monitor 按离线 kernel 规则在 CPU 上跟踪 GPU 内存的单一用户所有权。

    GIFT 让不可信框架只处理密文；monitor 独占 GPU，启动 kernel 前用离线规则检查单一用户所有权，混合则拒绝。

    保护域与请求路径

    • 部署：monitor 位于受保护域并独占 GPU。OS 与 hypervisor 可信时，框架与 monitor 分处两个 VM；不可信时改为 TEE（GIFT-CC）。框架经共享内存通道调用被包装的 CUDA API。
    • 实现规模：monitor 为 Rust，5.6K 行，32 个接口，负责 kernel 登记/启动和内存拷贝/分配。每个 serving 框架改动少于 120 行，用于跟踪请求属主。
    • 初始化与请求：登记模型所需 kernel，未登记的拒绝启动；参数载入后标为 parameter 所有，用户密钥只留在 monitor。分词在用户设备完成，提示按用户密钥加密后上传。框架在密文上做控制面（概述写 continuous batching 与调度），启动 kernel 时附上批量输入的属主元数据。
    • 解密与回传：monitor 解密后把明文送入 GPU 并记下输入区域的属主。作者称属主元数据被篡改只会导致解密失败。交回框架前按属主重新加密。不变量是：含私有信息的每个内存字节只有一个属主。

    加密即隔离

    • 边界：CPU 内存中的用户数据都是密文，明文只在保护域和 GPU 内。作者的理由是 CPU 不改语义，只编排计算和搬移，因此框架可以把密文当普通数据调度，演化时不必改 GIFT 的隔离逻辑。
    • 密钥与 label：每用户一把对称密钥，仅用户和 monitor 持有。文中的 ownership 即经典 IFT 的 label，用来区分用户，而不是只分敏感与非敏感。

    GPU 上的三段跟踪

    • 分段：同一属主的数据通常在连续显存段里，记录做到段。Figure 3 的加 bias 再 ReLU 的 kernel，逐元素是 B×H 条记录，分段后一块输入或输出矩阵是 B 条。KV cache 记到 block 切片，论文举例为五维张量上的 C[1,2,:,0:8,:]。
    • 记录：每个 GPU 一套记录，存在 monitor 内。两级索引：基址到 tensor 记录（基址、形状、元素大小、与所有权有关的维度），再由下标到用户 ID 或参数专用 ID。cudaMalloc 得到的块被看作 n 维 tensor。未记录区域禁止读；释放时清空记录。
    • 规则从哪来：开发者根据良性推理手工做信息流图（IFG），节点是单用户的显存段。Figure 6 给出 AddResidual、AddBias、FindMax、MatrixMultiply。CUDA 转到 C++ 后用 KLEE 做符号执行，确认没有 IFG 以外的流，再生成规则。运行时按参数基址找 tensor、核对形状、检查非预期别名和参数属主，再把同一源属主写到目标节点。
    • 何时拒绝：框架请求启动 kernel 时，monitor 先按规则和参数做跟踪。没有跨用户混合才启动，否则拒绝。Figure 3 的例子里，逐指令方案是每元素 7 条插桩；规则把运行时操作收到检查 bias、读输入行属主、写输出行，次数从 7×B×H 降到 2×B+1。
    • 与 GPU 重叠：跟踪在 CPU 上、不等待 kernel 结束，以便叠在已启动的 kernel 后面（Figure 4）。作者称两边都顺序执行，所以某次跟踪看到的所有权与对应 kernel 看到的显存一致；数据出 GPU 前会等待 device-to-host 拷贝，选密钥时两边对齐。

    多流、token 与 KV cache

    • 多流：框架用多条 GPU stream，例如后台换 KV、主 stream 计算。monitor 为每条 stream 配 CPU 线程。记录还保存该段最后的写入 kernel 与读取 kernel（stream ID 和流内序号），以及每条流最后完成的 kernel。完成的判定是：在 cudaMemcpy 或 cudaStreamSynchronize 之前启动。跨流读-写或写-写时，对方必须已完成。集合通信按 Figure 7 的顺序放行。
    • token：按 token 做分组密码，因为框架要追加新 token 或把提示切块。64 位 token 追加随机 nonce 后成为 128 位再加密，避免相同 token 密文相同；解密时去掉 nonce。结束符有单独密文，用来通知生成完成。
    • 交换与缓存：KV 换出到框架内存就必须加密。作者以 OPT-13B 每 token 400 KB 为例。monitor 改在自己的受保护内存提供交换空间，并在换回 GPU 时恢复属主。注意力等 kernel 用的 index table 在 monitor 内存留一份，避免跟踪时从 GPU 回拷并堵住流水线。
    • 规则库：作者建了 29 个 kernel family（§6；§4.3 称 29 个常用算子）的规则，并称可跨模型与框架复用。抽取 IFG 和翻译 CUDA 仍要人工。

    GIFT-CC

    • 放置：monitor 在 CVM 中，独占支持 TEE 的 GPU，计算在 TEE 内。用户用远程证明确认机密计算开启后，再与 monitor 建安全通道。
    • 出域即密文：域外只见密文。CVM 与 GPU 经加密 PCIe 通信，作者称由此独占 GPU 并阻止物理攻击；拷贝 token 和 KV 时多一层加解密。

  4. 论文做了哪些实验？

    在 vLLM 与 DistServe 上，作者报告 GIFT 吞吐开销至多 4.1%，GIFT-CC 推测解码至多 10.7%。

    性能数字来自 §7 正文；Figure 8–14 的逐点秒数和 tokens/s 在文本中没有读数。

    实验设置

    • 框架与形态：未改的 vLLM、DistServe 为 baseline。GIFT、GIFT-CC 各接在这两个框架上。GIFT-CC 的对照 Baseline-TEE 是把原框架放进带 NVIDIA-CC 的 TEE。
    • 模型：正文展示 vLLM 上的 Qwen2.5-14B、32B、72B，DistServe 上的 OPT-13B、30B、66B。作者称其他模型结果相似，但未给出那些数字。实现节列出库可支持 Llama-3、Gemma-2、GPT-2、Phi-3，实验节没有单独报告它们。
    • 特性与基准：实验设置写 contiguous batching、paged attention、pipeline/tensor parallelism；vLLM 另开 chunked prefill；DistServe 另开 prefill-decoding disaggregation。基准为 ShareGPT、HumanEval、LongBench。论文未写样本量。
    • 机器：8 块 NVLINK 连接的 A800，Xeon Platinum 3.4 GHz；1 块 H100，Xeon Gold 3.5 GHz。Baseline-TEE 只在 H100，论文写 A800 不支持 NVIDIA-CC。H100 上 DistServe 的 prefill 与 decoding 被改到同一 GPU。OPT-66B 与 Qwen2.5-72B 的 GIFT-CC 未评测。
    • 指标：TTFT、TPOT、吞吐（tokens/s），以及相同延迟 SLO 下的最大请求率。论文未写 SLO 的具体阈值，也未写重复次数。
    • 推测解码：H100、vLLM、Qwen2.5，组合为 14B+0.5B、32B+0.5B、14B+1.5B、32B+1.5B（Figure 11）。论文未给出 0.5B 与 1.5B 的完整模型名。

    主结果

    表格较宽，可左右滑动

    系统条件对比指标上限出处
    GIFTA800，ShareGPTbaseline同 SLO 最大请求率5%§7.1.1，Fig 8
    GIFT，vLLMA800baseline吞吐4.1%§7.1.1，Fig 9
    GIFT，DistServeA800baseline吞吐2.3%§7.1.1，Fig 9
    GIFT-CCH100，ShareGPTBaseline同 SLO 最大请求率7%§7.1.2，Fig 8
    GIFT-CC，DistServeH100Baseline吞吐6.7%§7.1.2，Fig 10
    GIFT-CC，vLLMH100Baseline吞吐3.2%§7.1.2，Fig 10
    GIFT-CC，推测解码H100，vLLMBaseline吞吐10.7%Fig 11
    • 相对 TEE 基线：相对 Baseline-TEE，ShareGPT 上同 SLO 最大请求率开销至多 4%（§7.1.2）；吞吐至多 2.4%（DistServe）和 1.7%（vLLM）；推测解码至多 2.1%（Figure 11）。作者称相对非机密基线的额外开销主要来自 NVIDIA-CC 的 CPU–GPU 通信。
    • 作者对 GIFT 开销的解释：解耦跟踪把 IFT 叠在 GPU 计算之后；monitor 内存够用时不为换出的 KV 加密；token 加密不到单请求服务时间的 1%；API 重定向不到 0.5%。
    • 口径：摘要写吞吐开销 4∼10.7% 且延迟水平相同。引言写饱和负载下吞吐至多降 5%，GIFT-CC 相对非机密基线至多 7%。§7 把 5% 和 7% 记在相同延迟 SLO 的最大请求率上。作者称其他基准的该类开销与 ShareGPT 相似，但未给单独数字。正文没有 Figure 8 各点的 TTFT/TPOT 秒数。

    IFT 相对 kernel 时间

    • Figure 12：DistServe、ShareGPT、OPT-13B、A800。图中 kernel 包括 MatrixMultiply、AddBiasActivation、Embedding、LayerNorm、PrefillStageAttention、DecodingStageAttention、FindMax 等。作者称每个 kernel 的 IFT 时间都低于执行时间（纵轴为对数），并称 DecodingStageAttention 的 IFT 可叠在先前的 MatrixMultiply 执行中。文本没有毫秒读数。
    • Figure 13：参数规模变大时执行时间上升，IFT 时间不变；作者的理由是一段 hidden state 或一个 KV block 的属主可一次读写。DecodingStageAttention 在参数规模小于 2,048 时，IFT 时间超过执行时间。作者称可用多线程 IFT 再降，并标为 future work。
    • Figure 14：OPT-13B、A800；图例有 batch 8、16、32，上下文长度轴标有 250、500、750、1000。prefill 的 MatrixMultiply 执行时间随 batch 或上下文增加，IFT 主要随 batch。作者称 DecodingStageAttention 的 IFT 最长，但在所测输入规模上仍低于执行时间，且涨得比执行时间慢。

    三项优化

    §7.3 的设置是 DistServe、ShareGPT、OPT-13B、1×A800。

    • 细粒度并发：避免可能竞争时只留一条 stream。作者报告 GIFT 吞吐提高 12%。
    • 安全交换空间：不用时相对 Baseline 吞吐降低 11%；用后开销降到 1.9%。
    • 缓存 index table：四个使用 index table 的 kernel（含 DecodingStageAttention）不再在跟踪时从 GPU 回读。作者报告吞吐提高 50%。

    安全机制分析

    §8 没有攻击成功率或重复次数，是作者的机制分析。

    • 直接读取：作者分析称 CPU 内存只有密文；读 monitor 或 GPU 明文会被 VM 隔离（GIFT）或 TEE 边界（GIFT-CC）挡住。
    • confused-deputy：按 IFT 规则拒绝混合不同用户数据的 kernel；即使用一串 kernel 在显存里搬运，写出时仍按属主选密钥。
    • 物理攻击与 TCB：GIFT-CC 依赖 NVIDIA-CC 的内存加密、抗常见物理工具的 HBM，以及加密的 PCIe 与 NVLINK。TCB 含 TEE 硬件、1M 行精简 Linux、CUDA runtime（行数未知）、CUDA driver 1.4M 行、monitor 5.6K 行。作者称排除了 vLLM 及其依赖 3.6M 行，以及估计超过 30M 行的宿主机与云设施；相对标准 NVIDIA-CC 模型只多约 5.6K 行 Rust。无 TEE 时当前实现用 vanilla KVM，TCB 还包括 hypervisor。

    其他消融与分析

    • 全部 A800 与 H100 设置下，额外 CPU 低于 124%（1.24 cores），内存低于 130 MB（§7.2.3）。
    • token 加密不到单请求服务时间的 1%，API 重定向不到 0.5%（§7.1.1）。
    • 高请求率下 DistServe 的 GIFT 与 baseline 都会换出 KV，因为 GPU 放不下 decoding batch 的全部 KV（§7.1.1）。
    • H100 上 OPT-66B 与 Qwen2.5-72B 的 GIFT-CC 未评测，论文写 GPU 不足（§7）。
    • 唯一一块 H100 上，DistServe 的 prefill 与 decoding 被改到同一 GPU（§7）。

  5. 有什么可以进一步探索的点？

    作者列出三条局限：CPU 不改数据的假设、无法预先分析的 kernel，以及 IFT 规则仍须人工参与。

    作者指出的局限与后续方向

    • CPU 不改内容：设计假设 CPU 侧框架不修改用户数据内容。作者写明，若该假设不成立，就要改框架，把这类操作委托给 monitor（§6 Limitations）。
    • 无法预先分析的 kernel：部分 kernel 因技术限制或法律限制不能提前分析。作者写明，此时须用黑盒采样得到近似 IFT 规则，可能牺牲 soundness（§6）。
    • 规则生成半自动：作者写明，原因是没有完整的 CUDA 符号执行器，也没有完备的 CUDA 到 C++ 转译器（§6）。

    实验覆盖范围

    • 系统：GIFT 与 GIFT-CC 都实现在 vLLM 和 DistServe 上（§6–§7）。
    • 负载：正文给出结果的模型是 vLLM 上的 Qwen2.5-14B、32B、72B，以及 DistServe 上的 OPT-13B、30B、66B；基准为 ShareGPT、HumanEval、LongBench。推测解码在 H100 的 vLLM 上使用 14B+0.5B、32B+0.5B、14B+1.5B、32B+1.5B（Figure 11）。
    • 平台：8×A800（NVLINK，Xeon Platinum 3.4 GHz）与 1×H100（Xeon Gold 3.5 GHz）。Baseline-TEE 只在 H100；论文写 A800 不支持 NVIDIA-CC。OPT-66B 与 Qwen2.5-72B 的 GIFT-CC 未在 H100 上评测。
    • 论文未报告：各基准样本量、重复次数、延迟 SLO 的具体阈值，以及 Figure 8–14 的逐点秒数或 tokens/s。§8 是机制分析，没有攻击成功或失败的计数。
    • 规则与论证范围：IFT 规则库为 29 个 kernel family。§2.4 将侧信道、DoS 和结果完整性列为范围外。§7.3 的优化数字来自 DistServe、ShareGPT、OPT-13B、1×A800。

  6. 总结一下论文的主要内容

    GIFT 以加密隔离加 GPU 信息流规则，在 vLLM 与 DistServe 上强制用户数据隔离，并报告了吞吐开销。

    GIFT 是作者为共享 LLM serving 做的用户数据隔离系统，并有启用机密计算的 GIFT-CC。作者在结论中称它是该场景的首个 IFT 设计。

    • 问题：框架在 CPU 上调度、在 GPU 上计算。作者认为漏洞和 GPU 内 confused-deputy 可以不触发传统主机防护，就把一人的 KV cache 等数据写进他人响应。
    • 方法：CPU 内存只留按用户密钥加密的数据。独立 monitor 独占 GPU，启动 kernel 前用离线信息流规则检查单一所有权，禁止跨用户混合，回传前再加密。GIFT-CC 把 monitor 和 GPU 放进 TEE，不信任 OS 与 hypervisor。
    • A800 上的 GIFT：相对未改框架，吞吐开销至多 4.1%（vLLM）和 2.3%（DistServe，§7.1.1）。相同延迟 SLO 下，ShareGPT 的最大请求率开销至多 5%。
    • H100 上的 GIFT-CC：相对非机密基线，吞吐开销至多 6.7%（DistServe）和 3.2%（vLLM）；推测解码至多 10.7%（Figure 11）。作者称相对 Baseline-TEE，吞吐至多 2.4%（DistServe）和 1.7%（vLLM），推测解码至多 2.1%。
    • 作者的结论：加密边界让 serving 框架可以继续演化；所有权分段、静态规则和解耦跟踪使 GPU 侧跟踪能与 kernel 执行重叠。摘要称延迟水平相同，§7 未给出 TTFT/TPOT 的逐点秒数。§6 写明该设计依赖 CPU 不改用户数据、kernel 可预先分析，且规则生成仍是半自动的。
阅读原文arxiv.org