【AI大模型】大模型是怎么运作的？一文拆解底层原理、架构设计与系统关键路径

观熵

于 2025-04-18 11:54:28 发布

阅读量1.6k

点赞数 30

分类专栏： AI前沿探索文章标签：深度学习人工智能大模型语言模型

本文链接：https://blog.csdn.net/sinat_28461591/article/details/147316179

版权

AI前沿探索专栏收录该内容

39 篇文章

订阅专栏

个人简介

作者简介：全栈研发，具备端到端系统落地能力，专注大模型的压缩部署、多模态理解与 Agent 架构设计。热爱“结构”与“秩序”，相信复杂系统背后总有简洁可控的可能。
我叫观熵。不是在控熵，就是在观测熵的流动
个人主页：观熵
个人邮箱：privatexxxx@163.com
座右铭：愿科技之光，不止照亮智能，也照亮人心！

专栏导航

观熵系列专栏导航：
AI前沿探索：从大模型进化、多模态交互、AIGC内容生成，到AI在行业中的落地应用，我们将深入剖析最前沿的AI技术，分享实用的开发经验，并探讨AI未来的发展趋势
AI开源框架实战：面向 AI 工程师的大模型框架实战指南，覆盖训练、推理、部署与评估的全链路最佳实践
计算机视觉：聚焦计算机视觉前沿技术，涵盖图像识别、目标检测、自动驾驶、医疗影像等领域的最新进展和应用案例
国产大模型部署实战：持续更新的国产开源大模型部署实战教程，覆盖从模型选型 → 环境配置 → 本地推理 → API封装 → 高性能部署 → 多模型管理的完整全流程
TensorFlow 全栈实战：从建模到部署：覆盖模型构建、训练优化、跨平台部署与工程交付，帮助开发者掌握从原型到上线的完整 AI 开发流程
PyTorch 全栈实战专栏： PyTorch 框架的全栈实战应用，涵盖从模型训练、优化、部署到维护的完整流程
深入理解 TensorRT：深入解析 TensorRT 的核心机制与部署实践，助力构建高性能 AI 推理系统
Megatron-LM 实战笔记：聚焦于 Megatron-LM 框架的实战应用，涵盖从预训练、微调到部署的全流程
AI Agent：系统学习并亲手构建一个完整的 AI Agent 系统，从基础理论、算法实战、框架应用，到私有部署、多端集成
DeepSeek 实战与解析：聚焦 DeepSeek 系列模型原理解析与实战应用，涵盖部署、推理、微调与多场景集成，助你高效上手国产大模型
端侧大模型：聚焦大模型在移动设备上的部署与优化，探索端侧智能的实现路径
行业大模型 · 数据全流程指南：大模型预训练数据的设计、采集、清洗与合规治理，聚焦行业场景，从需求定义到数据闭环，帮助您构建专属的智能数据基座
机器人研发全栈进阶指南：从ROS到AI智能控制：机器人系统架构、感知建图、路径规划、控制系统、AI智能决策、系统集成等核心能力模块
人工智能下的网络安全：通过实战案例和系统化方法，帮助开发者和安全工程师识别风险、构建防御机制，确保 AI 系统的稳定与安全
智能 DevOps 工厂：AI 驱动的持续交付实践：构建以 AI 为核心的智能 DevOps 平台，涵盖从 CI/CD 流水线、AIOps、MLOps 到 DevSecOps 的全流程实践。
C++学习笔记？：聚焦于现代 C++ 编程的核心概念与实践，涵盖 STL 源码剖析、内存管理、模板元编程等关键技术
AI × Quant 系统化落地实战：从数据、策略到实盘，打造全栈智能量化交易系统
大模型运营专家的Prompt修炼之路：本专栏聚焦开发 / 测试人员的实际转型路径，基于 OpenAI、DeepSeek、抖音等真实资料，拆解从入门到专业落地的关键主题，涵盖 Prompt 编写范式、结构输出控制、模型行为评估、系统接入与 DevOps 管理。每一篇都不讲概念空话，只做实战经验沉淀，让你一步步成为真正的模型运营专家。

《大模型是怎么运作的？一文拆解底层原理、架构设计与系统关键路径》

摘要

当前大模型从训练、推理到部署正加速走入产业系统，但很多从业者只熟悉调用，不了解背后机制。这篇文章从原理层到系统架构逐层拆解一个大模型是如何“理解、计算、输出”的，解析 Transformer 的内部结构，探讨大模型从参数存储、KV 缓存、序列并行到 Attention 优化等关键机制，最终串联形成一个“端到端”系统认知路径。适合所有希望深入理解大模型底层设计的技术人。

目录结构

一、为什么要理解大模型的“内部结构”？

只是会调用接口，已经不够用了
系统瓶颈常出在“架构不清”
哪些人需要真正读懂它的原理

二、Transformer 模型的底层构成原理

多层堆叠的本质：Residual + LayerNorm + Attention + MLP
Self-Attention 是怎么计算的？Q/K/V、Softmax 与 Mask 的关系
Position Embedding 与 Rotary Position Embedding（RoPE）的核心作用
Decoder-only 架构与 Encoder-Decoder 的差异

三、大模型训练时的“并行结构”拆解

为什么需要模型并行？参数太大怎么办
数据并行 vs 张量并行 vs 管道并行
Megatron-LM 的三大并行路径与通信成本分析
Checkpoint 合并与权重分布策略

四、推理路径上的系统设计细节

推理时为什么“快不起来”？序列依赖与 KV 缓存机制
KV Cache 是怎么实现的？缓存更新机制详解
Prefill vs Decode：两阶段推理流程详解
Logits 输出、Top-K、Top-P 与温度的作用机制

五、Prompt 是怎么影响模型行为的？

Prompt 的位置决定上下文窗口的使用方式
长上下文机制中的 Attention 范围裁剪技巧
ALiBi、FlashAttention、Rope Cache 的优化路径
多轮对话中的 Token 滑窗与历史剪枝策略

六、大模型的参数存储与系统结构图

参数加载的形式：静态图 vs 动态图
ONNX / Safetensors / HuggingFace 权重格式解析
多 GPU/多节点加载模型的具体方法
一个完整的大模型推理系统架构图（图示 + 文字解析）

七、总结：如何构建自己的“模型结构理解体系”？

建议阅读路径：代码、论文、开源项目与系统工程文档
面试、调优、推理优化中该如何应用这些原理
从原理到系统，才能成为真正的大模型工程师

一、为什么要理解大模型的“内部结构”？

过去一年，大模型像瀑布一样砸进了我们的系统开发和业务逻辑中。开发者开始调用模型接口、拼接 Prompt、部署微调后的权重，但随着实际落地项目增多，一个核心问题变得越来越突出：

“我明明换了更大参数的模型、GPU 也够用，为什么推理速度上不去？”

“我用了 LoRA 微调，为什么精度反而下降？”

“我想把多模型合并部署，结果权重爆了内存，该怎么拆？”

这些问题，光靠“会用”是不够的。你需要真正理解“大模型在做什么”。模型调用接口只是冰山一角，背后涉及的是从参数加载到序列计算的完整推理路径，而每一步，都与底层架构紧密相关。

1.1 不是写 Prompt、调接口就叫懂大模型

当前不少初级从业者把大模型当作一个“可以交谈的 API”来看，甚至很多教程都鼓励“零代码也能用大模型”，但当你面对真实业务系统，事情并不那么简单。

比如：

你要优化响应时延，但不知道 KV Cache 的存储位置在哪；
你想融合多个微调模型做 Ensemble，但不了解模型参数结构；
你部署了 INT8 压缩模型，却遇到精度偏移，而查不到是哪一层造成的。

只有深入理解模型内部结构，你才知道：

每一层 Attention 和 MLP 在计算什么；
输入是怎么被切分成 token、嵌入、经过旋转位置编码传入模型；
输出 logits 是怎么生成、怎么采样的。

懂结构，才能调行为；懂路径，才能控系统。

1.2 系统瓶颈，往往就藏在你不了解的那一层

大模型不是“黑盒”也不是“魔法”。它是一个层层堆叠的系统结构，从输入、计算、输出，每一环都可以优化，也都可能成为性能瓶颈。

我们以最典型的推理时延问题为例：

推理环节	可能的瓶颈	需要了解的结构
Token 生成慢	序列依赖，不能并发生成	Decoder-only 架构，Auto-Regressive 机制
KV Cache 爆显存	缓存机制、上下文过长	Attention Cache、RoPE、FlashAttention
多模型切换慢	权重加载 IO 慢	Checkpoint 格式、权重分片结构
上下文不对齐	Prompt 编排错误	输入位置编码、Context Window 管理

你会发现，这些问题的根源，并不是调用方式，而是对模型“是如何构建与运作的”理解不够深入。

1.3 哪些人，真的需要读懂模型的结构？

我们通常认为只有模型算法工程师才需要理解结构，但事实是，以下几类技术人都必须建立结构理解能力：

角色	需要理解的结构内容
平台研发 / 系统架构师	模型加载方式、并行结构、KV Cache 管理、显存占用机制
模型调优工程师	LayerNorm/Attention 行为、微调层选择、精度漂移原因
推理部署工程师	编译图优化、TensorRT 支持结构、Batch 合并策略
Prompt 工程师 / 模型运营专家	Prompt 对行为的影响路径、Token 对应结构变化
AI 产品经理 / 解决方案架构师	模型运行瓶颈识别、不同架构模型适配能力

如果你处于以上任何一个角色，而你还不了解模型是怎么“从一个 Prompt 生成一句话”的，说明你对自己的技术栈还不够掌控。

小结：这是系统级认知，而不是“模型原理课”

理解大模型的架构，不是为了看懂 Transformer 的论文，而是为了解决系统中的真实问题。

这是一种系统性工程能力，它让你能：

精确定位瓶颈点在哪一层；
清楚判断不同结构能不能压缩；
设计出贴合系统的推理路径和部署方案。

接下来，我们将从最核心的模型结构出发，一步步拆解：
Transformer 到底是怎么工作的？它内部每一层在干什么？

准备好了吗？我们从 LayerNorm 开始。

二、Transformer 模型的底层构成原理（通俗 × 工程化解读）

Transformer 是如今几乎所有主流大模型的架构基础，无论是 GPT 系列、LLaMA、ChatGLM，还是国内的 DeepSeek、Yi、百川，内部结构都离不开它。但很多人只知道“它是一堆层叠结构”，却不清楚：

每一层具体在计算什么？
这些结构是怎么协同让模型“理解上下文”的？
哪些地方可以做压缩、提速、优化？

这一节我们就来拆清楚：Transformer 的“内脏”到底长什么样，它是怎么动起来的。

2.1 每一层都干了啥？一图看清 Transformer Block 内部结构

无论是 12 层的小模型，还是 96 层的 GPT-4，它们的基本单元都是这个结构：

输入
  │
  ├── LayerNorm（归一化）
  │      ↓
  │   Multi-head Self-Attention（注意力机制）
  │      ↓
  └── Residual 残差连接（加回输入）

  │
  ├── LayerNorm
  │      ↓
  │     MLP（前馈网络：两层全连接 + 激活）
  │      ↓
  └── Residual 残差连接（再加回输入）

输出

说人话就是：

每一层都是：先归一化 → 注意力看上下文 → 接上原始输入 → 再归一化 → 前馈处理 → 接上结果 → 继续往下走。

这就是所谓的“堆叠结构”，每层都有“看全局 + 做局部处理”的机制，最后形成“深度理解 +生成”的能力。

2.2 Self-Attention 到底在算什么？

这部分是 Transformer 的“灵魂”，也最容易懵。咱们用打电话找人来打个比方：

每个词（Token）就像一个人，要决定当前说这句话的时候该参考谁的信息，于是他打电话给所有人（包括自己），问：“你对我有帮助吗？”

这个打电话的过程，就是 Attention。具体步骤是这样的：

每个词会生成三个向量：Query（我想找谁）、Key（我是谁）、Value（我的信息）
然后所有人拿着 Query 和别人 Key 比对，“你是不是我要找的”
对比完得出一个打分表（谁更重要），用来加权每个人的 Value 信息
汇总之后，得出最终理解结果

用公式表达就是：

Attention(Q, K, V) = Softmax(Q × Kᵀ / √d_k) × V

其中：

Q 是 Query，K 是 Key，V 是 Value
Softmax 让得分变成概率
√d_k 是缩放系数，防止分数过大

再补充一个实际点：

在推理时，为了避免看到“未来的信息”，还会加个 Mask（遮住后面没说的话）
所以是 Decoder-only 架构中核心的“自回归”机制

2.3 RoPE：让模型知道“谁在前谁在后”

Transformer 不像 RNN，有天然的顺序感，所以要“加点位置信息”。以前 GPT-2 用的是绝对位置编码（固定第 1 个词是啥），但现在主流都用 RoPE（旋转位置编码）。

它的本质是：

让每个位置的向量像钟表上的指针一样，旋转一定角度，不同位置的词就带上了“节奏感”。

RoPE 的好处：

支持长文本，适合 KV 缓存；
可与 Attention 融合得更好，支持更多层次的上下文建模；
在 LLaMA、DeepSeek、Baichuan 等主流模型中是标配。

2.4 Decoder-only 是怎么让模型一句一句说话的？

目前大多数大语言模型（LLM）都用的是 Decoder-only 架构，它的核心逻辑是：

每次只生成一个词，不能偷看未来，只能用历史信息一个字一个字往下推。

结构对比：

架构	应用场景	特点
Decoder-only（GPT）	文本生成、对话系统	自回归，单向，支持 KV 缓存
Encoder-only（BERT）	分类、匹配、提取	双向建模，非生成
Encoder-Decoder（T5, UL2）	翻译、摘要	编码理解上下文，解码输出结果

为什么大家用 Decoder-only？

更容易缓存中间结果（即 KV Cache）；
推理可以更高效；
架构简单，工程好实现。

🔧 工程小结：理解结构就是在学“优化手册”

大模型的结构并不是“造神”，而是经过层层打磨后的工程系统，理解每一部分能带来很多实际收益：

模块	理解后可以做什么
Attention	找出序列瓶颈，能不能用 FlashAttention 优化
RoPE	判断模型上下文能不能扩，是否支持 RoPE 插值
MLP + Residual	是否能剪枝 / 蒸馏，能否插入 LoRA 结构
Decoder-only	适不适合你要做的任务（生成 vs 检索）
KV Cache	能否加速推理，节省内存 / IO 读写

你掌握得越深，就能调得越细，踩坑越少，性能越高。

三、大模型训练时的“并行结构”拆解

一个 70 亿参数的模型可能还可以单卡训练，但一个 130B 参数的模型，单张 GPU 根本装不下。这时候怎么办？并行训练就成了救命稻草。

这节我们来讲：

为什么要并行？
分别有哪些并行策略？
每种策略到底在“并”什么？
它们如何影响训练代码和系统部署？

3.1 为什么需要并行？一个卡放不下，怎么办？

简单举个例子：

一个 1300 亿参数的大模型，按 FP16 存储，每个参数 2 字节，总共是：

130B × 2 = 260 GB 显存

而你一张 A100 只有 80GB，连参数都装不下，更别说中间缓存（激活值）、优化器状态、梯度等等。

所以我们必须 “把模型拆开，分给多个 GPU 一起算”，而这就催生了下面三种经典并行策略。

3.2 数据并行（Data Parallel）：一人一本，大家同步梯度

这是最简单也最容易实现的方式。做法是：

把一批数据平均分给多个 GPU，每个 GPU 拿着一样的模型参数各自训练，最后再把梯度平均一下同步回来。

关键点：

模型结构每个 GPU 都一样；
梯度通过 AllReduce 同步；
容易实现（PyTorch 的 DDP 就是这个）

适合中小模型，大模型容易“爆显存”，因为参数每卡都要放一份。

3.3 模型并行（Model Parallel）：模型太大，拆成几段放

顾名思义，把模型拆开：

第一层在 GPU1，第二层在 GPU2，前向传播时层层传下去，反向传播时层层传回来。

举个例子，LLaMA 的 Layer1~24 在卡1，Layer25~48 在卡2…

但有两个问题：

前向和反向必须串行走，不易并发，吞吐低；
通信开销大（显存省了，速度慢了）

所以它常与管道并行一起使用，称为 Pipeline Parallel。

3.4 张量并行（Tensor Parallel）：参数拆成几份，大家各算一部分

这个是 Megatron-LM 最核心的策略。

把每一层的参数按维度“劈开”，每个 GPU 负责计算一小段，最后合起来。

比如一个 Linear 层的矩阵乘法：

[batch, hidden] × [hidden, 4*hidden] → [batch, 4*hidden]

我们把后面那一坨切成 4 份，每个 GPU 只负责算 1/4，再把结果拼起来。

优点：

显存分摊到每个 GPU；
吞吐高，支持大模型；
能配合 Activation Checkpointing 节省更多显存。

但对代码要求高，必须使用支持张量并行的框架（如 Megatron-LM、DeepSpeed、Colossal-AI）

3.5 管道并行（Pipeline Parallel）：每张卡负责一段，流水线推进

管道并行跟模型并行有点像，但加了**“流水线”机制**来提升并发性。

流程是这样：

把模型分段，每段丢到一张卡；
Batch 数据切成多个 micro-batch；
前一个 micro-batch 在第一张卡计算时，下一张卡已经在计算另一个 micro-batch；
整个过程像工业流水线一样并发推进。

它解决了模型并行“串行慢”的问题，但：

延迟依然高（因为有 bubble）；
调度难度更高（需设置 pipeline stage）。

3.6 混合并行：TP + PP + DP = 训练高效组合拳

现实中一个模型训练常常是 三种策略混合使用：

并行方式	拆什么	干什么	优点	典型框架
数据并行	拆数据	批量训练	简单易用	PyTorch DDP
张量并行	拆权重	多卡协同算一层	精度好，显存省	Megatron-LM
管道并行	拆层数	多卡分层	并发计算，加速	DeepSpeed, Colossal

比如 LLaMA 的训练就用了：

每层权重拆成多个张量 → TP
每 12 层分配给不同卡 → PP
多机节点同步梯度 → DP

所以你才会看到训练代码里有一堆：

--tensor-model-parallel-size 2 \
--pipeline-model-parallel-size 4 \
--distributed-world-size 32 \

别慌，这其实是你未来必须掌握的“大模型基本功”。

小结：大模型训练不是“一行代码”，而是多层并行策略协同

想真正搞清楚大模型训练：

不是开个 DDP 就行，而是TP + PP + DP 的组合拳
每一种策略都牵涉显存、通信、调度和稳定性
真正的工程价值，在于：如何高效利用硬件资源把一个超大模型训出来

四、推理路径上的系统设计细节

当你部署一个大语言模型后，常常会遇到这样的场景：

一句话生成 20 个词，模型跑了 3 秒；
上下文一长就 OOM，显存直接爆；
Token 一多就开始延迟严重、吞吐掉线。

这些问题背后的核心，其实就是：你不了解模型推理时真正的计算路径。这一节我们就来拆清楚——从 Token 输入到文本输出，大模型推理路径中到底发生了什么？系统瓶颈在哪里？工程如何优化？

4.1 推理为什么“快不起来”？你得理解推理阶段的两种模式

大模型推理其实是两个阶段组成的，它们的特征完全不同：

✅ 第一阶段：Prefill 阶段（也叫 Context Stage）

输入：用户的一段 Prompt，例如 500 个 token
模型：一次性处理整个输入序列
Attention：对每个 Token 都重新算一次 Attention（计算量大，不能缓存）

✅ 第二阶段：Decode 阶段（也叫生成阶段）

输入：每次只输入一个新 Token
模型：依赖前面的 KV 缓存，仅计算当前位置的输出
Attention：Query 是新的，Key/Value 来自缓存（计算量大大减少）

所以你会发现：

模型越长越慢，其实慢在“Prefill”；而如果你在对话中只生成几个词，那 Decode 就会很快。

4.2 KV Cache 是怎么实现的？一次缓存，重复使用

KV 是什么？

在 Self-Attention 中，模型会对输入生成三个向量：

Q：当前这个 Token 想关注谁  
K：每个 Token 的身份标签  
V：每个 Token 的内容向量

在生成过程中：

Query 每次都要重算（因为是新 Token）
但前面的 Key 和 Value 是历史的，不需要变

所以我们就把历史的 K/V 缓存起来，称为 KV Cache。

举个例子：

第 1 次输入：我 喜 欢 吃 🍕
→ 生成了 Q1~Q5，K1~K5，V1~V5（存入缓存）

第 2 次：生成下一个 Token
→ 用 Q6，直接去对 K1~K5、V1~V5 做 Attention

这样我们就避免了重复计算历史序列的开销，尤其在多轮生成中，KV Cache 是提升推理速度的关键。

4.3 FlashAttention 到底“快”在哪？看两个核心点

普通 Attention 的计算复杂度是 (O(N^2))，当 Token 数上千时，这一步会非常慢，还占显存。

FlashAttention 是一种稀疏优化 + CUDA 调度重构的 Attention 实现，核心加速点有：

加速点	描述
✅ 低显存	不再保存中间大矩阵，全程使用 chunk 机制
✅ 更高带宽	利用 GPU 内存访问模式优化加载效率
✅ 支持 RoPE / Mask / 长上下文	可直接在 LLaMA、ChatGLM、Baichuan 中替代原 Attention

工程上表现为：

内存下降 50%+
推理速度提升 1.5~3 倍

想判断你的模型有没有启用 FlashAttention？看它是不是用了 xformers、flash_attn 或者 Triton 优化算子。

4.4 Logits、采样策略与生成质量的关系

生成文本最后一步，是从模型输出的 logits 向量中选出一个词作为下一个输出。

什么是 logits？

它是一个长度为词表大小的向量，每个值表示该词的“置信度”。

例如：

[苹果: 0.6, 香蕉: 0.3, 火龙果: 0.1]
→ 选“苹果”作为输出

但我们不能总是选最大，否则就变得很机械，所以需要加上一些 采样策略：

策略	作用	说明
Temperature	控制“随机程度”	越低越保守，越高越发散
Top-K	保留前 K 个概率最高的词	防止尾部词被选中
Top-P（Nucleus）	保留前 P% 累计概率的词	动态截断，适合生成
Repetition Penalty	避免重复生成	对重复词打压得分

想生成“更有创意”的内容，可以提高 Temperature 和 Top-P；想控制在业务词域中，降低它们 + 加强限制词表。

小结：推理慢，不是模型太笨，是你没用对路径

这一节你应该记住这些知识点：

推理 = Prefill + Decode，KV Cache 只对 Decode 有用；
KV Cache 是加速的关键，没用上就是纯 CPU 算；
FlashAttention 是工程上的爆点，能把推理提速到极致；
生成逻辑（Logits + Sampling） 是输出质量的调节阀，别忽视这一环！

五、Prompt 是怎么影响模型行为的？

很多人觉得 Prompt 就是“提示词”——写句人话，让模型听懂。但其实，当你的系统一旦进入工业级落地，Prompt 就不再只是语言，而是一个输入指令链条，模型行为的触发机制。

本节我们从模型结构的角度，来重新审视 Prompt 的影响路径：它不只影响输出内容，更影响模型执行时的计算方式、上下文窗口、注意力策略和缓存结构。

5.1 Prompt 的位置，决定了模型感知的“重点区域”

大语言模型是基于 Attention 机制工作的，它会对每一个 Token 计算“注意力权重”，即当前要“关注”前面哪个词。

而 Prompt 放在输入的什么位置，会直接影响 Attention 的计算方向。

举例：

用户 Prompt：
你是一个专业的法律顾问。请根据以下案情提供法律建议：……

系统拼接输入：
[System Prompt] + [用户输入] + [案情描述] → 输入序列

如果 Prompt 放在输入序列的开头，那么模型在生成答案时，需要：

每一个词都回头看前面所有 Prompt 里的内容；
形成“行为约束 + 风格设定”的前置指令

但是，上下文一长，Prompt 的“影响力”会被稀释，Attention 会自然衰减，这就需要你：

控制 Prompt 的位置和长度；
在长文本中“重复前置引导”；
或者用系统结构重写（如 Function Call、Tool Use）来显式控制行为。

5.2 长上下文机制下，Attention 会自动“忽略”不重要的内容

当前主流模型，如 DeepSeek、Baichuan、LLaMA2，支持 4K、16K 甚至 128K 的上下文长度。听起来很爽，但也带来一个问题：

Token 太多，Attention 算不过来，怎么办？

所以，各大模型都引入了各种 长上下文优化机制，常见有：

优化机制	作用	原理
RoPE 插值	支持无限长位置	对旋转位置编码做比例放大
ALiBi（线性偏移）	距离越远注意力越低	Attention mask 直接加入偏置项
Sliding Window Attention	只看临近内容	Attention 区域局部滑动窗口
Ring Attention / Multi-Scale	看局部 + 关键 Token	先提取摘要，再多尺度 Attention

这些机制会在推理时主动忽略掉远距离的内容，这也意味着：

如果你的 Prompt 在 5000 个 Token 之前，模型可能“根本没看到”。

所以，Prompt 的位置和结构设计，直接影响能否被模型记住。推荐技巧包括：

Prompt 放在每轮对话的开头重复一遍；
用缩写、标记明确提示功能；
对长对话使用摘要 + Prompt 重构机制。

5.3 多轮对话的滑窗机制：Token 剪枝是现实的刚需

以 ChatGPT 为例：

它支持你与模型进行多轮对话；
每轮对话内容 + Prompt 都会作为下一轮的输入；
所有历史内容会被拼接进“上下文窗口”里；

但一旦超过最大 Token 长度，比如 4K、8K，就会自动做 “Token 滑窗 + 剪枝”。

Token 滑窗的逻辑大致如下：

1）保留最近 N 轮对话的内容；
2）固定保留 Prompt + 指令部分；
3）丢弃最早的几轮内容；

这就带来几个工程挑战：

问题	影响	解决方法
历史丢失	模型上下文缺失	引入摘要模块保留历史要点
Prompt 被截断	行为漂移	将 Prompt 放入系统字段或 Function 调用中
KV Cache 无法增量复用	内存负担	限制 Decode Token 数量，合理拆分轮次

所以在企业场景中，我们常常需要：

引入对话摘要模型（如 MiniLM）来做历史压缩；
自建Prompt 管理器，实现行为模板标准化；
对输入做“窗口剪枝 + 动态 Prompt 拼接”，控制上下文长度。

5.4 Prompt 触发 Function Call，影响的不只是语义，而是结构

像 OpenAI 的 function_calling、DeepSeek 的 tool_calling，本质上是结构化 Prompt 编排的升级玩法：

模型通过指定结构（函数、工具、参数格式），对接外部系统。

这种结构 Prompt 的本质是：

让模型从“输出语言”变成“控制行为”；
对接函数、插件、数据库等外部模块；
构建具备“调用力”的 Agent 系统。

但要做好这件事，你必须理解：

Prompt 编写 → Token 编码 → Attention 计算 → 输出格式 → JSON 验证 → 工具调用；
每一步都与模型内部结构机制强相关。

小结：Prompt 不只是“文字提示”，它是模型行为的“编程语言”

你应该这样重新理解 Prompt：

传统认知	实际工程含义
是语言提示	是计算路径控制
是内容设定	是行为注入
是“软参数”	是结构激活器

掌握结构，是为了更好地编写 Prompt；而掌握 Prompt，是为了最大化发挥结构的效能。

六、大模型的参数存储与系统结构图

当你下载一个大模型，比如 Qwen2-7B 或 Baichuan2-13B，你可能会看到这些文件：

pytorch_model-00001-of-00008.bin  
pytorch_model-00002-of-00008.bin  
...  
config.json  
tokenizer.model  
generation_config.json

再大一点的模型，就变成：

model.safetensors.index.json  
model-00001-of-00020.safetensors  
...

你有没有想过：

这些文件到底装了哪些东西？
为什么要拆成这么多份？
加载时怎么知道参数属于哪一张 GPU？
safetensors、PT、ONNX 有什么区别？

这一节就来彻底拆清楚：大模型是怎么被“装起来”的，又是怎么被“加进来”的。

6.1 一个模型=结构 + 权重 + Tokenizer + 配置

我们先建立概念，一个大模型的“系统包”主要包含四部分：

模块	说明
结构定义	`config.json`：决定模型层数、隐藏维度、头数等
参数权重	`.bin` 或 `.safetensors`：存储每层 W、b、QKV 矩阵等
分词器	`tokenizer.model` / `tokenizer.json`：把句子转成 Token 的规则
生成配置	`generation_config.json`：包括温度、top_k、采样策略等

这些部分共同决定了模型“长什么样”、“吃什么输入”、“怎么推理生成”。

6.2 参数格式大比拼：safetensors vs pytorch vs onnx

格式	优点	缺点	使用场景
PyTorch（.bin）	原生支持、兼容性强	加载慢、安全性差	早期 HuggingFace 模型主流
safetensors	加载快、零拷贝、安全	工具支持略滞后	目前 HuggingFace 推荐标准
ONNX	可部署到非 PyTorch 环境	权重导出不完整，易丢信息	编译部署，配合 TensorRT / ONNXRuntime 使用

如果你是工程部署人员，建议：

训练/微调用 PyTorch or safetensors
部署压缩推理用 ONNX / TensorRT / GGUF（llama.cpp）

safetensors = 更快加载 + 更安全（无法注入 pickle）

6.3 为什么要“分片存储”？不是偷懒，而是性能刚需

当模型变得很大，比如 65B 参数以上，不可能把所有权重塞进一个文件——会带来两个大问题：

IO 性能低下：几十 GB 的单文件载入耗时严重；
分布式加载难：无法做并行映射

所以，主流做法是“权重分片（Shard）+ 索引文件”。

例如：

model-00001-of-00020.safetensors  
model-00002-of-00020.safetensors  
...
model.safetensors.index.json

索引文件里会写清楚：

{
  "weight_map": {
    "model.layers.0.attn.q_proj.weight": "model-00001-of-00020.safetensors",
    "model.layers.47.mlp.gate_proj.weight": "model-00015-of-00020.safetensors",
    ...
  }
}

这样就能在加载时：

自动映射每一层参数到正确的分片；
多卡并行读取，边加载边构图；
动态控制是否只加载部分参数（如 LoRA 微调）

6.4 多 GPU 加载时的典型架构图（通俗版）

我们用一个简化架构图来表示“大模型加载 + 分布式协同”的基本结构：

                        ┌────────────┐
                        │ config.json│
                        └────┬───────┘
                             │
       ┌────────────┬────────┴────────┬────────────┐
       ↓            ↓                 ↓            ↓
model-0001  model-0002      ...      model-0020   tokenizer.model
(.safetensors) (.safetensors)        (.safetensors)

       └────────────┬────────┬────────┬────────────┘
                    ↓        ↓        ↓
               ┌────────────┴────────────┐
               │ Distributed Loader (HF/DeepSpeed) │
               └────────────┬────────────┘
                            ↓
              ┌──────────────────────────┐
              │  GPU0 │ GPU1 │ GPU2 │ GPU3 │
              └──────────────────────────┘
                        ↓
               模型构图 & 启动服务

这套流程关键点在于：

索引文件知道“哪一层的参数”在哪个 shard；
多个 GPU 启动进程，通过 DDP / Tensor Parallel 协同加载；
形成完整模型后才启动推理/微调服务

6.5 轻量部署时的权重合并 +冻结策略

在一些场景下，比如量化推理、微服务部署，我们会希望：

模型体积更小；
加载更快；
不需要再写复杂的分布式启动脚本

可采用的策略包括：

权重合并（merge & convert）：把 LoRA、Adapter 融进 base model；
参数冻结（freeze）：加快加载，减少梯度；
模型裁剪（layer drop）：降低推理层数，仅保留前 N 层

工具推荐：

transformers-cli convert：HuggingFace 权重转换
merge_lora.py：合并 LoRA 到 base
AutoAWQ / GPTQ：量化后导出推理模型

小结：结构理解到系统部署，参数格式是你必须掌握的“中间语言”

掌握参数存储结构，有三大意义：

✅ 明确“模型都装在哪儿了”，加载流程不再靠猜；
✅ 可以自主合并 / 拆分 / 转换模型，适配部署框架；
✅ 搞清楚系统工程限制，为多机多卡部署打基础。

下一节我们将从结构图层面，完整绘制一个推理系统的关键路径图，串起从输入 Prompt → 编码 → Attention → Logits → 输出文字的全过程。

七、一个完整的大模型推理系统架构图（输入到输出全过程解析）

在你调用大模型的那一刻，看似只是发了一段 Prompt，拿回来一段文字。但在后台，其实触发了一个庞大的推理流程链路：

包含输入的处理、Token 化、模型加载与分发；
包含 KV 缓存管理、Attention 计算、输出采样；
更包括系统级的调度、负载均衡、错误处理机制。

这一节，我们就通过结构图 + 模块拆解，带你走完完整的推理路径。

7.1 总览结构图：从 Prompt 到输出文本，究竟发生了什么？

先上图（我这里用文字结构表达，后续可以帮你生成高清可视图）：

[Prompt 请求]
     │
     ▼
[输入处理模块（分词、系统Prompt拼接）]
     │
     ▼
[Tokenizer → Token序列]
     │
     ▼
[KV Cache 检查 / 构建（Prefill or Decode）]
     │
     ▼
[分布式模型执行引擎（如 vLLM / DeepSpeed / TensorRT）]
     │
     ▼
[多层 Transformer：LayerNorm → Attention → MLP]
     │
     ▼
[输出 Logits 向量]
     │
     ▼
[采样策略（Top-K、Top-P、温度）]
     │
     ▼
[生成下一个 Token → 解码成文字]
     │
     ▼
[拼接上下文 → 再次执行 → 直到生成结束]

这个链路中，每一块都可以被优化、监控、调试、扩展。

7.2 模块拆解与关键机制说明

模块	作用	关键点
Prompt 输入层	接收用户输入；拼接系统 Prompt / Tool 使用格式	Prompt 拼接标准化、长度控制、防 prompt 注入
Tokenizer 分词器	将文字转为 Token 序列	支持多语言、多粒度子词；Token 数决定计算量
KV Cache 管理器	判断是否可复用已有缓存，或重建	影响推理速度；Decode 阶段完全依赖 KV Cache
执行引擎（如 vLLM）	调度 Token 批处理、模型分发	支持多模型、多实例调度、Tensor 并行
Transformer 模型核心	编码语义、预测下一个 Token	多层 Attention + MLP；结构参数决定能力边界
Logits 输出器	输出预测结果向量（词表大小）	可加 bias、mask 控制可选词域
采样策略器	控制生成的“风格”与稳定性	控制创造性 / 稳定性；支持 beam search
解码器	Token 转换回自然语言	特殊 token 处理（如 BOS、EOS）
输出调度器	控制是否结束、是否继续生成	生成流控制；与 KV Cache、滑窗策略交互

7.3 推理系统中的核心优化点汇总

优化点	对应模块	作用
FlashAttention	Transformer Attention 层	降低内存、提升速度
KV Cache 分级存储	KV 管理模块	显存控制 + 跨轮重用
Prompt Prefix Pooling	Prompt 层 + Tokenizer	相同 Prompt 多次请求不重复计算
多模型权重共享	执行引擎	加载多个微调模型但共用 base 模型
Top-K 动态调节	采样模块	动态创造性输出控制
Decode Pack / Multi-query Attention	Token 批处理	提升吞吐，适用于长序列多请求场景