LLM 大语言模型是 AI 时代的 CPU

LLM 就像 CPU

CPU 运行程序（通常用汇编语言编写），处理输入并提供输出。这通常意味着修改内存状态。同样，LLM（大型语言模型）以文本形式接收指令，处理用户输入并生成文本输出。它甚至可以转换或增强输入本身。

但是，就像 CPU 一样，LLM 也有局限性。CPU 依赖外部内存和存储来实现持久性，因为它们的内部内存是有限的。同样，LLM 依赖外部数据来丰富其上下文，因为它们无法仅从训练数据中了解所有内容。我们需要从外部世界向它们提供信息，以完成更复杂的任务。

CPU 也由专门的组件支持——内存控制器、安全区域、显示处理器等。LLM 也不例外；它们也需要专门的支持。较小的 LLM 可以协助较大的 LLM，管理诸如过滤输出或解释命令之类的任务。Gen AI 程序通常需要多个 LLM 和其他组件来处理数据转换、管理通信、保护内容等。

正是由于 LLM 与 CPU 的类比，我们才自然而然地求助于程序员来构建 Gen AI 解决方案。但也许是时候重新考虑这种方法了。

LLM 和 CPU 之间的差异

CPU 和 LLM 有几个主要区别：

速度：CPU 速度快如闪电，以每秒万亿次浮点运算 (TFLOPS) 来衡量。另一方面，LLM 每秒只生成几十个令牌 (TPS)，因此速度要慢得多。我们说的是十个数量级的差异。

确定性：CPU 是确定性的——相同的输入产生相同的输出。LLM 是概率性的。即使输入相同，其输出也可能不同。您可以降低温度参数以使 LLM 更具确定性，但这通常会降低它们的创造力和解决问题的能力。

无限配置：在传统计算中，获得解决方案的方法有限，程序员可以就计算效率方面的最佳实现达成一致。在 LLM 编程中，获得答案的方法无穷无尽。一切都可以调整：提示、模型、温度、参考文档，甚至支持 LLM。这种多样性使该过程本质上具有不确定性 — 一种配置可能在一种情况下完美运行，但在另一种情况下失败 — 并且令人生畏。

错误和可靠性：在传统系统中，意外错误很少见，有时是由宇宙射线翻转内存位等现象引起的，这种情况可以通过纠错处理。相比之下，基于 LLM 的系统出现故障是不可避免的。即使是最好的 LLM 代理也可能只有 95% 的时间有效，因此有很大的出错几率。

成本：运行 LLM 的成本很高。例如，OpenAI 的 API 收费为每百万输入令牌 2.50美元，每百万输出令牌 10美元。处理具有中等输入和输出大小的请求每 1,000 个请求的成本可能为 5美元。相比之下，来自 Vercel 等云提供商的边缘请求每百万的成本可能为2美元。成本差异是显而易见的。

由于这些差异，传统的编程方法很难与基于 LLM 的系统相适应。

法学硕士 (LLM) 编程

那么，我们如何构建高效的通用人工智能程序呢？

首先，并非所有任务都需要最强大的 LLM。将问题分解为较小的子任务，使用传统编程技术处理数据量大的过程和用户界面渲染，利用小型模型完成情绪分析和拼写纠正等较简单的 AI 任务，并仅在必要时将重任留给较大的模型。

由于 LLM 速度较慢，因此编排变得至关重要。流式传输、并行性和推测执行可以帮助加快该过程。例如，虽然 Midjourney 在生成时会显示半成品图像，但您仍需要等待完整结果才能对其进行评估。使用 LLM 确定函数参数也是如此 - 在所有参数准备就绪之前，您无法执行该函数。

错误处理是另一个必不可少的组件。您需要一些机制来检测LLM 何时产生了错误或有害的输出，并决定是否重试、调整或放弃该任务。许多商业 LLM 都具有内置安全层，可在流式传输过程中切断令人反感的内容（又称保护）。

评估LLM 设置的有效性就像运行持续集成测试一样。鉴于配置和提示 LLM 的方式多种多样，您需要进行可靠的评估以确保可靠性。评估系统甚至可能涉及其他需要自行调整的 LLM。与自动化测试一样，您需要在每次配置更改后重新运行评估基准，以便在问题影响到客户之前发现它们。

监控成本也至关重要—— FinOps必须从第一天起就成为 Gen AI 的一部分。无论是使用托管的 LLM 还是在自己的 GPU 上运行 LLM，管理费用都是一项重大挑战，尤其是在扩展时。

好消息是，你不需要成为一名人工智能研究人员就可以使用 LLM。现成的模型、标准化的 API 和丰富的教程使传统开发人员能够构建 Gen AI 应用程序。

编程的未来

然而，传统开发人员并不熟悉 Gen AI 编程的本质。使用 Gen AI 实现一项功能需要更长的时间，而且往往令人沮丧。改进一个方面（如速度）可能会对另一个方面（如成本或准确性）产生负面影响。许多发布到生产中的功能最终以开发人员无法预测的方式出现故障。

学习这种新型编程很有挑战性。大多数教程都涵盖了简单的用例，而真正的复杂性只有在您超越基本任务时才会出现。第一次尝试往往很脆弱，传统开发人员可能需要数月才能达到能够提供优质 Gen AI 产品的水平。

这只是使用现有的 LLM。微调或训练自己的模型会增加更多的不确定性和费用。

与此同时，LLM 本身在编程方面也越来越优秀。如果您想要 100 种不同的提示，请让 LLM 生成它们。GitHub Copilot 等工具正在弥补这一差距，就像将人类意图转化为代码的编译器一样。

结论

谁将编写未来的 AI 代理？我们仍然需要传统开发人员围绕 LLM 打造用户体验。例如，OpenAI 的新 Canvas 的价值不仅在于它使用的 LLM；它还在于周到的用户体验 — 选择文本、选择画笔并在上下文中查看结果。

然而，他们必须成为增强型程序员，才能有效应对 Gen AI 的新挑战，并将 LLM 融入他们的工作流程。我们还需要一类新的专业 AI 程序员——那些擅长识别极端情况并为 AI 代理设计最佳架构的人。这需要调整我们的教育系统：编程学校必须开始教授这些新范式，以便让下一代能够应对 Gen AI 的独特挑战。

至于我，我喜欢探索这些新范式，即使它们需要大量的学习投入。我已将LLM作为我工具包中不可或缺的一部分。它们开辟了许多新的可能性，以至于我发现自己几乎每天都在想象一个新的产品创意。生态系统发展迅速，但我决心跟上。

我相信，只要我们能够为利益相关者提供比人工智能工具本身更多的价值，像我这样的人类程序员就会继续有一席之地。