针对LLM服务框架而非模型的延迟型拒绝服务攻击研究

基本信息

导语

现有研究多聚焦于通过算法触发长输出来攻击大模型，但本文指出此类手段在现代服务系统的隔离机制下往往失效。作者转而提出“Fill and Squeeze”策略，通过操纵调度器状态与耗尽KV缓存，在黑盒环境下实施针对系统层的延迟攻击。该研究揭示了LLM服务框架在调度逻辑上的脆弱性，但具体的防御方案无法从摘要确认。

摘要

《重新思考延迟拒绝服务：攻击LLM服务框架而非模型》内容总结

1. 背景与问题 大语言模型（LLM）面临一种新兴的关键威胁——延迟攻击。由于LLM推理成本高昂，即使是微小的延迟也会导致运营成本激增和服务可用性风险。现有研究多关注“算法级攻击”，即通过精心设计输入来触发最坏情况的输出长度。然而，本文指出一个反直觉的发现：这类针对算法的攻击对现代LLM服务系统几乎无效，因为现代系统（如连续批处理）提供了逻辑隔离，限制了延迟对并发用户的传染影响。

2. 攻击策略：从算法转向系统 作者将攻击焦点从算法层转移到系统层，提出了一种名为 “Fill and Squeeze”（填充与挤压） 的新攻击策略，旨在攻击调度器的状态转换：

  • Fill（填充）： 耗尽全局KV缓存，诱导“队头阻塞”。
  • Squeeze（挤压）： 强制系统进入重复的抢占循环。 攻击者可以通过简单的纯文本提示或复杂的提示工程来操纵输出长度，并结合内存状态侧信道探测，在黑盒环境下以较低成本实施攻击。

3. 攻击效果与评估 评估表明，与现有攻击相比：

  • 首字生成时间（TTFT）： 平均减慢了20至280倍。
  • 每个输出Token的时间（TPOT）： 平均减慢了1.5至4倍。
  • 攻击成本： 降低了30%-40%。

该研究揭示了LLM服务框架在系统调度层面的脆弱性，证明了针对基础设施的攻击比针对模型算法的攻击更为致命。

研究最佳实践

最佳实践指南

实践 1：实施严格的请求验证与输入清理

说明: 攻击者通常通过发送畸形的 HTTP 请求或包含恶意负载的输入来触发 LLM 服务框架的异常处理路径，从而导致服务延迟或崩溃。严格的验证机制可以确保只有符合格式预期的请求进入处理队列，减少后端处理异常的开销。

实施步骤:

  1. 在 API 网关层实施严格的模式验证，确保请求头、Content-Type 和 JSON 结构符合预期。
  2. 对 Prompt 输入进行长度限制和格式清洗，防止超长字符串或特殊字符序列导致解析器阻塞。
  3. 拒绝或重置包含未预期字段的请求，避免后端框架进入复杂的错误处理逻辑。

注意事项: 验证逻辑本身应当轻量级，避免引入新的延迟瓶颈。

实践 2：强制执行超时机制与请求取消

说明: 针对基于队列的攻击，攻击者可能发送大量请求占用连接但不发送完整数据，或者发送处理时间极长的请求。强制超时可以确保系统资源不被僵死或慢速请求长期占用。

实施步骤:

  1. 在负载均衡器和 API 网关层配置严格的连接超时和读取超时。
  2. 为推理引擎设置最大请求处理时间，超时立即返回错误并释放 GPU 资源。
  3. 实施异步取消机制，一旦客户端断开连接或超时，立即向下游服务发送取消信号以停止 Token 生成。

注意事项: 超时设置需根据模型的平均响应时间（TP50/TP99）进行精细调整，设置过短可能误杀正常请求。

实践 3：限制并发连接与请求队列深度

说明: 研究表明，LLM 服务框架（如 vLLM, TGI）的调度器在面对超过其处理能力的并发请求时，延迟会呈指数级上升。限制并发数可以防止系统过载。

实施步骤:

  1. 配置推理引擎的最大并发请求数，确保其与 GPU 显存和计算资源相匹配。
  2. 在 API 网关层实施漏桶或令牌桶算法，严格控制进入后端的请求速率。
  3. 限制 HTTP/2 的最大并发流数量，防止单一连接占用过多服务器资源。

注意事项: 当队列满时，应直接返回 HTTP 429（Too Many Requests）而非接受请求进入无限等待队列。

实践 4：优化调度器与预填充/解码隔离

说明: 现有的 LLM 服务框架通常将预填充和解码阶段混合调度。攻击者可以利用长 Prompt 的预填充阶段阻塞解码器，导致正常短请求无法生成 Token。优化调度策略可缓解此问题。

实施步骤:

  1. 启用或配置支持优先级调度的服务框架（如 vLLM 的优先级队列），将短请求或实时请求置于高优先级。
  2. 尝试将计算密集的预填充阶段与 I/O 密集的解码阶段在逻辑上或物理上进行隔离。
  3. 限制单个请求的最大 Prompt 长度，防止单个请求的预填充操作占用过多调度时间片。

注意事项: 修改调度策略可能会略微降低整体吞吐量，需在延迟和吞吐量之间寻找平衡。

实践 5：部署速率限制与资源配额

说明: 简单且有效的防御手段，通过识别和限制异常流量模式，防止攻击者通过洪水攻击耗尽服务器连接池或计算资源。

实施步骤:

  1. 基于用户 ID 或 API Key 实施每分钟请求数（RPM）和每分钟 Token 数（TPM）限制。
  2. 部署自动化的异常检测机制，识别来自单一 IP 的高频请求或异常慢速请求模式，并自动加入黑名单。
  3. 为不同的租户或用户组分配独立的资源配额，确保“吵闹邻居”不影响其他用户。

注意事项: 速率限制应尽可能靠近请求源头（如 CDN 或负载均衡器）实施，以减轻后端压力。

实践 6：监控框架层指标与异常响应

说明: 攻击往往针对服务框架的脆弱性而非模型本身。传统的模型准确率监控无法发现此类攻击，必须监控服务层面的健康指标。

实施步骤:

  1. 重点监控排队时间、首字节延迟（TTFT）和请求调度器的内部队列长度。
  2. 设置告警阈值，当错误率突增或延迟异常飙升（即使流量未明显增加）时触发警报。
  3. 定期进行压力测试和混沌工程测试，模拟高并发和畸形请求，验证框架的韧性。

注意事项: 确保监控日志本身不会因为记录详细的错误信息而导致磁盘 I/O 瓶颈或泄露敏感信息。

学习要点

  • 针对LLM推理框架（如vLLM、TGI）的“延迟拒绝服务”攻击，比针对模型本身的攻击更具破坏性，能造成高达数百倍的请求延迟。
  • 攻击的核心机制是利用推理框架的“预填充”阶段与“解码”阶段共享同一计算资源的特性，通过长Prompt恶意占满KV缓存空间。
  • 相比于传统DDoS攻击，此类攻击更具隐蔽性，攻击者仅需极低的带宽（发送少量恶意请求）即可使服务瘫痪。
  • 现有的防御机制（如简单的请求速率限制）完全失效，因为恶意请求在数量上并未触发阈值，但在计算资源消耗上却占据了主导地位。
  • 研究表明，主流的LLM服务框架（包括vLLM、TGI、TensorRT-LLM）均存在此漏洞，且在默认配置下极易受到攻击。
  • 提出的“Early Stopping”防御策略能有效缓解此类攻击，通过在预填充阶段检测并丢弃可能导致资源耗尽的恶意请求，保障正常服务流量。

学习路径

学习路径

阶段 1：基础构建

学习内容:

  • LLM 推理基础: 深入理解 Transformer 架构（特别是 Decoder-only 架构）、KV Cache 机制、Prefill（预填充）与 Decode（解码）阶段的区别。
  • 服务框架原理: 掌握 vLLM、Triton Inference Server、TensorRT-LLM 等主流推理框架的基本架构，了解连续批处理和分页注意力（PagedAttention）的实现原理。
  • 网络与协议: 复习 HTTP/REST 与 RPC（如 gRPC）通信机制，理解 TCP/IP 模型中的延迟、带宽和吞吐量概念。

学习时间: 2-3周

学习资源:

  • vLLM 官方文档与源码分析
  • 论文: Attention Is All You Need (Transformer 原理)
  • 论文: Efficient Memory Management for Large Language Model Serving with PagedAttention (vLLM 原理)

学习建议: 不要只停留在理论层面，建议在本地环境搭建一个简单的 vLLM 服务，并使用 Python 的 requests 库编写脚本发送请求，观察不同请求长度下的响应时间变化。

阶段 2：攻击面与漏洞分析

学习内容:

  • 拒绝服务 攻击原理: 区分针对带宽的传统 DoS 与针对应用逻辑或资源调度的 DoS。
  • LLM 特定攻击向量: 学习如何利用推理框架的调度机制进行攻击。重点理解“干扰攻击”，即如何通过发送精心设计的恶意请求来阻塞调度器的队列或耗尽 GPU 显存（KV Cache）。
  • 延迟放大: 研究如何通过控制请求的输入/输出长度比或发送频率，导致合法请求的排队时间呈指数级上升。
  • 论文核心解读: 精读《Rethinking Latency Denial-of-Service》，理解作者提出的“攻击框架而非模型”的视角，分析其中的攻击算法（如最大干扰算法）。

学习时间: 3-4周

学习资源:

  • 论文原文: Rethinking Latency Denial-of-Service: Attacking the LLM Serving Framework, Not the Model
  • 开源工具: Locust (负载测试工具)
  • 相关阅读: 关于 Kubernetes 和容器资源限制的文档

学习建议: 尝试复现论文中的场景。你可以使用 Locust 或 JMeter 编写并发测试脚本，模拟多个用户同时发送请求，观察服务器的 TPS（每秒请求数）和 TTFT（首字延迟）在攻击下的下降情况。

阶段 3：防御机制与安全加固

学习内容:

  • 请求调度策略: 学习公平调度与优先级队列的设计，了解如何防止恶意请求独占计算资源。
  • 配额与限流: 掌握基于 Token 的限流和基于请求复杂度的动态限流策略。
  • 隔离技术: 了解多租户环境下的资源隔离方案，如使用 GPU 切片或独立的推理实例来隔离不同用户的请求。
  • 异常检测: 探索如何利用统计学或机器学习模型实时识别异常的流量模式（如请求长度分布异常）。

学习时间: 2-3周

学习资源:

  • 论文: DoS Defense in LLM Serving Systems (相关防御文献)
  • vLLM 和 Ray Serve 关于 Rate Limiting 的配置文档
  • Nginx 或 Envoy 网关的限流配置指南

学习建议: 在测试环境中实施防御措施。例如，配置推理框架的最大并发数限制，或在网关层增加针对请求 Payload 大小的检查规则，然后再次运行攻击脚本验证防御效果。

阶段 4：实战演练与评估

学习内容:

  • 自动化攻击脚本编写: 使用 Python 编写针对特定 API 端点的 DoS 攻击脚本，实现自动化的攻击探测与利用。
  • 性能基准测试: 学习使用专业的 LLM 推理基准测试工具（如 LLMPerf），量化攻击对系统性能的具体影响（如生成延迟增加的百分比）。
  • 红队演练: 模拟真实的攻击场景，对部署的 LLM 服务进行全方位的安全评估，并撰写评估报告。

学习时间: 2-4周

学习资源:

  • GitHub 项目: LLMPerf
  • OWASP Top 10 for LLM (大语言模型应用安全十大风险)
  • 云服务提供商的安全最佳实践 (AWS/Azure/GCP 关于 AI 服务的安全白皮书)

学习建议: 将重点放在“量化”上。不仅仅是证明服务可以被拒绝服务，更要测量出攻击者的成本（如每秒需要发送的请求数）与防御者的收益，从而评估防御策略的性价比。

常见问题

1: 这篇论文的核心发现是什么？为什么它说传统的延迟攻击思路是错误的？

1: 这篇论文的核心发现是什么？为什么它说传统的延迟攻击思路是错误的？

A: 该论文的核心发现在于，针对大型语言模型（LLM）的延迟拒绝服务攻击，其最脆弱的环节并非模型本身的推理计算，而是承载模型的服务框架。

传统的攻击思路通常认为，由于 LLM 拥有数十亿甚至数千亿的参数，其巨大的计算量是延迟的主要瓶颈，因此攻击者需要通过生成极其复杂的 Prompt 来消耗 GPU 资源。然而，这篇论文通过研究指出，现代 LLM 服务框架（如 vLLM, TGI, TensorRT-LLM 等）为了提高吞吐量，采用了复杂的调度机制（如连续批处理 Continuous Batching 和 KV Cache 管理）。攻击者可以通过精心设计的请求序列，利用这些调度机制中的设计缺陷或同步开销，导致框架陷入“死锁”或频繁进行昂贵的上下文切换，从而在几乎不消耗 GPU 算力的情况下，使服务吞吐量暴跌。

2: 论文中提到的“攻击框架而非模型”具体是如何实现的？

2: 论文中提到的“攻击框架而非模型”具体是如何实现的？

A: 论文提出了几种针对 LLM 服务框架的攻击向量，主要利用了框架在处理请求时的调度策略和同步机制：

  1. 利用调度死锁： 攻击者发送一组特定的请求，使得框架的调度算法（例如某些基于迭代级的调度）无法找到合适的批次进行推进。这会导致 GPU 处于闲置状态，而 CPU 控制逻辑在空转，从而拒绝正常服务。
  2. 抢占与上下文切换开销： 在多租户或高优先级抢占场景下，攻击者可以通过发送大量请求并频繁触发抢占机制。由于将模型状态从显存换出换入或重建 KV Cache 的成本极高，这种频繁的上下文切换会严重拖慢整体处理速度。
  3. 利用系统资源竞争： 攻击者针对框架中的非计算组件（如请求排队锁、KV Cache 内存管理器）进行压制，使得即使 GPU 空闲，新的请求也无法被及时调度处理。

3: 这种攻击对现有的 LLM 推理系统（如 vLLM, TGI, TensorRT-LLM）有何影响？

3: 这种攻击对现有的 LLM 推理系统（如 vLLM, TGI, TensorRT-LLM）有何影响？

A: 研究表明，这种攻击对目前主流的 LLM 推理系统具有广泛的破坏性。

  • 广泛性： 论文测试了包括 vLLM、TGI (Text Generation Inference)、TensorRT-LLM 等在内的业界标准框架，发现它们都存在不同程度的漏洞。
  • 高效性： 相比于传统的计算密集型攻击，这种攻击的成本极低。攻击者往往只需要发送少量的特定请求，或者以较低的速率发送请求，就能导致服务吞吐量下降 90% 甚至更多。
  • 隐蔽性： 由于攻击主要针对逻辑控制而非计算资源，监控面板可能会显示 GPU 利用率极低，这会让防御者误以为是系统空闲或网络抖动，而实际上系统正处于瘫痪状态。

4: 论文作者提出了哪些防御措施或建议？

4: 论文作者提出了哪些防御措施或建议？

A: 针对这些新发现的攻击面，论文提出了几项防御和缓解建议：

  1. 改进调度算法： 框架开发者需要重新审视调度逻辑，避免设计可能导致死锁的等待条件。例如，引入更智能的请求排队策略，防止恶意请求长期占用调度槽位。
  2. 隔离与资源限制： 对不同的请求队列或用户实施严格的资源隔离。限制单个用户或租户能够同时占用的 KV Cache 块数量，防止单一攻击者耗尽关键内存资源。
  3. 成本感知的调度： 在调度决策中引入对“上下文切换成本”的评估。如果频繁切换会导致性能急剧下降，系统应倾向于拒绝低优先级请求而非进行频繁切换。
  4. 请求指纹识别与异常检测： 监控系统的调度效率指标（如每批次的平均请求数、GPU 空闲时间），如果发现异常模式（如 GPU 空闲但队列堆积），应及时触发熔断机制。

5: 什么是“连续批处理”，为什么它是攻击的重点目标？

5: 什么是“连续批处理”，为什么它是攻击的重点目标？

A: 连续批处理，也称为迭代级批处理，是现代 LLM 服务框架中的一项关键技术，旨在提高 GPU 利用率。

在传统的静态批处理中，一个批次必须等待其中最长的那个请求生成完毕后，才能整体结束并处理下一批。而在连续批处理中，一旦一个请求生成了下一个 token，它就可以立即被放入下一个批次中处理，无需等待同批次的其他请求。

虽然这极大地提高了效率，但也引入了复杂的动态调度逻辑。攻击者利用连续批处理中请求到达和离开的动态性，通过构造特定的请求长度和时序，使得调度器无法有效地填充批次，或者迫使调度器花费大量时间在重组批次数据上，从而导致服务延迟增加。

6: 这种攻击与传统的 DoS（如 SYN Flood）有何不同？

6: 这种攻击与传统的 DoS（如 SYN Flood）有何不同？

A: 传统的网络层 DoS 攻击（如 SYN Flood）旨在耗

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章