AI 推理中的 GPU 显存压力与 OOM 工程缓解策略：从 PagedAttention 到 KV Cache 压缩、Offloading 与请求准入控制

当 LLM 推理服务走向生产环境，GPU 显存 OOM 是最频繁、最致命的故障之一。本文从显存压力的根因分析出发，系统讲解 PagedAttention、KV Cache 量化和压缩、CPU Offloading、自适应请求准入控制以及动态批量调整这五大工程策略，并给出生产级的配置基准与急救方案。

一、GPU 显存 OOM 的根因：为什么推理服务总在深夜崩溃

在 AI 推理集群中，OOM（Out of Memory）往往不是突然发生的，而是多个因素叠加的"慢性中毒"。

1.1 显存的三个消费者

一个 LLM 推理服务的 GPU 显存主要由三部分组成：

• 模型权重（Model Weights）：通常是最大且固定的开销。以 FP16 精度的 7B 模型为例，约占用 14GB；70B 模型约 140GB。
• KV Cache（Key-Value Cache）：注意力机制的核心缓存，用于避免重复计算历史 token 的 Key 和 Value。这是可变部分，也是 OOM 的主要来源。
• 临时计算缓冲区（Activation/Scratchpad）：前向传播中的中间张量，通常在 batch 维度上随请求数量线性增长。

显存占用的公式可以简化为：

Total Memory = Model_Weights + KV_Cache_per_Request × Num_Active_Requests + Activation_Batch

当突发流量导致并发请求数激增，或个别请求的长度远超预期时，KV Cache 部分会急速膨胀，突破 GPU 显存上限。

1.2 KV Cache 的精确开销计算

精确估算 KV Cache 大小对容量规划至关重要。以下是一个完整的计算公式（以 Llama 2 70B 为例）：

def kv_cache_per_token(
    num_layers: int = 80,
    num_kv_heads: int = 8,      # GQA分组数（70B 模型）
    head_dim: int = 128,
    dtype_bytes: int = 2,       # FP16 = 2 bytes
) -> int:
    """计算单个 token 的 KV Cache 大小（字节）"""
    # K 和 V 各占一份
    kv_bytes = 2 * num_layers * num_kv_heads * head_dim * dtype_bytes
    return kv_bytes  # 80 × 8 × 128 × 2 × 2 = 327,680 bytes ≈ 320KB/token

def kv_cache_per_request(
    max_seq_len: int = 4096,
    max_prompt_tokens: int = 2048,
    max_gen_tokens: int = 2048,
) -> int:
    """单次请求的 KV Cache 峰值（字节）"""
    peak_tokens = max_prompt_tokens + max_gen_tokens
    return kv_cache_per_token() * peak_tokens
    # 4096 × 320KB ≈ 1.25 GB/请求

这意味着在一张 80GB A100 上，运行 Llama 2 70B（模型权重约 140GB，需 2 卡张量并行），剩余可用 KV Cache 空间约 20GB，同时只能服务大约 16 个长序列请求——远低于 GPU 的计算吞吐量极限。

显存瓶颈不是计算能力，而是内存墙。

1.3 生产环境的"显存碎片化"

即使总显存足够，分配给 KV Cache 的非连续页面也会导致碎片化分配失败。传统推理引擎（如早期 HuggingFace transformers）会为每个请求预先分配最大长度的连续显存块，导致：

• 内部碎片：实际生成长度远小于预分配长度，大量显存被浪费
• 外部碎片：请求释放后留下大小不一的空闲块，新请求无法找到足够大的连续空间

这正是 PagedAttention 要解决的核心问题。

二、PagedAttention：操作系统虚拟内存思想在 KV Cache 管理中的革命

2.1 核心思想：借鉴 OS 分页机制

vLLM 的 PagedAttention 灵感直接来自操作系统的虚拟内存分页：

操作系统概念	PagedAttention 对应
虚拟页（Page）	逻辑块（Logical Block）
物理页帧（Frame）	物理块（Physical Block）
页表（Page Table）	Block Table
缺页异常（Page Fault）	新 Token 分配新块
页面置换	KV Cache Eviction

2.2 核心数据结构

class BlockAllocator:
    """GPU KV Cache 的物理块分配器"""

    def __init__(self, block_size: int = 16, num_gpu_blocks: int = 8192):
        """
        block_size: 每个块存储的 token 数量（通常 16-32）
        num_gpu_blocks: 预分配的 GPU 物理块总数
        """
        self.block_size = block_size
        self.free_blocks = list(range(num_gpu_blocks))  # 空闲块池
        self.allocated: dict[str, list[int]] = {}        # seq_id → [block_ids]
        self.block_tables: dict[str, torch.Tensor] = {}  # GPU 上的块映射表

    def allocate(self, seq_id: str, num_tokens: int) -> bool:
        """为序列分配 KV Cache 块"""
        num_blocks_needed = (num_tokens + self.block_size - 1) // self.block_size
        if len(self.free_blocks) < num_blocks_needed:
            return False  # OOM：触发驱逐或拒绝

        blocks = [self.free_blocks.pop() for _ in range(num_blocks_needed)]
        self.allocated[seq_id] = blocks
        # 构建 Block Table 用于 CUDA Kernel 寻址
        self.block_tables[seq_id] = torch.tensor(blocks, dtype=torch.int32, device='cuda')
        return True

    def append_token(self, seq_id: str):
        """追加新 token：仅在当前块未满时才需要新分配"""
        blocks = self.allocated[seq_id]
        # 检查最后一个块是否还有空间
        last_block_usage = self._get_block_usage(blocks[-1])
        if last_block_usage >= self.block_size:
            # 当前块已满，需要新块
            if not self.free_blocks:
                return False  # OOM
            blocks.append(self.free_blocks.pop())
        return True

    def free(self, seq_id: str):
        """释放序列占用的所有块"""
        if seq_id in self.allocated:
            self.free_blocks.extend(self.allocated[seq_id])
            del self.allocated[seq_id]
            del self.block_tables[seq_id]

class PagedAttentionKernel:
    """Paged Attention 的 CUDA Kernel 伪代码"""

    def forward(
        self,
        query: Tensor,                    # [num_heads, head_dim]
        k_cache: Tensor,                  # [num_blocks, block_size, num_kv_heads, head_dim]
        v_cache: Tensor,                  # 同上
        block_table: Tensor,              # [max_num_blocks] 物理块映射
        context_len: int,
    ) -> Tensor:
        """分页注意力的核心：通过 block_table 间接寻址 KV Cache"""
        output = zeros_like(query)
        num_blocks = (context_len + BLOCK_SIZE - 1) // BLOCK_SIZE

        for block_idx in range(num_blocks):
            physical_block = block_table[block_idx]
            # 从非连续的物理块中加载 K/V
            k_block = k_cache[physical_block]  # [block_size, num_kv_heads, head_dim]
            v_block = v_cache[physical_block]

            # 仅对有效 token 位置计算 attention
            valid_len = min(BLOCK_SIZE, context_len - block_idx * BLOCK_SIZE)
            output += attention(query, k_block[:valid_len], v_block[:valid_len])

        return output

2.3 PagedAttention 的实际收益

实测数据显示，PagedAttention 可以将显存利用率从传统方案的 ~20-40% 提升到 95% 以上：

传统方案：预分配 max_seq_len × batch_size × KV_hidden
  - 70B 模型, batch=8, max_seq=4096
  - 实际需要：8 × 320KB × 4096 = 10.0 GB
  - 但碎片和预分配浪费约 60-80%

PagedAttention：按实际 token 数动态分配
  - 假设平均实际生成长度只有 1024 token
  - 实际需要：8 × 320KB × 1024 = 2.5 GB
  - 浪费仅 ~5%（块内最后一个块的部分空间）

结论：PagedAttention 让 OOM 概率降低 3-5 倍，同时允许支持更大的 batch size。

三、KV Cache 量化与压缩：用精度换显存

3.1 非对称量化：Key 和 Value 差异处理

KV Cache 的 K 和 V 分量对量化的敏感度不同。Key 值分布在注意力 softmax 中参与比较运算，对精度敏感；Value 在加权求和后相对鲁棒。实践采用非对称量化策略：

import torch

class KVCacheQuantizer:
    """KV Cache 在线 FP8 量化器（配合 FP8 Eigen Engine）"""

    def __init__(self, num_layers: int, quant_dtype=torch.float8_e4m3fn):
        self.quant_dtype = quant_dtype
        # 每层独立的缩放因子（在线校准）
        scale_k = torch.ones(num_layers, dtype=torch.float32, device='cuda')
        scale_v = torch.ones(num_layers, dtype=torch.float32, device='cuda')

    def quantize_cache(
        self,
        k_cache: torch.Tensor,   # [num_blocks, block_size, num_kv_heads, head_dim]
        v_cache: torch.Tensor,
        layer_idx: int,
    ) -> tuple[torch.Tensor, torch.Tensor, float, float]:
        """FP8 非对称量化：scale to [-max, max]"""
        # 计算当前层 block 的最大绝对值作为缩放基准
        with torch.no_grad():
            scale_k = k_cache.abs().max() / torch.finfo(self.quant_dtype).max * 1.01
            scale_v = v_cache.abs().max() / torch.finfo(self.quant_dtype).max * 1.01

        # 量化：fp16 → fp8
        k_quantized = (k_cache / scale_k).to(self.quant_dtype)
        v_quantized = (v_cache / scale_v).to(self.quant_dtype)

        return k_quantized, v_quantized, scale_k.item(), scale_v.item()

    def dequantize_and_compute(
        self,
        k_quantized: torch.Tensor,
        scale_k: float,
    ) -> torch.Tensor:
        """反量化回 BF16 用于注意力计算"""
        return k_quantized.to(torch.bfloat16) * scale_k

3.2 GQA 与 MLA：从架构层面压缩 KV Cache

除了运行时量化，模型架构创新也极大降低了 KV Cache 压力。以 DeepSeek-V2 的 MLA（Multi-head Latent Attention）为例：

# 标准 GQA 的 KV Cache 大小对比
def standard_gqa_cache(
    num_heads=32, head_dim=128, num_layers=28, dtype=2
):
    """Qwen-2.5 7B（GQA）：每个 token 32 个 KV head"""
    return num_layers * num_heads * head_dim * 2 * dtype  # 28×32×128×2×2 ≈ 448KB/token

def mla_compressed_cache(
    kv_lora_rank=512, qk_rope_head_dim=64, num_layers=28, dtype=2
):
    """DeepSeek-V2 MLA：KV 被压缩到低秩 latent 向量"""
    return num_layers * (kv_lora_rank + qk_rope_head_dim) * dtype
    # 28 × (512 + 64) × 2 ≈ 32KB/token —— 只有标准 GQA 的 7%

MLA 通过将 KV 投影到一个低秩 latent 空间，再以微小精度代价恢复，实现了 10 倍以上的 KV Cache 压缩比。这是当前最有效的显存优化路径之一。

四、CPU KV Cache Offloading：用 PCIe 带宽换显存容量

当 GPU 显存不足以承载全部活跃请求时，可以将部分 KV Cache 卸载到系统内存。NVIDIA TensorRT-LLM 和 vLLM 均支持此特性。

4.1 Offloading 的核心权衡

class CPUOffloadingStrategy:
    """动态 KV Cache Offloading 策略"""

    def __init__(
        self,
        gpu_block_limit: int = 4096,      # GPU 块上限
        cpu_block_limit: int = 16384,     # CPU 块上限（系统内存充足）
        swap_bandwidth_gb_s: float = 32.0, # PCIe 4.0 x16 单向带宽
        block_size_kb: float = 320.0,     # 每个块的 KB 数
    ):
        self.gpu_limit = gpu_block_limit
        self.cpu_limit = cpu_block_limit
        self.swap_bandwidth = swap_bandwidth_gb_s
        self.block_size_kb = block_size_kb

    def swap_time_ms(self, num_blocks: int) -> float:
        """计算将 N 个块从 CPU 换入 GPU 的延迟"""
        transfer_mb = (num_blocks * self.block_size_kb) / 1024
        return (transfer_mb / (self.swap_bandwidth * 1024)) * 1000  # ms

    def should_offload(self, pending_requests: int, active_requests: int) -> bool:
        """决策是否进行 Offload"""
        # 预测活跃请求将超出 GPU 容量时提前 offload
        predicted_blocks_needed = pending_requests * self.avg_blocks_per_request
        gpu_available = self.gpu_limit - active_requests * self.avg_blocks_per_request

        return predicted_blocks_needed > gpu_available

    def offload_under_pressure(
        self,
        block_allocator: BlockAllocator,
        lru_seqs: list[str],
    ) -> list[str]:
        """GPU 显存压力下，将最近最少使用的序列 KV 块卸载到 CPU"""
        offloaded = []
        # 选择 TTL 最大的序列 offload（冷序列）
        for seq_id in reversed(lru_seqs):  # 从 LRU 端开始
            blocks_to_offload = block_allocator.allocated[seq_id]
            # 异步 DMA 传输（不应阻塞 GPU 计算）
            self._async_offload_to_cpu(blocks_to_offload)
            block_allocator.free(seq_id)
            offloaded.append(seq_id)

            # 释放够了就停止
            if len(block_allocator.free_blocks) > self.min_free_threshold:
                break

        return offloaded

4.2 实测 Offloading 延迟影响

在 PCIe 4.0 x16 链路下的典型数据：

Offloading 延迟测试 (A100 80GB + DDR4-3200):
  - 单个 320KB 块的传输延迟：~10 μs
  - 一个 4096-token 请求（128 个块）的换入延迟：~1.3 ms
  - Decode 阶段每个 token 的计算延迟：~8-15 ms

  结论：Offload 引入的开销仅 ≈ 10%，在可接受范围内

  但如果 batch 中的每个 token 都需要多次 offload，
  则流水线气泡会导致吞吐量下降 30-50%

  最佳实践：仅对长序列 / 低优先级请求进行 offload

五、自适应请求准入控制（Admission Control）

当 KV Cache 和 Offloading 都已无法阻止显存耗尽时，系统需要主动拒绝或排队新请求——这就是准入控制。

5.1 Token Bucket 准入算法

import time
from dataclasses import dataclass

@dataclass
class AdmissionDecision:
    allowed: bool
    queue_position: int = 0
    estimated_wait_ms: int = 0

class TokenBucketAdmissionController:
    """基于可用显存容量的请求准入控制器"""

    def __init__(
        self,
        total_gpu_memory_mb: float = 80000.0,
        model_weights_mb: float = 14000.0,    # FP16 7B ≈ 14GB
        reserved_headroom_mb: float = 4096.0,  # 保留 4GB 安全余量
        safety_factor: float = 1.2,            # 20% 安全系数（应对预测误差）
    ):
        self.max_kv_budget = (
            total_gpu_memory_mb - model_weights_mb - reserved_headroom_mb
        ) / safety_factor  # 可用 KV Cache 显存预算
        self.current_kv_usage_mb: float = 0.0
        self.max_seq_tokens: int = 4096         # 最大序列长度
        self.kv_per_token_kb: float = 320.0     # 每 token KV 字节数

    def estimate_request_memory_mb(
        self,
        prompt_tokens: int,
        max_new_tokens: int,
    ) -> float:
        """预测请求的 KV Cache 峰值显存（MB）"""
        # 保守估计：prompt + 最大生成长度
        peak_tokens = prompt_tokens + max_new_tokens
        return (peak_tokens * self.kv_per_token_kb) / 1024.0

    def admit(
        self,
        prompt_tokens: int,
        max_new_tokens: int,
        priority: str = "normal",
    ) -> AdmissionDecision:
        """决策是否允许新请求进入系统"""
        required_mb = self.estimate_request_memory_mb(prompt_tokens, max_new_tokens)

        # 紧急模式：显存使用率 > 95%，仅接受高优先级
        if self.usage_ratio > 0.95 and priority != "high":
            return AdmissionDecision(
                allowed=False, 
                queue_position=self.queue_length + 1,
                estimated_wait_ms=self._estimate_wait(0),
            )

        # 预测接纳后是否超出预算
        projected_usage = self.current_kv_usage_mb + required_mb

        if projected_usage <= self.max_kv_budget:
            self.current_kv_usage_mb = projected_usage
            return AdmissionDecision(allowed=True)
        else:
            # 估算需要等待的时间
            avg_release_rate = self._avg_kv_release_rate_per_sec()
            wait_mb = projected_usage - self.max_kv_budget
            wait_ms = int((wait_mb / max(avg_release_rate, 1)) * 1000)

            return AdmissionDecision(
                allowed=False,
                queue_position=self.queue_length + 1,
                estimated_wait_ms=min(wait_ms, 30000),
            )

    @property
    def usage_ratio(self) -> float:
        """当前 KV Cache 使用率"""
        return self.current_kv_usage_mb / self.max_kv_budget

    def release_memory(self, prompt_tokens: int, gen_tokens: int):
        """完成请求后释放显存配额"""
        released_mb = ((prompt_tokens + gen_tokens) * self.kv_per_token_kb) / 1024.0
        self.current_kv_usage_mb = max(0.0, self.current_kv_usage_mb - released_mb)

5.2 动态 max_new_tokens 截断

在生产请求中，客户端经常设置过大的 max_new_tokens（如 8199）。准入控制器可以动态截断：

def dynamic_max_tokens(
    request_max: int,
    usage_ratio: float,
    prompt_tokens: int,
    max_seq_length: int,
) -> int:
    """
    根据当前显存压力动态调整 max_new_tokens
    - 低压力: 允许完整长度
    - 中压力: 逐步截断
    - 高压力: 仅允许极短回复
    """
    remaining_capacity = max_seq_length - prompt_tokens

    if usage_ratio < 0.5:
        return min(request_max, remaining_capacity)
    elif usage_ratio < 0.75:
        # 截断到请求的 75%
        return min(int(request_max * 0.75), remaining_capacity)
    elif usage_ratio < 0.9:
        # 截断到 50%，最少保留 50 token
        return max(int(request_max * 0.5), 50)
    else:
        # 紧急模式：仅允许 100 token
        return min(100, remaining_capacity)

六、生产急救：OOM Kill 后的降级与恢复

6.1 分级降级策略

class EmergencyDegradation:
    """GPU 显存紧急降级策略链"""

    def __init__(self, vllm_engine):
        self.engine = vllm_engine
        self.degradation_log: list[tuple[float, str]] = []  # (timestamp, action)

    def handle_oom(self, pending_batch_size: int) -> dict:
        """
        OOM 后的分级降级：
        1. 降低 max_num_seqs → 缩小 batch
        2. 触发 KV Cache 驱逐 → 释放低优先级序列
        3. 切换 CPU Offloading → 将冷 KV 卸载
        4. 启用激进量化 → FP8 KV 替代 FP16
        5. 最终手段：拒绝所有新请求
        """
        actions = {}

        # Level 1: 缩小 batch size
        current_batch = self.engine.max_num_seqs
        if pending_batch_size < current_batch:
            new_batch = max(1, pending_batch_size // 2)
            self.engine.update_config(max_num_seqs=new_batch)
            actions['reduce_batch'] = f"{current_batch} → {new_batch}"

        # Level 2: 驱逐低优先级序列
        evicted = self.engine.kv_cache_manager.evict_lowest_priority(k=4)
        if evicted > 0:
            actions['evict_sequences'] = evicted

        # Level 3: Activate CPU offloading for cold sequences
        if self.engine.cpu_offloading_enabled:
            offloaded = self.engine.offload_cold_sequences(threshold_seconds=300)
            actions['cpu_offload'] = offloaded

        # Level 4: 切换到 FP8 KV Cache
        if not self.engine.kv_cache_quantized:
            self.engine.enable_kv8_quantization()
            actions['fp8_kv_switch'] = True

        # Level 5: 极端模式——停止接纳
        if self.engine.gpu_memory_usage() > 0.98:
            self.engine.stop_admission()
            actions['halt_admission'] = True

        self.degradation_log.append((time.time(), str(actions)))
        return actions

    def recovery_check(self) -> bool:
        """检查是否可以从降级模式恢复"""
        return self.engine.gpu_memory_usage() < 0.75

6.2 监控告警配置

OOM 的预防胜于治疗。以下为 Prometheus + Grafana 的关键告警规则：

# prometheus-alerts.yml
groups:
  - name: llm-gpu-memory
    rules:
      # 预警：KV Cache 使用率 > 80%
      - alert: KVCachePressure
        expr: |
          (vllm_gpu_cache_usage_per{quantization="fp16"} / vllm_gpu_cache_total_blocks) > 0.80
        for: 30s
        labels:
          severity: warning
        annotations:
          summary: "KV Cache 使用率超过 80%，启动扩容或限流"

      # 紧急：显存使用率 > 95%
      - alert: GPUNearOOM
        expr: |
          (nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes) > 0.95
        for: 10s
        labels:
          severity: critical
        annotations:
          summary: "GPU 显存接近耗尽！即将触发 OOM 保护降级"

      # 致命：已发生 OOM
      - alert: GPUOOMKilled
        expr: increase(nvidia_gpu_oom_events[5m]) > 0
        labels:
          severity: critical
        annotations:
          summary: "GPU OOM 事件发生，检查准入控制是否过于宽松"

七、生产环境配置基准与选型建议

以下是在不同规模部署中经过验证的配置经验：

7.1 小型部署（单卡 A100 80GB，7B 模型）

serving:
  model: meta-llama/Llama-2-7b-hf
  tensor_parallel: 1
  gpu_memory_utilization: 0.85     # 留出余量给 Activation
  max_num_seqs: 32                 # 默认 batch 大小
  max_model_len: 4096              # 限制序列长度
  kv_cache_dtype: fp16             # 7B 显存压力不大

admission_control:
  enable: true
  safety_factor: 1.15
  reserved_headroom_mb: 2048

recovery:
  target_vram_usage: 0.80          # 低于此值正常运行
  throttle_threshold: 0.90         # 高于此值开始限流

7.2 中型部署（2×A100 80GB，13B 模型，张量并行）

serving:
  model: meta-llama/Llama-2-13b-hf
  tensor_parallel: 2
  gpu_memory_utilization: 0.90
  max_num_seqs: 24
  max_model_len: 8192
  kv_cache_dtype: fp8_e4m3         # FP8 量化节省 50% KV 空间

admission_control:
  enable: true
  safety_factor: 1.2
  reserved_headroom_mb: 4096

offloading:
  enable_cpu_offload: true
  cpu_cache_ratio: 0.4            # 最多允许 40% 的 KV 在 CPU 上
  min_gpu_blocks: 512             # GPU 至少保留 512 个热块

7.3 大型部署（8×H100 80GB，70B 模型，张量并行 + Pipeline 并行）

serving:
  model: meta-llama/Llama-2-70b-hf
  tensor_parallel: 8
  pipeline_parallel: 2
  gpu_memory_utilization: 0.93
  max_num_seqs: 64
  max_model_len: 16384
  kv_cache_dtype: fp8_e4m3

  # Chunked Prefill 将长 prompt 分块处理，避免单次 batch 显存爆炸
  enable_chunked_prefill: true
  max_num_batched_tokens: 2048

admission_control:
  enable: true
  safety_factor: 1.25              # 70B 预测误差大，安全系数更高
  reserved_headroom_mb: 8192
  dynamic_max_tokens: true         # 启用动态截断

quantization:
  # 使用 AWQ 或 GPTQ 将模型权重量化到 4-bit，释放更多空间给 KV Cache
  model_quantization: awq_4bit     # 70B 权重大约 35GB（原 140GB）

monitoring:
  oom_alert_threshold: 0.90
  degrade_levels:
    - threshold: 0.92
      action: reduce_batch_by_half
    - threshold: 0.95
      action: evict_lowest_priority(4)
    - threshold: 0.97
      action: enable_fp8_kv
    - threshold: 0.99
      action: halt_admission

八、结语：从被动救火到主动防御

GPU 显存管理在 AI 推理服务中已经从"事后急救"演进为"主动容量规划"。核心原则总结如下：

1. 永远不要信任 max_seq_len：使用 PagedAttention 按实际 token 数分配，消除预分配浪费。
2. 多级防线设计：准入控制 → 动态 batch 调整 → KV 驱逐 → CPU Offload → 量化降级，层层递进。
3. KV 量化是性价比最高的优化：FP8 KV 在几乎不损失模型精度的前提下节省 50% 显存。
4. Offloading 适合长序列但需警惕带宽瓶颈：PCIe 带宽不是无限的，要限制同时卸载的请求数。
5. 监控先行：超过 80% KV 使用率时应预警，超过 90% 应自动限流。

OOM 不是 LLM 推理的"意外故障"，而是系统设计的正常边界条件。理解了这些工程手段，你就能在有限的 GPU 资源上榨取最后一分吞吐量。

---

作者注：本文涉及的代码基于 vLLM v0.4+ 和 TensorRT-LLM v0.10+ 的架构设计，具体 API 可能因版本迭代略有不同。工程实践部分基于 A100/H100 集群上的真实部署数据。建议读者在生产环境实施前，使用小规模流量进行 48 小时以上的稳定性验证。