如今，似乎每个人都在寻找运行本地大语言模型的方法。确实如此，你实际上可以在自己的个人电脑甚至笔记本电脑上运行类似 GPT 的模型作为 AI 助手、代码编辑器等。人们这样做的原因有很多。首先，大语言模型的运行成本可能相当高昂，因此自行部署可以节省大量资金。同时，你可能经历过 AI 服务中断或受到速率限制的情况，这确实很棘手。但对我个人而言，使用本地大语言模型的最大原因和最后一点是隐私和安全问题，因为这是在自有机器上运行所带来的优势。

然而，当我们谈论在本地部署大语言模型时，通常会听到两个著名的工具：llama.cpp 和 vLLM。它们针对不同类型的用例。但别担心，你仍然可以使用检索增强生成（RAG），构建 AI 智能体，甚至将其用作 AI 代码助手。但在本视频结束时，你将了解如何以及为何在这两个工具之间做出选择。我想把时间倒回几年前的 Llama 2 发布时刻。Llama 2 来自 Meta，它是一个大语言模型，但非常独特，因为它是首批在商业上成功的开源权重模型发布之一。

虽然当时已有 ChatGPT 等服务可以通过 API 使用或付费，但 Llama 模型允许你前往 Hugging Face 或 GitHub 下载该模型。你可以保存这个模型并尝试在自己的机器上运行它。但存在一个小问题：你可能实际上无法在自有硬件上运行它。这是因为该特定模型以几种不同的尺寸发布，包括 70 亿参数、130 亿参数以及最大的 700 亿参数。后者需要相当庞大的硬件配置，通常需要大型显卡，而如今这类显卡要么价格昂贵难以获取，要么在某些情况下很难找到。

因此，与其购买昂贵的硬件加速器和更大的 GPU，llama.cpp 的理念是让模型在较小的硬件上变得可用。通过一些优化措施，你可以从开源存储库下载模型并在自己的计算机上运行它们。其中一项优化是量化（Quantization）。让我举个例子说明其工作原理：当我们想到圆周率时，它是 3.1415926...并无限延伸。我们通常将其简化为 3.14。大语言模型也遵循类似的理论，因为在 GPU 中进行大量计算时，权重有时以较高精度存储。

例如，这可能是基线浮点数 16（float16）精度。通过量化或将其压缩到更小的值，我们可以降低到整数 8（int8）甚至整数 4（int4）。这样我们就将一个大模型缩小到更小的尺寸。这可以将我们对 GPU 的容量需求从例如 30GB 存储降低到仅需约 4GB VRAM 即可高效运行该模型。此外，还有其他优化措施，例如将模型的权重及相关元数据合并为一个单元。

让我们想想神经网络的权重（如 safetensors 格式）。将这些文件与分词器、模型配置等所有不同文件合并为一个单一的 .gguf 文件。这使我们能够轻松切换不同的模型，并从单个 .gguf 文件中尝试各种功能。这是 llama.cpp 带来的一项重大创新。最后，我们还能够在 CPU 以及 GPU 上进行推理运行，这非常重要，因为许多个人电脑并没有配备 GPU。

所有这些优化都取得了显著成效，突然之间你可以在笔记本电脑或树莓派上运行大语言模型，并且可以离线运行。想想工厂或物联网环境。整个 llama.cpp 项目催生了其他工具，如 Ollama 和 LM Studio，这些工具在全球开发者中得到了广泛采用。当然，在本地运行一个模型很棒，但如果我们有不同类型的模型用于生成嵌入以进行 RAG、作为编码智能体或执行工具使用，该怎么办呢？

或者可能有 10 个用户甚至 10,000 个用户同时使用这些模型？又或者你正在部署到高性能计算机、虚拟机或 Kubernetes（以在硬件和区域间分配工作负载而闻名）。vLLM 的作用是将本地大语言模型的理念提升到另一个层次。它专注于利用硬件加速器（如 Nvidia GPU、Google TPU，以及 AMD 和 Intel）的大规模效率。它提供了一个广泛的硬件堆栈供你使用以运行这些模型。

与 llama.cpp 一样，vLLM 充当大语言模型引擎。它允许你运行能够处理文本、音频、图像和视频的模型，涵盖了几乎所有领先模型制造商的不同类型模型格式。大多数开源实验室通常都会为 vLLM 这样的引擎提供首日支持。不仅拥有广泛的硬件和模型兼容性，vLLM 还进行了许多改进以处理例如批处理（Batching）的问题。

那么，什么是批处理呢？假设有 10 个请求连续进入每个用户。为了形象说明，我用煎锅上的煎饼来比喻：假设我们在烹饪六个煎饼，但它们将在不同时间完成。也许这个好了，那个也好了，另一个也完成了。如果我要为所有这些煎饼做完之前不添加新煎饼，那将非常低效。这就是 vLLM 所称的连续批处理（Continuous Batching）。

此外，还有针对高效 KV Cache 使用的其他优化措施。让我举个例子：当用户请求进入大语言模型时，我们会将这些输入令牌通过大型语言模型的每一层。在此过程中，我们逐个令牌地生成更多文本，同时积累所谓的 KV Cache（键值缓存），这是因为我们对原始源文本进行的计算。相信我，这可能会变得非常大，我们通常会看到数十 GB 的占用空间。

用于将提示词通过模型传递，最终获得期望的输出响应。问题是硬件加速器的存储空间有限。以 NVIDIA 的 A100 GPU 为例，我们实际上将其划分为几个不同的部分。大部分空间通常用于将模型权重本身加载到内存中，但其余部分的绝大部分实际上是 KV 缓存。这样，如果同一用户多次发出相同的请求，我们就不必重新计算整个提示词本身。

因此，vLLM 通过一种称为分页注意力（paged attention）的技术进行了大量优化以实现正确的缓存。但问题是，虽然 llama.cpp 和 vLLM 都极大地受益于量化技术，vLLM 还带来了另一种优势，即推测执行（speculators）。让我举个例子。假设我们有一个表现良好的较小模型，它能生成响应的几个不同部分，而我们希望使用一个较大的模型来验证该响应是否正是我们要返回给用户的。这就是所谓的推测执行技术。

它还可以与一种称为解耦（disaggregation）的技术结合使用，并通过开源项目 LLM-D 将预填充和解码阶段分开。作为构建 RAG（检索增强生成）或 AI 代理的终端用户，不必担心，因为这两种工具都可以像使用 OpenAI 兼容端点一样服务 DeepSeek、Quinn 或 Llama，甚至是多模态模型。因此，你不需要更改代码库中的大量配置，因为你仍然使用相同的补全或响应 API。

这本质上是对 ChatGPT 风格 API 的即插即用替代方案。通常人们会先使用付费 API 进行轻松测试，看到账单开始上涨后，再切换到 VLLM 或 llama.cpp 在更大的环境中运行。问题是它们适用于不同的用例：对于 llama.cpp，你通常是在消费级硬件上工作；而对于 vLLM，则是在生产负载中运行。但目标保持不变：在本地运行你自己的 AI 模型。

现在我很想知道，你是否尝试过或正在尝试本地 AI 模型？请在评论区告诉我什么对你有效。如果你今天学到了新东西，请务必点击点赞按钮以“黑”算法。一如既往，感谢观看，我们下期再见。