LLM中的拒绝服务与资源耗尽

大型语言模型在推理时本质上会执行计算密集型任务。这一特点使其易于遭受拒绝服务（DoS）和资源耗尽攻击。与可能侧重于网络带宽的传统DoS攻击不同，针对大型语言模型的攻击通常旨在使模型处理可用的计算资源不堪重负，导致服务对合法用户而言变慢、无响应或完全无法使用。理解这些弱点是构建更具弹性的LLM系统的一个重要步骤。

LLM中资源耗尽的机制

攻击者可以采用多种策略来引发DoS状况或耗尽部署大型语言模型（LLM）的系统资源。这些方法借助LLM处理输入和生成输出的方式。

计算量大的查询

一个主要途径是提交旨在使计算负载达到最大的提示。LLM可以被指示去执行本质上资源密集型的任务。例如：

• 极长输出： 请求生成过长文本（例如，“写一篇10万字的故事”）会消耗大量的处理时间和内存。
• 复杂推理或迭代： 需要多步推理或模拟迭代计算的提示，会给模型带来不成比例的负担。攻击者可能会精心构造一个提示，要求LLM递归地定义一个术语，或通过文本生成分形图案。
• 针对已知低效点： 如果攻击者知道特定LLM架构处理某些特定类型的查询或结构效率低下，他们可以借助这些信息进行攻击。

此类查询会导致CPU、GPU和内存使用量激增。这不仅影响攻击者的请求，还会降低所有并发用户的性能，如果基础设施自动扩容，运营成本可能会大幅增加。

滥用输入长度和注意力机制

输入序列本身的长度和复杂度可能成为一个弱点。许多LLM架构，尤其是基于Transformer的架构，采用注意力机制，其计算成本可能随输入序列长度呈平方增长。这通常表示为 $O(n^2)$，其中 $n$ 是输入中的词元数量。

攻击者可以通过以下方式进行攻击：

• 发送极长、可能毫无意义的输入序列。
• 构造难以或缓慢进行词元化的输入。

即使模型有最大输入词元限制，重复发送达到或接近此限制的输入，仍可能导致资源耗尽。系统可能会花费过多的时间处理这些大型输入，从而有效地拒绝为其他用户提供服务。

攻击者用资源密集型查询淹没LLM系统，导致推理引擎资源消耗高，并使合法用户获得的服务质量下降。

上下文窗口过载

大型语言模型在有限的上下文窗口中运行，该窗口是指模型在生成响应时可以考虑的近期对话或输入文本的数量。尽管这本身并非总是直接的DoS攻击途径，攻击者可能会试图用大量不相关或特殊构造的数据填充此上下文窗口。这可能导致：

• 如果模型重新处理上下文的很大一部分，则增加每个后续轮次的负载。
• 可能触发上下文管理中的边缘情况或优化较少的处理路径，导致性能下降。
• 在设计不佳的系统中，如果上下文处理效率低下，则会导致内存问题。

API层面洪水攻击

除了精心构造计算量大的单个提示外，攻击者还可以对LLM的API端点采取更传统的流量攻击。这涉及以高频率发送请求，这些请求可以是：

• 大量简单的、看似合法的查询。
• 简单查询和资源密集型查询的混合。

如果API速率限制缺失、不足或配置不当，此类洪水攻击可能使服务基础设施不堪重负，导致LLM实例或API网关本身的资源匮乏。

对集成组件的攻击

现代LLM应用程序通常并非独立运行。它们可能与向量数据库结合以进行检索增强生成（RAG）、使用外部工具或其他API。针对这些依赖服务的DoS攻击可以有效地瘫痪LLM应用程序。例如，如果一个LLM依赖向量数据库来为其上下文获取相关文档，并且该数据库因攻击而变得不可用，那么LLM提供有用响应的能力将受到严重阻碍，导致功能性拒绝服务。

DoS和资源耗尽的后果

这些攻击的影响不仅限于简单的服务不可用：

• 服务不可用： 最直接的结果。合法用户无法访问LLM服务。
• 性能下降： 即使服务部分可用，响应时间也可能对所有用户而言变得慢得无法接受。
• 运营成本增加： 对于云托管的LLM，资源耗尽攻击可能导致计算成本大幅且意外增加，因为系统会尝试扩容以满足恶意需求。
• 信任和声誉受损： 不可靠的服务会迅速失去用户信任。频繁的停机或糟糕的性能会严重损害LLM提供商或基于其构建的应用程序的声誉。

在模拟资源耗尽攻击期间（15-30分钟），LLM系统上的CPU和内存使用率飙升。

区分LLM特有的DoS

尽管与传统DoS攻击有相似之处，针对大型语言模型的资源耗尽攻击具有其独特的特点。恶意负载通常嵌入在查询本身的内容中，其目的是借助LLM推理的计算特性进行攻击，而非仅仅利用网络协议或服务器软件漏洞。这使得检测和缓解更具挑战性，因为如果不进行更细致的分析，就难以区分合法、复杂的查询与恶意构造、耗尽资源的查询。

解决这些弱点需要多层防御策略，包括输入验证、仔细的资源监控、自适应速率限制，以及可能采用专门的模型架构或推理优化。这些防御措施将在后续章节中更详细地讨论。目前，认识到这些攻击途径是了解LLM安全环境的核心组成部分。