💻 computer science

OTRO: Oblivious Tokenization Path with Square-Root ORAM

OTRO 是一个高效、不透明的标记化系统，专为机密大语言模型（LLM）推理服务设计，通过利用具有基于纪元旋转和分块 KV 缓存感知重叠的平方根级 ORAM 实例池，在显著减少可观测泄漏的同时，实现了近乎零的延迟开销，从而缓解了来自内存访问模式的侧信道泄漏。

原作者： Jonghyun Lee, Yongqin Wang, Rachit Rajat, Daniel Wong, Mengyuan Li, Murali Annavaram

发布于 2026-06-17

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Jonghyun Lee, Yongqin Wang, Rachit Rajat, Daniel Wong, Mengyuan Li, Murali Annavaram

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正通过一个高度安全的、全玻璃墙结构的邮局，向你的朋友发送一封秘密信件。这个邮局由一个“可信执行环境”（TEE）运行，它就像一个超级安全的保险库，你的信被锁在一个保险箱里，连邮局经理也无法打开。他们无法读出信中的文字。

问题所在：“标记”（Token）翻译员
在你的信件被处理之前，它必须被翻译成计算机能理解的代码。这个过程是由一个叫做“分词器”（Tokenizer）的工具完成的。把分词器想象成一个翻译员，他会在一本巨大的、固定的字典中查找你信中的每一个单词，从而找到它们对应的秘密代码数字。

但问题在于：即便信件的内容被锁在保险箱里，翻译员手指移动的模式仍然是可见的。

如果你写“The cat”，翻译员会查找“The”，然后查找“cat”。
如果你写“The dog”，翻译员会查找“The”，然后查找“dog”。

一个狡猾的间谍（比如恶意的云服务器管理员）通过观察翻译员的手指动作，就能看清他在查阅字典的哪些页面。通过观察这些“查找”的顺序和频率，间谍就能重构出你原本的信件内容，即便他们从未直接看到那些单词。这被称为侧信道攻击。

旧的解决方案：PathORAM 的“洗牌”法
为了阻止间谍，研究人员之前尝试使用一种叫做 PathORAM 的方法。想象这是一个神奇的图书馆，每当你索要一本书时，管理员不仅会把书取出来，还会把整个图书馆里的每一本书都随机移动到一个新的位置。这使得人们无法判断你到底想要哪本书。

结果： 这确实完美地解决了安全性问题，但它极其缓慢。这就像是你每问一本书，都要等管理员重新整理整个大楼，这会导致巨大的延迟，让你在 AI 开始说话之前就得等待很久。在论文中，这种方法让系统变慢了 13 倍，造成了严重的延迟。

新的解决方案：OTRO（“旋转图书馆”系统）
本文的作者开发了 OTRO，他们意识到翻译员使用的字典是永远不会改变的。单词始终是那些单词，改变的只是间谍观察它们的顺序。

他们利用三个聪明的技巧构建了一个更智能的系统：

相同的图书馆池： OTRO 没有创建一个需要不断洗牌的单一图书馆，而是创建了一个相同图书馆的池子。想象一下你有 50 本完全一样的字典副本。
“切换”系统： 当翻译员需要查找单词时，他们会使用“图书馆 #1”。一旦“图书馆 #1”被使用了特定次数（例如 1,000 次查找），翻译员就会悄悄地切换到“图书馆 #2”。
- 其中的奥秘： 当翻译员忙于使用“图书馆 #2”时，一个后台工作者正在阴影中默默且缓慢地重新整理“图书馆 #1”。因为工作者是在翻译员处理下一个图书馆的过程中同步进行的，所以重新整理的工作永远不会拖慢翻译员的速度。
信件切块： 对于很长的信件，OTRO 会将信件拆分成小块。它在 GPU（AI 的大脑）开始思考第一块内容的同时，就开始翻译下一块内容。这使得“重新整理”的工作可以在后台进行，而不会中断主进程。

结果

速度： 由于沉重的“重新整理”工作是在后台进行的，该系统的速度几乎与最初不安全的版本一样快。论文显示，它仅使速度降低了约 4.5%，这几乎察觉不到。
安全性： 间谍无法再看到具体查找了哪些单词。他们能看到的仅仅是“发生了一次查找”。间谍唯一仍能猜测到的只有你的信件有多长（因为更长的信件需要更多的查找次数），但他们无法猜出信件的具体内容。
内存： 它使用了一点额外的内存（每个用户不到 0.5 GB），但这对于保护你的秘密来说是一个微小的代价。

总结
OTRO 就像是雇佣了一支轮班制的翻译团队。当一名翻译员在工作时，另一名则在后台悄悄地整理书籍。这样一来，盯着门口看的间谍就无法分辨人们挑的是哪本书，同时工作也能几乎瞬间完成。它将一个曾让系统变慢 13 倍的安全问题，变成了一个近乎即时的解决方案。

技术摘要：OTRO – 基于平方根 ORAM 的不透明分词路径

1. 问题陈述

本文指出，机密大语言模型（LLM）推理服务中存在一个关键的安全漏洞：分词器（Tokenizer）。虽然可信执行环境（TEE，如 Intel TDX 和 NVIDIA GPU TEE）可以保护内存内容和计算过程，但它们并不能本质上隐藏内存访问模式。

漏洞： 现代 LLM 使用字节对编码（BPE）分词器，该技术依赖于确定性的、基于表的查找（词表和合并表）将原始文本转换为 Token ID。由于从 Token 到内存地址的映射在初始化后是固ب定的，控制着超视距监控程序（Hypervisor）或拥有服务器物理访问权限的攻击者可以观察到 DRAM 的访问模式（通过页错误或缓存侧信道）。
后果： 最近的研究（TDXRay）表明，这些访问模式允许实现用户提示词（Prompt）的端到端重建，相似度超过 90%，从而有效地绕过了 TEE 的保护。
缓解挑战： 标准的义务内存（Oblivious RAM, ORAM）解决方案（如 PathORAM）会引入极高的延迟。朴素集成 PathORAM 会使首字时间（TTFT）增加约 13 倍，而朴素的平方根 ORAM（SqrtORAM）由于每 $\sqrt{N}$ 次访问就会发生昂贵的 $O(N \log^2 N)$ 重建成本，会导致 TTFT 增加约 323 倍。这些开销对于延迟敏感的 LLM 推理而言是不可接受的。

2. 方法论：OTRO 架构

作者提出了 OTRO（Oblivious Tokenization Path，不透明分词路径），这是一种专为 LLM 服务量身定制的高效、不透明分词路径。其核心洞察在于分词器表在推理过程中是只读的。这一特性使得 OTRO 能够将昂贵的重建操作与关键的访问路径解耦。

OTRO 通过以下三个关键创新来实现这一目标：

A. 池化 SqrtORAM 复制（Pooled SqrtORAM Replication）

不同于必须在 $\sqrt{N}$ 次访问后进行重建的单个 SqrtORAM 实例，OTRO 维护了一个由复制的、只读的 SqrtORAM 实例组成的池。

每个实例持有相同的词汇表和合并数据，但具有不同的随机排列。
由于数据是只读的，实例之间不需要协调更新；它们只需要进行重洗（Reshuffle）以维持不透明性。
当一个实例正在进行重建时，其他实例可以继续处理请求。

B. 基于 Epoch 的轮转与填充（Epoch-Based Rotation and Padding）

OTRO 实现了一种基于 Epoch 的轮转策略来管理该池：

轮转（Rotation）： 每个实例正好服务 $\sqrt{N}$ 次访问（一个 Epoch）。一旦达到限制，该实例将被标记为异步后台重建，系统随即轮转到新的实例。
填充（Padding）： 为了防止每个 Epoch 内的确切访问次数泄露信息，OTRO 在每个 Epoch 中填充了虚拟访问（Dummy Accesses），使其达到 $\sqrt{N}$ 的边界。这确保了可观测的记录仅揭示 Epoch 计数（即粗略的访问计数），而非精确的查找次数。
安全性： 实例的选择是全局访问计数的确定性函数，独立于所访问的具体逻辑地址，从而确保了访问模式的不可区分性。

C. 具备 KV 缓存感知能力的块状分词（Chunked Tokenization with KV-Cache Awareness）

为了最小化所需的池规模以避免停顿并隐藏重建延迟，OTRO 引入了块状分词（Chunked Tokenization）：

长输入提示词在预分词边界（以空格分隔的单词）处被拆分为较小的块。
块的分词过程与 GPU 的**预填充（Prefill）**阶段交织进行。
系统经过调优，使得 GPU 处理一个块所需的时间（ $T_{gpu, prefill}$ ）大于重建一个 SqrtORAM 实例所需的时间（ $T_{reshuffle}$ ）。
这种重叠使得重建可以在 GPU 计算的同时在后台进行，从而有效摊销了重建成本，并减少了所需的 SqrtORAM 实例数量。

D. 解码（Detokenization）

OTRO 也将 ORAM 保护应用于解码路径（将 Token ID 转换回文本）。由于解码阶段的性质（即 Token 生成速度较慢），一个小型池（例如 2 个实例）就足以与解码内核（Decode Kernels）重叠，从而隐藏延迟。

3. 核心贡献

成本特征化： 作者证明了虽然朴素的 ORAM 防御措施代价高昂（13×–323× 减速），但重建成本是主要的瓶颈。通过将重建从关键路径中移除，OTRO 的表现接近未受保护的基准线，开销极低。
不透明架构： 一种利用只读 SqrtORAM 实例池、基于 Epoch 的轮转以及访问计数填充的新型架构，消除了关键路径上的重建过程。
延迟感知集成： 通过将块状分词与 GPU 预填充及 KV 缓存机制相结合，实现了 CPU 端重建与 GPU 计算的重叠，最大限度地减少了内存占用和实例数量。
端到端原型： 在配备 NVIDIA H100 GPU 的 Intel Xeon Gold CPU 环境下，在支持 TDX 的机密虚拟机（CVM）中，将 OTRO 集成到 HuggingFace Tokenizers 和 nano-vLLM 中。
泄露减少： 形式化证明了 OTRO 的访问模式不会泄露任何关于所触及的特定表条目的信息。通过填充，唯一不可避免的泄露是输入提示词的长度（字节长度），这是任何实际 ORAM 设计中固有的。

4. 实验结果

该系统在 Llama-3.1、Qwen3、Gemma-3 和 Phi-3 模型上进行了评估，使用了 Intel Xeon Gold CPU 和 NVIDIA H100 GPU。

延迟 (TTFT)： OTRO 将 TTFT 的开销限制在最多 4.5%（相对于未受保护的基准线）。
- PathORAM 使 TTFT 增加了约 1.48×。
- 朴素 SqrtORAM 使 TTFT 增加了约 11.12×。
- 采用分块技术的 OTRO 表现接近“理想”的 SqrtORAM 场景（无重建惩罚），将分词器引起的延迟控制在总 TTFT 的 10% 以内。
内存开销： OTRO 为每个客户端增加的内存开销不到 0.5 GB（例如，Llama-3.1 配备 48 个实例时约为 286 MB）。这显著低于某些配置下 PathORAM 所需的开销，使得 256 GB 的 CVM 能够支持数十个并发客户端。
初始化： 初始化成本根据模型不同增加 35–350%，但由于这是每个模型加载时的单次成本，因此不被视为系统瓶颈。
泄露分析：
- 在没有 ORAM 的情况下，攻击者可以以接近 0 bit 的残余不确定性重建提示词。
- 使用 OTRO（无填充）时，残余不确定性为 1.60 bit。
- 使用 OTRO（带访问计数填充）时，残余不确定性上升至 5.49 bits，恢复了原始提示词熵的 38.4%。剩余的泄露主要源于输入字节长度与访问计数之间不可避免的相关性。

5. 重要性与主张

论文声称 OTRO 为生产级 LLM 服务栈提供了通往端到端机密性的可行路径。它解决了一个特定的、高保真的侧信道问题（分词器访问模式），该问题在标准的 TEE 保护下依然存在。

实用性： 不同于以往的理论性 ORAM 方案或针对不同威胁模型（如内存受限的 SGX）设计的方案，OTRO 专门针对现代支持 GPU 的 CVM 中具有延迟敏感性和只读特性的 LLM 分词过程进行了设计。
安全与性能的权衡： 该工作证明了实现强访问模式机密性（隐藏哪些 Token 被访问）且几乎不影响性能（<5% TTFT 开销）是可能的，而这种权衡在以前被认为是难以实现的。
范围： 作者明确指出，OTRO 保护的是分词器表的内存访问模式。它并不声称消除所有侧信道（例如来自特定代码模式的定时差异），也不保护输入长度泄露，这在实际的 ORAM 部署中被视为不可避免的基础情况。

总之，OTRO 通过复制和调度，将爆发式的、处于关键路径上的 SqrtORAM 重建成本转化为后台任务，从而在存在强大且拥有特权的对手的情况下，实现了安全且低延迟的 LLM 推理。