这篇论文提出了一种新的职责分配方式：把原本必须在运行时，极短时延内完成的预取决策，转移到离线的大模型静态分析里；运行时硬件只负责极轻量地执行这些 hints

背景问题

论文聚焦 硬件数据预取（hardware data prefetching）

已有方案主要有两类：

  1. 单一专用预取器
    • 问题: 现实程序的访存模式是分阶段变化的，一个程序内部往往同时混有多种模式，所以单一预取器很难全覆盖
  2. prefetcher ensemble（预取器集成）: 把多个预取器拼在一起，然后再用一个在线策略决定:
    • 某个 demand request 要喂给哪个子预取器训练
    • 某个子预取器发出的 prefetch request 是否真的需要发出
      问题：这类在线管理策略通常依赖运行时试错和学习，适应慢，而且受芯片面积, 功耗, 时序约束，策略一般比较简单

论文的观察是：对很多 load 指令来说，最佳预取策略其实能从静态代码上下文里看出来

作者的思路是：用LLM 来自动做这个判断

  1. LLM 能做“代码语义级”理解
    • 传统硬件预取器观测的是地址流
    • 编译器启发式往往也只是局部模式匹配
    • LLM 可以从代码上下文中推断更高层语义
  2. LLM 可以自动学习启发式，而不是手工写规则
  3. 比 PGO 更泛化
    • PGO 是“这个程序在这些输入下 profiling ，再总结最佳策略”
    • PF-LLM 是“从很多程序的整体经验里，学出一般规律，再去推断新程序”
  4. 直接工作在 assembly 上
    • 即使是闭源二进制，只要能静态反汇编，就能分析

核心思想

这篇论文提出两部分组成的框架：

  1. PF-LLM：离线分析 assembly 上下文，为每条 load 指令生成预取 hints
  2. LMHint Prefetcher：运行时硬件预取框架，消费这些 hints，驱动一个预取器 ensemble

不是让 LLM 直接在线控制硬件；而是：

  • 离线：LLM 读代码，预测“这条 load 应该用什么预取器, 预取激进程度, 是否该屏蔽某些子预取器的训练输入”
  • 在线：硬件用一个很小的查表结构按 PC 取 hint，然后按照 hint 预取

PF-LLM

Input

输入: 反汇编后的 assembly (主要时为了针对闭源二进制)

目标 load 周围的 257 行 assembly (目标 load 前 128 行 + 后 128 行)

Output

PF-LLM 针对每个 load instruction 输出三类 hint：

  1. Prefetcher Selection：这条 load 最适合哪一个子预取器
  2. Prefetch Degree：该预取得保守, 中等还是激进
  3. Demand Request Filtering：这条 load 的 demand request 不要输入到哪个子预取器训练，以避免污染它的内部状态

没有试图让 LLM 直接预测具体预取地址，而是预测 policy-level control signal (更容易嵌入现有硬件)

Model

模型: Qwen-2.5-Coder-0.5B-Instruct

原因很直接：

  • 任务高度专门化；
  • 不需要特别大的通用推理能力
  • 小模型训练和推理便宜
  • 更适合未来离线批量部署

输入输出约束成 JSON:

  • 训练和推理都通过 instruction-tuned 格式包装
  • 要求模型输出结构化 JSON，其中包含 "PF Sel", "PF Degree", "Filter"
  • 用 <load>...</load> 专门标出目标 load 的位置，并把这两个 tag 作为特殊 token 加进 embedding table

训练数据: 怎么构造 ground truth

  1. 先选定一个预取器集合和各自可选 degree
  2. 对 benchmark 程序做大量 ChampSim 仿真
  3. 对每条 load PC，记录在每种预取策略下的 AMAT
  4. 选 AMAT 最小的配置作为这条 load 的最优策略标签
  5. 选表现最差的预取器，作为可过滤对象的候选

标签不是人工语义标签，而是“通过架构仿真得到的性能最优标签”

将问题从自然语言/代码理解，转成了一个 静态代码 → 微结构最优决策 的监督学习问题

运行时硬件 LMHint Prefetcher

两级结构：

  • PHT（Prefetch Hint Table）：主存里的大表，按 load 的虚拟 PC 索引
    • 预取 hint 是静态的，适合按 PC 建表
  • PHB（Prefetch Hint Buffer）：片上的小 buffer，类似 TLB，缓存最近使用的 hints

运行时流程：

  1. load 发射
  2. 用 PC 查 PHB
  3. 取出 8-bit hint
  4. 控制 ensemble

每条 hint 为 8 bit：

  • 4 bit：prefetcher selection 决定允许哪个子预取器给这条 load 发 prefetch
  • 2 bit：degree 决定它的 aggressiveness
  • 2 bit：filtering policy 决定某个子预取器是否不该接收这条 demand request 作为训练输入

Demand Filtering

传统 ensemble 的一个问题在于：

  • 有些高级 spatial prefetcher 不是按单个 PC 索引的，而是跟踪更大区域、更复杂的访问关系
  • 如果用简单的 PC-centric 选择逻辑作为开关预取器的输入，可能会污染它的状态，反而让它失效

作者认为 demand filtering 能帮助 ensemble：

  • 让某个子预取器只训练它擅长的那部分访存
  • 避免不相关 load 破坏其模式检测

作者承认: 不是所有预取器都适合做 filtering
对于 Pythia, Bingo, DSPatch, Sandbox, SMS 这类复杂预取器，他们明确限制 不对其进行 demand filtering，因为这类组件对输入状态很脆弱

实验

Setup

作者在 ChampSim 上做实验，核心配置接近 Arm Neoverse N2 风格的单核系统

训练集使用 SPEC 2006 memory-intensive benchmarks，测试集使用 SPEC 2017 memory-intensive benchmarks，刻意避免数据泄漏

训练方面：

  • 基模：Qwen-2.5-Coder-Instruct
  • 8 张 NVIDIA H20
  • BF16
  • lr = 1e-5
  • effective batch size = 64
  • 2 epochs

loss 只算在模型输出的 JSON token 上，不算输入 assembly 和 prompt
(目的是使模型专注于学 hint 预测，而不是记输入文本)

1. 模型精度

PF-LLM 在 held-out test set 上达到 95.0% 的策略预测准确率

错误预测往往不是随机乱选，而是接近 second-best option，因此性能损失有限。

2. SPEC 2017 上的性能

最完整配置 LMHint-SDF 相比：

  • 最强单一预取器 Sandbox：平均 IPC 提升 9.8%
  • 最强已有 ensemble 方法 Alecto：平均 IPC 提升 18.9%

3. 消融实验

作者定义了几种配置：

  • LMHint-S：只用 selection
  • LMHint-SD：selection + degree
  • LMHint-SDF：selection + degree + filtering
  • LMHint-SDFR：只保留最常用的四个子预取器的低成本版本

结果显示：

  • selection 是最大头的收益来源；
  • degree 在其上再加约 0.3% IPC
  • filtering 再加约 0.3% IPC。

Reduced-cost 版本的意义:(LMHint-SDFR)

  • 平均性能甚至比完整 SDF 高 0.01%
  • 说明：不一定需要把 11 个预取器全都做进硬件里，做一个更小但被 LLM 强约束过的 ensemble，也可能够用

4. 真实 Web 服务负载上的结果

作者还测了真实应用：

  • Apache HTTP Server
  • MySQL
  • RocksDB
  • Xapian

并且把主存延迟提高 2×，模拟数据中心拥挤环境

结果显示 LMHint 仍优于所有单一预取器和 ensemble baseline

但这些 workload 的提升比 SPEC 温和，原因主要有两个：

  1. 这些应用更偏 I/O-bound，而不是纯 CPU/memory-bound
  2. 这些应用被人工优化得很充分，自带缓存/预取机制，增益空间较小

5. 开销分析

5.1 离线推理成本

  • 在 1 张 NVIDIA H20 上，吞吐可到 234 req/s
  • 对整个 SPEC 2017 套件生成 hints，总共要 38.5 分钟
  • 在 16 核机器上编译整个套件约 25.4 分钟

结论：一次性离线开销，在开发部署流程里是可以接受的

5.2 存储成本

PHT(主存中) 中每条 entry 存：(合计 56 bit，即 7 byte / load)

  • 48-bit virtual PC
  • 8-bit hint

作者统计 SPEC 2017 后得出：

  • 平均每 MB 可执行代码约有 10.62K 个 load instructions
  • PHT 开销约 74.34 KB / MB binary，相当于 7.26% 静态程序体积增加。

Limits and Futurn Work

  1. 工程落地问题
    • toolchain 与 binary distribution 流程集成
    • OS/loader 配合: OS loader 可能需要针对 ASLR 做相应的处理
    • ISA/平台迁移
    • 多核共享 cache/带宽干扰
    • 不同输入下同一 PC 策略漂移
    • 安全与可验证性
  2. 训练的 loss 函数取决于：在作者给定的子预取器集合, degree 离散方式, 仿真环境下，哪种策略最优
    • 但它不是对“真实世界最优预取行为”的完全逼近
  3. 标签生成使用的是逐 load 的局部最优启发式
    • 作者按 load PC 选择最小 AMAT 的配置作为 ground truth
    • 不同 load 之间会通过 cache, 带宽, MSHR, prefetch queue 相互影响
  4. 静态上下文不能覆盖动态 phase 行为
    • 数据依赖驱动的路径变化
    • 相同 PC 在不同输入上表现为不同模式
    • 复杂 aliasing
    • 多态/间接调用引起的控制流不确定性
    • 同一 PC 在不同 phase 中访存局部性不同
  5. 只在单核, L1D, x86-64 静态二进制上验证
    • 不支持 JIT / bytecode 程序