Jeff的性能优化哲学，不做什么远比做什么重要

前不久看到YC采访前谷歌大神Deff的一个播客，聊了非常多关于AI、Agent、创业公司的话题，其中谈到模型上下文的话题，主持人问Jeff，你有做过什么上下文工程的例子吗？那种对你工作流产生巨大影响的例子。

Jeff并没有说如何给模型增加Agent、Harness、Loop engineering等现在很火热的技术，而是做减法，教模型有所为有所不为，优化性能一直是他认为最重要的工作。

为什么这么说？

普通人用模型，快一秒慢一秒并不影响体验，但对于谷歌来说，一个模型算法可能被几百万个进程在使用，哪怕0.001秒的提升对系统性能也是巨大的优化。

他提到一个工程方法论，用大量且反复的微基准测试来试探模型不同操作需要多长时间，这样就能知道什么操作是影响性能的拖油瓶，然后再去做修改，再做微基准测试。

他和Sanjay还专门为此开发过一套性能优化手册，叫《Performance Hints》，足足有30页，可以作为SKILL注入给大模型，能极大的提升模型推理、识别、debug性能。

看完之后我的脑袋是懵的，整个手册引出了一个非常经典且具备哲学思考的原则。

最快的计算是根本不执行； 

其次是只执行一次； 

再次是批量执行； 

最后才是让每次执行更快。

以我简单的理解是，模型遇到性能问题，第一要估算运行总成本，删掉不必要的工作。

如果无法删除，则降低算法复杂度，减少执行次数，而不是总想加速每一个环节。

这个逻辑牵扯到内存分配、缓存占用、数据复制等非常底层却又重要无比的细节，每一处都有优化的余地。

Jeff其实用这套手册教模型如何自改优化性能，基于一套完全闭环、严格熵减的优化顺序。

这和奥卡姆剃刀原理有异曲同工之处，如无必要，勿增实体。

我让ChatGPT提炼了Jeff的这篇文档，生成一段能高效生产的提示语，测试下来效果不错，大家可以用用。

你是一名结果导向的高效专家。收到任务后，先在内部明确目标、约束、交付物与成功标准，识别决定结果的关键问题；删除无关工作，优先采用简单、高杠杆、可验证的方案。充分复用已知信息，合并重复步骤；常见情况走最短路径，仅在必要时处理复杂例外。信息足够时直接完成任务；只有缺失信息会实质改变结果时才提问，否则基于合理假设继续并明确假设。不得编造事实，不确定或可能过时的信息应标注并核验。输出应结论先行、结构清晰、详略与任务类型匹配，保留必要依据和关键细节，给出可立即使用的结果，不重复题意、不展示内部推理。提交前静默检查正确性、完整性、相关性、可执行性和简洁性，发现问题先修正，再只输出最终结果。 ❞

其实在谷歌的这27年，Jeff大部分重要成果都围绕性能优化展开的。

比如MapReduce分布式计算框架，相当经典的一次化繁为简的案例。

谷歌搜索业务量暴增的年代，原先的分布式计算非常不稳定，几千台老破电脑集群经常出故障，工程师大部分时间都用在处理bug上了。

Jeff通过Map(分片处理) 、Reduce(聚合结果)的机制，非常巧妙将把数据切分，并行跑在多台机器上，然后聚合到结果。

就算某几台机器出故障，也完全不影响结果，因为系统会自动把失败任务调度到其他机器去执行。

TPU的出现也完全脱胎于这套系统优化机制，我称它为Jeff的取舍哲学。

TPU不像CPU、GPU这样的全能选手，而是只做一件事，那就是机器学习推理，你甚至不能用它运行excel、chrome，但好处是TPU的AI推理能效是CPU、GPU的几十倍。

其实不光是大模型系统的优化，作为打工人也没想明白为啥工作这么累，说到底还是多了很多无效的消耗，包括精力和情绪的消耗。

凡事应该多想想这件事是否值得做，有没有更简单的方法做，如何借助工具去做等等。

文章最后，分享我基于《Performance Hints》蒸馏出来的SKILL optimize-output，它会让模型输出的结果更加聚焦和准确，非常适合作为策略输出、数据分析、调研规划、编程开发这样结果导向的任务。

它工作流是：

框定成果目标-> 定位核心瓶颈-> 先做删减，再谈提速-> 选用最高杠杆的实现方式-> 专注执行主流场景-> 交付产出物，而非过程-> 静默自检核验

比如同样基于GLM 5.2大模型，在Trae上开发太阳系行星运转可视化界面，用了该SKILL输出的效果要远远好于不用的情况。

测试组Prompt：结合skill optimize output， 写一个太阳系行星运转交互页面，需遵循物理规律，UI简洁美观

对照组prompt：写一个太阳系行星运转交互页面，需遵循物理规律，UI简洁美观

测试组效果：

对照组效果：

测试组一次性跑出结果，完整展示了行星的绕行规律，而对照组几乎是没有完成设定的任务。

在其他任务情形下，我也做了相关测试，使用该SKILL输出质量得到很明显的提升。