PrfaaS：跨数据中心 LLM 服务架构——KVCache 传输与选择性 Offload

目标读者：AI Infra 工程师、分布式系统研究员、对大模型服务化有兴趣的开发者 预计阅读时间：50-70 分钟 前置知识：了解 LLM 基本原理、熟悉分布式系统概念、对模型服务化有基础认知 难度定位：⭐⭐⭐⭐ 专家设计

§1 研究背景：为何需要跨数据中心 LLM 服务

1.1 LLM Serving 的挑战

大语言模型（LLM）正在成为 AI 应用的核心引擎。然而，将 LLM 部署到生产环境面临严峻挑战：

1.2 Prefill-Decode Disaggregation 架构

当前大规模 LLM serving 的标准架构是Prefill-Decode（PD） disaggregation：

┌─────────────────────────────────────────────────────────────┐
│                      LLM Serving Architecture                 │
│                                                              │
│   ┌──────────────┐              ┌──────────────┐          │
│   │   Prefill    │              │   Decode     │          │
│   │   Cluster    │   KVCache    │   Cluster    │          │
│   │              │ ──────────▶ │              │          │
│   │  处理输入    │   传输       │  生成输出    │          │
│   │  生成KVCache │              │              │          │
│   └──────────────┘              └──────────────┘          │
│                                                              │
│   特点：                                                      │
│   - Prefill：计算密集，适合高带宽，低延迟                    │
│   - Decode：内存密集，适合大显存，高并发                      │
└─────────────────────────────────────────────────────────────┘

核心思想：将 LLM 推理的两个阶段解耦，分别优化。

1.3 传统方案的局限

在传统 dense-attention 模型中，Prefill 阶段生成巨大的 KVCache 流量，这导致：

• 紧耦合部署：Prefill 和 Decode 必须部署在同一高带宽网络域内
• 异构受限：无法利用不同地理位置的异构 GPU 资源
• 弹性不足：资源扩缩容受限于单一集群

§2 问题分析：为何 KVCache 是瓶颈

2.1 KVCache 的诞生

Transformer 模型的自注意力机制需要访问所有历史 token：

Attention(Q, K, V) = softmax(QK^T / √d) × V

其中 K（Key）和 V（Value）就是所谓的KVCache——每个 token 都会生成一组 KV 向量，需要存储供后续生成使用。

2.2 KVCache 的规模问题

假设一个 100B 参数的 dense 模型，处理 2048 个 token 的上下文：

对于更大上下文（如 32K tokens），KVCache 可达数 GB！

2.3 跨集群 KVCache 传输的挑战

论文指出，即使 hybrid-attention 架构大幅减小了 KVCache 大小，单纯依靠"更小的 KVCache"仍然不足以实现实用的跨数据中心服务：

§3 PrfaaS 设计

3.1 设计理念

PrfaaS（Prefill-as-a-Service）的关键判断：

光把 KVCache 压小不够，系统还得知道哪些 prefill 该 offload、哪些该本地处理。

3.2 整体架构

┌─────────────────────────────────────────────────────────────────┐
│                        PrfaaS Architecture                       │
│                                                                  │
│   ┌─────────────────┐              ┌─────────────────────────┐│
│   │  Remote Prefill │   KVCache    │     Local PD Cluster    ││
│   │     Cluster     │              │                         ││
│   │  (Compute Dense) │ ──────────▶ │  (Decode + Short Prefill) ││
│   │                 │  Ethernet   │                          ││
│   └─────────────────┘              └─────────────────────────┘│
│           ▲                                  │                 │
│           │          Control Plane           │                 │
│           └──────────────────────────────────┘                 │
│                    Selective Offloading                          │
└─────────────────────────────────────────────────────────────────┘

3.3 四大机制

PrfaaS 通过四项核心技术实现跨数据中心服务：

3.3.1 模型侧 KV 效率优化

在模型层面优化 KVCache 的生成和利用效率。

• Hybrid Attention：混合使用 MQA（Multi-Query Attention）、GQA（Group-Query Attention）和 MHA（Multi-Head Attention）
• KVCache 量化：对 KV 向量进行 INT8/FP8 量化，进一步压缩传输量
• 选择性缓存：只缓存高价值的 KVCache（如公共 prefix）

3.3.2 选择性 Offloading

不是所有 prefill 都需要 offload，系统智能决策。

# 决策逻辑示例
def should_offload(request):
    # 长上下文优先offload
    if request.context_length > THRESHOLD:
        return True
    
    # 带宽充足时offload
    if current_bandwidth > BANDWIDTH_THRESHOLD:
        return True
    
    # 缓存命中时本地处理
    if cache_hit_rate > CACHE_THRESHOLD:
        return False
    
    return False

3.3.3 带宽感知调度

根据实时带宽状况动态调整 offload 策略。

3.3.4 缓存感知请求放置

将请求路由到 KVCache 命中率最高的集群。

# 请求放置策略
def place_request(request):
    best_cluster = None
    max_hit_rate = 0
    
    for cluster in clusters:
        hit_rate = estimate_prefix_hit_rate(
            request.prefix, 
            cluster.cache_state
        )
        if hit_rate > max_hit_rate:
            max_hit_rate = hit_rate
            best_cluster = cluster
    
    return best_cluster

§4 技术深度解析

4.1 KVCache 传输协议

PrfaaS 使用基于 TCP 的传输协议，针对 KVCache 特点优化：

4.2 Prefill 集群设计

Remote Prefill 集群特点：

4.3 一致性保证

KVCache 在传输过程中需要保证一致性：

class KVCacheConsistency:
    def __init__(self):
        self.version_map = {}  # prefix → version
        self.inflight = set()  # 传输中的请求
    
    def on_prefill_complete(self, request_id, kv_cache):
        # 1. 版本号递增
        self.version_map[request_id] += 1
        
        # 2. 标记传输完成
        self.inflight.discard(request_id)
        
        # 3. 通知所有相关集群更新本地缓存
        broadcast_to_clusters(request_id, kv_cache)

§5 性能评估

5.1 实验设置

论文使用内部 1T 参数的 hybrid 模型进行评估：

5.2 实验结果

PrfaaS 在三种配置下进行对比：

吞吐量提升：

5.3 关键发现

1. 带宽利用效率高：只消耗适度的跨数据中心带宽
2. 延迟可控：Offload 引入的额外延迟在可接受范围
3. 资源弹性好：Prefill 和 Decode 可独立扩缩容

§6 可复用的经验

1. 选择性优于全量：不是所有操作都需要 offload，智能选择是关键
2. 观察者模式：持续监控带宽、负载、缓存状态，动态调整策略
3. 分層优化：模型层优化 + 系统层优化，形成合力
4. 优雅降级：带宽不足时自动回退到本地处理

6.2 常见陷阱

§7 未来展望

7.1 潜在发展方向

1. 更激进的 KVCache 压缩：如基于学习的量化方法
2. 智能前缀共享：跨请求共享更多前缀 KVCache
3. 多级缓存层次：L1 本地 → L2 集群 → L3 全局
4. 端边云协同：将 offload 扩展到边缘设备

7.2 与现有工作的关系

§8 相关资源

• 论文：arXiv:2604.15039
• 作者：Ruoyu Qin, Weiran He, Yaoyu Wang, Zheming Li, Xinran Xu, Yongwei Wu, Weimin Zheng, Mingxing Zhang
• 领域：Distributed, Parallel, and Cluster Computing (cs.DC)

🦞 撰写于 2026 年 4 月 18 日