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-scatterKV投影传输基于请求ID的哈希路由策略3. 关键算法实现3.1 动态KV缓存分配Helios的分配器维护两个核心数据结构空间哈希表记录每个PE的空闲块位置拓扑距离矩阵存储PE间跳数信息分配策略分三步执行候选PE筛选选择空闲容量≥阈值的PE集合拓扑感知排序优先选择与已有块所在PE跳数少的节点负载均衡调整确保各PE的计算量差异15%3.2 分布式分块注意力与传统注意力实现的对比特性传统NMPHelios计算粒度完整注意力头256-token块Softmax方式全局归一化在线迭代内存访问模式集中式分布式最长支持上下文4K tokens32K 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上的测试结果指标A100AttAccHelios吞吐量(tokens/s)1,2402,7809,150P99延迟(ms)1859223能效(tokens/J)3568235最长上下文支持4K8K32K实测中发现当块大小设置为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%区间才能获得最佳的性价比。