Nexus: 面向统一内存上代理型大语言模型的深度自适应KV缓存拼接与检索解耦的工具路由

# 面向统一内存上代理LLMs的深度自适应KV缓存拼接与检索解耦工具路由

来源：https://arxiv.org/html/2608.20397

###### 摘要

基于模型上下文协议（MCP）的代理大语言模型（LLMs）每轮都会重新编码冗长的工具模式，因此随着工具注册表的增长，预填充——其计算量随序列长度呈平方增长——主导了首token时间（TTFT）。Nexus的主要控制杠杆在于*将路由与模式预填充成本解耦*：一个带有校准交叉编码器阈值门的INT8语义查找缓冲区（SLB）通过检索选择工具，而参数则基于压缩的文本签名（约1919个token）生成，而非基于拼接的键值（KV）缓存。此路径与深度无关：当注册表扩展到250个工具时（此时连接所有模式的基线方法完全超出上下文窗口），路由准确率仍保持在约89%，并且在节省约80%主上下文token的情况下，其生成首个参数token的速度比完整的模式重新预填充快1.66倍。作为次要的、有界杠杆，我们直接将编译后的模式KV块移植到活动上下文中。这本质上受限于旋转位置嵌入（RoPE）的相位漂移：固定位置的拼接输出是精确的，但非固定位置的放置会破坏注意力，因此超过阈值P=256后，Nexus会用一种深度自适应的后缀重新解码来修复拼接缝，该修复会升级为完全重新预填充。由此产生的“永不回退”特性是对输出*保真度*（top-1一致性，DKL≈0）的保证——而非对延迟的保证，延迟在收敛至对等水平前可能降至0.98×——同时在中等深度下实现1.1–1.7×的TTFT加速，该加速在深度上下文中会缩小至对等水平。两个负面结果界定了设计范围：非固定位置的RoPE保真度边界，以及无参考漂移门无法预测漂移（Spearman ρ=0.193）失败。所有测量均来自Apple Silicon统一内存上的单一模型组合（Qwen2.5-14B-Instruct Q4_K_M）；*定性*边界具有普适性，而*定量*包络则特定于该模型组合。

## I 引言

工具增强的LLM代理越来越多地采用模型上下文协议（MCP）[1 (https://arxiv.org/html/2608.20397#bib.bib1)]进行标准化，向模型呈现一个可调用工具的注册表，每个工具都由冗长的JSON模式描述。当注册表扩展到数百个工具时，这些模式主导了提示词。由于自注意力的计算复杂度为O(N²)（N为序列长度）[2 (https://arxiv.org/html/2608.20397#bib.bib2)]，每轮重新编码工具模式会带来一个预填充墙，其扩展性随着可用工具数量和冗长度的增加而变差。

一个诱人的优化思路是将每个模式编译一次为一个KV块，并在推理时将其移植到活动上下文中，从而只支付一次预填充成本。我们发现，这本质上受限于旋转位置嵌入（RoPE）[3 (https://arxiv.org/html/2608.20397#bib.bib3)]的位置依赖性：为某一绝对位置编译的块无法在不破坏注意力的情况下任意移动到其他深度。先前的通过从不移动缓存来规避此问题（分页和前缀共享KV[4 (https://arxiv.org/html/2608.20397#bib.bib4), 5 (https://arxiv.org/html/2608.20397#bib.bib5)]将块保持在其计算时的位置）。Nexus则转而探究一个*重新定位*的模式块可以被信任到什么程度，以及修复它需要什么代价。

本文介绍了*Nexus*的设计、实现和实测包络，这是一个用于Apple Silicon统一内存（UMA）上代理工具使用的用户空间KV缓存服务原型。以下每个机制都锚定在代码库中的具体符号，每个数字都对应于结果/v2.0_canonical/下已提交的工件。我们做出四个贡献，按证据类别标记：

1. 1. 检索解耦路由（*实测*），这是更持久且可迁移的结果。工具选择通过带有校准交叉编码器门的INT8语义查找缓冲区（SLB）运行，而参数则基于压缩的文本签名生成，避免了拼接缝。它与深度无关，可扩展到250个工具（此时连接所有模式的基线方法无法运行），并在节省约80%token的情况下，实现首个参数延迟降低1.66倍的优势（§V (https://arxiv.org/html/2608.20397#S5), §VII (https://arxiv.org/html/2608.20397#S7)）。
2. 2. 具有永不回退保证的深度自适应重计算（*实测*），这是一个有界的、特性明确的次要杠杆。超过256个token的拼接阈值后，Nexus会重新解码一个与深度成比例增长至100%的后缀部分R(n_past)，保持输出保真度精确，并优雅地收敛到预填充对等水平（§IV (https://arxiv.org/html/2608.20397#S4), §VII (https://arxiv.org/html/2608.20397#S7)）。
3. 3. UMA的系统机制（*已实现*）：针对软注意力上限模型的转置V拼接，以及块分配器的缓存行硬化（§VI (https://arxiv.org/html/2608.20397#S6)）。
4. 4. 两个界定性的负面结果（*有充分支持*）：非固定位置的RoPE保真度边界和无参考漂移门控的失败（§IV (https://arxiv.org/html/2608.20397#S4)）。

我们明确了范围。所有基准测试均在一台配备64GB统一内存和1TB NVMe SSD的Apple M4 Max SoC（16核CPU，40核GPU，16核神经引擎）上执行，运行macOS/Darwin 25.5.0 (arm64)，使用git 1ce4aa4/llama.cpp cb2463bb。所有测量均使用Qwen2.5-14B-Instruct Q4_K_M模型，并搭配nomic-embed-text-v1.5。工件位于results/v2.0_canonical/下。转置V拼接机制还在第二个软注意力上限模型（Gemma-2-9B）上实现并通过了保真度测试；该Gemma保真度检查不在已提交的v2.0工件包内。物理拼接需要将数据直接复制到本地物理缓存地址，因此它仅在本地UMA驻留执行时运行；云端/远程API（仅接受文本token流）和独立GPU后端则完全回退到文本预填充（路径B，1.0×加速）。精确的架构边界在§VI-B (https://arxiv.org/html/2608.20397#S6.SS2)中详述。样本量较小（端到端路径n≤30），深层拼接是在保真度和延迟层面进行验证，而非作为多轮生产路径。我们将负面结果和实测包络视为持久贡献。

三个研究问题组织了本文。RQ1：在下一个token分布偏离完全预填充之前，一个重新定位的模式块可以被信任到什么程度（§IV (https://arxiv.org/html/2608.20397#S4)）？RQ2：修复该漂移在TTFT方面需要多少代价（§VII (https://arxiv.org/html/2608.20397#S7)）？RQ3：路由和参数生成能否完全避免拼接路径（§V (https://arxiv.org/html/2608.20397#S5), §VII (https://arxiv.org/html/2608.20397#S7)）？

*工件可用性。*每个报告的数字都可追溯到git 1ce4aa4（llama.cpp cb2463bb）下results/v2.0_canonical/中已提交的工件——唯一的例外是图1 (https://arxiv.org/html/2608.20397#S4.F1)中的放置偏移DKL扫描，该部分在5d43008重新生成——针对模型组合Qwen2.5-14B-Instruct Q4_K_M与nomic-embed-text-v1.5。该工件包可在发布前应作者要求获取；一个带有DOI的公共存档将在论文发表后添加。

## II 相关工作

*工具检索与模式压缩。* 应对模式膨胀的两个标准响应都作用于模型之前。检索增强工具选择——以RAG-MCP[6 (https://arxiv.org/html/2608.20397#bib.bib6)]为例——在预填充之前仅获取相关的MCP模式。模式级编译[7 (https://arxiv.org/html/2608.20397#bib.bib7)]和学习的潜在工具检索[8 (https://arxiv.org/html/2608.20397#bib.bib8)]在应用程序和嵌入层面缩减或替换工具描述，后者需要训练对齐。Nexus采用相同的检索原则来解耦路由，但增加了一个互补的系统级杠杆：对剩余模式进行直接KV移植，并使用基于冻结嵌入的零样本校准阈值门。我们在表I (https://arxiv.org/html/2608.20397#S2.T1)中将Nexus与RAG-MCP和原位KV服务系统进行了定位对比；因为那些数字是在不同硬件和工作负载上报告的，我们将其视为背景信息而非受控的直接对比，后者留给未来工作。

*服务的KV缓存管理。* 分页和前缀共享KV管理[4 (https://arxiv.org/html/2608.20397#bib.bib4), 5 (https://arxiv.org/html/2608.20397#bib.bib5)]以及动态虚拟内存方案[9 (https://arxiv.org/html/2608.20397#bib.bib9), 10 (https://arxiv.org/html/2608.20397#bib.bib10)]消除了碎片并*原位*重用缓存；它们不会将块移动到新位置，而这正是Nexus所描述的情景。RedKnot[11 (https://arxiv.org/html/2608.20397#bib.bib11)]将重用推进到单个注意力头的粒度，但保持缓存原位，而Nexus重新定位的是粗粒度的按工具划分的块。失败关闭的驻留KV声明降低[12 (https://arxiv.org/html/2608.20397#bib.bib12)]形式化了运行时何时可以将缓存的KV义务视为满足；Nexus的拼接器采取了相同的失败关闭立场，在离散GPU后端上拒绝转置V拼接，以避免损坏风险。预填充/解码分离和分块预填充[13 (https://arxiv.org/html/2608.20397#bib.bib13), 14 (https://arxiv.org/html/2608.20397#bib.bib14), 15 (https://arxiv.org/html/2608.20397#bib.bib15)]从调度层面攻击相同的预填充成本，是互补的。事务性推测性KV[16 (https://arxiv.org/html/2608.20397#bib.bib16)]同样区分了稳定的和瞬态的KV状态。

*RoPE、注意力内核和解码。* 通过频率插值进行上下文窗口扩展[17 (https://arxiv.org/html/2608.20397#bib.bib17)]与我们的重新锚定路径共享RoPE机制，但其目标是更长的上下文，而非缓存移植。FlashAttention[18 (https://arxiv.org/html/2608.20397#bib.bib18), 19 (https://arxiv.org/html/2608.20397#bib.bib19)]决定了V缓存的布局，这影响了我们转置V的处理方式。受约束解码[20 (https://arxiv.org/html/2608.20397#bib.bib20), 21 (https://arxiv.org/html/2608.20397#bib.bib21), 22 (https://arxiv.org/html/2608.20397#bib.bib22)]是用于参数生成的FSM/JSON掩码的基础。Nexus针对不同的情景——在统一内存下重新定位编译后的模式块——我们不对这些系统做出性能超越声明。SLB扫描机制和.atb页面对齐直接建立在Aeon v3[23 (https://arxiv.org/html/2608.20397#bib.bib23)]中引入的神经符号记忆基底（Memory Palace/Atlas索引、Trace DAG、SLB）之上，将其扩展到UMA下的直接、零拷贝物理缓存移植。

表I：Nexus所处背景。原位KV服务系统从不重新定位编译后的块；Nexus重新定位按工具划分的块，并将路由与拼接路径解耦。非Nexus数字是在不同硬件和工作负载上报告的（†：背景信息，*非*受控直接对比；参见results/comparison_sources.md）。
## III 背景与动机

### III-A 自注意力与模式预填充墙

对于长度为N、每维大小为d的序列，缩放点积注意力计算softmax(QKᵀ/√d)V，其中Q, K, V ∈ ℝ^{N×d}，每层的时间复杂度为O(N²d)，注意力内存占用为O(N²) [2 (https://arxiv.org/html/2608.20397#bib.bib2)]。这个表达式是定义性的，而非新的界限；我们引用它只是为了定位主要成本。在代理服务中，N = H + ∑S_k，其中H是对话历史，S_k是第k个工具模式的token长度。因为模式每轮都会重新编码，减少其预填充贡献是主要的控制杠杆，而两个标准基线——连接所有模式，或检索K个并预填充它们——都需要在线支付此成本。

### III-B RoPE相位漂移

RoPE通过按位置相关角度旋转查询/键特征对来注入位置信息[3 (https://arxiv.org/html/2608.20397#bib.bib3)]。对于特征对i，基础频率θ_i = b^{-2i/d}（运行时模型使用基数b=10^6），一个假设锚定位置m₀编译但在位置n_past使用的键会产生相位误差
Δθ_i = (n_past - m₀) θ_i. (1)
这是RoPE的定义性结果，并非§IV (https://arxiv.org/html/20397#S4)中发散值的经验预测器。因为注意力分数取决于查询和键之间的*相对*旋转，一个键携带错误绝对相位的移植块会被每个后续查询偏离轴心地读取。误差随放置偏移量(n_past - m₀)增长，并且在维度上不均匀（高频特征对漂移最快），因此预编译的模式块仅在其编译锚点的邻域内是忠实的。代码库使这一边界具体化：拼接器计算delta_pos = n_past - header->base_pos（在nexus_kv_splicer.cpp中），一旦n_past超过拼接上限max_splice_pos_=256（在nexus_orchestrator.cpp中；在Python代理中显示为MAX_SPLICE_POS），协调器就会拒绝裸拼接。

Nexus在拼接时通过*重新锚定*来抵消大部分误差：每个移植的键从其编译锚点m₀重新旋转到运行时位置n_past——这是公式(1)中偏移量Δθ_i的精确逆操作——这样后续查询就能轴心对齐地读取重新定位的块。重新锚定精确恢复了*相对*查询-键旋转，但该块的键和值是在不同的前序上下文中编译的，因此微小的残余发散在修正后依然存在。这个残余——而非公式(1)的原始漂移——是§IV (https://arxiv.org/html/20397#S4)所测量的（图1中约10^{-2}-nat的范围），也是下面深度自适应修复将其驱动至零的对象。这就是为什么非固定位置拼接只会*轻微*漂移而非灾难性漂移，以及为什么256个token的边界是修复起点而非硬性故障点。

### III-C 深度自适应重计算

Nexus不是将256视为硬性墙壁，而是通过重新解码拼接模式的尾部token来修复漂移，其比例随深度增长。令M=256为拼接阈值（max_splice_pos_），R_base=5%为基础重计算比例（recompute_pct_），K为M的倍数，此时重计算达到100%（recompute_full_mult_）。有效比例为
R(n_past) = \begin{cases} R_{\mathrm{base}}, & n_{\mathrm{past}} \leq M, \\[2.0pt] R_{\mathrm{base}} + \frac{n_{\mathrm{past}} - M}{M(K-1)} \bigl(100 - R_{\mathrm{base}}\bigr), & n_{\mathrm{past}} > M, \end{cases} (2)
并钳位至100%。这与代码中的eff_pct()完全匹配。在较深的位置，该比例接近100%，数值上即为完全的文本预填充（DKL(p₀ ∥ p_splice)=0...）