ArchLite

2 minute read

Published:

Read this post in English

ArchLite:静态微体系结构决策真的需要大模型吗?

过去几年,系统研究里一个很热的方向是 System for AI:怎样让大模型训练和推理更快、更省显存、更容易部署。ArchLite 关注的是反方向的问题:AI 能不能帮助系统本身做决策? 在今年四月份左右,笔者读了ASPLOS26 best paper PF-LLM: Large Language Model Hinted Hardware Prefetching,产生了一个疑惑,why PF-LLM,but not PF-DNN?PF-LLM 的确在预取决策上取得了不错的效果,但它的模型规模和训练成本也不小。于是便有了这份机器学习大作业———— ArchLite,一个针对静态 load-level prefetching 任务的模型规模对比研究。

更具体一点,ArchLite 想回答一个问题:

对于静态、局部、结构化的微体系结构决策,我们真的需要大语言模型吗?

这个问题来自 PF-LLM 的启发。PF-LLM 将硬件预取相关决策建模成代码上下文上的预测任务。ArchLite 没有尝试严格复现 PF-LLM,而是把它作为一个案例,研究模型规模本身:在同一批本地生成的数据和标签上,比较规则/线性模型、小型 DNN 和 Qwen2.5 LoRA 的表现。

任务:从汇编上下文预测预取 hint

ArchLite 选择的具体任务是静态 load-level prefetching。每个样本对应一个静态 load PC,输入是该 load 指令附近的汇编上下文,输出是一个三字段结构化标签:

{
  "PF Sel": "...",
  "PF Degree": "...",
  "Filter": "..."
}

其中:

  • PF Sel:选择哪类预取器,例如 streamsmsip_stridesandbox 等;
  • PF Degree:预取程度;
  • Filter:是否采用过滤策略。

这个任务和通用代码理解不一样。它不要求生成代码,也不需要跨文件推理,而是一个局部的、有限输出空间的监督学习问题。因此它很适合用来检验:大模型的规模优势是否真的必要。

数据如何生成

ArchLite 的标签不是人工标注的,而是通过系统模拟生成的。

整体流程可以概括为:

GAPBS 图算法 workload
        ↓
执行 trace
        ↓
提取静态 load 指令及其汇编上下文
        ↓
ChampSim 网格搜索不同预取配置
        ↓
用每个 load PC 上 AMAT 最低的配置作为标签
        ↓
训练并比较 LR、DNN、Qwen2.5 LoRA

这里使用 GAPBS 是因为图计算 workload 往往有不规则访存模式,预取决策并不容易。ChampSim 则提供可控的微体系结构模拟环境。对每个静态 load PC,ArchLite 会比较不同预取器配置下的 AMAT,然后选择 AMAT 最低的配置作为监督标签。

项目中构造了三组数据集,区别在于样本过滤规则不同:

Dataset规则Balanced trainBalanced testOriginal test
margin002margin >= 0.02, min count >= 355688192
nomarginno margin, min count >= 31240232508
mincount1_nomarginno margin, min count >= 141125922355

其中,balanced test 用于避免多数类掩盖模型缺陷,original test 则保留自然分布。

模型比较

ArchLite 比较了四类模型:

  1. Majority baseline:总是预测训练集中最常见的标签;
  2. Logistic Regression:基于汇编 token 的 hashed TF-IDF 特征;
  3. Compact DNN:小型三头 MLP,预测三个字段;
  4. Qwen2.5 LoRA:对 Qwen2.5-Coder-0.5B-Instruct 做 LoRA 微调。

最关键的结果来自最大数据集 mincount1_nomargin

SplitModelPF SelPF DegreeFilterJoint
balancedLogistic regression0.53890.64020.61990.2584
balancedDNN0.66220.69930.65540.4206
balancedQwen2.5 LoRA0.68580.65200.64360.4291
originalLogistic regression0.54950.66110.61020.2887
originalDNN0.69720.72310.66880.4599
originalQwen2.5 LoRA0.72270.69850.64500.4603

Qwen2.5 明显强于 Logistic Regression,但它并没有显著压倒小型 DNN。在 balanced split 上,Qwen 的 joint accuracy 只比 DNN 高 0.0085;在 original split 上,两者几乎持平。

这正是 ArchLite 的核心观察:对于这种局部、结构化、监督信号明确的系统任务,大模型并不一定是最划算的选择。

更有意思的发现:局部上下文反而更好

ArchLite 还做了 context-window ablation。默认情况下,模型可以看到完整汇编上下文;但如果只保留目标 load 周围的局部窗口,结果反而更好。

在最大 balanced test 上:

Context windowPF SelPF DegreeFilterJoint
full0.66550.69430.66720.4257
8 lines each side0.70440.70780.68750.4764

也就是说,只看目标 load 前后各 8 行汇编,小型 DNN 的 joint accuracy 达到 0.4764,超过了 full-context DNN,也超过了当前 Qwen2.5 LoRA 的 0.4291。

这说明这个任务的有效信号可能主要集中在目标指令附近。对微体系结构决策来说,更多上下文不一定更好;合适的局部表示反而更匹配问题本身。

AMAT proxy:不仅是分类准确率

分类准确率只能说明模型是否预测到同一个标签,但系统任务最终关心的是性能。因此 ArchLite 还计算了 AMAT-level proxy:把模型预测的预取配置映射回 ChampSim 结果,估计它能恢复多少 oracle prefetching benefit。

结果如下:

ModelPredicted AMATRecovery vs no-prefetch
Majority173.14430.2252
Logistic regression147.61760.4916
DNN127.40780.6966
Qwen2.5 LoRA126.88280.6960

DNN 和 Qwen2.5 的 AMAT recovery 几乎一样。这进一步说明,小型 DNN 不只是分类指标接近,在下游性能代理指标上也能达到相近效果。

ArchLite 的结论

ArchLite 并不是说 LLM 对体系结构任务没有价值。大模型可能更适合跨函数推理、源代码语义理解、低样本迁移、解释生成等任务。

它想强调的是一个更细的判断:

当任务是局部的、输出空间有限的、标签可以通过模拟或测量获得时,模型规模应该是一个系统设计参数,而不是默认越大越好。

对于静态 load-level prefetching 这样的任务,小型 DNN 已经能捕捉大量可学习信号,并且训练、推理和部署成本都更低。

局限与未来方向

当前 ArchLite 仍然是一个本地数据研究,而不是完整工业级系统。它的主要局限包括:

  • workload 主要来自 GAPBS,尚未覆盖 SPEC、server workload 等更广泛程序;
  • 标签来自 ChampSim 模拟,和真实硬件行为可能存在差异;
  • 当前 split 更接近 held-out input generalization,而不是严格的 cross-program generalization;
  • Qwen、DNN 和 LR 的调参空间不同,因此结果应理解为受控实践比较,而不是穷尽搜索。

未来可以继续扩展到更多 workload、更严格的跨程序测试、更真实的硬件验证,以及更多微体系结构决策,例如 cache bypass、branch behavior、memory dependence、load/store scheduling 等。

总结

ArchLite 的核心价值不在于提出一个新的预取器,而在于提出了一个系统设计问题:AI for Systems 是否总是需要大模型?

至少在这个静态预取决策任务上,答案并不绝对。Qwen2.5 LoRA 有效,但小型 DNN 已经非常接近,甚至在局部上下文设置下更强。

这给 AI for Systems 一个很实际的启发:在把 LLM 引入系统优化之前,应该先认真判断任务粒度、标签来源、输出空间和部署成本。很多时候,真正合适的模型不是最大的,而是最匹配问题结构的。