大模型安全（九）：模型可用性攻击之拒绝服务与资源耗尽

摘要：大型语言模型（LLM）是计算密集型系统，推理过程极其消耗GPU显存和算力。这种特性使得LLM极易受到应用层拒绝服务（DoS）攻击。与传统的流量洪水不同，针对LLM的DoS攻击利用了非对称消耗原理：攻击者只需发送很短的Prompt（极低成本），就能诱导模型生成超长文本或陷入复杂的推理循环（极高成本），从而迅速耗尽服务器资源（显存OOM或计算队列阻塞）。本文将深入分析海绵攻击（Sponge Examples）与上下文窗口耗尽的原理，并使用Python编写一个LLM资源耗尽压力测试器，模拟并发发送“放大（Amplification）”指令，展示如何导致推理服务延迟飙升甚至崩溃。

关键词：拒绝服务, DoS, 资源耗尽, 海绵攻击, 显存溢出, 推理延迟, 成本非对称

正文

1. LLM的软肋：昂贵的推理成本

在Web安全中，防止DoS通常意味着清洗流量。但在LLM时代，合法的请求也可能成为DoS的武器。 LLM的生成机制是**自回归（Auto-regressive）**的，即一个Token一个Token地生成。这意味着：

计算昂贵：生成1000个字需要运行大模型网络1000次。

显存敏感：KV Cache机制需要随着上下文长度增加而占用大量显存。

成本非对称：用户输入“请背诵圆周率后10000位”（10个Token），模型可能需要生成很久。

攻击者利用这种低输入成本、高计算消耗的非对称性，可以轻易发起资源耗尽攻击。

2. 攻击手法解析

海绵攻击 (Sponge Attacks)：

原理：设计一种特殊的输入，使得模型在处理时能耗最大化、延迟最大化。在NLP中，这通常意味着输入具有极高的计算复杂度（例如，触发最坏情况的Attention计算）。

放大攻击 (Amplification Attacks)：

原理：发送诱导模型生成长文本的指令。

Prompt示例：“请重复打印‘我是一个AI’这句话，重复10000次，不要停。”

上下文窗口溢出 (Context Window Overflow)：

原理：利用模型对长上下文的处理机制，发送接近窗口上限（如32k, 128k）的垃圾数据，迫使服务器分配最大显存，导致OOM（Out of Memory）。

3. Python实战：构建LLM资源耗尽压力测试器

我们将编写一个Python脚本，模拟对一个LLM推理API（模拟接口）发起并发的放大攻击，并监控其响应时间的变化（服务降级）。

代码实现：

Python



import time
import threading
import random
import queue
 
# 模拟一个 LLM 推理服务
class MockLLMService:
    def __init__(self, max_concurrent=5, gpu_memory=100):
        self.semaphore = threading.Semaphore(max_concurrent) # 模拟并发限制
        self.current_memory_usage = 0
        self.max_memory = gpu_memory
        self.lock = threading.Lock()
 
    def generate(self, prompt, max_tokens):
        """
        模拟推理过程：
        prompt长度影响内存，max_tokens影响生成时间
        """
        # 1. 申请资源
        if not self.semaphore.acquire(timeout=2):
            return 503, "Service Overloaded" # 服务过载
        
        try:
            # 模拟内存分配 (KV Cache)
            memory_needed = len(prompt) * 0.1 + max_tokens * 0.05
            
            with self.lock:
                if self.current_memory_usage + memory_needed > self.max_memory:
                    return 500, "OOM: Out Of Memory"
                self.current_memory_usage += memory_needed
            
            # 2. 模拟计算耗时 (生成每个Token需要时间)
            # 随着负载增加，单个Token生成变慢 (模拟计算争用)
            processing_time = (max_tokens * 0.05) * (1 + self.current_memory_usage / 50)
            time.sleep(processing_time)
            
            return 200, f"Generated {max_tokens} tokens..."
            
        finally:
            # 3. 释放资源
            with self.lock:
                self.current_memory_usage -= memory_needed
            self.semaphore.release()
 
# 攻击者脚本
class DoSAttacker:
    def __init__(self, target_service):
        self.target = target_service
        self.results = queue.Queue()
 
    def attack_request(self, attack_type):
        """
        发送不同类型的攻击 Payload
        """
        start_time = time.time()
        
        if attack_type == "AMPLIFICATION":
            # 放大攻击：短输入，要求超长输出
            prompt = "Repeat 'A' forever."
            max_tokens = 2000 
        elif attack_type == "CONTEXT_FLOOD":
            # 上下文洪水：超长输入，填满显存
            prompt = "X" * 5000 
            max_tokens = 10
        else:
            # 正常请求
            prompt = "Hi"
            max_tokens = 50
 
        status, response = self.target.generate(prompt, max_tokens)
        latency = time.time() - start_time
        
        self.results.put({
            "type": attack_type,
            "status": status,
            "latency": latency
        })
 
    def run_attack(self, concurrency=20):
        print(f"[*] 启动 DoS 攻击，并发线程数: {concurrency}")
        threads = []
        
        # 混合攻击流量
        for i in range(concurrency):
            # 80% 是恶意放大攻击，20% 是正常用户
            attack_type = "AMPLIFICATION" if random.random() > 0.2 else "NORMAL"
            t = threading.Thread(target=self.attack_request, args=(attack_type,))
            threads.append(t)
            t.start()
            
        for t in threads:
            t.join()
            
        self.analyze_results()
 
    def analyze_results(self):
        print("
--- 攻击效果分析 ---")
        counts = {"200": 0, "503": 0, "500": 0}
        latencies = []
        
        while not self.results.empty():
            res = self.results.get()
            counts[str(res["status"])] = counts.get(str(res["status"]), 0) + 1
            if res["status"] == 200:
                latencies.append(res["latency"])
                
        print(f"请求总数: {sum(counts.values())}")
        print(f"服务过载 (503): {counts['503']} 次")
        print(f"显存溢出 (500): {counts['500']} 次")
        
        if latencies:
            avg_latency = sum(latencies) / len(latencies)
            print(f"成功请求平均延迟: {avg_latency:.2f}s (正常情况下应 < 0.5s)")
            print("--> 结论: 攻击成功导致服务严重降级。" if avg_latency > 2.0 else "--> 结论: 服务抗住了攻击。")
 
# 运行模拟
print("--- 初始化脆弱的 LLM 服务 ---")
# 限制并发为 5，显存为 100 单位
vulnerable_llm = MockLLMService(max_concurrent=5, gpu_memory=100)
 
attacker = DoSAttacker(vulnerable_llm)
# 发起 20 个并发请求（远超服务承载能力）
attacker.run_attack(concurrency=20)

代码运行结果解析：

由于max_concurrent被设置为5，当攻击者发起20个线程时，大量的请求会返回 503 Service Overloaded。

对于挤进去的请求，由于使用了AMPLIFICATION（要求生成2000 tokens），它们会长时间占用GPU资源。

mock_llm_service中的模拟逻辑会让延迟随着内存占用增加而变慢，你会看到平均延迟显著升高，这就是服务降级（Service Degradation）。

如果有CONTEXT_FLOOD攻击，可能会直接触发500 OOM，导致服务崩溃。