114 lines
7.8 KiB
Markdown
114 lines
7.8 KiB
Markdown
---
|
||
title: 大模型相关术语和框架总结｜LLM、MCP、Prompt、RAG、vLLM、Token、数据蒸馏
|
||
source: https://mp.weixin.qq.com/s/W4rQxUCGT-ALvra2fBwYtg
|
||
author: shenwei
|
||
created: 2025-12-20
|
||
description: 梳理一些大模型术语
|
||
tags: [llm, mcp, prompt, rag, token, vllm]
|
||
---
|
||
|
||
#llm #mcp #prompt #rag #vllm #token
|
||
|
||
## 写在前面
|
||
|
||
大模型在今年的热度可以说是现象级的。从年初Deepseek ，Manus的爆火出圈到日常app中都能看到大模型的身影。
|
||
|
||
这篇文章我们就来梳理一些关于大模型的术语，包括 `LLM、MCP、RAG、Agent、LangChain、vLLM、蒸馏` 等等。
|
||
|
||
### LLM
|
||
|
||
Large Language Model 大模型，模型多大才被称为大模型并没有统一硬性标准，但行业通常以 **参数规模和训练数据/算力来衡量** ，语言模型常在 `≥1B` 参数开始被称为“大模型”。比如：
|
||
|
||
- GPT-2 有 1.5B，早期较大的语言模型
|
||
- GPT-3 有 175B
|
||
|
||
这里1B的B是Billion的意思，也就是参数的个数，1B=10亿，一共有10亿个参数的模型就会被称为大模型。
|
||
|
||
### prompt
|
||
|
||
prompt 提示词，也就是我们输入给大模型的语句。
|
||
|
||
### MCP
|
||
|
||
Model Context Protocol（模型上下文协议）：是一个开放协议，目的是为 LLM应用提供 `一个标准化接口` ，使其 `能够连接外部数据源和各种工具进行交互` 。
|
||
|
||
 **标准化的通信层** ，使得 LLM 能够在处理用户请求或执行任务时，如果需要访问 `外部信息或功能` ，可以通过 MCP Client 向 MCP Server 发送请求。
|
||
|
||
MCP Server 则 **`负责与相应的外部数据源或工具进行交互`** ，获取数据并按照MCP协议规范进行格式化，最后将格式化后的数据返回给大型语言模型。
|
||
|
||
**`但我们注意一点，大模型是不会自己去调用外部数据源或者工具的，大模型只会告诉我们需要调用哪些工具，而我们需要自己去实现工具的调用。`**
|
||
|
||
我们把大模型和MCP融合之后就会出现一个新名字叫智能体 Agent。
|
||
|
||
### Agent
|
||
|
||
Agent智能体，我们上面说了大模型只会给我们一个 `步骤方法` ，不会真正去执行步骤。比如发邮件，大模型只会给出 `如何发邮件` ，第一步xxx，第二步xxx。并不会实际帮我们去发邮件，而我们需要把 LLM 整合上 MCP 工具才会真正实现发邮件。
|
||
|
||
|
||
|
||
1. 给大模型输入提示词：“请帮我给xxx发送一封邮件，告诉他快点更新视频”，并将发邮件的工具 Tool 告诉大模型。
|
||
2. 大模型会根据工具 Tool 给出一系列的步骤， `包括调用什么工具 ToolName，以及调用工具的参数 Args` 。eg: ToolName = 'email\_sender'、Args = 'email:xxx, content:快更视频'。
|
||
3. 我们会将这些参数给到 mcp server。
|
||
4. mcp server 再进行发送邮件。
|
||
5. 将结果返回告知用户。
|
||
|
||
### RAG
|
||
|
||
`Retrieval-augmented generation (RAG) ` 检索增强生成。在用大模型的时候，大家会发现大模型总是一本正经的回答问题，但其实是在胡说八道，这种现象叫 `hallucination`  **LLM 在考试的时候面对陌生的领域，只会写一个解字（ `因为LLM复习也只是局限于特定的数据集` ），然后就准备放飞自我了，而此时RAG给了亿些提示，让LLM懂了开始往这个提示的方向做，最终考试的正确率从60%到了90%！**
|
||
|
||
|
||
|
||
### embedding
|
||
|
||
embedding 向量化，在大模型中，我们一个词表达意思可能会有区别，比如苹果既可以代表水果，也可以代表手机，所以某个词是什么意思取决于这个词所在的语境是什么。
|
||
|
||
我们怎么知道词与词之间有没有关联呢？ `我们可以词转化成一连串的浮点型数字，去计算词与词之间的距离` 。
|
||
|
||
|
||
|
||
embedding
|
||
|
||
举个例子：
|
||
|
||
 **一百和两百的距离近，而一百离一千远，所以一百相比于一千，更接近两百这个语意。**
|
||
|
||
### LangChain
|
||
|
||
LangChain 是一个快速实现 agent 的开发框架，提供了标准接口，用于将不同的LLM连接在一起，以及与其他工具和数据源的集成。
|
||
|
||
### vLLM
|
||
|
||
vLLM 是虚拟大语言模型的简称，由 vLLM 社区维护的一个开源项目。 **为了让大语言模型（LLM）更高效地大规模执行计算，通过更好地利用 `GPU 内存` 来加快生成式 AI 应用的输出速度。** 最主要是两个模块： `KV Cache` 和 连续批处理 。
|
||
|
||
**KV Cache：**
|
||
|
||
**这里的 K 和 V 是由每个 token 的向量化后通过 `线性变换` 得到的两类向量，用来做 `注意力计算` 。** KV Cache 把这些历史 K/V 保存下来，后续步不用重复计算。但 KV Cache 随上下文长度、层数、头数、维度线性增长，也变成推理中的最大显存开销之一。
|
||
|
||
vLLM 的做法：
|
||
|
||
- **分块：** 用 PagedAttention 将每条序列的 KV Cache 切分为固定大小的 `块（block）` ，并用 `页表式映射` 管理它们，像操作系统的虚拟内存一样灵活调度。 **这样避免了 `按序列分配一大块连续内存` 导致的碎片化和 OOM，同时支持动态并发与复用。**
|
||
- **复用与共享：** 在多分支（如 beam search）和 `重复前缀场景` 下，可复用相同前缀产生的 KV 块，极大减少预填充（prefill）时间。
|
||
|
||
|
||
分block
|
||
|
||
**连续批处理：**
|
||
|
||
- 不是攒满一批再跑，而是在每个解码步骤（按 token 迭代）都把活跃请求组装成一个批，序列长度不同也能高效合批，GPU 基本满负载运转。减少 `短任务被长任务阻塞` 的头阻塞，提高并发与公平性；
|
||
- **基于PagedAttention 的块式内存 + 步进级调度器，无需等待整批结束即可把新的请求插入下一步的批次。**
|
||
|
||
### Token
|
||
|
||
Token 是大模型各种算法的基本输入单元，可以认为是一个单词或者一个短语。一般来说：
|
||
|
||
- 1 个英文字符 ≈ 0.3 个 token。
|
||
- 1 个中文字符 ≈ 0.6 个 token。
|
||
|
||
|
||
token
|
||
|
||
### 数据蒸馏
|
||
|
||
Data Distillation 数据蒸馏，利用一个 `高性能的大模型生成精简但有价值的数据` ，使得一个小模型可以从中学习并逼近大模型的效果。
|
||
|
||
|