Karpathy团队3小时让大模型提速15%

606 MiB的模型跑在49 tokens/s，内存带宽吃掉30 GB/s，接近硬件天花板。这时候你让AI去优化SIMD指令集，就像给堵车路段换更宽的马路——车还是动不了。

这是Karpathy团队最近把自动研究系统（autoresearch）对准llama.cpp时遇到的真实现场。3小时、4台云虚拟机、5个有效优化，Flash Attention文本生成在x86上快了15%，ARM上快了5%。关键改动不是加算力，而是让AI先读论文、再写代码。

第一波实验：AI在代码里打转

团队给AI的任务很明确：优化llama.cpp的CPU推理路径。这个场景和之前的神经网络训练脚本完全不同——优化空间不是"调个学习率"，而是"要不要融合这两次内存访问""算力瓶颈还是内存瓶颈""ik_llama.cpp已经试过什么"。

AI的第一反应很"工程师"：直奔GGML矩阵乘法的热路径，在量化点积里折腾SIMD微优化。它试了各种向量化技巧，结果全部落在噪声范围里。

事后复盘，AI自己写了总结：「第一波结果表明，计算路径的微优化收益可以忽略，因为文本生成受内存带宽约束，而非算力约束。」

代码能告诉AI这里在做什么，但解释不了为什么慢。就像你拿到一份写得密密麻麻的账本，知道每一笔收支，但看不出公司为什么亏损——需要行业知识、竞品对标、外部研究。

加了一个环节：文献检索

团队给autoresearch循环加了一个文献检索阶段。现在AI动手之前，要先读论文、研究竞品项目。这个改动把"代码上下文"扩展成了"领域上下文"。

具体到llama.cpp，AI开始查：Flash Attention的原始论文、x86和ARM的内存架构差异、竞品实现里怎么处理KV Cache、社区已经讨论过哪些优化方向。这些原本需要资深工程师凭经验调用的外部知识，变成了AI工作流里的标准步骤。

3小时后产出的5个优化，核心思路转向内存布局重构：减少不必要的内存往返、对齐访问模式以提升带宽利用率、针对ARM的特定缓存层级调整分块策略。全是"怎么搬数据"的问题，而非"怎么算更快"。

结果验证了这个转向的价值。TinyLlama 1.1B的测试里，x86端提速15%，ARM端5%。数字不算炸裂，但考虑到这是零人工干预的自主优化，且全程有基准测试和单元测试兜底，意义在于证明了"读论文→写代码"这个闭环可以跑通。

从神经网络模板引擎到通用框架

这个系统的进化路径值得细说。Karpathy最初的autoresearch演示是自动改进神经网络训练脚本。团队上一篇文章把它扩展到16块GPU，8小时跑910个实验，把val_bpb压下去2.87%。那时候AI还只从代码上下文里 brainstorm 想法，实验全是围绕同一个train.py的变体。

后来的pi-autoresearch把这个循环通用化了，变成任何可基准测试目标都能用的扩展。Shopify CEO Tobi Lütke拿它跑Liquid——Shopify的Ruby模板引擎，每年处理2920亿美元商品交易流水。AI跑了约120个实验，提交93次代码，把解析+渲染时间砍掉53%，内存分配减少61%，974个单元测试零回归。

Liquid那个案例里，优化面在源码里肉眼可见。AI读一遍tokenizer，发现StringScanner是瓶颈，就能从代码库里 brainstorm 替代方案。但llama.cpp证明了这个假设的边界：当答案藏在代码之外，纯代码上下文的AI会生成浅层假设。

一个更深层的问题

这个实验指向一个正在被验证的判断：AI编程助手的下一个分水岭，不是生成代码的速度，而是"知道该优化什么"的准确率。

GitHub Copilot和同类工具已经把"写代码"的边际成本压得很低。但"写什么代码"——识别真正的瓶颈、理解硬件约束、追踪学术前沿——仍然依赖人的经验。Karpathy团队做的，本质上是把这部分经验用自动化检索替代了一部分。

具体实现上，文献检索阶段大概涉及：arXiv关键词搜索、相关仓库的issue和PR扫描、技术博客和文档的语义检索。这些动作本身不新，新的是把它们塞进一个自主循环，让AI能根据检索结果动态调整实验方向。

有个细节：整个llama.cpp优化跑在4台云VM上，3小时产出5个有效优化。成本可控，意味着这个模式可以频繁触发——比如每次硬件换代、每次上游依赖更新、每次业务负载特征变化时，自动重新跑一遍研究-实验循环。

Shopify的Liquid案例已经展示了商业价值：53%的渲染提速，直接换算成服务器成本节省和用户体验提升。llama.cpp的15%提速，对边缘部署和本地推理场景同样有意义。

但更值得观察的是反馈机制。AI在postmortem里自己识别出"内存带宽约束"这个关键洞察，说明系统具备了某种程度的自我诊断能力。这不是通用推理，而是在特定优化任务里的模式识别——从实验结果的噪声分布里，推断出假设空间的结构性问题。

下一步的悬念在于：当AI开始读论文，它会怎么选择读哪些论文？llama.cpp的优化相对有明确的技术文献指向，更模糊的工程问题——比如"为什么这个服务在峰值时延迟抖动"——需要检索和综合的信息源更杂，噪声也更大。这个筛选和排序的环节，目前还是人在设计检索策略，还是已经有一部分自动化了？