xMIx：面向机械可解释性应用的高性能服务时平台

# xMIx：面向机械可解释性应用的高性能服务运行时平台
来源：https://arxiv.org/html/2607.22595
###### 摘要

**MI** 已成为分析和干预推理计算的强大方法，其应用日益广泛，例如越狱尝试检测、真实性评估和幻觉检测。遗憾的是，当前在生成式模型服务系统中部署 MI 还不实际，因为大多数现有 MI 框架会引入过高运行时开销。根本问题在于 MI 函数无法与已部署的模型干净组合：它们使部署碎片化，常常强制排空请求并重建服务状态，并且与生产部署关键的性能优化（如连续批处理和 CUDA 图执行）相冲突。

我们提出 **xMIx**，一个面向生产推理服务环境中部署 MI 应用的原生服务框架。**xMIx** 支持将 MI 函数*附加*到模型运行时中预定义的位置集，在层和残差流中插入激活干预。**xMIx** 支持根据前面模型层的输出条件调用 MI 函数。多个 MI 应用可以部署在单个模型实例中。**xMIx** 将它们全部编译到服务路径中，但在运行时*动态*仅当需要时才激活，性能开销可忽略不计，且无需单独的模型实例或替代执行栈。

我们将 **xMIx** 与 **vLLM** 服务系统集成，并在三个主流模型和七个不同的 MI 应用上进行评估。**xMIx** 实现了与原生 **vLLM** 执行相当的性能，引入的延迟开销为：平均 token 间延迟（ITL）1.3%（见 https://arxiv.org/html/2607.22595#id12.12.id12），尾部 P99 ITL 1.2%，平均首 token 时间（TTFT）2.6%，以及平均总 token 吞吐量（TTT）1.6%。

**缩写词**
CFG 控制流图
DFA 确定性有限自动机
FSM 有限状态机
PTA 前缀树接收器
LLM 大语言模型
MLP 多层感知机
MI 机械可解释性
SAE 稀疏自编码器
MoE 混合专家
TTFT 首 token 时间
TTT 总 token 吞吐量
ITL token 间延迟

## 1 引言

见图1：xMIx 概述。MI 函数可以安装（*附加*）在不同的 Transformer 层以及层内的多个位置（*钩子*），并可读取/写入各自的激活和残差流。在每个位置，函数可以被动态启用/禁用，从而轻松实现常见的 MI 原语，并在单个模型部署中无缝切换不同的 MI 函数。图中，基于 L1 后激活的处理（读取），L16 层的激活被修改（条件写入）。

机械可解释性（MI）已成为理解和控制大语言模型（LLM）行为的有前途方法。MI 不将模型视为黑盒仅通过输入输出推理，而是直接在推理过程中操作模型的内部计算。通过检查、跟踪和干预中间激活和残差流，MI 技术旨在深入了解模型如何产生特定行为，并在运行时修改这些行为。

存在一类日益增长的*MI 应用*，例如越狱检测（Kadali 和 Papalexakis，2026），幻觉缓解（Li 等人，2023），真实性评估（Orgad 等人，2025），安全监控（Lee 等人，2025），以及可控生成（Stickland 等人，2024）。更广泛地，MI 承诺成为一种实用机制，用于*增强已部署的模型*，在不重新训练或微调的情况下添加运行时新功能。与传统修改模型权重不同，MI 应用操作于瞬态推理计算，使系统能够在执行过程中注入新行为、抑制不良输出、强制执行安全约束或动态调整响应。这种运行时干预机制可能成为部署后扩展模型能力的重要系统机制。

不幸的是，目前大多数 MI 应用仍局限在研究原型中，很少部署在生产服务栈中。一个关键原因是*缺乏满足生产部署严格效率目标的高性能运行时*。现有 MI 框架（例如 TransformerLens（Nanda and Bloom，2022）以及第2节讨论的其他框架）通常依赖于侵入式仪器钩子和自定义执行路径，与现代推理系统不兼容。在生产环境中，服务吞吐量和延迟严重依赖于连续批处理和 CUDA 图执行等优化，即使是影响这些优化的一点点 MI 逻辑也可能破坏调度并显著降低性能。例如，最近的 vLLM-lens 项目报告在简单单层引导逻辑上，相对于原始 vLLM 导致了约 20% 的吞吐量下降（见第5节更多结果）。

与此同时，MI 应用的日益多样性带来了另一个挑战：每个应用通常作为独立的推理管道修改实现，紧密耦合到特定运行时、模型和干预机制。因此，操作员无法在同一个服务的模型上高效部署多个 MI 应用。相反，部署新应用需要维护单独的模型实例、替代执行栈或专门的服务基础设施，而不是统一的控制平面来管理多个干预操作。这使得部署更加复杂：需要预先选择启用哪些 MI 应用。运行时切换应用的成本极高：它强制重新启动服务栈，排空请求并重建服务状态。

**缺失的环节**。我们认为 MI 研究到生产部署之间缺失的环节是一个原生服务抽象层，使 MI 应用能够与优化的推理运行时干净组合。这样的层对于使 MI 变得*可行动化*（Orgad 等人，2026）至关重要，能够推动更广泛的采用和在生产模型服务系统中的实际影响。

我们提出 **xMIx**，一个轻量级原生服务框架，用于在生产推理环境中灵活高效地部署 MI 应用。图1 说明了主要概念。开发者指定模型中的*钩子*，在这些位置 MI 函数（Triton 中的 GPU 内核）可以*附加*以实现相应的 MI 逻辑。每个函数可以访问钩子位置的激活，修改它们以影响后续推理层，并/或将其结果保存在缓冲区中，供 CPU 或 GPU 代码后续访问。此外，MI 函数的调用可以*条件化*，取决于在更早层执行的 MI 函数输出上的谓词。为了方便，**xMIx** 提供了 MI 函数模板来实现典型的 MI 原语 – *读取*、*写入*和*条件写入*。这个简单的、与模型无关的接口允许实现广泛已知的 MI 应用，包括我们在评估中展示的 7 种。

**xMIx** 支持在同一个已部署模型上运行多个 MI 应用，而不需要单独的执行栈或专用的模型副本。它将所有附加函数直接编译到服务路径中，但仅在*需要时*激活它们。主导原则很简单：如果一个已部署的 MI 应用在一个请求上不活动，就不应对该请求施加有意义性能成本。因此，MI 应用可以以可忽略的开销禁用或启用，且不影响正在处理的推理请求的服务。

在底层，**xMIx** 采用了几种先进技术来实现其性能和灵活性目标。首先，它插入到服务框架创建的 CUDA 图中，以支持 MI 函数的附加和切换。其次，它添加了 token 触发的 MI 函数以及跨不同层附加函数的数据共享，同时保持可忽略（几 MB）的内存状态。第三，它支持在每个钩子位置的 batch 中 token 的分散处理，而无需回退到 CPU 驱动执行。最后，它无缝支持多 GPU 执行，无需 MI 应用开发者参与。

**结果**。我们将 **xMIx** 与 **vLLM** 服务运行时集成，并为三种流行的中型 LLM 实现了七个具有不同 MI 原语的 MI 应用。在所有配置中，**xMIx** 在所有关键性能指标上展示了微小开销，使 **vLLM** 的延迟降低：平均 ITL 1.3%，尾部 P99 ITL 1.2%，平均 TTFT 2.6%，平均 TTT 1.6%。这些结果不仅显示 **xMIx** 的开销比现有 MI 框架低至少一个数量级，也表明 MI 应用可以以可接受成本轻松部署在生产服务系统中。

**贡献**。我们的主要贡献是：（i）我们分析了不同的 MI 应用和用例，并将其泛化，创建了统一的抽象，使 MI 开发者能够在通用框架下与模型交互。（ii）我们在 **vLLM** 之上构建了一个框架，支持部署广泛的应用谱系，同时保留高吞吐、低延迟推理的所有优势。（iii）我们实现了动态切换机制，支持“不用则不付”的部署，使得可以根据运行时需要启用或禁用应用。

## 2 动机与相关工作

机械可解释性（MI）技术分析并干预模型内部的计算，而不仅仅是其输入和输出（见附录表4中调研的应用列表）。对于自回归 Transformer，这通常意味着在选定层和 token 位置读取隐藏状态、注意力值或 MLP 激活，然后要么报告信号（例如探针分数），要么写回修改后的激活。这种模式是探针、激活修补、激活引导和条件干预等广泛的应用集合的基础。

MI 应用不仅仅是事后分析。它们是推理时程序，必须与模型的前向传播同步执行。许多 MI 干预读取特定层和 token 位置的中间值，然后使用该值修改同一执行中的后续中间状态。例如，Lee 等人（2025）读取一个层的激活，并通过写入修改后的激活在后续层诱导拒绝。

不幸的是，尽管其巨大潜力，MI 应用在生成式模型服务系统中的广泛部署由于高性能成本而受到限制。接下来我们分析关键原因。

**MI 研究工具**。大多数现有 MI 工具是为快速研究迭代构建的，而不是为生产推理。TransformerLens（Nanda and Bloom，2022）推广了方便的基于钩子的接口，并为 Transformer 内部结构标准化了命名，使得缓存、编辑和替换激活变得容易。然而，它是作为 PyTorch 级仪器库而非作为与服务引擎的集成来实现的（Paszke 等人，2019）。它使用 PyTorch 的*即时执行模式*，优先考虑灵活性而非效率。具体来说，它允许在推理期间任意调用 MI 函数，这与 CUDA 图不兼容，因此由于频繁的 CPU-GPU 同步而牺牲性能。NNsight（Fiotto-Kaufman 等人，2024）通过灵活的跟踪 API 和远程后端泛化了这种风格，再次优先考虑表达性实验而非性能。EasyEdit（Wang 等人，2024）将广泛的知识编辑方法组织在公共框架后面，但其重点是离线或会话级模型编辑，而非低延迟、多租户服务。EasyEdit2（Xu 等人，2025c）、EasySteer（Xu 等人，2025b）以及最近的 vLLM-lens（29）将控制更靠近 vLLM 的服务引擎，统一了引导向量生成和应用，但它们仍然将引导视为推理之上的模型级框架，并诉诸于 PyTorch 的即时执行模型。因此，通过瞄准 MI 研究和原型设计，这些工具与生产服务系统的严格性能目标不兼容。

**为什么生产模型服务不同**。现代 LLM 服务系统（如 vLLM）通过应用复杂技术最大化吞吐量，包括预填充和解码的分离执行、连续批处理、显式 KV 缓存管理，以及 GPU 导向的优化如 FlashAttention（Dao 等人，2022）和 PagedAttention（Kwon 等人，2023）。它们通常依赖于*CUDA 图*（NVIDIA，2026a）以减少反复出现的核启动开销，并引入自定义 GPU 内核，包括 vLLM 中基于 Triton 的融合内核，以将性能关键操作保留在设备快速路径上（Tillet 等人，2019；vLLM 项目，2026b）。这些系统设计用于最小化主机-设备同步，并保持固定的、对 CUDA 图友好的执行路径。

在这些条件下，常规 Python 钩子不是合适的实现方法。它们强制服务栈回退到主机驱动的即时执行模式。每次逃逸 GPU 快速路径的干预，都会在关键路径上添加 CPU 参与，引入同步点，并且通常需要额外的数据移动。该成本直接与连续批处理和 CUDA 图冲突：一旦执行必须等待 Python，系统就会失去这些优化依赖的固定路径。在解码期间惩罚尤其严重，此时服务已经是内存受限，即使是每个 token 的适度开销也会在长生成中累积。

从系统角度看，现有 MI 框架有一个共同的核心假设：它们通过 CPU 驱动的执行运行，其中张量操作由主机程序立即调度，而不是被阶段化到原生服务执行图中（Paszke 等人，2019），并带有钩子、跟踪或用户空间回调层。