第3章大模型快速体验

在上一章中，我们从多个维度认识了大模型——它由什么构成、为何能理解自然语言、擅长哪些任务。但认识不等于会用。真正理解一个工具，你需要亲手操作它。

怎么操作？打开网页或 App 直接对话当然可以，但在实际工作中，你大概率需要以编程的方式与大模型交互——就像你不能只用看图软件预览代码，你需要编译器。本章按"从易到难"的顺序，梳理了四种可编程的体验方式：从最简单的 API 调用开始，逐步深入到本地模型部署与推理优化，再到 Ollama、LM Studio 等集成平台，最后落脚于 Claude Code 和 OpenClaw 代表的 Agentic 工作流——让模型不只是回答问题，而是自主完成多步骤任务。

这四种方式覆盖了从"消费者"到"构建者"的不同需求层次。你不需要全部掌握，但读完本章后，至少要亲手跑通其中一种。

3.1 方法1：直接调用现有大模型服务

你很可能已经用过 DeepSeek 或通义千问的网页版——打开浏览器，注册账号，打字提问，模型回答。这是目前门槛最低的体验方式。但如果你想在自己的应用里调用大模型，那个聊天窗口的背后发生了什么？本节就来拆开这些问题：从 Web/APP 的用户入口，到 API 的程序化调用，再到你实际要花多少钱。

Web 与 APP：普通用户的入口

几乎所有主流大模型厂商都提供了 Web 端和手机 APP。截至 2026 年中，DeepSeek、通义千问、豆包等国产模型以及 Gemini、ChatGPT 等海外模型均提供免费的网页对话服务。注册一个账号，就能直接对话——这是体验门槛最低的方式。

但这种方式有明确的局限：

只能手动交互，无法程序化集成。 你只能通过浏览器或 APP 操作，不能把模型能力嵌入自己的软件系统，也不能在代码中自动发起请求、解析结果或做错误重试。
功能受限于界面设计。 不能批量处理、不能调用外部工具、不能精细控制系统提示词（system prompt）。

如果你只是偶尔问答、写写文案、翻译一下文档，Web 聊天完全够用。但如果你的场景是"我需要在我的产品中自动处理用户输入，由大模型生成回复"，那就必须走下一层：API 调用。

API 调用：开发者的正确打开方式

API（Application Programming Interface）是大模型厂商提供给开发者的程序化调用接口。你的代码直接向模型服务器发起 HTTP 请求，传参、等待、拿结果——整个过程可以集成到任何后端服务、命令行工具或自动化流水线中。这也是目前大模型商业化的核心形态：厂商按 Token 消耗量收费，开发者按需付费。

以 DeepSeek 为例，整个流程只需三步：

第一步：获取 API Key。 访问 platform.deepseek.com 注册并进入「API Keys」页面创建一个 Key。这个 Key 就是你的身份凭证，调用时需要携带它。建议创建后立即复制保存——DeepSeek 只在创建时完整展示一次，之后只显示首尾片段。

安全提醒：不要把 API Key 写死在代码里。 Key 泄露相当于你的账户被接管——任何拿到 Key 的人都可以以你的名义调用模型，产生费用。即使代码只存在本地，也容易通过 Git 提交、日志打印、屏幕截图等方式意外泄露。正确做法是：将 Key 保存在环境变量中，代码运行时读取。

第二步：编写调用代码。 DeepSeek API 兼容 OpenAI SDK（OpenAI SDK 是目前大模型 API 的事实标准客户端库，兼容 OpenAI Chat API），你只需要改 base_url 和 api_key，就能复用已有的 OpenAI 调用代码。这意味着切换模型供应商的成本极低——这个兼容性后面还会反复用到：

依赖：pip install openai。未设置 DEEPSEEK_API_KEY 时会直接抛 OpenAIError，先 export DEEPSEEK_API_KEY=<你的 key>。

python

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ.get("DEEPSEEK_API_KEY"),   # 从环境变量读取，绝不硬编码
    base_url="https://api.deepseek.com"
)

response = client.chat.completions.create(
    model="deepseek-v4-flash",      # 模型名截至 2026年6月，以官方最新文档为准
    messages=[
        {"role": "system", "content": "你是一个简洁的技术助手。"},
        {"role": "user", "content": "用一句话解释什么是 API。"}
    ]
)

print(response.choices[0].message.content)

设置环境变量的方式有多种，按复杂度从低到高：

终端 export（临时）：export DEEPSEEK_API_KEY="sk-xxxx" —— 只在当前终端会话有效，关闭即失效。
.env 文件（推荐）：在项目根目录创建 .env 文件写入 DEEPSEEK_API_KEY=sk-xxxx，配合 python-dotenv 库或 IDE 自动加载。务必把 .env 加入 .gitignore，防止提交到版本控制系统。
系统环境变量（生产环境）：写入 ~/.bashrc、~/.zshrc 或使用服务器配置管理工具（如 Docker 的 --env 参数、Kubernetes 的 Secret）。

运行后模型会返回类似下面的回复：

API 是一套让不同软件之间进行通信和数据交换的标准化接口，开发者无需了解对方内部实现即可调用其功能。

第三步：在应用中集成。 这段代码可以放进 Web 后端、CLI 工具、自动化脚本——任何能发 HTTP 请求的环境。你获得了完整的程序化控制能力：可以设定 system prompt 定义模型行为、传递对话历史维持上下文、通过 max_tokens 限制输出长度、启用流式返回（streaming）实现打字机效果，甚至让模型通过 function calling 调用外部工具。

💡 兼容性是关键。 DeepSeek、Qwen、豆包、Gemini、OpenAI 等主流 API 大多遵循 OpenAI 接口格式。你不需要为每个厂商写一套新代码——切换模型往往只需改一行 base_url 和 model。后面做技术选型时（详见第 4 章），我们会反复利用这个兼容性来降低切换成本。

付费模式：Token 即金钱

大模型 API 的计费单位是 Token。Token 是模型理解和生成文本的最小处理单元——它不是"字"，但近似于字。中文里大约 1 个汉字对应 1.5～2 个 Token，英文中 1 个单词约对应 1.3 个 Token。每次 API 调用，你输入的内容和模型输出的内容都会被分解为 Token 后按量收费。

以 DeepSeek 截至 2026年6月的最新价格为例（单位：元/百万 tokens，来源：platform.deepseek.com/pricing）：

模型	输入（缓存未命中）	输入（缓存命中）	输出
deepseek-v4-flash	¥1	¥0.02	¥2
deepseek-v4-pro	¥3	¥0.025	¥6

📌 上表中的模型名称和价格均为截至 2026年6月的数据。大模型领域迭代快，实际使用请以厂商官网最新定价为准。

输入和输出价格不同。 模型的输出（生成的内容）通常比输入（你发的内容）贵 2～3 倍。原因是：模型生成每个 Token 都需要完整的逐 token 解码计算，而输入 Token 在编码阶段可以并行处理。所以，精简 prompt 中的冗余信息不仅是工程习惯——它直接省成本。

缓存命中（cache hit）。 如果你短时间内连续发送相同或相似的 prompt 前缀（比如不变的系统提示词和对话历史），DeepSeek 会命中 KV Cache，输入价格降到几乎为零（¥0.02/百万 tokens，仅为全价的 1/50）。这在构建聊天系统时尤为有用：每轮对话只有最新一轮用户消息是"新"的，前面的历史和系统提示词都可以复用缓存。实际成本通常远低于"全部按原价算"。

实际花多少钱？ 用一个典型问答场景估算：用户问题约 200 Token，系统提示词和对话上下文约 500 Token，模型回答约 500 Token。使用 deepseek-v4-flash：

输入成本：700 ÷ 1,000,000 × ¥1 ≈ ¥0.0007
输出成本：500 ÷ 1,000,000 × ¥2 = ¥0.001
单次问答总成本 ≈ ¥0.0017

这意味着一块钱可以支撑约 600 次问答。即使每天处理 10,000 次问答，日消耗大约 ¥17。这就是为什么说"大模型 API 很便宜"——它不是营销话术。DeepSeek 的 API 定价大约是同性能级别商业模型的 1/50 到 1/100。

当然，不同厂商价格差异显著。GPT-5、Claude 4 等高端模型（模型名截至 2026年6月）的单次调用成本可能是 DeepSeek 的数十倍。选型时需要在成本、精度和推理速度之间做权衡——这不是"越贵越好"的问题，是"够用即可"的工程判断。

小结

"直接调用现有大模型服务"是起步最快的路径：无需管理服务器、不需要配置 GPU 环境，一个 API Key 就能把大模型能力嵌入你的应用。当你处于快速验证阶段、或应用规模在可控范围内时，这是最务实的选择。

但它也有明确边界：你无法控制模型版本、延迟受网络波动影响、所有数据需要发送到第三方服务器。如果你的场景涉及敏感数据、极高吞吐量或需要定制模型行为，就需要本章后续介绍的方法上场了——从下载模型文件开始，把推理能力掌握在自己手里。

3.2 方法2：调用大模型文件进行推理

在上一节中，我们通过调用云端 API 快速体验了大模型的推理能力——这是门槛最低的方式。但云端调用有两条天然的限制：第一，你的数据需要发送到远程服务器，这对金融、医疗等强合规场景来说是不可接受的；第二，你无法控制模型本身——不能微调、不能离线使用、也不能定制模型行为（比如调整温度、top_p 等生成参数）。

如果你需要在本地 GPU 或 CPU 上跑模型推理，那么直接下载模型文件、在自己的机器上加载运行，就是必经之路。本节从模型下载开始，先带你用 Transformers 库跑通一次完整的推理流程，再逐步深入到工业级推理引擎。

3.2.1 基于 Transformers 库调用大模型文件

Transformers 库由 Hugging Face 开发维护，是目前大模型生态中使用最广泛的基础库之一。它统一了数百种模型架构的调用接口，把「加载模型 → 编码输入 → 生成输出」这个流程封装得异常简洁。在深入各种高性能推理引擎之前，先通过 Transformers 理解推理的基本流程是很有价值的事情。

第一步：下载模型文件

在开始推理之前，你需要先拿到模型权重文件。如果你已经按照第 2 章的指引完成了 Hugging Face 或者ModelScope 的环境配置，这一步会非常快。

我们选择一个体量较小的模型——Qwen2.5-0.5B-Instruct——来做快速验证。选择小模型不是为了「凑合」，而是因为它的推理原理与千亿参数的大模型完全一致，但下载和运行速度足以让你在几分钟内完成整个实验。下面的示例我们以 modelscope 为例，演示如何下载模型。当然可以根据你所处环境选择Hugging Face 或者其他模型下载平台。

bash

# 激活第 2 章创建的 py310 环境（以你实际创建的环境为准）
conda activate py310

# 下载 Qwen2.5-0.5B-Instruct 模型
modelscope download --model Qwen/Qwen2.5-0.5B-Instruct \
    --local_dir ~/models

📌 本节起，文中所有 ~/models 请替换为你自己的模型目录（本节统一用 ~/models，第 2 章的 /home/yourname/... 是同一含义）。

--local_dir 参数指定了模型文件的本地存放路径。下载完成后，你会在目标目录下看到一系列文件：.safetensors（模型权重）、tokenizer.json（分词器配置）、config.json（模型架构参数）等。这些文件共同构成了一个可被推理框架加载的完整模型。

💡 注意：ModelScope 下载完成后，会在 --local_dir 指定的目录下自动创建 qwen/Qwen2.5-0.5B-Instruct/ 子目录（按「模型作者/模型名」的规则组织文件）。实际的模型权重和配置文件都位于这个子目录中，而不是 --local_dir 的根目录。因此，后续加载模型时路径要指向这个子目录，而非你传给 --local_dir 的那个路径。

💡 提示：如果下载速度不理想，可以配置 ModelScope 的镜像源。ModelScope 在国内的访问速度通常远优于 Hugging Face Hub，这也是我们选择它作为下载渠道的原因。当然可以根据你所处环境选择Hugging Face 或者其他模型下载平台。模型文件都是一样的。

第二步：安装推理依赖

Transformers 库依赖 PyTorch，这是必需要安装的。accelerate 是一个辅助库，它能自动处理多 GPU 分配和混合精度推理，让 device_map="auto" 这样的便利特性开箱即用，所以`accelerate也是需要安装的。

bash

pip install transformers accelerate

第三步：编写推理代码

下面这段代码演示了 Transformers 推理的完整流程：加载分词器和模型 → 将文本编码为模型能理解的数字序列 → 执行推理生成 → 解码回人类可读的文本。

python

import os
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

# ① 加载分词器和模型（换成你自己的目录）
model_name = os.path.expanduser("~/models/qwen/Qwen2.5-0.5B-Instruct")
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    device_map="auto"
)

# ② 准备输入
prompt = "请解释什么是人工智能？"
device = "cuda" if torch.cuda.is_available() else "cpu"
inputs = tokenizer(prompt, return_tensors="pt").to(device)  # "pt" = PyTorch 张量格式

# ③ 生成回答
outputs = model.generate(**inputs, max_new_tokens=100)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

我们来逐段理解这段代码做了什么。

① 加载分词器与模型

AutoTokenizer.from_pretrained() 和 AutoModelForCausalLM.from_pretrained() 是 Transformers 最核心的两个工厂方法。「Auto」前缀意味着你不需要手动指定模型架构——库会自动读取模型目录下的 config.json，识别出这是 Qwen2 架构，然后加载对应的实现。

device_map="auto" 会自动检测可用 GPU 并尽量将模型分布到各 GPU 上；如果显存不够，剩余的层会被放到 CPU。你不再需要手动写 .to("cuda:0") 之类的设备管理代码，这对刚接触模型推理的读者来说非常友好。

💡 提示：如果你的机器没有 GPU，Transformers 也可以纯 CPU 运行——device_map="auto" 在检测不到 GPU 时会将模型全部放在 CPU 上。不过推理速度会慢很多，大模型可能无法在可接受的时间内完成推理。如果你需要在 CPU 上高效运行大模型，可以跳到 3.2.3 节了解 Llama.cpp 等 CPU 优化方案。

AutoModelForCausalLM 中的「CausalLM」指的是因果语言模型（Causal Language Model），即自回归生成模型——这是 GPT 类模型的标准架构。它的工作方式是逐个 token 地预测下一个词，前一个 token 的生成结果会影响后续 token 的决策。与之相对的是 Bert 类模型使用的掩码语言模型（MaskedLM），区别在于注意力机制能否「看到」未来的 token。本节不展开这两种架构的比较，你只需要知道：我们现在用的所有 GPT 类模型都属于 CausalLM。

② 准备输入

python

device = "cuda" if torch.cuda.is_available() else "cpu"
inputs = tokenizer(prompt, return_tensors="pt").to(device)  # "pt" = PyTorch 张量格式

tokenizer() 调用将中文文本转换为模型能处理的张量（tensor）格式。return_tensors="pt" 中的 "pt" 是 PyTorch 的缩写，指定返回 PyTorch 张量（若使用 TensorFlow 可改为 "tf"）。

在调用 .to(device) 之前，代码先用 torch.cuda.is_available() 检测当前环境是否有可用的 NVIDIA GPU。如果有，device 被设为 "cuda"，张量会移到 GPU 上；如果没有，device 设为 "cpu"，张量留在 CPU 上——代码在两种环境下都能正常运行，不会因为缺少 GPU 而直接报错。

分词器在内部做了三件事：

切分：将文本拆成 token 序列。Qwen 的分词器对中文使用 BPE（Byte Pair Encoding）子词分割，一个中文字通常被编码为 1~3 个 token。
映射：将每个 token 映射为词汇表中的整数 ID。
构造 attention mask：标记哪些位置是有效内容（1），哪些是填充。

③ 生成回答

python

outputs = model.generate(**inputs, max_new_tokens=100)

model.generate() 是 Transformers 提供的高级生成接口。它在内部执行自回归循环：每一步将当前序列输入模型，得到下一个 token 的概率分布，从中采样出下一个 token，拼接到序列末尾，然后继续——直到达到 max_new_tokens=100 的上限，或模型输出了结束符（EOS，即 End of Sequence）。

max_new_tokens 控制的是新生成的 token 数量，不包括输入部分的 token。设置一个合理的上限可以防止模型「跑飞」——如果模型陷入重复循环，至少不会无限生成下去。

最后，tokenizer.decode() 将生成的整数序列反向映射回文本。skip_special_tokens=True 会过滤掉 <s>、</s>、<|endoftext|> 等控制标记，只保留对人类有意义的内容。

执行这段代码，你应该能看到模型对「什么是人工智能」的一段中文回答。虽然 Qwen2.5-0.5B 是一个轻量模型，回答质量无法与 72B 级模型相提并论，但整个推理链路的原理是完全相同的。

Transformers 推理的定位

用 Transformers 跑推理有它的优势：代码简洁、文档丰富、社区活跃，非常适合学习和原型验证。但它的设计初衷不是为高并发生产服务——没有内置的连续批处理（Continuous Batching）、没有 PagedAttention 这样的显存优化、没有 KV Cache 的高效管理策略。

当你需要把模型部署为真正的线上服务时，就需要用到专门的推理引擎。接下来的 3.2.2 节和 3.2.3 节，我们会依次介绍三种主流推理引擎——vLLM（3.2.2 节）、TGI 和 Llama.cpp（3.2.3 节）——看看它们各自是如何在性能、易用性和资源消耗之间做出取舍的。

3.2.2 vLLM：工业级推理引擎

上一节我们用 Transformers 跑通了 Qwen2.5-0.5B 的推理，几行代码就拿到了模型的回复。如果你是做实验、验证模型效果，这套方案够用了——轻量、直观、不依赖额外服务。

但如果你想把模型部署成 API 服务，供团队内部多个服务同时调用，问题就来了：Transformers 的 model.generate() 是单请求串行的——每来一个请求它从头到尾跑完，下一个才能进来。即使你手动开多线程并发，原生 Transformers 的 KV cache 内存管理也会成为瓶颈：每处理一个请求预分配一大块连续显存，用不完也不释放，并发一上来 GPU 显存利用率直线下跌，吞吐量远低于硬件该有的水平。

什么是 vLLM

vLLM 是加州大学伯克利分校 Sky Computing Lab 开发的高性能大模型推理引擎，目前已是工业界部署开源大模型最广泛使用的方案之一。它的核心贡献是两项工程创新：PagedAttention 和连续批处理（continuous batching）。

PagedAttention 的思路来自操作系统中的虚拟内存分页。传统的 KV cache 管理方式是：每个请求来，分配一整块连续显存存放它的 key-value 缓存，用多少都占着，请求结束才整体释放。这意味着两个请求之间，哪怕前一个只用了 30% 的缓存空间，后面的 70% 也白白浪费。PagedAttention 把 KV cache 切分成固定大小的"页"（block），按需分配、用完回收，像操作系统管理物理内存页一样管理 GPU 显存中的 KV cache。页面级别的管理让显存碎片大幅减少，同一张 GPU 能同时塞进的服务请求数提升了数倍——在 vLLM 团队的测试中，相比原生 Transformers 等传统方案，PagedAttention 能将单次推理的显存浪费从 60% 以上压缩到 4% 以下。

打个比方：Transformers 的内存管理像在纸带上连续写字——每个人必须独占一整条纸带，哪怕只用前面一小段，后面的空间也不能给别人用。PagedAttention 则像图书馆的书架——每本书占一个格子，归还后格子可以放别的书，资源利用率完全不在一个量级。

连续批处理解决的则是另一个问题：GPU 空闲等待。传统静态批处理需要等一个 batch 里的所有请求都处理完，才能进入下一批。如果一个请求生成 10 个 token 就结束了，另一个需要生成 100 个，前者就得干等 90 步，GPU 在那干烧电不出活。连续批处理在每个 token 生成步骤动态调整 batch 中的请求：完成的立即退出，新到达的立即加入。GPU 几乎不会因为"等别人"而空闲，吞吐量实现了数量级的跃升。

安装和启动

vLLM 安装简单，一行命令：

bash

pip install vllm

环境要求：vLLM 依赖 NVIDIA GPU + CUDA 环境（推荐 CUDA 12.1+，Ampere 及以上架构）。如果你在 Mac 上开发，vLLM 目前不支持 Apple Silicon GPU——3.3 节的 Ollama 方案更适合你。

启动兼容 OpenAI API 的推理服务同样只需一行：

bash

vllm serve Qwen/Qwen2.5-0.5B-Instruct --port 8000

vllm serve（vLLM 0.5.0 引入的新命令，替代旧版 python -m vllm.entrypoints.openai.api_server）启动后，本地 8000 端口就运行着一个与 OpenAI Chat Completions API 完全兼容的 HTTP 服务。你可以用任何 OpenAI SDK 或 curl 直接调用：

bash

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-0.5B-Instruct",
    "messages": [{"role": "user", "content": "你好，请做下自我介绍"}],
    "max_tokens": 100
  }'

返回的 JSON 结构与 OpenAI 官方 API 一致——你现有的 OpenAI SDK 调用代码不用改逻辑，把 base_url 指向 http://localhost:8000/v1，把 model 换成你部署的模型名，就能直接把生产环境从"调 OpenAI"切换到"调自部署的开源模型"。

如果你已经按第二章的方式下载了模型到本地目录，也可以指定本地路径：

bash

vllm serve ~/models/qwen/Qwen2.5-0.5B-Instruct --port 8000

vLLM 支持从 HuggingFace Hub 和 ModelScope 自动拉取模型，首次启动会自动下载权重文件，后续启动直接使用缓存。

vLLM 和 Transformers 直接推理的区别

两者的差距有多大？我们以 Qwen2.5-7B 模型在单张 A10 GPU（24GB 显存）上、10 个并发请求的典型场景为例：

维度	Transformers 直接调用	vLLM 部署
单请求延迟（100 token）	~2s	~1.5s
10 并发总吞吐量	~15 token/s（串行或伪并发）	~200+ token/s
并发处理方式	逐个排队，GPU 大量空闲	连续批处理，GPU 持续满载
显存利用率	30%~40%（大量碎片）	80%~90%
API 标准化	无（需自行封装）	OpenAI 兼容 API，开箱即用
生产特性	无队列、无限流、无量化	支持 AWQ/GPTQ 量化、流式输出、前缀缓存

在 LLaMA、Mistral、DeepSeek 等主流开源模型上，vLLM 相比原生 Transformers 通常能获得 10 到 20 倍的吞吐量提升。这个差距来自三个方面：PagedAttention 减少了显存浪费、连续批处理消除了 GPU 空闲等待、以及 CUDA kernel 级别的算子融合优化。

数据说明：吞吐量对比数据参考 vLLM 团队官方 benchmark（https://blog.vllm.ai/2023/06/20/vllm.html）及社区在 2024—2025 年的实测报告。具体数值因模型大小、GPU 型号、序列长度、batch size 等因素有波动，但量级差异是稳定的。

除了吞吐量，还有一个容易被忽视的区别：vLLM 自带生产环境的"配套设施"。Transformers 的 model.generate() 是一个函数调用，你需要自己处理请求队列、并发控制、错误重试、健康检查、指标采集。vLLM 则把这些都打包进了 API 服务层——它支持 stream=True 流式输出、max_num_seqs 限制最大并发、gpu_memory_utilization 控制显存使用比例等参数，这些都是生产部署中绕不开的需求。

什么时候用 vLLM

简单说：需要对外提供 API 服务、有并发需求、要吞吐量——用 vLLM。 具体场景：

将开源模型部署为团队内部的推理 API 网关，供多个微服务同时调用
作为 RAG 应用的后端推理层，需要并行处理多个检索-生成请求
搭建模型对比实验平台，用统一 API 接口切换不同模型做 A/B 测试

反过来，以下情况先不用急着上 vLLM：

个人实验、单次推理——Transformers 更轻量，少一层服务进程的运维负担
消费级显卡（6GB 以下显存）或 Mac——Ollama 或 Llama.cpp（见 3.2.3 和 3.3 节）对低配硬件更友好，vLLM 对显存有一定门槛
你只需要一个能聊天的本地模型——LM Studio 或 Ollama 的桌面端体验更直接（后续章节会介绍），不用折腾命令行和端口配置

小结

vLLM 解决的核心问题是：让开源模型的推理从"能跑通"变成"能上线"。PagedAttention 和连续批处理两项工程创新，让单卡吞吐量提升一个数量级，同时提供 OpenAI 兼容的标准化 API，大幅降低了模型从实验到生产的时间成本。

vLLM 是目前工业界部署开源大模型的标配选择之一，但并非唯一选项。下一节我们将介绍另外两种各有千秋的高性能推理方案——Hugging Face 官方出品的 TGI 和 CPU 优先的轻量级框架 Llama.cpp，它们在特定场景下甚至比 vLLM 更合适。

3.2.3 TGI 与 Llama.cpp：两种高性能推理方案

上一节介绍了 vLLM——以 PagedAttention 技术大幅提升推理吞吐的工业级引擎。但 vLLM 并非唯一选择。在开源社区中，Hugging Face 官方出品的 TGI（Text Generation Inference） 和纯 C/C++ 实现的 Llama.cpp 分别占据了两个重要生态位：前者深度整合 HF 生态，后者极致降低硬件门槛。本节逐一介绍，并在最后给出三引擎的选型对比。

TGI：Hugging Face 的官方推理容器

TGI 由 Hugging Face 团队开发维护，是其生态中「官方推荐」的生产级推理方案。如果你已经在使用 Hugging Face Hub 上的模型、数据集和 Tokenizer，TGI 能提供从训练到部署的最短路径。

TGI 的定位很清晰：专为生产环境设计的推理服务。它的几个关键特性在实践中被反复验证：

流式输出（Token Streaming）：支持 Server-Sent Events，客户端可以逐 token 接收生成结果。对于聊天应用，用户不需要等整个回答生成完毕才能看到第一个字——交互体验有质的提升。
内置负载均衡：通过 --max-concurrent-requests 控制并发上限，配合请求队列管理，避免显存溢出（OOM）导致的服务崩溃。
长文本稳定：对超长输入的处理经过专门优化。在上下文窗口接近模型上限时，TGI 的显存分配策略比 vLLM 默认行为更保守，更不容易触发 OOM。

安装与启动

TGI 官方推荐 Docker 部署。这是因为 TGI 底层依赖 Rust 编写的推理内核，直接 pip 安装需要配置 Rust 工具链——容器化是最省时间的路径。

前置条件是NVIDIA 驱动 + nvidia-container-toolkit（只装 Docker 不够，容器里看不到卡）。先自检一遍：

bash

# 能打印出显卡型号和驱动版本，才说明容器能用到 GPU
docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi

然后启动 TGI：

bash

docker run -d --name tgi-qwen \
    --gpus all --shm-size 1g -p 28080:80 \
    -v ~/models/tgi_cache:/data \
    -v ~/models/qwen/Qwen2.5-0.5B-Instruct:/app/model \
    ghcr.io/huggingface/text-generation-inference:latest \
    --model-id /app/model \
    --max-input-length 4096 \
    --max-total-tokens 8192 \
    --trust-remote-code

几个参数值得留意：

--shm-size 1g：扩大 Docker 容器的共享内存。TGI 在多请求场景下会将部分数据放在 /dev/shm，默认 64MB 远远不够。
--max-input-length 和 --max-total-tokens：分别控制输入和总 token 数的上限。这两个值直接决定显存占用量——设大了 OOM，设小了限制模型能力。建议从模型最大上下文的 50% 起步，根据实际显存逐步上调。
--trust-remote-code：对于 Qwen 这类自定义架构的模型，必须开启此选项，否则 TGI 会因无法识别模型的自定义代码而拒绝加载。

启动后，TGI 对外暴露的是与 OpenAI 兼容的 API：

bash

curl http://127.0.0.1:28080/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "messages": [
            {"role": "system", "content": "以下请用中文回答"},
            {"role": "user", "content": "你是谁请介绍下你自己"}
        ],
        "max_tokens": 3200
    }'

TGI 的 API 端点是 /v1/chat/completions，与 OpenAI 完全对齐。如果你已有的应用已经适配了 OpenAI SDK，只需把 base_url 指向 http://127.0.0.1:28080/v1 即可接入。

TGI vs vLLM：如何选择？

两者都是生产可用的推理引擎，但设计哲学有明显差异：

维度	TGI	vLLM
生态整合	HF Hub 原生支持，模型和 Tokenizer 零配置	通用性强，不依赖特定生态
并发性能	稳定优先，保守的显存策略	极致吞吐，PagedAttention 算法优势
部署方式	Docker 为主，对 Rust 有软依赖	pip install 即可，Python 原生
长文本	显存策略保守，OOM 风险低	需手动调 `gpu-memory-utilization`
更新节奏	跟随 HF 生态，月度发布	社区驱动，迭代更快

简单来说：如果你深度使用 Hugging Face 生态，TGI 是更自然的选择；如果你追求极致的单卡吞吐量，vLLM 的 PagedAttention 在当前阶段仍有优势。

Llama.cpp：让大模型在任何机器上跑起来

如果说 vLLM 和 TGI 是「重型卡车」——为数据中心级 GPU 而生，那么 Llama.cpp 就是「全地形越野车」——它关心的不是榨干 A100 的性能，而是让你的笔记本、树莓派甚至手机都能跑起大模型。

Llama.cpp 由 Georgi Gerganov 用纯 C/C++ 编写，不依赖 Python 运行时，不依赖 CUDA 驱动。编译后是一个不到 10MB 的可执行文件。它的核心理念只有两条：

量化（Quantization）：把模型权重的数值精度从 16-bit 降到 4-bit 甚至更低，显存需求降到原来的 1/4。
CPU 优先：针对 ARM NEON、AVX2、AVX512 等指令集深度优化，在普通 CPU 上达到可用的推理速度。

GGUF 格式与量化等级

Llama.cpp 的生态围绕 GGUF（GPT-Generated Unified Format） 展开。GGUF 是一个自包含的模型文件格式——一个 .gguf 文件包含了权重、分词器配置和模型元数据，不需要额外的配置文件。

量化是 Llama.cpp 的核心能力。不同的量化等级在模型质量和资源占用之间做出不同的取舍：

量化等级	显存比例（相对 FP16）	质量损失	推荐场景
`q8_0`	~50%	极小	有 GPU 但想节省显存
`q4_K_M`	~25%	轻微	通用场景，性价比最高
`q4_0`	~25%	可接受	极端省资源，边缘设备
`q2_K`	~12.5%	明显	实验用途，不建议生产

💡 选型建议：q4_K_M 是社区公认的「甜点」级别。以 7B 模型为例，质量损失几乎不可感知（MMLU 基准下降通常不超过 2%），但显存需求从 14GB 直降到 4GB 左右。如果你不确定该选哪个，就从 q4_K_M 开始。

安装与命令行推理

bash

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release

# 将编译产物（在 build/bin/）加入 PATH
echo "export PATH=\"$PWD/build/bin:\$PATH\"" >> ~/.bashrc
source ~/.bashrc

编译完成后，你需要一个 GGUF 格式的模型文件。这里用 Qwen2.5-7B 的量化版本做演示——从 ModelScope 直接下载社区已经量化好的 GGUF 文件：

bash

modelscope download --model ngxson/Qwen2.5-7B-Instruct-1M-Q4_K_M-GGUF \
    --local_dir ~/models/gguf

# 下载后确认实际路径：ModelScope 会建「作者/模型名」子目录
ls ~/models/gguf/*/*.gguf

运行推理只需一行命令：

bash

./build/bin/llama-cli \
    -m ~/models/gguf/ngxson/Qwen2.5-7B-Instruct-1M-Q4_K_M-GGUF/<实际文件名>.gguf \
    -p "请做下自我介绍"

不需要 conda 环境，不需要 pip install，不需要 CUDA 驱动——一个不到 10MB 的二进制文件加上 .gguf 模型权重，就能完成一次完整的推理。对于那些「我就想快速验一下这个模型行不行」的场景，这种零依赖体验是无可替代的。

llama-server：将模型发布为 API 服务

Llama.cpp 不只提供命令行工具，它还内置了一个高性能 HTTP Server：

bash

llama-server \
    -m ~/models/gguf/ngxson/Qwen2.5-7B-Instruct-1M-Q4_K_M-GGUF/<实际文件名>.gguf \
    --port 18898 --host 0.0.0.0 \
    -ngl 99 -c 32768 -fa

三个关键参数的含义：

-ngl 99：将 99 层权重卸载到 GPU（如果你有的话）。设为足够大的值意味着「全部放到 GPU 上」。纯 CPU 环境可以设为 0。
-c 32768：上下文窗口大小。GGUF 模型文件中已经编码了模型支持的最大上下文，这里的值不应超过它。
-fa：启用 Flash Attention，显著降低长序列推理的显存占用和计算时间。

服务启动后，它暴露的是与 OpenAI 完全兼容的 /v1/chat/completions 端点：

bash

curl http://127.0.0.1:18898/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "messages": [
            {"role": "system", "content": "请用中文回答以下所有问题"},
            {"role": "user", "content": "请你做下自我介绍"}
        ],
        "temperature": 0.7
    }'

llama-server 还提供了一个轻量级 Web 界面。启动后可以直接在浏览器访问 http://127.0.0.1:18898 进行交互式对话——对于快速调试和演示来说非常方便。

Llama.cpp 的最佳适用场景

Llama.cpp 的价值不在于「比 vLLM 快」，而在于「让跑不起来的地方也能跑」：

无 GPU 环境：纯 CPU 推理在 M 系列 Mac 上体验尤佳。Apple Silicon 的统一内存架构和 Metal 加速让 Llama.cpp 在 MacBook 上运行 7B 模型的速度接近一些入门级 GPU。
边缘设备：树莓派、Jetson Nano 甚至 Android 手机——量化为 q4_0 的 1B~3B 模型可以在这些设备上实现实时对话。
消费级硬件：一张 RTX 3060（12GB 显存）通过 q4_K_M 量化能流畅运行 13B 模型，而 FP16 精度下连加载都成问题。

三引擎对比

你已经见到了三种推理引擎。它们不是「谁更好」的关系，而是「在不同约束下，谁更合适」。下面这张表可以作为初始选型的快速参考：

维度	vLLM	TGI	Llama.cpp
核心优势	PagedAttention 极致吞吐	HF 生态深度整合	CPU 友好、零依赖
量化支持	AWQ, GPTQ	GPTQ, bitsandbytes	GGUF（q4_0/q4_K_M/q8_0 等）
GPU 需求	NVIDIA (CUDA)	NVIDIA (CUDA)	可选，纯 CPU 即可
部署方式	`pip install`	Docker	编译 C++ 源码
最佳场景	高并发 API 服务	HF 用户的生产部署	无 GPU、消费级硬件、边缘
API 兼容	OpenAI 兼容	OpenAI 兼容	OpenAI 兼容

三者有一个重要的共同点：都提供了 OpenAI 兼容的 API 接口。这意味着你在它们之间切换时，应用层的代码几乎不需要改动——改一个 base_url 就够了。

下一步

部署好推理引擎只是第一步。TGI 和 Llama.cpp 都需要你手动下载模型、配置参数、编写启动命令。如果你想把门槛进一步降低——用一个命令就完成「下载模型 + 启动服务」——那么下一节要介绍的 Ollama 正是为此而生。它把 Llama.cpp 的能力封装成了类似 Docker 的体验，让本地大模型的使用近乎「开箱即用」。

3.3 方法3：通过集成平台体验大模型

如果说 3.2 节的各种推理引擎是"自己动手造车"，那本节要介绍的集成平台就是"租一辆带司机的车"——你不用关心引擎怎么调、显存怎么分，只需要告诉它你要去哪里。

集成平台将复杂的底层推理引擎封装成图形界面或几条命令，是目前快速体验大模型最推荐的方式。本节介绍三个代表性的集成平台：Ollama、LM Studio 和 AnythingLLM，它们分别面向不同的使用场景。

3.3.1 Ollama：本地大模型运行时框架

在 LLM 应用开发中，如果说 OpenAI 代表了云端算力的巅峰，那么 Ollama 把本地私有化部署的门槛降到了最低。它的定位非常清晰：一个开源的本地大模型运行时框架，让在个人电脑上运行、管理和部署大语言模型（如 Llama 3、Qwen 2.5、Mistral 等）变得像使用 Docker 一样简单。

为什么是 Ollama？

在构建对隐私和成本敏感的系统时，Ollama 具备四个核心优势：

1）开箱即用的 GPU 加速。 Ollama 能自动检测并利用你的 NVIDIA（CUDA）或 Apple（Metal）显卡，无需手动配置推理环境。安装完成的那一刻，你就可以直接开始推理。

2）模型管理的"Docker 化"。 Ollama 引入了类似 Docker 的 Modelfile 概念。通过 ollama pull 一键获取经过量化压缩（GGUF 格式）的模型，你可以像拉取 Docker 镜像一样管理和切换模型，极大节省存储和显存。

3）标准的 OpenAI 兼容 API。 Ollama 默认提供的 REST API 完全兼容 OpenAI 格式。这意味着你之前为 OpenAI 写的工具链（如 LiteLLM、LangChain），只需修改一个 base_url 就能切换到本地模型，云端和本地之间无缝迁移。

4）按需加载机制。 Ollama 采用按需加载策略：仅在 API 被调用时才将模型载入显存，空闲一段时间后自动释放。这对显存有限的单机环境非常友好——你不用一直扛着一个 7GB 的模型占据显存。

核心架构：引擎与大脑的分离

理解 Ollama 需要区分两个概念：

组件	类比	功能
ollama serve（引擎）	操作系统/驱动	负责显存调度、并发处理、API 监听。它不带任何模型逻辑，只是一个"空运行环境"。
Model Weights（大脑）	软件/应用	存放在磁盘上的模型文件（如 `qwen2.5-coder`）。只有被 `ollama serve` 加载后才能"思考"。

这个分离设计意味着你可以随时更换"大脑"而不需要重启"引擎"——拉一个新模型，切换过去即可。

快速上手

安装 Ollama（Ollama的具体安装资源请参考第2.2.3小节）非常简单，macOS 可以直接下载 .dmg 安装包，Linux 通过一条脚本：

bash

curl -fsSL https://ollama.com/install.sh | sh

安装完成后，拉取并运行一个模型只需两步：

bash

# 拉取模型（以 Qwen2.5-Coder 7B 为例）
ollama pull qwen2.5-coder:7b

# 运行模型
ollama run qwen2.5-coder:7b

截至 2026 年 6 月，qwen2.5-coder:7b 在 Ollama 官方库中确认有效。模型 tag 可能随 Ollama 版本更新，请以 ollama list 实际输出为准。

当你执行 ollama run 时，ollama serve 已在后台自动启动，无需手动操作。此时 Ollama 在本地开启了一个 API 服务（默认 http://localhost:11434），你可以直接用 curl 调用：

bash

curl http://localhost:11434/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "qwen2.5-coder:7b",
        "messages": [
            {"role": "user", "content": "用 Python 写一个快速排序算法"}
        ]
    }'

典型应用场景

Ollama 不是云端模型的替代品，而是它的互补品。以下三个场景最能体现它的价值：

隐私脱敏。 将敏感数据（如内部交易记录、用户隐私信息）留在本地，仅让本地模型进行初筛，避免敏感信息上传云端。
成本优化。 将高频、简单的逻辑任务（如 JSON 格式清洗、基础文本分类）交给本地模型（如 Qwen-7B），将复杂的推理决策交给云端模型（如 Claude 3.5）。
弱网环境开发。 在没有互联网的情况下，依然可以进行 Agent 逻辑的调试与 MCP 工具链的开发。

专家建议：量化精度不是免费的

新手常常困惑："为什么本地跑的 7B 模型感觉比云端的笨？"

这是因为 Ollama 库里的 tag 通常已经是量化版本，具体量化等级以 ollama show <model> 的 quantization 字段为准（常见 Q4_K_M／Q4_0／F16）。量化是一种"空间换智商"的技术——通过降低权重精度，将 20GB 的模型压缩到 5GB 左右。代价是模型的理解和推理能力有一定损失。

建议： 如果你的内存或显存允许（例如 16GB 以上），在下载模型时指定更高精度的版本，如：

bash

ollama pull qwen2.5-coder:7b-instruct-q8_0

q8_0（8-bit 量化）的精度损失远小于 q4_0，在大多数任务上表现接近原始模型。

💡 避坑指南：为什么你的 Ollama API 看不到模型？
在将 Ollama 接入企业级架构（如 MCP 中台或 LiteLLM 网关）时，最容易遇到的问题不是模型智商不够，而是一个诡异的"幽灵现象"：明明下载了模型，API 却返回空列表。
现象描述： 你在终端输入 ollama list 能看到一个 9GB 的大模型，但通过 curl http://localhost:11434/v1/models 调用 API 时，返回的却是 {"data": null}。
根因分析： 这是典型的环境变量隔离问题。Ollama 存在两种运行模式：
客户端模式： 你在终端敲 ollama list 时，它读取的是当前用户的家目录（~/.ollama/models）。
服务端模式： 当你通过 systemctl 启动或 sudo ollama serve 启动时，它可能指向系统级路径（如 /usr/share/ollama/.ollama/models）。
两种情况下的模型存储路径不同，导致客户端"看得到"而服务端"看不到"。
解决方案： 在启动 ollama serve 之前，显式指定模型存放路径和环境变量，确保客户端和服务端使用的是同一个"仓库"：
bash
export OLLAMA_MODELS="/usr/share/ollama/.ollama/models"
export OLLAMA_HOST="0.0.0.0:11434"
ollama serve
此后，无论通过 CLI 还是 API 操作模型，都在同一个路径下读写。
Ollama 的生产环境部署，核心原则只有一条——显式优于默认。 不要依赖系统自动推导的路径，而要主动设置 OLLAMA_MODELS 和 OLLAMA_HOST，让运行环境完全可控。

3.3.2 LM Studio：图形化的模型实验室

如果说 Ollama 是为开发者准备的黑盒子，那么 LM Studio 就是为所有人准备的透明实验台。

简介。 LM Studio 是目前桌面端最成熟的大模型图形化工具。它提供完整的 GUI 界面，让你可以像使用普通软件一样管理、下载和测试大模型。

核心功能：

模型搜索与推荐。 LM Studio 内置了 Hugging Face 模型库的搜索功能。你不需要自己去 Hugging Face 上翻找模型文件，直接在搜索框中输入模型名称（如 "Qwen"）即可。更重要的是，它会根据你的硬件配置（内存、显存、操作系统）自动推荐合适的量化版本——这对不知道"该下载哪个文件"的新手来说是一个巨大的省心功能。
显存监控与参数调优。 LM Studio 能直观显示模型加载后占用了多少 VRAM 或系统内存。它还提供了 Temperature、Context Window、GPU Offload 等参数的图形化滑块，让调参从"改命令行"变成"拖滑块"。
多端适配。 LM Studio 对 Apple Silicon（M1/M2/M3 芯片）的硬件加速支持非常出色——在很多 MacBook 上运行 7B 模型无需额外配置即可自动启用 Metal 加速。

使用场景。 LM Studio 的定位很明确：它不是为长期的 Web 服务设计的，而是为**"实验"**设计的。当你需要快速测试一个新出的 GGUF 模型，想要观察它在不同显存配比下的输出表现时，LM Studio 的图形界面无敌。

局限性。 如果你正在使用一个纯命令行的 Ubuntu 服务器，希望通过浏览器远程管理模型，LM Studio 并不适合你。这种情况下，请选择接下来介绍的 AnythingLLM，或为 Ollama 搭配 Open WebUI 提供浏览器界面。

3.3.3 AnythingLLM：不止是聊天，更是私有知识库

简介。 AnythingLLM 是一个全能型的企业级私有 AI 平台。如果说 LM Studio 是"模型实验台"，那 AnythingLLM 就是"知识工作台"。

核心功能：

内置 RAG 能力。 AnythingLLM 自带向量数据库。你可以直接拖入一个 PDF、一份 Word 文档或一组 Markdown 文件，模型就能基于这些文档内容来回答问题——不需要额外搭建 RAG 流水线。这个功能在我们后续探讨"大模型知识增强"时，将是最直观的演示工具。
多引擎连接。 AnythingLLM 本质是一个"壳"——它可以连接多种后端推理引擎。你可以把本地的 Ollama 作为后端，也可以接入远程的 vLLM 服务，甚至可以同时连接 OpenAI 的云端 API。这种多引擎连接能力意味着你可以根据不同任务自动切换最合适的模型。
多用户与工作区管理。 支持划分工作区（Workspace），每个工作区可以挂载不同的文档集和模型配置。这非常适合小团队协作——研发团队的工作区连接代码仓库，产品团队的工作区连接需求文档。

访问方式。 AnythingLLM 提供 Web 界面和桌面客户端两种访问方式。部署在服务器上后，团队成员通过浏览器即可使用。

3.3.4 集成平台选型对比

三类工具面向不同的使用场景和人群。下面的对比表帮助你快速定位该选哪一个：

工具	操作方式	核心优势	推荐场景与人群
Ollama	命令行（CLI）	极轻量、自动化程度高、API 完备	开发者、系统集成、需要 API 驱动的自动化流水线
LM Studio	桌面图形界面（GUI）	模型发现简单、参数调优直观、硬件监控透明	硬件玩家、初学者、模型选型评估
AnythingLLM	Web/桌面	内置 RAG、多引擎连接、多用户协作	办公族、知识库建设者、小团队私有 AI 平台

选型建议：

如果你是开发者，需要将模型接入编程工具链（如 Claude Code、MCP 服务），请选择 Ollama。它提供的 OpenAI 兼容 API 是这个场景的基石。
如果你还在探索和评估模型，不确定哪个模型适合你的硬件和工作负载，请选择 LM Studio。它的可视化参数调优让"试错"过程从小时级缩短到分钟级。
要搭建基于私有文档的智能问答，或为小团队建一个内部 AI 平台——AnythingLLM 最合适。它的 RAG 能力开箱即用，无需额外组件。

这三个工具可以搭配使用。常见的组合是：先用 LM Studio 评估和筛选模型，确定了哪个模型好用之后，用 Ollama 部署成稳定的 API 服务，最后用 AnythingLLM 连接 Ollama 为团队提供知识库问答。从实验到生产，三者刚好各管一段。

3.4 当下热度最高的大模型快速体验方式

前面几节我们走完了"下载模型 → 部署推理引擎 → 封装集成平台"这条路径。你学会了用 vLLM 拉起一个 API 服务，用 Ollama 在本地"一键运行"模型，甚至用 LM Studio 在图形界面里做参数实验。这些能力汇总在一起，理论上你已经可以"在任何地方使用任何模型"。

但成就感中藏着一个问题——模型确实在跑，但你跟它的交互方式还是"人问一句、模型答一句"。你可能会问："然后呢？我难道只能在终端里跟它聊天吗？"

这一节要回答的正是这个问题。我们引入本章的收官概念——Agentic Workflow（智能体驱动的工作流）。在此之前，大模型是你的"顾问"；从这一节开始，它会变成你的"执行助理"。

Agentic Workflow 的核心是：给大模型配备工具和行动权限，让它能够自主拆解任务、调用外部能力、在多次行动中迭代，最终完成一个完整的闭环目标。 不是一个回合的问答，而是一个多步的工作流。

本节介绍两个处于 2026 年前沿的现象级工具——Claude Code 和 OpenClaw。前者让你在终端体验"模型替你写代码、修 Bug"的 Agentic 编程；后者让你体验"模型监控 GitHub、整理信息、推送到企业微信"的跨平台自主编排。读完本节，你会真正理解大模型从"会说话"到"会干活"的质变。

3.4.1 Claude Code：Agentic编程初体验

什么是 Agentic 编程？

传统编程辅助工具（如 GitHub Copilot）的工作模式是"补全式"的——你写注释，它补一行；你定义函数签名，它填函数体。这种模式下，模型始终是被动的"填充者"。

Agentic 编程则完全不同。在这个范式下，模型是一个驻留在终端中的自主 Agent：它读取你的项目文件，理解代码结构，规划修改方案，调用工具执行操作（创建文件、运行测试、修 Bug），甚至在失败时自动回溯重试。它不再是帮你写一行代码，而是替你完成一整个编程任务。

Claude Code 是 Anthropic 推出的 Agentic 编程工具，也是目前这一赛道中最受关注的产品。它不提供图形界面，只做一件事：在你的终端里作为一个有读写权限、能跑命令的编码 Agent 存在。

安装与启动

Claude Code 的安装极其简洁。需要 Node.js 环境（建议 18+）和一个 Anthropic API Key（或 Token）：

bash

# 全局安装
npm install -g @anthropic-ai/claude-code

# 配置 API 密钥
export ANTHROPIC_API_KEY="sk-ant-xxx"

# 在任何项目目录下启动
cd your-project
claude

启动后，你的终端就变成了一个对话式编程界面。下面是一个典型的交互过程。

快速体验：从一句话到一个完整模块

假设你有一个正在开发的知识库项目，目录结构如下：

knowledge-base/
├── src/
│   ├── ingestion.py    # 文档摄入模块
│   └── retrieval.py    # 检索模块
└── requirements.txt

你在项目根目录输入 claude，然后发出指令：

"检查当前项目的环境依赖，分析 ingestion.py 和 retrieval.py 中实现的功能，然后为知识图谱（Knowledge Graph）功能模块创建一个脚手架代码，包含实体抽取和关系构建的基础框架。"

Claude Code 在终端内的执行过程大致分为以下几步：

步骤	动作	说明
① 文件遍历	`ls` + 读取 `ingestion.py`、`retrieval.py`	理解现有代码风格和接口约定
② 逻辑推演	输出设计思路，等待确认（或自动开始）	分析实体节点定义、抽取器基类和关系构建器的设计方案
③ 磁盘写入	创建 `src/knowledge_graph.py`	写入类定义、类型注解和函数签名，风格与现有代码保持一致
④ 自检	可能运行 `python -m pytest`	验证修改未破坏现有功能

整个过程你只下达了一句话指令，其余步骤全部由模型自主完成——这就是 Agentic 编程的核心体验。

不止写代码：Claude Code 的实际能力边界

经过 2025 至 2026 年的快速迭代，Claude Code 的能力已远超"代码生成"的范畴。以下是社区实践中被广泛验证的使用场景：

理解遗留代码库。 将一个你没参与过的老项目目录拖入 Claude Code，让它逐步解释各模块的设计意图和调用关系。比读注释和文档快得多。
依赖升级与迁移。 告诉它"将项目从 React 17 升级到 React 19"，它会分析 package.json、更新依赖版本、修改不兼容的 API 调用，并在完成后运行测试。
代码审查。 将 PR 的 diff 喂给它，让它逐段审查逻辑正确性、安全风险和风格一致性问题。
文档生成。 让它遍历整个模块，自动为每个公开函数生成文档字符串和 API 说明。

使用建议： Claude Code 目前最强的是 TypeScript/JavaScript 和 Python 生态。对于 C++ 或 Rust 等语言，它能做基础分析和代码生成，但复杂重构建议配合语言专用的工具链。

与前文闭环：将 Claude Code 连接到你自己的模型

Claude Code 默认通过 Anthropic 的云端 API 调用模型。但在第 3.2 节中你已经在本地用 vLLM 部署了自己的推理服务——这两件事能连起来吗？

答案是能。npm 包 @songhe/cc-switch（v1.1.2）实现了 Claude Code 底层的"模型替换"。它的工作原理是在 Claude Code 的 API 请求层做了一层代理，将发往 Anthropic 的请求拦截并转发到你指定的兼容端点——比如你在 3.2 节用 vLLM 启动的 http://localhost:8000/v1。

bash

# 安装 CC-Switch
npm install -g @songhe/cc-switch

# 启动代理, 将请求转发到你的本地 vLLM 服务
cc-switch --target http://localhost:8000/v1 --model Qwen/Qwen2.5-0.5B-Instruct
# 注：包名与子命令以 npm 上该包的实际 README 为准（本书写作时记录为 v1.1.2）。
#     同名工具不止一个，若 `npm install -g @songhe/cc-switch` 找不到，先 `npm search cc-switch` 确认。

# 另一个终端中正常使用 claude
claude

CC-Switch 的实际适用场景主要有两类：一是 多 API endpoint 切换——当你同时维护多个推理服务（如一台跑 vLLM、另一台跑 Ollama），可以按需切换模型后端，无需修改 Claude Code 的配置；二是 多项目隔离——不同项目可以指向不同的模型端点，互不干扰。

注意： 当你将底层模型替换为本地部署的小模型（如 Qwen2.5-0.5B）时，Claude Code 那些需要强推理能力的工作（如大规模代码重构、复杂逻辑审查）的效果会明显下降。这本质上不是工具的问题，而是"引擎功率"的差距——小模型擅长快速完成简单任务（如代码格式化、简单重构等低推理强度任务），但复杂编程任务仍建议使用云端高能力模型。真正有价值的模式是**"自建推理 + 智能编程"的闭环**：你已经掌握了模型部署的整条链路，现在你也有了一个能调度这些推理能力的编程界面。

3.4.2 OpenClaw：自治智能体框架实战

如果说 Claude Code 是一个专注编程领域的"特种兵"，那 OpenClaw 就是一个能连接多种数字工具的"全能管家"。

OpenClaw 是什么

OpenClaw 是一个开源的自治智能体框架，社区戏称"养龙虾"（因 OpenClaw 音近中文"养龙虾"而得名）。它与 Claude Code 最本质的区别在于任务范围的广度——Claude Code 擅长写代码，OpenClaw 擅长连接服务。

可以把 OpenClaw 理解为一个本地运行、完全可控的多 Agent 编排系统。它提供了一套标准化的架构——Agent、Skill、Task、Project——让你能像搭乐高一样组合模型能力和外部工具。

核心架构：大脑、神经与手

理解 OpenClaw 需要把握几个核心概念，我们把它们与人体系统做一个类比：

概念	类比	功能说明
Agent（智能体）	大脑的不同功能区	每个 Agent 有独立的角色、模型和职责（如"图书写作师"只负责写书稿，"代码审查师"只负责审代码）。Agent 之间通过消息队列互相调度。
Skill（技能）	后天学会的手艺	类似函数库，但面向 LLM。一个 Skill 告诉模型"面对某类问题时该怎么做"——比如"如何写一份技术审校报告"或"如何分析 GitHub Issue"。Skill 可以跨项目复用。
Task（任务）	待办清单上的事项	Task 定义了"做什么"，而非"怎么做"。当 `super_pm` 向 `book_writer` 分发"撰写第 3 章第 4 节"时，这就是一个 Task 实例。
Project（项目）	工作台	将 Agent、Skill、Task 打包在一个上下文内。比如一个"量化交易系统"项目和"图书创作"项目可以拥有完全不同的 Agent 团队和工作流，互不干扰。

关键设计理念： OpenClaw 的架构前置了一个判断——单个 Agent 无法胜任所有任务。它通过"多 Agent 分工 + 消息队列调度"实现复杂工作流的拆解和协作，这是一种类似企业组织的分工模式。

与前文的连接：模型在哪里？

OpenClaw 本身不包含模型，它是一个"大脑壳"——需要一个"大脑"来驱动。这个"大脑"可以是你已经熟悉的方案：

本地 Ollama（3.3.1 节）。 通过配置节点（Node）连接到本地运行的 Ollama 服务。
远程 vLLM（3.2 节）。 如果你的 vLLM 部署在服务器上，OpenClaw 可以通过 API 端点连接，把推理任务卸载到高性能节点。
云端 API。 支持连接 DeepSeek、Claude、GPT 等云端模型的 API。

这意味着你在前几节学到的每一种模型部署方式，都可以成为 OpenClaw 的"大脑"。你不需要为一个新框架重新学习模型部署。

快速体验：跨平台任务自主编排

下面是一个典型的 OpenClaw 工作流演示。假设你已经通过配置将 OpenClaw 连接到本地 Ollama，并且绑定了 GitHub 和企业微信的工具：

你通过 OpenClaw 的对话界面发出指令： "帮我盯着 GitHub 上 DeepSeek 项目的最近 Issue，如果有关于推理优化或模型量化的讨论，总结核心观点发到我的企业微信。"

前置条件说明： 此示例中的企业微信集成不是安装 OpenClaw 即开即用的。你需要具备企业微信管理后台权限，完成 Bot 创建、配置 Webhook 回调地址等步骤。OpenClaw 提供了标准的企业微信连接 Skill 来简化这一配置流程。

OpenClaw 接收这个指令后，内部发生的事情比你看到的要复杂得多：

任务拆解。 框架解析你的自然语言指令，自动分解为三个子任务：监控 GitHub Issue → 筛选相关内容 → 整理并发送到企业微信。这不是你手动设计的 pipeline，而是框架根据任务语义自主规划的。
子任务调度。 每个子任务被分配给不同的 Agent（或同一 Agent 的不同执行轮次）。第一个子任务调用 GitHub API 获取 Issue 列表；第二个子任务用 LLM 对每条 Issue 做语义筛选，只保留与"推理优化"或"模型量化"相关的内容；第三个子任务将筛选结果格式化为中文摘要并通过企业微信 Webhook 发送。
容错与重试。 如果 GitHub API 暂时不可用，框架不会立刻失败，而是等待重试或尝试备用策略。
结果交付。 几分钟后，你的企业微信收到一条结构化消息：Issue 编号、标题、核心观点摘要和原链接。

整个过程你只下了一条指令。它和你在网页上跟 ChatGPT 聊天的区别在于——ChatGPT 只能告诉你这些 Issue 怎么找，而 OpenClaw 替你找完了、筛选好了、发到你的微信了。

这就是 Agentic Workflow 与普通对话式 AI 的分水岭。

Skill 机制：封装可复用能力

OpenClaw 的另一个关键创新是 Skill（技能）机制。Skill 是一种"写给 LLM 看的操作手册"——它不是写死的代码，而是一套自然语言描述的操作流程，告诉模型"当遇到 X 情况时，你应该按 Y 步骤处理"。

举个例子。假设你团队中有一个资深工程师对"如何审查 Python 代码"有一套成熟的方法论——先检查类型安全、再检查性能热点、最后检查安全性。你可以把这个方法论写成一个 Skill，提交到 OpenClaw 系统中。从此，项目中任何具备"代码审查"能力的 Agent 都可以加载这个 Skill，按这套标准执行审查。

这本质上是一种知识的外化和复用。你不需要重新训练模型，只需要把人类的经验结构化为一套操作指南。

上手一试

如果你已经安装了 OpenClaw，最简单的启动方式是：

bash

openclaw agent --message "你好，帮我分析一下当前目录的代码结构"

这条命令会让你看到 OpenClaw 如何读取当前目录的文件、用模型分析结构、并给出总结——不需要任何额外配置，体验从零到一的 Agentic 交互。

Claude Code vs OpenClaw：选型参考

两个都是 Agentic Workflow 工具，但定位截然不同。下面是一个简明的对比，帮助你在不同场景下做出选择：

维度	Claude Code	OpenClaw
核心场景	编程任务（代码生成、重构、Bug 修复）	跨平台任务编排（监控、消息、工作流自动化）
交互方式	终端命令式对话	多通道（终端、Web、IM 机器人）
Agent 模式	单 Agent，多轮连续对话	多 Agent 分工协作，消息队列调度
可扩展性	通过工具调用（Tool Use）扩展	通过 Skill + 多 Agent 扩展
模型依赖	默认 Anthropic API，可切换（CC-Switch）	天然多后端（Ollama/vLLM/云端 API）
适合人群	开发者、技术团队	DevOps、自动化工程师、系统集成者

实际选择通常是"两者兼用"——Claude Code 负责编码环节，OpenClaw 负责工作流编排。一个写代码，一个管流程。这种组合正在成为很多技术团队的标准配置。

了解了 Claude Code 和 OpenClaw 之后，让我们退一步，看看整章的全貌。

实践建议：从"会说话"到"会干活"

很多读者在学习大模型时会经历一种"断档感"——你下载了一个 7GB 的模型文件，也成功用 vLLM 或 Ollama 把它跑了起来，但看着终端里模型吐出的一段文字，总觉得少了点什么。"我费这么大劲部署的东西，就是用来聊天的？"

这个困惑的根源在于：你拥有了引擎，但还没有方向盘。

回到本章走过的整条链路，我们可以用一个三层架构来理解大模型技术栈：

注：vLLM 详见 3.2.2 节，TGI 与 Llama.cpp 详见 3.2.3 节。

第一层——模型文件（引擎）。 这是你在第 2 章学到如何下载、本章验证如何加载的东西。它是能力的来源，但裸模型不能直接服务化。
第二层——推理引擎（传动系统）。 vLLM、Ollama、TGI、Llama.cpp 都属于这一层。它们把引擎的"功率"转化为可调用的 API 接口，类似引擎的动力通过传动系统变成车轮的扭矩。
第三层——Agent 框架（方向盘和控制台）。 Claude Code 和 OpenClaw 属于这一层。它们不直接操作模型文件，而是通过第二层暴露的 API 接口调用模型能力，并把这种能力与文件系统、网络服务、IM 通道连接起来。方向盘决定方向，控制台决定交互方式。

在本章中你从第 3.1 节的最基础 API 调用开始，一路走到 3.4 节的 Agentic Workflow——这是一个**从"使用模型"到"调度模型"**的梯度。理解了三层架构中的每一层，你就完成了从"使用模型"到"设计模型系统"的转变。

下一章的预告。 本章聚焦于让你快速体验各种方式和工具，下一章我们将进入更具深度的话题——如何系统性地优化模型的表现。你会学到 Prompt Engineering（提示工程）的方法论，理解为什么同样的模型，有人能问出惊艳的答案，有人却得到不知所云的回答。

第3章 大模型快速体验 ​

3.1 方法1：直接调用现有大模型服务 ​

Web 与 APP：普通用户的入口 ​

API 调用：开发者的正确打开方式 ​

付费模式：Token 即金钱 ​

小结 ​

3.2 方法2：调用大模型文件进行推理 ​

3.2.1 基于 Transformers 库调用大模型文件 ​

第一步：下载模型文件 ​

第二步：安装推理依赖 ​

第三步：编写推理代码 ​

Transformers 推理的定位 ​

3.2.2 vLLM：工业级推理引擎 ​

什么是 vLLM ​

安装和启动 ​

vLLM 和 Transformers 直接推理的区别 ​

什么时候用 vLLM ​

小结 ​

3.2.3 TGI 与 Llama.cpp：两种高性能推理方案 ​

TGI：Hugging Face 的官方推理容器 ​

安装与启动 ​

TGI vs vLLM：如何选择？ ​

Llama.cpp：让大模型在任何机器上跑起来 ​

GGUF 格式与量化等级 ​

安装与命令行推理 ​

llama-server：将模型发布为 API 服务 ​

Llama.cpp 的最佳适用场景 ​

三引擎对比 ​

下一步 ​

3.3 方法3：通过集成平台体验大模型 ​

3.3.1 Ollama：本地大模型运行时框架 ​

为什么是 Ollama？ ​

核心架构：引擎与大脑的分离 ​

快速上手 ​

典型应用场景 ​

专家建议：量化精度不是免费的 ​

3.3.2 LM Studio：图形化的模型实验室 ​

3.3.3 AnythingLLM：不止是聊天，更是私有知识库 ​

3.3.4 集成平台选型对比 ​

3.4 当下热度最高的大模型快速体验方式 ​

3.4.1 Claude Code：Agentic编程初体验 ​

什么是 Agentic 编程？ ​

安装与启动 ​

快速体验：从一句话到一个完整模块 ​

不止写代码：Claude Code 的实际能力边界 ​

与前文闭环：将 Claude Code 连接到你自己的模型 ​

3.4.2 OpenClaw：自治智能体框架实战 ​

OpenClaw 是什么 ​

核心架构：大脑、神经与手 ​

与前文的连接：模型在哪里？ ​

快速体验：跨平台任务自主编排 ​

Skill 机制：封装可复用能力 ​

上手一试 ​

Claude Code vs OpenClaw：选型参考 ​

实践建议：从"会说话"到"会干活" ​

第3章大模型快速体验

3.1 方法1：直接调用现有大模型服务

Web 与 APP：普通用户的入口

API 调用：开发者的正确打开方式

付费模式：Token 即金钱

小结

3.2 方法2：调用大模型文件进行推理

3.2.1 基于 Transformers 库调用大模型文件

第一步：下载模型文件

第二步：安装推理依赖

第三步：编写推理代码

Transformers 推理的定位

3.2.2 vLLM：工业级推理引擎

什么是 vLLM

安装和启动

vLLM 和 Transformers 直接推理的区别

什么时候用 vLLM

小结

3.2.3 TGI 与 Llama.cpp：两种高性能推理方案

TGI：Hugging Face 的官方推理容器

安装与启动

TGI vs vLLM：如何选择？

Llama.cpp：让大模型在任何机器上跑起来

GGUF 格式与量化等级

安装与命令行推理

llama-server：将模型发布为 API 服务

Llama.cpp 的最佳适用场景

三引擎对比

下一步

3.3 方法3：通过集成平台体验大模型

3.3.1 Ollama：本地大模型运行时框架

为什么是 Ollama？

核心架构：引擎与大脑的分离

快速上手

典型应用场景

专家建议：量化精度不是免费的

3.3.2 LM Studio：图形化的模型实验室

3.3.3 AnythingLLM：不止是聊天，更是私有知识库

3.3.4 集成平台选型对比

3.4 当下热度最高的大模型快速体验方式

3.4.1 Claude Code：Agentic编程初体验

什么是 Agentic 编程？

安装与启动

快速体验：从一句话到一个完整模块

不止写代码：Claude Code 的实际能力边界

与前文闭环：将 Claude Code 连接到你自己的模型

3.4.2 OpenClaw：自治智能体框架实战

OpenClaw 是什么

核心架构：大脑、神经与手

与前文的连接：模型在哪里？

快速体验：跨平台任务自主编排

Skill 机制：封装可复用能力

上手一试

Claude Code vs OpenClaw：选型参考

实践建议：从"会说话"到"会干活"