1. 大语言模型内存访问的痛点与挑战

现代AI加速器在处理大语言模型（LLM）时面临一个根本性矛盾：计算单元需要连续吞吐数百KB到MB级别的数据块，而底层内存系统却仍以32B/64B的缓存行粒度提供服务。这种不匹配导致HBM内存系统在服务LLM时产生严重的效率瓶颈。

以典型的Llama 3 70B模型为例，其单个注意力层的权重矩阵可达12MB，KV缓存可能增长到数十MB。当这些数据通过传统HBM接口传输时，会被拆分成超过37万次32B的缓存行访问。每次访问都需要内存控制器执行完整的命令序列：激活(ACT)→读取(RD)→预充电(PRE)，同时还要维护16个bank、4个bank group和2个pseudo channel的复杂状态机。

2. 传统HBM架构的效率瓶颈

2.1 缓存行粒度访问的代价

现代HBM系统采用缓存行粒度访问主要基于两个历史假设：

1. 匹配CPU/GPU的缓存行大小（32B/64B）
2. 适应不规则的内存访问模式

但在LLM场景下，这两个假设都不成立。如图1所示，LLM的权重、激活值和KV缓存都呈现连续的大块访问特征。维持细粒度访问带来的代价包括：

• 命令/地址(CA)引脚开销 ：HBM4中每个64b数据通道需要18个CA引脚（10行+8列），CA/DQ引脚比达28%
• 调度复杂度 ：内存控制器需要维护7种bank状态和15+个时序参数
• 内部总线利用率低 ：BG-BUS（1GHz）实际带宽利用率不足50%

2.2 层级化结构的调度负担

为维持缓存行粒度同时提升带宽，HBM引入了bank group和pseudo channel结构：

结构	作用	带来的复杂度
Bank Group	通过交错访问隐藏tCCDS延迟	需要维护跨bank group的时序约束
Pseudo Channel	通过窄通道增加并发度	CA引脚数量线性增长

如图2所示，从HBM1到HBM4，CA引脚带宽需求增长了3倍，而有效数据带宽提升主要依赖引脚数量增加而非架构革新。

3. RoMe的核心设计思想

3.1 行粒度访问接口

RoMe提出用两个精简命令替代传统DRAM命令集：

• RD_row ：读取整行数据（典型4KB）
• WR_row ：写入整行数据

这种设计基于LLM负载的关键特征：

1. 空间局部性 ：90%以上的访问是连续地址
2. 访问粒度 ：90%请求大于8KB
3. 可预测性 ：GEMM/GEMV操作模式固定

3.2 虚拟存储体(Virtual Bank)架构

RoMe创新性地提出虚拟存储体(VBA)概念，通过三种方式重构bank组织：

1. 物理bank合并 （图7c）：

   • 将同一bank group内的2个物理bank合并
   • 共享I/O控制缓冲区
   • 有效行大小翻倍(4KB→8KB)

2. 跨bank group交错 （图7d）：

   • 不同bank group的bank组成VBA
   • 利用现有BG-BUS实现带宽聚合
   • 无需修改DRAM内部结构

3. 伪通道融合 （图8b）：

   • 两个pseudo channel协同工作
   • 共享CA引脚但独立数据传输
   • 等效通道宽度恢复至128b

4. 内存控制器的简化设计

4.1 状态机精简

传统内存控制器需要维护7种bank状态，而RoMe仅需3种：

1. IDLE ：存储体就绪
2. ACTIVE ：行已激活
3. REFRESH ：刷新中

状态转换图简化为：

IDLE → ACTIVE → IDLE
       ↳ REFRESH → IDLE

4.2 时序参数优化

RoMe消除的时序约束包括：

• 跨bank group时序（tRRDS/tCCDS）
• 行命中/冲突参数（tRCD/tRP/tRAS）
• 读写转换延迟（tWTR/tRTW）

保留的核心参数仅剩：

• tREFI：刷新间隔
• tRC：行周期时间
• tRFC：刷新周期

4.3 调度算法革新

RoMe采用两级调度策略：

1. VBA间交错 ：轮询可用VBA
2. 命令流水线 ：隐藏行激活延迟

与传统调度器对比：

指标	传统MC	RoMe MC	优化幅度
调度决策周期	15-20ns	2-3ns	85%↓
状态查询延迟	CAM查找	直接索引	90%↓
硬件资源占用	32K gates	8K gates	75%↓

5. 实现效果与性能分析

5.1 带宽提升机制

RoMe通过两种途径提升有效带宽：

1. CA引脚复用 ：减少50% CA引脚，用于增加通道数
2. 总线利用率 ：BG-BUS利用率从45%提升至92%

在HBM4配置下：

• 原始设计：16通道×2TB/s
• RoMe设计：18通道×2.25TB/s
• 带宽增益：12.5%

5.2 实际工作负载测试

使用Llama 3 70B模型测试：

阶段	传统HBM	RoMe	加速比
Prefill	38ms	32ms	1.19x
Decode(avg)	5.2ms	4.3ms	1.21x

5.3 能效比改进

由于调度复杂度降低带来的收益：

• 动态功耗：降低17%（主要来自CA总线）
• 静态功耗：降低9%（简化控制逻辑）
• 能效比：提升23%（TOPS/W）

6. 工程实现中的关键考量

6.1 数据对齐处理

行粒度访问需要特殊处理非对齐请求：

// 示例：处理8KB请求但起始地址不对齐4KB边界
void* aligned_addr = (void*)((uintptr_t)addr & ~0xFFF);
size_t padding = addr - aligned_addr;
dma_transfer(aligned_addr, 8KB + padding);

6.2 刷新机制优化

RoMe采用bank分组刷新策略：

1. 将VBAs分为3组
2. 每组轮流刷新
3. 保证至少2个VBA可用

6.3 异常处理流程

针对行访问失败的特殊情况：

1. ECC校验失败时回退到缓存行模式
2. 记录错误行地址避免重复访问
3. 触发中断通知驱动层

7. 与传统方案的兼容设计

RoMe提供两种工作模式：

1. 原生模式 ：完全使用行粒度接口
2. 兼容模式 ：通过命令生成器转换传统命令

模式切换流程：

写配置寄存器 → 复位内存控制器 → 重训练PHY

实测模式切换延迟仅18μs，适合混合负载场景。

8. 实际部署建议

8.1 硬件配置要求

• 建议搭配≥4MB的片上缓存
• 需要DMA引擎支持scatter-gather
• 建议PCIe Gen5以上互联

8.2 软件栈适配

需要修改的软件组件：

1. 驱动层：实现行粒度分配器
2. 运行时：优化tensor布局
3. 编译器：插入预取提示

典型部署时间表：

Day1-3：硬件bring-up
Day4-7：驱动开发
Day8-14：性能调优

9. 扩展应用场景

除LLM外，RoMe还适用于：

1. 科学计算：CFD、分子动力学
2. 媒体处理：8K视频编辑
3. 数据库：列式存储扫描

在OLAP场景测试中，RoMe使ClickHouse的scan性能提升41%。