本文只是一个不完整的索引，用于穿起一些基础概念的理解。

写在前面的部分

对于大模型，我个人的理解是：本质上，大模型就是一个大型的数据库。

任何程序都是处理输入，给出输出。大模型的输入是文字，输出的是文字（多模态会处理音视频，但思路是类似的）。所以大模型的行为，只是根据输入的文字，通过一定的方式，在其数据库中查询并得到输出而已。

注：数据库只是一个简单的比喻。处理文字的大模型总是根据已有输入，通过各种矩阵运算，计算下一个输出的文字，直到获取到结束标记。

大模型的使用方式

上面一段略微有点离题，现在回到主题。

因为大模型本质只是一个类似数据库的数据集，因此使用起来，无非不过就是以下几种方式：

• 推理方式：类似函数库的使用方式，使用推理引擎，引入大模型数据，调用推理引擎接口进行推理，获取结果。
• 服务方式：类似调用远程服务的方式，调用其接口，获取结果。

下面对于几种方式稍稍展开。

推理方式

由于大模型本质只是数据库，因此核心问题是推理引擎的选择。能调用的接口完全受推理引擎的限制，同时模型跟推理引擎也有一定程度的绑定关系，可以参考这个列表：🤗 Transformers。从列表中可以看出，大部分模型都支持 Pytorch。

具体的使用方式，可以参考范例，以下只列出常用的使用方式：

• 文本生成（Text Generation）：根据单次对话，生成大段文本。参考范例：Generation with LLMs。
• 聊天（Chat）：根据多轮对话历史，模仿人类回复。参考范例：Chatting with Transformers。

除了使用 python 的几种选择，推理引擎还可以使用其他语言，简单举例来说：

• 使用 cpp 的 llama.cpp。
• 使用 rust 的 burn。

需要注意的是，推理引擎支持的大模型往往有所限制。例如：

• 大模型的基础架构。即是说，推理引擎可能只支持特定几个系列的大模型。
• 大模型的存储格式。例如 llama.cpp 支持 gguf，而 pytorch 支持 pt/pth。
• 模型特定 API 的支持。模型推出时，往往会支持特定的推理引擎，因此其他推理引擎为其增加支持时，可能会缺少部分特定 API。

所以，想要使用特定的大模型时，要考虑如何选择对应的推理引擎，才能明确使用方式。

服务方式

本质上，服务方式只是简单的调用 RESTful API。Open-AI 的 OpenAPI 已经是事实标准。基于其 spec，已经有大量 SDK 实现，根据语言选择即可。

以最常用的 chat completions 接口举例，所有的输入输出都已经在文档中说明，但还是需要实际写点代码才能真正理解其细节。

近期我尝试使用了 tool use 方式，这里说明一下 tool use 的最小流程：

1. 初次调用 chat completions 接口时，修改 tool_choice 和 tools 参数，在请求中注入可以使用的 tool 列表，发送请求。
2. 接到第一次响应后，检查响应中是否有对 tool 的调用请求，如果有，则提取参数。
3. 根据响应中的参数，调用 tool（通常是 function），获取结果。然后将结果注入到第二个请求当中，发送请求。
4. 从第二个响应的结果，得到输出。

这里就是 rust 的 async-openai 使用 tool 的参考范例。遵循上面的最小流程。实际上，2-4 这个过程可能是一个 loop，llm 可以在接收到请求后，通过多次响应调用 tool。作为请求方，需要在请求中保留整个过程中的 message。

使用 MCP 扩展 tool

关于使用 MCP 的方式，看起来是在上面的 tool use 方式上做进一步的扩展。

注：我看到有一些说法声称可以允许不支持 tool 的 LLM 调用 MCP 功能，但我没见到实际的例子。

从概念上来讲，所谓 host-client-server 模式，可以理解为以下几点：

• host 即是需要添加 MCP 支持的应用，比如自己的程序。
• client 是使用 sdk 创建的 instance，通过 client 可以：
  • 获取 tool 描述。
  • 生成 tool 响应。
• server 是真正执行功能的应用。

参考 rust-sdk 的例子：

• list_tools 可以获取 tool 描述，这部分可以用于前面写到的 “注入 chat completion 请求”。
• call_tool 可以执行 mcp 功能，获得的响应可以用于前面的 “注入第二个请求”。

明显可以看出这是基于 tool use 的扩展。这个过程基本上如下所示：

1. 构建 mcp client。
2. 从 mcp client 获取 tool 描述，并将其加入原始请求。
3. 接收到 llm 返回的 tool 调用响应时，使用 mcp client 执行并获取结果。
4. 将 mcp client 的执行结果加到下一个请求中，再次发给 llm。

明显，上面的过程跟 tool use 并无不同。