Helios加速器：突破LLM推理瓶颈的近内存处理技术
1. 项目概述：Helios加速器的设计背景与核心创新
在当今AI服务领域，大型语言模型（LLM）的在线推理服务面临两大关键挑战：计算密集型的预填充阶段和内存密集型的解码阶段。传统GPU架构虽然擅长处理矩阵运算，但其内存带宽（通常仅2-3TB/s）与计算能力（数十TFLOPS）之间存在两个数量级的差距，导致解码阶段成为性能瓶颈。近内存处理（NMP）技术通过将处理引擎（PE）集成到DRAM模块中，理论上可将有效带宽提升至10TB/s量级，但现有方案存在严重的资源利用率问题。
Helios创新性地采用混合键合（Hybrid Bonding）三维集成技术，在四个关键维度实现突破：
- 动态KV缓存管理：将传统以注意力头为单位的固定分配改为以token块（通常256-512 tokens/块）为单位的动态分配，使内存利用率从平均37%提升至89%
- 分布式分块注意力：首创NMP-native的在线softmax算法，支持跨PE的迭代式注意力计算，使长上下文（10K tokens）处理的延迟降低72%
- 空间感知调度：基于PE间的NoC拓扑结构优化KV块放置策略，使跨PE数据传输量减少63%
- 异构计算架构：通过PCIe-CXL异构集群实现预填充（GPU）与解码（Helios）的物理分离，避免计算资源争用
实测数据显示，在服务LLaMA3-70B模型时，当请求长度差异达8倍（1K vs 8K tokens）时，Helios仍能保持90%以上的PE利用率，而传统NMP方案此时利用率会骤降至35%以下。
2. 硬件架构设计解析
2.1 混合键合集成技术
Helios的核心突破源于其创新的三维堆叠架构。通过铜-铜直接键合（Cu-Cu Hybrid Bonding）技术，将逻辑层与四层DRAM进行垂直集成，关键参数包括：
- 键合密度：110,000 I/O/mm²（间距3μm）
- 互连电阻：<0.5Ω
- 能效比：0.66pJ/bit（相比HBM降低58%）
图：Helios的四层DRAM堆叠架构，通过微型TSV实现层间互连
2.2 处理引擎阵列设计
每个Helios设备包含16×16的PE阵列，每个PE包含：
- 矩阵单元：64×64 MAC阵列，支持BF16/FP8格式
- 在线softmax单元：采用基址重定标技术，误差<1e-6
- 归约单元：支持动态因子生成的向量累加器
- 双缓冲机制：计算缓冲区（128KB）与传输缓冲区（64KB）隔离
// 在线softmax的硬件实现示例 void online_softmax(float* x, float& m_prev, float& l_prev) { float m_curr = max(m_prev, vector_max(x)); float e = exp(x - m_curr); float l_curr = l_prev * exp(m_prev - m_curr) + vector_sum(e); float alpha = l_prev * exp(m_prev - m_curr) / l_curr; m_prev = m_curr; l_prev = l_curr; return e / l_curr; }2.3 网络互连优化
Helios采用双NoC设计应对不同通信模式：
- 路由器NoC：处理PCIe传输和模型并行数据
- PE间NoC：基于mesh拓扑，优化两种通信原语：
- 分块注意力归约：采用X-Y维度交替的reduce-scatter
- KV投影传输：基于请求ID的哈希路由策略
3. 关键算法实现
3.1 动态KV缓存分配
Helios的分配器维护两个核心数据结构：
- 空间哈希表：记录每个PE的空闲块位置
- 拓扑距离矩阵：存储PE间跳数信息
分配策略分三步执行：
- 候选PE筛选：选择空闲容量≥阈值的PE集合
- 拓扑感知排序：优先选择与已有块所在PE跳数少的节点
- 负载均衡调整：确保各PE的计算量差异<15%
3.2 分布式分块注意力
与传统注意力实现的对比：
| 特性 | 传统NMP | Helios |
|---|---|---|
| 计算粒度 | 完整注意力头 | 256-token块 |
| Softmax方式 | 全局归一化 | 在线迭代 |
| 内存访问模式 | 集中式 | 分布式 |
| 最长支持上下文 | 4K tokens | 32K tokens |
迭代式注意力的数学表达：
\begin{aligned} &m^{(t)} = \max(m^{(t-1)}, \max(QK_t^\top)) \\ &l^{(t)} = l^{(t-1)}e^{m^{(t-1)}-m^{(t)}} + \sum e^{QK_t^\top - m^{(t)}} \\ &O^{(t)} = \frac{l^{(t-1)}e^{m^{(t-1)}-m^{(t)}}}{l^{(t)}}O^{(t-1)} + \frac{e^{QK_t^\top - m^{(t)}}}{l^{(t)}}V_t \end{aligned}4. 系统集成与实测性能
4.1 集群部署方案
典型配置包含：
- 8台GPU服务器（A100×8）：处理预填充
- 16台Helios节点（4设备/节点）：专用于解码
- 网络互联：200Gbps RDMA + CXL 2.0
# 启动服务的示例命令 $ heliosd --model llama3-70b \ --tensor-parallel 8 \ --max-batch-size 128 \ --kv-block-size 2564.2 性能基准测试
在LLaMA3-70B上的测试结果：
| 指标 | A100 | AttAcc | Helios |
|---|---|---|---|
| 吞吐量(tokens/s) | 1,240 | 2,780 | 9,150 |
| P99延迟(ms) | 185 | 92 | 23 |
| 能效(tokens/J) | 35 | 68 | 235 |
| 最长上下文支持 | 4K | 8K | 32K |
实测中发现，当块大小设置为512 tokens时，在16K以上长上下文场景会出现约15%的性能下降，建议此时调整为256 tokens以获得最佳吞吐。
5. 工程实践中的挑战与解决方案
5.1 混合键合的散热管理
由于逻辑层被DRAM包围，Helios面临严峻的散热挑战。我们采用的解决方案包括：
- 脉宽调制技术：动态调整PE工作频率，保持结温<85℃
- 非对称布局：将高功耗模块靠近散热柱放置
- 液体冷却接口：在封装顶部集成微流体通道
5.2 不规则请求处理
针对极端场景的优化策略：
- 短请求合并：将<64 tokens的请求合并为超级块
- 长请求拆分：对>16K tokens的请求采用滑动窗口
- 优先级抢占：为高优先级请求保留5%的PE资源
5.3 故障恢复机制
Helios通过三重保障确保服务连续性：
- 块级CRC校验：每256 tokens生成校验码
- 热备PE切换：保留2%的冗余PE资源
- 检查点快照：每5分钟持久化KV缓存状态
6. 未来演进方向
基于现有架构，我们正在探索以下增强：
- 光互连集成：采用硅光技术提升PE间带宽
- 存内计算扩展：支持Attention-Free架构
- 多模态适配：优化视觉token的处理流程
在实际部署中，我们建议从中小模型（7B-13B）开始验证，逐步扩展到更大规模。一个常见的误区是过度追求单设备性能，而忽视了集群级别的负载均衡。根据我们的经验，保持解码集群的峰值利用率在70%-80%区间，才能获得最佳的性价比。