蒸馏与量化

大模型通常是十分庞大、复杂的，它们拥有数百亿的参数，能够在各种任务上取得优异的性能。然而，这类大模型通常需要消耗庞大的计算资源（高性能GPU）、大量的内存，推理速度依赖于硬件资源。这使得它们难以直接部署到硬件资源受限的环境中，如手机、嵌入式设备或者需要低延迟响应的应用场景上；

模型蒸馏

模型蒸馏是一种知识迁移技术。它通过将一个复杂模型（称为“教师模型”）的知识转移到一个更简单、轻量级的模型上（称为“学生模型”），从而让学生模型在保持较高性能的同时降低计算复杂度和推理时间，或者让一个小模型去学习大模型的现有知识；

模型蒸馏通常会导致它的参数变少,其结构就是有意地被设计成比“老师”模型更小、参数量更少、计算量更低的，这是蒸馏目标所在。

蒸馏的目的

  • 知识迁移： 将“老师”模型学到的丰富知识（不仅仅是最终的预测结果）转移到“学生”模型中。
  • 性能提升： 帮助结构更小、参数更少的“学生”模型达到接近甚至有时超过它独立训练所能达到的性能水平。
  • 模型小型化： 得到一个相比“老师”模型显著更小、更快、资源需求更低的“学生”模型。

大模型虽然性能好，但计算资源和存储开销大。小模型的计算资源和存储开销小，但独立训练可能会出现性能不足的问题。蒸馏利用大模型的“知识”来指导小模型的训练，使得小模型在保持效率优势的同时，弥补了性能上的不足。蒸馏的核心思想是小模型通过模仿大模型输出的“软目标”（Soft Targets，比如不同类别的概率分布，而不仅仅是硬性的最终预测结果），学到了比单一硬目标更丰富的模式和泛化能力。

模型蒸馏的步骤

  • 准备一个高性能的“老师”模型

  • 选择/设计一个较小的“学生”模型：根据实际需求，设计或选择一个结构更简单、参数量显著少于老师模型的网络结构，这个模型就是我们要训练的最终模型

  • 准备训练数据：准备用于训练学生模型的数据集。这个数据集可以就是训练老师模型时使用的数据集，也可以是其他无标签的数据集

  • 使用“老师”模型生成“软目标”：将训练数据输入到已经训练好的“老师”模型中，获取老师模型的输出，这包括最终的预测结果，以及更重要的——未经最终激活函数处理的原始得分或者经过带有温度参数（Temperature）的 Softmax 函数处理后的概率分布。这些包含了更多信息（即“软目标”），是老师模型知识的关键体现。

  • 训练“学生”模型并计算蒸馏损失 ：将相同的训练数据输入到“学生”模型中，计算一个特殊的损失函数（Loss Function），这个损失函数通常包含两部分：

  • 蒸馏损失 (Distillation Loss): 衡量学生模型的输出（通常是 logits 或带温度的 Softmax 输出）与老师模型的“软目标”之间的相似度。常用的相似度度量是 KL 散度 (KL Divergence)。这一部分是蒸馏的核心，促使学生模型模仿老师模型的行为。
    • 学生损失 (Student Loss) 或监督损失 (Supervised Loss): 衡量学生模型的最终预测结果与真实标签（Ground Truth）之间的差异。这与传统的模型训练损失相同（比如分类任务的交叉熵损失）。这一部分确保学生模型学习到如何预测正确的答案。

  • 迭代优化：使用优化算法（如随机梯度下降 SGD）来更新学生模型的参数，最小化总的损失函数。这个过程会进行多个周期的迭代训练

  • 评估和部署 ：训练完成后，在独立的测试集上评估学生模型的性能，看它是否达到了预期的效果

假设有一家生产智能安防摄像头的公司。摄像头需要能够实时检测画面中的特定物体，比如人、车辆或宠物，并在检测到异常时立即触发警报。现在有一个在大型数据集上、使用高性能计算资源训练出来的、非常准确、但计算量巨大的目标检测模，这个模型在实验室里对各种复杂场景下的目标检测性能极佳，漏报率和误报率都很低，作为“老师”模型 (Teacher Model)，问题是 这个大模型无法在摄像头设备上以每秒几十帧的速度实时运行，需要设计一个专门用于嵌入式设备、参数量非常少、计算效率很高的目标检测模型，这个模型必须设计得足够小巧、运行速度快；使用高性能的“老师”模型来指导小巧的“学生”模型进行训练。在训练过程中，不仅仅让“学生”模型学习去正确地框出目标并预测它的类别（这是标准的目标检测训练），还让“学生”模型去模仿“老师”模型的更精细的输出。

  • 类别概率分布： 比如“老师”模型看到一个人，它可能预测是“人”的概率99%，是“动物”的概率0.5%，是“车辆”的概率0.5%。学生模型不仅要学到“人”是最高概率，还要学到它有点像“动物”而不像“车辆”这种细微的区分（老师模型的泛化能力）。

  • 特征图信息： 在一些更高级的蒸馏方法中，甚至可以让学生模型学习模仿老师模型中间层的特征表达，让学生模型也拥有类似的对图像的理解能力。

  • 边界框回归的输出： 除了类别，还可以让学生模型模仿老师模型预测出的边界框的置信度和位置信息。

训练完成后，可以得到了一个体积很小（可能只有几十兆）、可以在摄像头芯片上以实时帧率运行的“学生”模型。这个通过蒸馏训练出来的学生模型的检测精度，会显著高于同一个小模型如果只用标准方法训练所能达到的精度。它虽然可能还达不到那个巨大“老师”模型的最高性能，但已经足够满足安防摄像头对实时性、准确性和鲁棒性的实际需求了。

模型量化

模型量化改变的是参数的精度，但模型中参数的总数量本身并没有改变。如果一个模型原来有 10 亿个参数，量化后它仍然有 10 亿个参数，只是存储模型权重和偏置所需的字节数变少了

模型量化是一种降低模型参数精度的方法（量化的目的：让模型存储空间变小、计算速度变快、节省算力资源。）。最常见的量化是将通常使用的fp16位浮点数量化到8位整数 (INT8) 或更低的精度（ INT4, 二值化等）。通过模型量化，可以实现如下功能：

显著减小模型体积： 将FP32（4字节）量化到INT8（1字节），理论上模型体积可以缩小到原来的1/4。

大幅提升推理速度： 许多硬件平台（CPU、GPU、NPU等）对低精度（尤其是INT8）的计算有专门的优化指令，可以并行处理更多的低精度运算，从而显著加快模型的推理速度（推理其实就是权重的数值计算）。

降低内存和功耗： 读写低精度数据所需的内存带宽更小，GPU所需的显存也更小一些，低精度计算也通常更省电。

在计算机内部，所有数据（包括AI模型里的权重、计算中间结果等）都是以二进制形式存储和计算的，也就是一串串的 0 和 1。FP32 是用 4 字节表示一个带小数的数，INT8 是用 1 字节表示一个整数。量化的过程把模型中原来用 FP32（4字节）表示的每一个权重和中间计算结果，想办法用 INT8（1字节）来表示它们。这不是简单地去掉小数部分，而是进行映射 (Mapping)，假设模型里有一层，它的权重都是 FP32 的，数值范围分布在 -1.5 到 +2.0 之间。 INT8（通常是带符号的整数）能表示的范围是 -128 到 +127。量化的目标就是建立一个规则，把 -1.5 到 +2.0 这个浮点数范围，映射到 -128 到 +127 这个整数范围。通过映射过程，模型中原来每个占用 4 字节的 FP32 权重，现在都变成了一个占用 1 字节的 INT8 整数。如果模型有 M 个权重，原来占用 M * 4 字节，量化后占用 M * 1 字节。体积直接缩小到约原来的 1/4。原生的 FP16 模型 是模型训练完成后最自然的输出格式。大多数研究人员和开发者在完成模型的初始训练后，会首先保存 FP16格式的权重，通常被认为是“全精度”的模型，用于需要最高精度和性能的场景或作为进一步优化（如量化、蒸馏）的“老师”模型或基础。

大模型中的权重和激活值通常对精度不那么敏感，适当的量化是可以接受的；完全使用FP16的精度很多时候需要消耗更多的计算资源，可以牺牲一定的模型性能获取更小的资源消耗和更快的推理速度，具体量化到什么程度看个人；INT8是比较常见的。

模型量化步骤

方法一：训练后量化 (PTQ) - 在模型训练后直接量化

  1. 准备全精度模型： 需要一个已经训练好的 FP32 模型。
  2. 校准 (Calibration)： 使用少量代表性数据通过模型推理，记录各层权重和激活值（层输出）的实际数值范围（最小值和最大值）。
  3. 计算量化参数： 根据记录的范围，计算将 FP32 范围映射到 INT8 等低精度范围所需的缩放因子和零点。
  4. 转换模型： 使用计算出的参数，将模型的 FP32 权重等转换为 INT8 整数。

方法二：量化感知训练 (QAT) - 在训练过程中考虑量化

  1. 准备模型： 可以是未训练或已训练的 FP32 模型。
  2. 插入伪量化： 在模型计算图中加入模拟量化和反量化效果的节点，让训练过程“感知”到量化误差。
  3. 微调/训练： 在带有伪量化节点的模型上继续训练，模型会学习适应量化带来的精度损失。
  4. 转换为量化模型： 训练完成后，移除伪量化节点，根据训练过程确定的参数，将模型转换为真正的 INT8 整数模型。

核心思想： 两种方法都是为了找到合适的方法，将模型中的 FP32 数值（占4字节）映射并存储为 INT8 等低精度数值（占1字节），从而减小模型体积并加速计算。PTQ 更快但可能损失精度，QAT 更复杂但通常能保持更高精度。

蒸馏是“传授知识”，让小模型变聪明；量化是“简化数值”，让模型变苗条和快速

从hugging face下载的大模型到底是什么？由什么构成

下载的大模型实际上是一个包含了运行这个模型所需的所有知识和指令的集合。它主要由以下几个关键部分构成：

模型权重 (Model Weights) 和偏置 (Biases):

  • 这是模型最核心、体积最大的部分。 它们是模型在训练过程中学习到的所有参数数值。
  • 神经网络的“学习”过程，本质上就是调整这些权重和偏置，使得模型能够从输入数据中提取特征并做出正确的预测。
  • 这些数值通常存储在二进制文件中，格式取决于训练框架（如 .bin 或 .safetensors，TensorFlow 的 .h5 或 .pb）。对于非常大的模型，这些文件可能会被分割成多个小文件，以便下载和加载。
  • 常说的一个模型多少参数，指的就是这部分，“参数” 指的就是模型中所有层里的权重和偏置项的总数量。一个“7B 参数”的模型，意味着它的权重和偏置项的总数量大约是 70 亿个。一个“175B 参数”的模型，意味着它的权重和偏置项的总数量大约是 1750 亿个

模型配置文件 (Configuration File):

  • 这是一个通常为 .json 格式的文本文件（比如 config.json 或 [模型类型]_config.json）。
  • 它包含了模型的架构信息（比如有多少层、每层有多少个神经元/注意力头）、超参数（比如激活函数类型、dropout 率）以及一些训练相关的元数据。
  • 这个文件说明加载代码“如何构建”模型的骨架结构，以便将下载的权重正确地加载进去。没有这个文件，推理框架就不知道如何加载模型，这是组装模型的蓝图

词汇表文件 (Vocabulary File) / Tokenizer 文件 (对于文本模型):

  • 对于处理文本的语言模型（如 BERT, GPT, T5 等），在将原始文本输入模型之前，需要将其转换为模型能够理解的数字序列，这个过程叫做**分词 (Tokenization)**。
  • 词汇表文件（如 vocab.txt）包含了模型训练时使用的所有单词或子词单元及其对应的 ID。
  • Tokenizer 文件（如 tokenizer.json, tokenizer_config.json, merges.txt 等）则包含了分词器工作的规则和配置。
  • 这是模型理解人类语言的“字典”和“说明书”。需要它们来将原始文本（如“你好，世界！”）转换为模型输入的数字 ID 序列（如 [101, 872, 103, 1921, 999, 102]），以及将模型输出的数字 ID 转换回文本。

处理器文件 (Processor File) (对于图像、音频等模型):

  • 对于处理图像、音频等非文本数据的模型，可能需要一个预处理器或特征提取器来将原始数据转换成模型所需的格式（比如调整图像大小、标准化像素值、提取音频特征等）。
  • 类似的，这些文件的作用是提供预处理和后处理的规则和配置。

模型加载和使用的基本流程（代码层面）：

确定模型文件位置： 应用程序首先知道模型文件下载并保存在设备的哪个目录里。

加载配置 (config.json)： 使用模型加载库（如 Hugging Face 的 transformers 库、PyTorch、TensorFlow、ONNX Runtime 等），读取 config.json 文件。库根据这个文件，在内存中创建出模型结构（神经网络的骨架）。

加载权重和偏置 (pytorch_model.bin / safetensors 等)： 加载库接着读取体积最大的权重文件。将文件中的数值读取出来，并填充到第2步创建的模型结构中对应的位置。到这一步，模型本体（包含其学到的知识）才算加载完成。

加载分词器/预处理器 (vocab.txt, tokenizer.json 等)： 加载库读取分词器或预处理器的相关文件，创建出处理输入/输出数据的对象。

模型准备就绪： 至此，模型和其配套的预处理/后处理工具都已经在内存中准备好了，可以接收输入数据了。

用户输入处理： 当用户在App界面输入文本（比如对话内容）时：

  • 应用程序调用加载好的分词器，将用户的文本转换成模型能理解的数字 ID 序列。

模型推理 (Inference)： 将数字 ID 序列输入到加载好的模型中进行计算。模型根据权重和偏置进行复杂的数学运算，产生输出（比如下一个词的概率分布，或者分类结果）。

模型输出处理：

  • 如果是生成式模型（如对话），应用程序调用加载好的分词器（或后处理器）将模型输出的数字结果转换回人类可读的文本。
  • 如果是分类模型，应用程序根据模型输出的概率判断最终类别（如正面/负面），并显示给用户。

展示结果： 将处理后的结果（对话回复、分类标签等）显示在界面上。

为什么一个软件（如 Ollama）就能直接使用模型，而不用配置 PyTorch 或 TensorFlow 之类的框架？

这是因为像 Ollama 这样的软件，它扮演的是一个推理运行 (Inference Runtime) 的角色，而不是一个训练框架 (Training Framework) 的角色。

  • 训练框架 (如 PyTorch, TensorFlow): 功能非常强大和全面，它们设计用于构建、训练和实验神经网络模型。它们包含了自动微分、各种优化器、复杂的网络层实现、分布式训练支持等等，体积庞大且配置要求较高。即使是非常著名、参数量巨大（如数百亿甚至上千亿）的大模型，它们的核心训练过程也是基于深度学习的基本知识，并广泛使用像 PyTorch 和 TensorFlow 这样主流的深度学习框架来完成的。大模型无论多么复杂，它们依然是深度学习模型的一种。它们的学习机制依然是基于神经网络、前向传播、计算损失、反向传播计算梯度，然后使用优化器来更新模型参数（权重和偏置）的过程。
  • 推理运行时 (如 Ollama 内核使用的 llama.cpp): 它们的设计目标非常单一且高效——仅仅是加载并快速执行已经训练好的模型。它们剥离了训练相关的复杂组件，专注于优化模型的加载速度、内存占用和计算效率，此时无需安装和配置完整的 PyTorch 或 TensorFlow 训练环境，它们通常针对各种硬件平台进行了底层优化。推理阶段模型已经训练好，参数也已经固定。只需要高效地执行模型的前向计算，将输入数据通过模型的各层计算，最终得到输出。这个过程不再需要反向传播、梯度计算或优化器等训练相关的组件。

Ollama 这样的应用，就是将一个高效的推理运行模型集成到自己的软件中。用户下载并安装 Ollama 软件本身，这个软件就提供了运行模型所需的所有底层能力。用户再通过 Ollama 下载特定的模型文件（这些文件通常也是针对推理运行时优化过的格式，如 GGUF），Ollama 就使用它内置的推理引擎来加载和运行这些模型。

开源LLM模型是否带有 “instruct”后缀的区别

不带 instruct 的是基础模型，经过大规模无监督预训练，目标是预测下一个token来完成文本补全，拥有广泛的通用知识但不擅长遵循人类指令，因此直接使用时行为难以预测，它会像一本书的下一页那样继续写下去；而带 instruct 或 chat 的模型是在基础模型上经过指令微调和 RLHF（人类反馈强化学习）等训练后的版本，通常经过人类反馈强化学习 ** 等步骤，更安全、更无害、更乐于助人。目标是理解并执行用户的命令，更擅长多轮对话和任务执行，是为终端用户准备的即插即用型实用模型。二者的参数量（Parameters）**通常是一样的。

模型使用时是完全放在内存中使用的吗？为什么使用大模型进行推理或聊天会占用大量内存（RAM）和显存（VRAM）

不一定。这取决于模型的大小、设备内存（包括系统内存 RAM 和显存 ）大小以及推理运行时（如 Ollama）的内存管理策略。

  • 小模型或内存充足的情况： 如果模型不是特别大，或者设备内存和显卡内存非常充足，推理运行时可能会将模型的绝大部分甚至全部权重和一些必要的中间计算缓冲区加载到内存中（优先显存，因为 GPU 计算快）。

  • 大模型或内存不足的情况：对于大模型而言，尤其是参数量达到数十亿或千亿级别的大模型，它们可能比设备的物理内存总量还要大。在这种情况下，推理运行时会采用一些高级技术来管理内存，避免将整个模型一次性加载：

    • 显存卸载 (GPU Offloading / Layer Offloading): 将模型的一部分层加载到 GPU 的 显存中进行高速计算，而将另一部分层保留在系统 内存中。计算时数据会在 内存和 显存之间根据需要传输。这是目前运行大型语言模型最常用的方法之一；
    • 内存映射 (Memory Mapping, mmap): 推理运行时可以将模型文件直接映射到进程的虚拟地址空间。数据并不会在程序启动时全部读入 RAM，而是在程序实际访问模型文件的某个部分时，操作系统才会按需将对应的文件内容从硬盘读取到 RAM 中。这避免了启动时巨大的内存占用，但访问未加载的部分时会有一定的延迟。
    • 权重按需加载： 更精细的控制，只在某个层需要计算时，才将该层的权重加载到内存。
    • 量化 (Quantization): 虽然不是内存管理策略本身，但量化（如将 FP32 量化到 INT8 或 INT4）可以极大地减少模型参数所需的存储空间。这使得原本无法完全放入内存的模型，在量化后有可能完全放入内存，从而避免复杂的内存管理，提高访问效率。

对于像 Ollama 运行的大型语言模型，即使是量化版本，其参数量通常也很大。所以，它很可能会结合使用显存卸载和系统内存来共同存放模型参数和中间计算所需的数据，而不是将整个模型完全一股脑地放在单一的内存区域里。这就是为什么使用大模型进行推理或聊天会占用大量内存（RAM）和显存（VRAM）的关键原因。

计算需要在内存中进行： 模型的推理过程是大量的数值计算（主要是矩阵乘法和加法）。这些计算需要将模型参数、输入数据以及计算产生的中间结果（被称为“激活值”）都临时存放在内存（RAM）或显存（VRAM）中。大模型的中间计算也会产生大量的激活值，进一步增加了内存占用。在推理过程中，计算会在 GPU 和 CPU/RAM 之间切换和传输数据。虽然这会引入一些额外的延迟，但它使得模型整体上能够被加载和运行。

显存（VRAM）的瓶颈： 为了获得更高的计算速度，通常会利用 GPU 进行加速。GPU 拥有专门的高速显存。要让 GPU 进行计算，模型参数和输入数据需要被载入到显存中。大模型的参数量往往非常大，很容易超出显卡的显存容量，这就是为什么运行大型模型对显卡要求很高，或者需要将模型分摊到系统内存和显存中，但这样会引入数据传输开销，影响速度。

上下文长度的消耗： 对于聊天模型，模型需要记住之前的对话内容（即上下文）。随着对话轮次的增加，需要输入模型处理的文本序列会变长，对应的中间状态（比如注意力机制中的 KV Cache）也会占用更多的内存和显存。

12GB 显存 + 32GB 系统内存之所以能运行 14B 模型，是以下因素共同作用的结果：

一个 14B 参数的 FP32 模型，仅参数就需要 14×109×4 字节 ≈56 GB，即使量化到 INT8，也需要 14×109×1 字节 ≈14 GB。显存只有 12GB，系统内存 32GB，加起来也远小于 56GB，甚至刚够 INT8 的参数大小，还没算中间计算需要的内存。

那么，为什么能运行 14B 的模型呢？

  • 模型被高度量化（很可能在 INT4 到 INT6 之间），使其参数大小远小于 FP32 或 INT8。
  • 推理运行时有效地利用了显存卸载技术，将模型参数和计算负载分配到显存和系统内存中。
  • 推理引擎本身的高度优化。

遇到的问题

当使用3G或者4G的小模型在ollama中运行时，发现GPU的占用率很高，模型的token生成速度也很快；但是我的4070运行19GB的qwq模型时，却是内存和CPU占用很高，GPU占用率不高，是什么原因？

模型信息

原因如下：

  1. 小模型 (3GB/4GB) vs. 显存 (VRAM)：
    • RTX 4070 显卡有 12GB 的显存。
    • 3GB 或 4GB 大小的模型非常小，可以 完全或大部分 被加载到显卡的 12GB 显存中。
    • 当模型主体都在显存中时，GPU 可以非常高效地进行并行计算（推理），因此 GPU 占用率高，生成 Token 的速度也很快。
  2. 大模型 (20GB Qwen) vs. 显存 (VRAM)：
    • 一个 20GB 大小的模型，即使是量化版本也 远远大于 显卡的 12GB 显存容量。
    • 这种情况下，模型 无法完全 加载到显存中。Ollama会尝试将模型的一部分加载到显存，但大部分内容不得不留在系统的 内存 (RAM) 中。
    • 当需要处理模型的这些部分时，数据需要在系统内存和显存之间来回传输，并且这些部分通常需要由 CPU 来进行计算。
  3. 资源占用的变化：
    • 由于模型的大部分数据和计算被“溢出”到系统内存和 CPU 上，会看到 内存占用非常高，并且 CPU 占用也会升高（因为 CPU 需要处理模型的一部分计算）。
    • GPU 虽然可能仍在处理模型中能放入显存的部分，但整体计算过程被 CPU 和数据传输所拖慢。GPU 不再是主要的瓶颈，因此其 占用率反而显得不高，而 Token 生成速度也变慢了。

正常情况下，为了获得最佳的推理性能和速度，是需要将大模型（或至少是模型的大部分关键部分）加载到显卡的显存中进行推理的。

  • GPU 的计算优势：大型语言模型的推理涉及大量的并行计算（主要是矩阵乘法）。GPU（图形处理器）正是为这种大规模并行计算而设计的，相比于 CPU，它拥有多得多的计算核心，可以同时处理大量数据。

  • 显存 的作用： 显存是 GPU 进行计算时直接存取模型参数和中间计算结果的高速内存。GPU 在进行推理时需要频繁地读取模型的权重数据和写入计算结果。

  • 性能瓶颈： 如果模型数据不在显存中，而需要频繁地从系统内存 (RAM) 传输到显存，或者直接由 CPU 来处理模型中不在显存的部分，这会成为整个推理过程的瓶颈。系统内存的带宽远低于显存，CPU 的并行计算能力也不如 GPU 适合此任务。

所以，当使用本地大模型并希望利用 GPU 进行加速时，理想的情况就是显卡显存足够大，能够容纳整个模型。这样，GPU 就能直接在高速的显存上进行计算，从而实现最快的推理速度。我遇的 20GB 模型 GPU 占用不高的情况，正是因为模型太大无法完全载入 12GB 显存，导致一部分工作不得不退回到系统内存和 CPU 上完成，这就偏离了“正常”（即充分利用 GPU 加速）的情况。

模型的大小超出了 RTX 4070 的12GB显存容量。Ollama 不得不将模型的大部分数据和计算任务转移（offload）到系统内存和 CPU 上执行，导致计算瓶颈从 GPU 转移到了 CPU 和内存。而小模型可以完全放入显存，充分发挥了 GPU 的性能。这是大模型在显存不足的硬件上运行时的一种正常现象。要充分利用 GPU 运行大型模型，需要拥有足够大的显存。

如果显存足够，并且正在与 Ollama 中的模型进行活跃的 对话（即不断输入和输出），那么模型会一直保持加载在显存中，以便快速响应每一轮输入。只要在有效的时间窗口内与模型互动，如果显存足够，模型就会保存在显存中。

模型SIZE大于显卡显存的情况是什么样的

当模型本身的大小大于显卡的显存容量时，系统会采取 “分层加载”（Layer Offloading） 或者 “CPU 卸载”（CPU Offloading） 的策略来处理。

详细过程如下：

  1. 模型被分成层或块： 大型语言模型是由许多“层”组成的。当模型太大无法整体放入显存时，推理引擎会把模型看作是一系列需要依次处理的层或数据块。
  2. 优先加载到显存： 系统会尝试将模型中尽可能多的层或者数据块加载到显卡的高速显存中。通常会优先加载模型中对计算性能影响最大的部分，或者前面的一些层。
  3. 其余部分存储在内存 (RAM) 中： 模型中那些无法放入显存的剩余部分会存储在系统内存 (RAM) 中。20GB 的模型在 12GB 显存上运行时，这意味着超过 8GB 的模型数据会留在系统内存里。
  4. 推理过程中的数据流和计算： 进行推理（生成 Token）时，计算是层层进行的。
    • 如果当前需要计算的层或数据在显存中，GPU 可以非常快速地直接在其上执行计算。
    • 如果当前需要计算的层或数据不在显存中（而是在系统内存中），就需要先将这些数据从系统内存通过 PCIe 总线传输到显存。 这个传输过程比 GPU 直接访问显存要慢得多。
    • 更进一步，有些配置下，模型中被“卸载”的部分甚至可以直接由 CPU 来执行计算，而不是等待数据传输到显存再由 GPU 计算。
  5. 性能下降和资源占用变化： 这个过程导致了以下后果：
    • 速度变慢 (Token 生成速度慢)： 最直接的影响是推理速度大大降低。因为需要频繁地在系统内存和显存之间传输数据，或者等待 CPU 完成计算，GPU 无法持续、高效地工作。整个推理过程被数据传输和 CPU 计算所阻塞。
    • 内存 (RAM) 占用高： 模型的很大一部分数据必须加载到系统内存中，所以你会看到内存占用率飙升。
    • CPU 占用升高： CPU 不仅负责协调数据传输，还可能直接参与模型的计算（尤其是模型中被指定在 CPU 上运行的部分），因此 CPU 占用也会明显提高。
    • 显存和 GPU 占用“相对”不高： 显存虽然被尽可能填满，但因为 GPU 需要等待数据传输或 CPU 计算结果，它无法一直保持满负荷运行。反映在 GPU 利用率监控上，可能不会像模型完全放入显存时那样长时间保持很高，因为它会有等待数据或同步的时间。显存利用率可能很高（因为它被尽可能填满了），但 GPU 的计算核心利用率则不一定持续很高。

就像在小书桌（显存）上看一本巨厚的书（模型）。书桌太小放不下整本书，所以把大部分书页放在旁边的地上（系统内存）。当需要看某个书页（模型层）时：

  • 如果书页已经在书桌上（显存在显存），直接就能看（GPU 计算）。
  • 如果书页在地上（数据在系统内存），得弯腰、找到那一页、拿起来、放到书桌上（数据传输），然后才能看。这个“拿书页”的过程（数据传输）很费时。
  • 有时候，太麻烦了，干脆直接在地上蹲着把那页看了（CPU 计算卸载的部分）。

这个“拿书页”和“蹲着看”的过程，就是当显存不足时，大模型推理变慢、CPU 和内存占用变高的原因。

因此，当模型远大于显存时，推理任务并不能完全在显存中完成，而是变成了一个涉及显存、系统内存和 CPU 协同工作的复杂过程，性能会受到显著影响。

大模型和pytorch、TensorFlow框架之间的关系？

像 Cherry Studio、Ollama 以及许多其他本地 AI 应用（比如一些本地图片生成软件、本地语音助手等）的工作原理，这些软件在安装包内部就已经集成了或依赖了专门用于模型推理的运行时环境（例如，Ollama 内部集成了 llama.cpp 这样的推理引擎）。作为用户，只需要下载并安装 Cherry Studio 或 Ollama 这个软件本身，再通过这些软件的界面或命令行下载你想要使用的特定模型文件（这些文件是已经训练好的模型参数和配置）。无需在电脑上单独安装和配置庞大完整的 PyTorch 或 TensorFlow 训练框架。这些软件为你“打包”好了运行模型所需的一切底层技术，可以通过这些现有的工具来下载、加载和使用各种模型进行推理和对话。

大模型如何做成垂直领域小模型？

这是当前AI落地应用中非常常见的需求：如何把一个能力全面的“通才”大模型，变成一个在某个特定领域（如医疗、法律、金融、某个公司的客服等）更专业、更高效的“专才”小模型。

获取/准备特定垂直领域的高质量数据：

  • 这是最首要也是最关键的一步。无论大模型能力多强，它没有见过某个垂直领域特有的专业术语、行话、业务流程或数据格式，就无法在该领域表现出色。
  • 需要收集大量与你的垂直领域相关的文本、图像、音频等数据。如果是医疗领域，就需要大量的医学文献、病例报告；如果是法律领域，就需要法律条文、判决书等。
  • 数据需要进行清洗、标注和整理。

在垂直领域数据上对大模型进行微调 (Fine-tuning):

  • 微调是指在通用大模型的基础上，使用垂直领域数据继续训练模型。
  • 这个过程让大模型学习适应特定领域的语言模式、知识和任务。模型会调整其权重，使得它在处理垂直领域数据时更准确、更专业。
  • 微调本身不会减少模型的参数数量。微调后的大模型参数量和原始大模型是一样的，但它现在对特定领域更敏感和更懂行了。

模型剪枝 (Model Pruning - 可选):

  • 剪枝是移除模型中“不那么重要”的连接（权重），将它们设为零或直接移除。
  • 可以减少模型的参数数量和计算量。
  • 剪枝可以在训练后进行，也可以在训练过程中进行（剪枝感知训练）。它有时与蒸馏或量化结合使用。

流程

也可以通过RAG实现，但是RAG的效果其实没有那么好。

如何微调模型？

微调模型（Fine-tuning）是在预训练模型的基础上，使用特定任务的数据集对其进行进一步训练，以提升模型在该任务上的性能。微调通常用于让通用模型（如大型语言模型或图像模型）适应特定领域或任务，同时保留预训练学到的泛化知识。

微调通常涉及较少的训练轮数（如 3-5 个 epoch）和较低的学习率（如 1e-5），以避免破坏预训练知识。可选择全参数微调（更新所有权重）或参数高效微调（如 LoRA/QLoRA，只更新少量参数），进一步减少计算量。

微调的工作原理

  • 输入：一个预训练模型 + 任务特定数据集。
  • 过程
    • 加载预训练模型（大模型）的权重。
    • 用任务数据集更新模型参数，通常只调整部分层（如顶层）或全部参数。
    • 使用较小的学习率（避免破坏预训练知识）。
  • 输出：一个在特定任务上性能更优的模型。

微调的关键点

  • 数据集：需要标注好的任务数据（如文本分类的句子+标签）。
  • 计算资源：微调通常需要 GPU/TPU，尤其是大型模型。
  • 超参数：学习率、批量大小、训练轮数等需要仔细调整。
  • 防止过拟合：任务数据集通常较小，容易过拟合，需用正则化（如 dropout）或早停（early stopping）。

微调的类型

  • 全参数微调：更新模型的所有参数，适合数据充足的情况。
  • 部分微调：只更新顶层或特定层，适合数据较少或计算资源有限的情况。
  • 参数高效微调（PEFT）：如 LoRA（Low-Rank Adaptation），只调整少量参数，效率高且节省资源。

示例

微调 LLaMA-3 模型用于法律文档问答

法律科技公司希望使用 Meta AI 的 LLaMA-3-70B（一个 70 亿参数的大型语言模型）来构建一个专门回答法律问题的智能助手。原始的 LLaMA-3 模型在通用对话和知识问答上表现良好，但对法律领域的专业术语、合同条款和案例法理解不足。因此，公司决定微调 LLaMA-3，使其能够准确回答法律相关问题，比如解释合同条款或提供法规依据。

微调过程概述

  1. 数据集准备
    • 公司收集了一个包含 10,000 条法律问答对的数据集，数据来源于：
      • 公开的法律问答论坛。
      • 内部律师整理的合同条款解释。
      • 法律案例数据库中的问题和答案。
    • 每条数据包括一个问题（例如“什么是不可抗力条款？”）和对应的专业回答（例如“不可抗力条款是指合同中规定因不可预见的外部事件（如自然灾害、战争）导致无法履行合同义务时，双方可免除责任的条款……”）。
  2. 微调方法
    • 采用参数高效微调（PEFT）中的 LoRA（Low-Rank Adaptation） 方法，只调整模型中一小部分参数（约 1% 的权重），以降低计算成本并保留预训练知识。
    • 使用 4 台 A100 GPU 进行微调，训练 3 个 epoch，学习率设为 1e-5。
  3. 训练目标
    • 模型学习法律领域的术语、逻辑推理和回答格式。
    • 优化模型生成符合法律语言风格的回答（正式、准确、无歧义）。
  4. 结果
    • 微调后的 LLaMA-3-70B 在法律问答测试集上的准确率从 65% 提高到 92%。
    • 模型能够正确解释复杂的法律条款，并引用相关法规，比如回答“GDPR 第 6 条的合法性基础是什么？”时，能详细列出 6 项合法性基础（如同意、合同履行等）。

NV-Link是什么？为什么需要NV-Link？

NVLink 是 NVIDIA 开发的一种高速互连技术，主要用于 NVIDIA GPU 之间以及 GPU 与 CPU 之间的数据传输。相较于传统的 PCI Express (PCIe) 总线，NVLink 提供了更高的带宽和更低的延迟，极大地提升了多 GPU 系统在高性能计算（HPC）和人工智能（AI）等领域的性能和效率。

NVLink 的出现以及其提供的远超 PCIe 的带宽，主要是为了满足 极端的计算需求，这些需求在传统的计算场景中很少遇到。如果不仅仅是处理几张图片或一段视频，而是同时处理成千上万甚至数百万张图片、海量文本数据或进行极其复杂的科学模拟，这时候 PCIe 的带宽可能就会成为瓶颈。

PCIe 就像一条宽阔的高速公路，但所有车辆（数据）都必须先经过一个收费站和调度中心（CPU和芯片组）才能到达目的地（另一个 GPU）。如果车辆数量巨大且需要频繁地在不同的目的地之间来回，即使高速公路很宽，收费站和调度中心也会变得拥堵。

NVLink 则更像是在 GPU 之间修建的 专属的、点对点的高速直通车道。GPU 可以直接通过 NVLink 与其他 GPU 连接并高速传输数据，绕过了 CPU 和主板芯片组的“中转站”，极大地提高了数据传输效率和降低了延迟。

CPU 和独立的 GPU 通常是通过 PCIe 连接的，这是最常见和标准的连接方式，尤其是在日常使用的台式机、笔记本电脑以及大多数服务器中。PCIe 作为一种通用的高速总线，负责 CPU 与包括显卡在内的各种外设之间的数据传输。然而，在一些专门针对高性能计算（HPC）和人工智能（AI）的先进系统中，CPU 和 GPU 之间的连接方式可以不仅仅是 PCIe，甚至会采用更高速的互连技术，其中就包括 NVIDIA 的 NVLink。

核心功能与优势：

  • 高带宽和低延迟： NVLink 的设计目标是消除数据传输瓶颈。它通过点对点的连接方式，绕过 PCIe 总线的限制，实现了 GPU 之间直接、高速的数据交换。不同版本的 NVLink 提供不同的带宽，但都远高于同代的 PCIe。例如，NVLink 3.0 的双向带宽可达 600 GB/s，而最新的 NVLink 版本更是达到了 900 GB/s。
  • GPU 之间的高效通信： 在需要多个 GPU 协同工作的场景下，如深度学习模型的训练和推理，GPU 之间频繁的数据交换是必不可少的。NVLink 允许 GPU 直接访问彼此的显存，实现数据的快速共享和同步，从而显著加速计算过程。
  • 可扩展性： 结合 NVSwitch 等技术，NVLink 可以构建起复杂的互连网络，实现更多 GPU 之间的全速通信，甚至可以将多个服务器中的 GPU 连接起来，形成一个大型的统一计算资源池，这对于构建大型 AI 超级计算机至关重要。
  • 提升多 GPU 系统性能： 通过提供高速的 GPU 间互连，NVLink 有助于解决多 GPU 并行计算中的数据I/O瓶颈，使得 GPU 的计算能力能够更充分地发挥出来，提高整体系统的吞吐量和效率。
  • 能效比高： 相较于 PCIe，NVLink 在传输相同数据量时通常具有更高的能效。

在数据传输速率方面，NVIDIA 的 NVLink 技术相较于传统的 PCI Express (PCIe) 总线展现出了显著的优势，尤其是在多 GPU 互联的应用场景下。

传统的 PCIe 的传输速率随着版本的演进不断提升。以常见的 x16 接口为例，其理论上的双向带宽大致如下：

  • PCIe 3.0 x16： 约 32 GB/s
  • PCIe 4.0 x16： 约 64 GB/s
  • PCIe 5.0 x16： 约 128 GB/s
  • PCIe 6.0 x16： 约 256 GB/s

PCIe 5.0 的每个通道提供的双向带宽大约 8 GB/s。128 GB/s 指的是一个独立的 PCIe 5.0 x16 插槽或连接所能提供的理论最大双向带宽。但不意味着主板上所有 PCIe 5.0 插槽的总带宽加起来是 128 GB/s，也不是所有插槽共享一个 128 GB/s 的总管道。实际情况是，CPU 和主板芯片组提供一定数量的 PCIe 5.0 通道。

一个高端 CPU 可能提供 24 条 PCIe 5.0 通道。主板制造商会根据这些通道来配置不同的 PCIe 插槽。如果主板有一个 PCIe 5.0 x16 插槽(显卡插槽)，并且 CPU/芯片组为它分配了完整的 16 条 PCIe 5.0 通道，那么这个插槽就可以独立提供高达 128 GB/s 的双向带宽。主板上还可能有 PCIe 5.0 x4 或 x1 插槽，它们分别只占用 4 条或 1 条 PCIe 5.0 通道，带宽相应更低。 PCIe 的带宽是按通道累加的。128 GB/s 是 16 条 PCIe 5.0 通道的总双向带宽。主板上有多个 PCIe 5.0 插槽时，每个插槽能获得的带宽取决于分配给它的通道数量，而通道的总数受到 CPU 和芯片组的限制。所有同时使用的 PCIe 插槽的总带宽不能超过 CPU/芯片组提供的总通道带宽。

个人 PC 主板上的 PCIe 通道通常插什么设备？

在个人电脑主板上，PCIe 插槽是最主要的扩展接口，用于连接各种需要高速与 CPU 直接通信的设备：

  1. 显卡 ： 这是最常见也是最占用带宽的设备，通常插在主板上最主要、速度最快（通道数量最多，通常是 x16）的 PCIe 插槽里。
  2. 固态硬盘 (SSD)： 特别是 NVMe 协议的 SSD，它们通过 PCIe 通道与 CPU 直接通信，提供远超 SATA SSD 的读写速度。虽然很多 NVMe SSD 直接插在主板的 M.2 插槽（M.2 接口通常走 PCIe x4 通道），但也有一些高性能或大容量的 NVMe SSD 以 PCIe 扩展卡的形式出现，插在 PCIe x4 或 x8 插槽上。
  3. 网卡 ： 用于提供更高速的网络连接，例如 10 千兆以太网 (10 GbE)、25 千兆以太网等。这些网卡通常插在 PCIe x4 或 x8 插槽上。普通的千兆网卡现在多集成在主板上，很少作为独立的 PCIe 卡。
  4. 声卡： 虽然主板集成声卡已经很普遍，但追求更高音质或特定音频处理功能的用户会购买独立的 PCIe 声卡，它们通常插在 PCIe x1 或 x4 插槽上。
  5. 其他扩展卡： 包括 USB 扩展卡（提供更多或更高速率的 USB 接口）、雷电 (Thunderbolt) 扩展卡、视频采集卡、RAID 控制卡、无线网卡（有时也做成 PCIe 接口）等等。这些卡根据所需的带宽会使用不同通道数量的 PCIe 插槽（x1, x4, x8）。

应用场景

人工智能 (AI) 和深度学习训练：

  • 训练大型深度学习模型（比如大型语言模型）需要处理海量的训练数据和模型参数。
  • 这些模型通常非常庞大，需要分布在多个高性能 GPU 上进行并行计算。
  • 在训练过程中，GPU 之间需要频繁地交换模型参数、梯度信息和中间计算结果。
  • 如果 GPU 之间的通信速度不够快，它们就会花费大量时间等待数据传输，而不是进行有效的计算，导致训练过程变得非常缓慢。
  • NVLink 提供了 GPU 之间超高速的数据传输能力，使得多个 GPU 能够更紧密地协作，像一个超级大的 GPU 一样工作，显著缩短训练时间，甚至 enable (实现) 训练以前无法处理的超大规模模型。

高性能计算 (HPC)：

  • 科学研究中的许多模拟和计算任务需要巨大的计算能力，例如气候模拟、分子动力学模拟、物理学计算等。
  • 这些任务往往需要将计算分布到大量的计算节点和 GPU 上。
  • 计算节点之间以及节点内部的 GPU 之间需要高速地同步和交换数据，以保证模拟的准确性和效率。
  • NVLink 在这些大规模并行计算任务中提供了关键的高速互连能力，使得科学家能够更快地获得模拟结果，推动科学发现。

大型数据分析和处理：

人工智能 (AI) 和深度学习训练：

  • 训练大型深度学习模型（比如大型语言模型）需要处理海量的训练数据和模型参数。
  • 这些模型通常非常庞大，需要分布在多个高性能 GPU 上进行并行计算。
  • 在训练过程中，GPU 之间需要频繁地交换模型参数、梯度信息和中间计算结果。
  • 如果 GPU 之间的通信速度不够快，它们就会花费大量时间等待数据传输，而不是进行有效的计算，导致训练过程变得非常缓慢。
  • NVLink 提供了 GPU 之间超高速的数据传输能力，使得多个 GPU 能够更紧密地协作，像一个超级大的 GPU 一样工作，显著缩短训练时间，甚至 enable (实现) 训练以前无法处理的超大规模模型。

高性能计算 (HPC)：

  • 科学研究中的许多模拟和计算任务需要巨大的计算能力，例如气候模拟、分子动力学模拟、物理学计算等。
  • 这些任务往往需要将计算分布到大量的计算节点和 GPU 上。
  • 计算节点之间以及节点内部的 GPU 之间需要高速地同步和交换数据，以保证模拟的准确性和效率。
  • NVLink 在这些大规模并行计算任务中提供了关键的高速互连能力，使得科学家能够更快地获得模拟结果，推动科学发现。

大型数据分析和处理：

  • 处理极大规模的数据集（如基因组数据、金融交易数据、宇宙学数据等）需要强大的计算和数据吞吐能力。
  • 将数据加载到 GPU 显存、在不同 GPU 之间分配和处理数据都需要高速的带宽。
  • NVLink 加速了这些数据密集型任务的处理速度。

连接方式

显卡之间的连接： NVLink 接口（如果显卡具备的话）是用来连接两块或多块支持 NVLink 的显卡之间的，目的是实现它们之间的高速数据交换，比如共享显存或加速并行计算。它是在 PCIe 连接之外的额外连接。

高端显卡通常有两种类型的连接能力，但不是两种接口都插到主板上，而是通过 PCIe 插到主板上，如果需要，再通过 NVLink 接口（使用桥接器）连接到另一块显卡。

多 GPU 推理需要大量通信

多 GPU 推理的工作原理是将每个模型层的计算分散到服务器中的两个、四个甚至八个 GPU 上。理论上，两个 GPU 可以使模型运行速度提高 2 倍，四个 GPU 可以使模型运行速度提高 4 倍，八个 GPU 可以使模型运行速度提高 8 倍。

然而，每个 GPU 无法独立完成工作。每个 GPU 完成其模型层部分的执行后，必须将计算结果发送给其他所有 GPU，进行“全对全”的归约。只有这样，推理执行才能进入下一个模型层。

最大限度地减少 GPU 之间传递结果所花费的时间至关重要，因为在此通信期间，Tensor Core 通常保持空闲状态，等待数据继续处理。

在此通信步骤中，必须传输大量数据。对 Llama 3.1 70B（8K 输入令牌和 256 个输出令牌）的单个查询需要从每个 GPU 传输高达 20 GB 的 TP 同步数据。由于多个查询通过批处理并行处理以提高推理吞吐量，因此传输的数据量会成倍增加。

这就是为什么高带宽 GPU 到 GPU 互连对于多 GPU 推理至关重要。

参考文章：NVIDIA NVLink and NVIDIA NVSwitch Supercharge Large Language Model Inference

NV-SWITCH对比

对比结果

应用场景： 一台服务器，1个 CPU，4个或8个高性能 GPU。执行任务是运行一个参数巨大、需要分布在多个 GPU 上的大模型进行推理。

1. 只使用传统 PCIe 通道连接各显卡 (GPU) 的情况：

在这种情况下，每个 GPU都通过 PCIe (主干道) 连接到 CPU (总调度员)。GPU 之间的任何数据交换，都需要通过这条主干道，并且通常要经过 CPU/系统内存 (中央仓库) 中转。

数据流大致是这样的：

  • GPU1 需要给 GPU2 发送数据。
  • 同时，GPU2 需要给 GPU4 发送数据。

  • 同时，GPU3 需要从 GPU1 获取数据。

  • 同时，GPU4 需要从 GPU2 获取数据。

所有这些独立的 GPU 间数据传输，都必须挤在 PCIe 这条共享的主干道上，并且都要经过 CPU/系统内存这个中央仓库。

问题：

  • 带宽限制： PCIe 总线是有带宽限制的，并且这个带宽是 CPU 与所有 GPU 以及其他 PCIe 设备共享的。当多个 GPU 需要频繁地、大量地相互交换数据时，有限的 PCIe 带宽会成为瓶颈，数据传输速度不够快。
  • 延迟增加： 数据需要经过从一个 GPU 到 CPU/内存，再到另一个 GPU 的路径，这个中转过程会引入额外的延迟，使得 GPU 之间的通信不够迅速。
  • CPU 负担（相对）： 虽然 CPU 不会直接处理推理计算，但它需要管理和调度这些通过 PCIe 进行的 GPU 间数据传输，增加 CPU 的负担。

随着 GPU 数量增加到 4 个（甚至 8 个），GPU 之间的通信需求呈指数级增长（任何一个 GPU 可能都需要和另外 3 个或 7 个 GPU 通信）。如果所有这些通信都要挤在有限带宽的 PCIe 主干道上，并且经过中央仓库中转，那么主干道会变得极其拥堵，中央仓库也会成为巨大的瓶颈。GPU 会花费大量时间等待数据传输，计算资源被闲置，整体推理速度会非常慢。

想象一下，4 条生产线都想同时通过有限的几条通道进出中央仓库交换物料，而仓库本身处理能力也有限，整个物流系统就会瘫痪。

2. 使用 NVLink 技术连接各显卡 (GPU) 的情况：

在支持 NVLink 的系统中，高性能 GPU 之间通过专门的 NVLink 接口直接相连（可能是点对点连接，或通过 NVSwitch 构成网络）。除了通过 PCIe 连接到 CPU 外，这 4 个 GPU 还通过 NVLink 相互连接。通常，在 4 个 GPU 的情况下，这些 NVLink 连接会组成一个更高效的拓扑，例如一个环形或者使用一个小型 NVSwitch (专属的内部交通枢纽)，使得 GPU 之间可以更直接地通信。

数据流大致是这样的：

  • GPU1 可以通过 NVLink 直接给 GPU2 发送数据。

  • 同时，GPU2 可以通过 NVLink 直接给 GPU4 发送数据。

  • 同时，GPU3 可以通过 NVLink 直接从 GPU1 获取数据。

  • 同时，GPU4 可以通过 NVLink 直接从 GPU2 获取数据。

NVSwitch (内部交通枢纽) 设计用来同时处理多条这样的 NVLink 通信请求。

区别和优势在多 GPU 场景下更明显：

  • 强大的内部物流网络： NVLink 配合 NVSwitch 构建了一个 GPU 之间独立于 PCIe 的高速内部物流网络。GPU 间的物料（数据）交换在这个网络中进行，速度快，延迟低。
  • 并行通信能力： 多个 GPU 可以同时通过 NVLink 与其他 GPU 进行通信，相互之间影响很小。这不像 PCIe 那样所有通信都挤在一条共享的总线上。
  • 消除 PCIe 瓶颈： GPU 之间大量的、频繁的数据交换不再占用 PCIe 带宽，PCIe 主要用于 CPU 与 GPU 之间相对较少的初始数据加载和最终结果回传。
  • 高效的大模型并行推理： 当大模型分布在 4 个 GPU 上时，每个 GPU 负责模型的一部分或处理一部分数据。它们之间需要频繁地交换计算结果和参数。NVLink 提供的高速并行通信能力确保了这些 GPU 之间的协作是高效流畅的，不会因为等待数据而浪费计算能力，从而才能真正实现 4 个 GPU 并行带来的性能提升。

NVLink + NVSwitch 就像在 4 条生产线之间修建了一个专属的、多端口的、超高速内部传送带系统。任何两条生产线之间都可以高速直接交换物料，多个交换可以同时进行，极大地提高了整个工厂（多 GPU 系统）的生产效率。

想象一下，这就像在工厂的两条生产线之间修建了一条专属的、超高速的直通传送带。物料可以直接从一条生产线传送到另一条，无需经过中央仓库，速度快、效率高，而且不会占用主干道的资源。

总结：

  • 传统 PCIe 方式： 多 GPU 之间通信需通过 PCIe 经 CPU/内存中转，带宽受限，延迟较高，在处理超大模型时容易成为瓶颈。
  • NVLink 方式： 在 PCIe 连接到系统（CPU）的基础上，提供了 GPU 之间的直接、高速、低延迟连接。这使得 GPU 之间能够更高效地协同工作，对于需要分布在多 GPU 上的超大模型推理任务而言，可以显著提升性能和效率，甚至 enabling (实现) 在 PCIe 模式下因通信瓶颈而无法高效完成的任务。

在 多个 GPU 的高端服务器上，NVLink 的价值在于它为 GPU 之间提供了一个独立于传统 PCIe 的、高性能的互连网络，这对于需要紧密协作进行并行计算（如超大模型推理）的任务至关重要，能有效避免 PCIe 成为性能瓶颈。

大模型工具与框架

vLLM

  • 是什么： 一个高性能的大型语言模型推理加速库（Python 库）。
  • 有什么用/干嘛的： vLLM 是一个专门为加速 LLM 推理而生的开源库。通过其创新的 PagedAttention 显存管理和高效的 Continuous Batching 等技术，它能够极大地提高服务器在多用户并发访问时的模型推理速度和吞吐量，尤其适合在拥有强大 GPU 组的服务器上部署大型量化模型，是构建高性能 AI 推理服务的理想选择。它的主要目的是让你在硬件上（尤其是 GPU）更快、更高效地运行（推理）大模型。当你需要让模型生成文本、回答问题时，vLLM 能显著提高模型的响应速度，并且能在同一时间处理更多的请求（高吞吐量）。

当您需要让大模型接收用户的输入（Prompt），然后快速生成回复时，这个过程就是推理。尤其是在服务器环境中，可能会有非常多的用户同时向模型发送请求。传统的模型加载和运行方法在这种高并发场景下效率不高，会导致模型响应慢，服务器资源（特别是 GPU 显存）利用不充分。vLLM 的主要目的就是解决这些问题，能够在有限的硬件资源下，以高吞吐量（单位时间内处理更多请求）和低延迟（每个请求的响应速度快）的方式稳定地对外提供大模型服务。

  • 解决什么问题： 解决直接使用传统方法运行大模型时速度慢、效率低、难以充分利用硬件性能的问题。它采用了先进的算法（如 PagedAttention）来优化显存使用和计算效率。
  • 谁会用： 主要由开发者、公司或机构使用，用于将大模型部署到服务器上，为用户提供服务。
  • 比喻： 如果大模型是汽车，那么 vLLM 就是一个经过专业调校的高性能引擎，让汽车跑得更快、更稳，而且能同时载更多乘客。

Ollama

  • 是什么： 一个用于在本地轻松运行和管理大模型的工具。
  • 有什么用/干嘛的： 它极大地简化了在你的个人电脑（Windows, macOS, Linux）上下载、安装和运行各种开源大模型的过程。你只需要安装 Ollama，然后通过简单的命令就可以下载和运行 Llama 2, Mistral, Gemma 等模型，并通过命令行或简单的 API 与它们交互。
  • 解决什么问题： 降低了普通用户和开发者在本地尝试和实验大模型的门槛，无需复杂的环境配置，也无需强大的云服务器。
  • 谁会用： 希望在自己电脑上体验和使用大模型的普通用户、开发者、研究人员。
  • 比喻： 如果大模型是各种型号的汽车，那么 Ollama 就是一个集成的车库和启动器，你可以在这里轻松下载不同型号的汽车，然后一键启动它们，直接就能开了。

Open-WebUI

  • 是什么： 一个用户友好的网页界面。
  • 有什么用/干嘛的： 它提供了一个类似 ChatGPT 的聊天界面，但它可以连接到你正在运行的各种大模型后端（比如通过 Ollama 运行的模型，或者其他兼容的 API）。你可以通过这个美观的界面与你的本地或自托管大模型进行对话，管理聊天记录，甚至上传文档进行问答（如果后端模型支持）。
  • 解决什么问题： 提供一个比命令行更直观、更易用的方式来与大模型交互，方便进行日常使用和模型测试。
  • 谁会用： 使用本地或自托管大模型的最终用户、测试模型的开发者。
  • 比喻： 如果大模型是引擎，Ollama 是启动器，那么 Open-WebUI 就是汽车的驾驶舱仪表盘和控制台，提供一个舒适、直观的环境让你来“驾驶”和控制大模型。

FastGPT

  • 是什么： 一个基于大模型的问答系统构建平台。
  • 有什么用/干嘛的： 它的核心功能是帮助你将大模型与你自己的私有知识库（文档、网页、数据库等）连接起来，快速构建一个能够回答关于这些特定内容的问答机器人。它通常使用 RAG (Retrieval Augmented Generation - 检索增强生成) 技术。你可以在它的可视化界面中导入数据，然后配置模型的回答方式。
  • 解决什么问题： 解决大模型缺乏实时或特定领域知识的问题。让大模型能够“学习”并基于你的私有数据进行准确回答，而无需重新训练模型。
  • 谁会用： 希望为企业、团队或个人构建定制化智能客服、知识问答系统等的开发者和非技术用户。
  • 比喻： 如果大模型是博学的老师，但只懂公开知识。FastGPT 就是为老师提供一个图书馆管理员和查找工具，让你把自己的藏书（私有知识）交给它管理，老师就可以根据你的书库来回答问题了。

Dify

  • 是什么： 一个一站式的大模型应用开发平台。
  • 有什么用/干嘛的： 它的功能比 FastGPT 更全面，不仅仅是连接知识库（RAG），还提供了工作流编排、Agent（智能体）能力、数据集管理、模型管理、以及一个简单的 Web 界面部署等功能。你可以用它来连接不同的模型，设计复杂的 AI 应用流程（比如先搜索信息，再总结，再调用其他工具），并轻松发布成一个可用的应用。
  • 解决什么问题： 简化了从构建、调试到部署和管理基于大模型的应用的整个流程，提供丰富的工具和模块来构建更复杂的 AI 应用。
  • 谁会用： 希望快速开发、部署和管理各种类型大模型应用的开发者和团队。
  • 比喻： 如果大模型是能力各异的专家，Dify 就是一个项目管理和协调平台。你可以在上面召集不同的专家（模型），给他们分配任务，设计他们之间的协作流程，并最终将这个专家团队的能力打包成一个可以直接使用的服务。
  • vLLM 是底层技术，让大模型跑得快。
  • Ollama 是让你把大模型在本地跑起来变得简单。
  • Open-WebUI 是一个漂亮的界面，让你能方便地对话运行起来的大模型。
  • FastGPT 和 Dify 是应用开发平台，帮你用大模型构建具体的功能（如知识问答、自动化流程），特别是将大模型与你的数据或外部工具连接起来。Dify 的功能通常比 FastGPT 更全面。

实际场景

vLLM 充当后端推理服务。它负责加载模型到 GPU，接收来自 Open-WebUI 的用户 Prompt 请求，进行高效的推理计算，并将生成的回复通过 API 返回给 Open-WebUI。

Open-WebUI 充当前端用户界面**。它提供用户友好的网页聊天框，接收用户的输入，将输入发送给 vLLM 的 API，然后将从 vLLM 接收到的回复展示给用户。

如何部署大模型到服务器上并实现web交互？

流程图

将 DeepSeek 671B (INT4) 模型部署到一台现有强大服务器上，并搭建供公司内部使用的 Open-WebUI Web 交互平台的核心步骤概览：

  1. 服务器基础环境配置：
    • 在这台服务器上安装 Linux 操作系统。
    • 安装匹配的 NVIDIA 显卡驱动、CUDA Toolkit 和 cuDNN。
    • 安装 Docker 和 Docker Compose。
    • 安装 Python 3.8+ 并创建虚拟环境。
  2. 获取模型文件：
    • 从 Hugging Face 或其他来源下载 DeepSeek 671B 的 INT4 量化版本模型文件到服务器的指定目录。
  3. 安装和配置后端推理服务 (vLLM)：
    • 在 Python 虚拟环境中安装 vLLM 库。
    • 编写并运行命令，使用 vLLM 启动 API 服务。
    • 命令中需要指定模型路径、监听的本地 IP 和端口（例如 0.0.0.0:8000）、使用全部 **8 张 GPU (tensor-parallel-size=8)**、以及模型是 INT4 量化的。
    • 确保将此服务设置为后台运行。
  4. 部署前端界面 (Open-WebUI) (使用 Docker)：
    • 创建 Docker Compose 文件，配置 Open-WebUI 容器。
    • 在配置中，将 Open-WebUI 的端口（默认 8080）映射到服务器的端口。
    • 关键： 配置 Open-WebUI 连接到第3步启动的 vLLM API 服务地址（通常是 http://<服务器内网IP>:8000 或 http://host.docker.internal:8000）。
    • 运行 Docker Compose 启动 Open-WebUI 容器。
  5. 配置网络访问：
    • 在服务器的防火墙中，仅允许公司内网的 IP 地址范围访问 Open-WebUI 监听的端口（例如 8080）。
    • 切勿将 Open-WebUI 或 vLLM 的端口直接暴露到互联网上。
  6. 提供用户访问：
    • 将服务器在公司内网中的 IP 地址（或对应的内网主机名）和 Open-WebUI 的端口号（例如 8080）告知公司内部人员。
    • 用户通过浏览器访问 http://<服务器内网IP>:8080 即可使用。
    • 推荐： 在 Open-WebUI 中启用用户认证功能，确保只有授权人员能访问。

什么是智能体？

在当前围绕大型语言模型（LLM）发展的 AI 应用浪潮中，“智能体”通常特指一种以大语言模型为核心，能够调用外部工具或 API，从而执行更复杂任务的 AI 系统。

一个基于 LLM 的智能体不仅仅是接收一段文字然后生成另一段文字，它还具备了以下能力：

  1. 感知/观察 (Perception / Observation): 它能够获取当前任务的相关信息。这可能来自用户的指令、读取文档内容、获取网页信息、查看某个工具的执行结果等等。

  2. 思考/规划 (Thinking / Reasoning - LLM 的核心作用): 大语言模型在这里充当了“大脑”。它接收感知到的信息，理解用户的目标，然后运用其推理能力来决定下一步应该做什么。它可能会进行任务分解、规划执行步骤、判断需要使用什么工具、甚至反思之前的行动是否有效。

  3. 行动 (Action): 智能体最关键的能力是能够执行外部操作。它不再仅仅局限于生成文本，而是能够通过调用特定的功能来影响外部环境或获取更多信息。

  4. 工具 (Tools):

    这是智能体能够采取行动的“手”和“脚”。工具是智能体可以调用的外部函数、API 或程序。常见的工具包括：

    • 搜索引擎工具： 让智能体能够联网搜索信息。
    • 计算器工具： 让智能体能够进行数学计算。
    • 代码解释器工具： 让智能体能够运行代码（如 Python）来处理数据、执行复杂逻辑。
    • 数据库查询工具： 让智能体能够查询或修改数据库。
    • 日历/邮件工具： 让智能体能够安排日程、发送邮件。
    • 文件读写工具： 让智能体能够读取或保存文件。

智能体为什么重要？有什么用？

  • 突破纯文本限制： 让大模型不再是一个只能“说”的系统，而是能够“做”的系统。
  • 解决更复杂的问题： 它们可以将一个宏大的目标分解成多个可执行的步骤，并利用合适的工具逐一完成。
  • 自动化工作流： 能够根据用户的指令，自主地调用一系列工具，完成一个端到端的工作流程。
  • 利用实时/外部信息： 通过搜索、读取文件等工具，智能体可以获取大模型训练数据中没有的实时或私有信息来辅助决策和生成。

举例来说，一个“差旅预订智能体”可能的工作流程是：

  1. 感知： 用户输入“我想预订下周去上海的往返机票和酒店”。
  2. 思考 (LLM)： 理解用户的目标是预订机票和酒店。判断需要调用机票查询工具和酒店查询工具。
  3. 行动 (调用工具)： 调用机票查询工具，输入目的地（上海）、日期（下周）、类型（往返）。
  4. 感知： 接收到机票查询工具返回的航班列表和价格信息。
  5. 思考 (LLM)： 分析航班信息，判断需要用户进一步选择或推荐几个选项。
  6. 行动 (生成文本)： 向用户展示几个推荐的航班选项，并询问用户的偏好。
  7. 思考 (LLM)： 理解用户选择了某个航班后，判断需要调用酒店查询工具。
  8. 行动 (调用工具)： 调用酒店查询工具，输入目的地、日期等。
  9. … 循环往复，直到完成预订或告知用户需要进一步信息。

之前提到的 FastGPT 和 Dify，它们就是帮助开发者构建和管理这种智能体应用的平台。它们提供了连接各种工具的能力、设计智能体工作流程的可视化界面、以及管理知识库（用于 RAG，可以看作是给智能体一个“记忆”或“参考手册”）等功能。“智能体”是当前 AI 应用发展的一个重要方向，它赋予了大模型通过与外部世界交互来解决实际问题的能力。