高效工程化

最后更新：2026年4月8日

AI基础设施提供商的商业模式很直接：你配置越多算力，他们赚得越多。ML炒作周期强化了这一点，每个新基准分数都由更大的模型创造，每份部署指南都默认使用最高GPU规格。如果你是一名生产工程师，试图合理地交付产品，那么整个生态系统里没有人有动力帮你降低成本。

我们认为，对AI系统进行合理规模调配是一种工程纪律，而不是妥协。本页面介绍我们在此平台上如何思考资源权衡，以及我们为何教导工程师将同样的思维方式应用到他们自己的系统中。

"规模焦虑"是被制造出来的

AI行业存在一种结构性动机，让你感觉自己永远落后。基准测试排行榜以参数量为奖励标准。会议演讲默认使用演讲者能调用的最大模型。AI基础设施提供商发布的参考架构假设你需要专属GPU集群。这些参与者没有在欺骗你，他们只是在优化自己的利益，而那与你的利益并不一致。

结果就是我们所说的"规模焦虑"：一种普遍的感觉，无论你拥有多少算力都不够，解决方案永远是"更多"。更多参数、更多GPU、更多托管服务、更多支出。团队过度工程化，是因为他们被训练成将基础设施规模当作工程质量的代理指标。

真正值得问的问题：

那些已经掌握效率之道的团队，往往被迫而非自愿，通常远超那些默认依赖规模的充裕资金团队。一个量化的7B模型，经过领域数据微调，通常能以约5%的成本匹配70B API调用的效果。这个差距并非暂时的；它反映了前沿模型的优化目标与大多数生产任务实际需求之间的根本性错位。

这在全球范围内都很重要。世界上大多数工程师在面临硬件供应和预算限制的条件下构建 AI。效率技术不是变通方案，而是主航道。我们认为这个群体值得比“如何调用 API”更好的资源。

团队经常为推理工作负载临时启用A100或H100集群，而实际上一个在CPU上运行的量化7B模型就能以可接受的延迟处理同样的任务。GPU是现成的，本季度预算充裕，没有人停下来对比过替代方案。
算力成本是显而易见的。不那么明显的成本包括：拖慢迭代速度的架构复杂性、过度工程化编排带来的冷启动延迟，以及维护从未合适的基础设施所带来的运营负担。
过度配置限制了可用性。通过专注于算力效率，我们将 AI 从仅限于顶级云端资源的奢侈品，转变为可以在你已有的本地或混合硬件上运行的高便携性系统。

在大多数ML课程中，部署哪个模型的决策被当作固定输入，使用最好的可用模型，仅此而已。但对于生产系统而言，模型选择是你能做的最高杠杆工程决策之一。一个量化7B模型运行在$0.50/小时的实例上，对比70B模型运行在$12/小时的GPU实例上，这绝不是微不足道的实现细节。

我们教导工程师明确地推理这些权衡：任务复杂度与模型容量、延迟需求与吞吐量、微调成本与提示工程成本。目标是将工具与问题匹配，而不是使用排行榜上排名最高的模型。

我们的课程涵盖量化（INT4、INT8、GPTQ、AWQ）、知识蒸馏、LoRA和QLoRA微调以及边缘推理，不是因为这些是小众话题，而是因为这些技能能让一个两人团队与拥有50万美元云预算的团队竞争。我们也教何时不使用这些技术，因为盲目将它们应用到错误的问题上本身就是一种失败模式。

更广泛的工程判断力，如何时使用前沿模型、何时微调较小的模型、何时完全跳过ML，贯穿于我们组织内容的方式之中。我们认为这种判断力比知道上周二哪个模型在基准测试中得分最高更有价值。

能耗与算力使用率直接挂钩，直接影响到运行开销、散热要求和硬件寿命。与量化适配的7B模型相比，从头训练一个175B参数的模型所需的原始能量高出几个数量级。即使使用有补贴或碳补偿的绿色数据中心，这种成本开销依然居高不下。

优化资源利用并不意味着牺牲性能。一个适配规模的模型通常在核心任务上实现相当的准确率，而其运行成本仅为一小部分，省去了为简单推理负载而维护庞杂多节点集群编排的麻烦。

本平台运行在基于ARM的基础设施上。内部工具和内容流水线使用更小的、适合任务的模型，在较小模型能胜任的地方不使用前沿模型。缓存是第一要务，而不是事后想法。我们不默认按峰值容量配置。

我们记录这些选择不是作为公关练习，而是因为它们反映了我们所教授的权衡。如果我们向用户推荐合理规模调配，自己却运行过度配置的基础设施，那将是一个值得质疑的立场。

这些不是固定立场。模型效率研究进展迅速，一年前需要大量工程投入的技术正在成为标准库功能。随着格局变化，我们会更新课程和自身的基础设施选择。

如果你发现了我们在此描述的某个权衡的更好方案，或者不同意我们在某个具体点上的推理，我们很感兴趣。目标是把这件事做对，而不是看起来我们已经做对了。