LLM Model

导言

Foudation Models(One4All): General pre-training model

LLM path ，generative-ai-for-beginners

LLM Research path¶

¹

to read: https://wandb.ai/vincenttu/blog_posts/reports/A-Survey-of-Large-Language-Models--VmlldzozOTY2MDM1

https://www.linkedin.com/pulse/evolution-generative-ai-deep-dive-life-cycle-training-aritra-ghosh

https://medium.com/predict/chatgpt-gpt-4-gpt-5-and-llm-b32c3d03275e

LLM Parameters Size¶

7B，70B to GPU memory?

B是10亿的单位，全精度是32位，也就是4字节。More in detail.

\[ 7B * 4 Byte = 28 * 10^9 Byte = 28 GB\]

Tranformer¶

LLM News¶

GPT-3（自回归模型）¶

GPT的全称是Generative Pre-Trained Transformer。
- 2017年，OpenAI(2015年成立)提出GPT论文
  - 2018.6 推出GPT1 1.2亿
  - 2019.11 推出GPT2 15亿。这时OpenAI没钱了，非盈利组织变收益封顶的盈利组织，微软注资10亿美元
  - 2020.6 推出GPT3 1750亿，这时没有人工反馈，导致参数量再增大，效果也无法提升了。
  - 2022.3 推出GPT3.5
  - 2022.11 推出ChatGPT
  - 2023.4 推出GPT-4, 虽然诞生于22年8月，OpenAI经过8个月的时间来确保对齐后才发布。
GPT核心原理：根据前面输入的语句，推测下一个字是什么
- GPT 拥有一张包含了五万个单词的词汇表，它会基于互联网上的海量文本，大致了解每个单词后面可能会跟着哪些单词，并给出相应的出现概率。
GPT模型的生成过程核心是
- 先通过无标签的文本去训练（无监督学习）生成语言模型，
- 再根据具体的NLP任务（如文本蕴涵、QA、文本分类等），来通过有标签的数据对模型进行fine-tuning微调（有监督学习、人工反馈的强化学习）。
它与ELMO一样，仍然是用语言模型进行无监督训练的，但是它用了特征提取能力更强的Transformer，并且是单向的Transformer。

GPT-3 模型的参数量达到 1750 亿，即便拥有 1024 张 80GB A100，那么完整训练 GPT-3 的时长都需要 1 个月。

2021年1月，OpenAI官宣了120亿参数的GPT-3变体DALL-E。多模态可以实现语言到图像的转化。

ChatGPT¶

使用了GPT-3.5大规模语言模型（LLM，Large Language Model），
并在该模型的基础上引入强化学习来Fine-turn预训练的语言模型。这里的强化学习采用的是RLHF（Reinforcement Learning from Human Feedback），
即采用人工标注的方式。目的是通过其奖励惩罚机制（reward）让LLM模型学会理解各种NLP任务并学会判断什么样的答案是优质的（helpfulness、honest、harmless三个维度）。
部分有趣的原理：关于token和无法反转字符
意义
- chatGPT貌似打通了机器理解人类自然语言的屏障，表面上能理解人们的意思。
- 如果机器能直接理解人类的目的，就不需要编程人员来实现我们的想法，可以让chatGPT理解并自主实现，AutoGPT的出现就是如此，去掉了对目的实现方式的深究，直接获得AI结果的方式。就是AIGC的核心。
- 这也激发了人们对AGI的畅想，期待着会自主思考(思维链CoT与常识)并学习进化的AI。
带来的思考
- 记忆力特别好，会找规律，但是不明白自己在说什么的小孩。(数学逻辑欠缺，如何修正？)
  - 不理解真实世界，没有真正在“回答”问题，只是在模仿人类的语言行为
- 大力出奇迹，以及NLP+强化学习的方式能够取得很好的表现。
- 当无监督学习的数据量增大到一定到程度，有监督学习就算变少也不会影响模型效果。
  - 到了GPT-3，当参数到达了1750亿以后，更是突然出现了诸如思维链等特性。
缺点
- 准确度(胡说（人工标注强化学习过。过于专业或者网上缺少的知识，chatgpt难以回答
- 据对齐和伦理性
- AI 生成的东西会污染网络
- transform 绝对不是AGI的基础模型，不是未来。
关于最佳模型的讨论 - 2023北京智源AI大会
- Transformer不会是超强AI的模型架构，大语言模型（LLM）不理解世界运转逻辑，更强的AI模型应具备对现实世界的无监督学习能力
- 自回归模型”(Auto-regressive model)没有关于基础现实的知识，既缺乏常识也没法规划答案

如何使用LLM：

(L)借助庞大的数据库：头脑风暴
(LM)语言模型
1. 办公辅助，生成书信论文格式，谦卑语气的检讨书
整合版本的搜索引擎
1. 快速入门概念：不熟悉的领域的基本操作( 如何写简单前端，关于这一点的准确性，由于是入门的问题，也能精确解决
模板或者格式化的工作，不再只限于重复工作
1. 如何使用新编程语言，如何爬虫。

GPT-5 / 6¶

OpenAI 已经在尝试用AI训练(面临崩溃问题)和解释AI，并且直接从世界中学习

世界模型？¶

论文： A Path Towards Autonomous Machine Intelligence

通过世界模型，AI可以真正理解这个世界、能预测和规划未来。通过成本核算模块，结合一个简单的需求（按照最节约行动成本的逻辑去规划未来），它就可以杜绝一切潜在的毒害和不可靠性

这个未来如何实现？世界模型如何学习？杨立昆只给了一些规划性的想法，比如还是采用自监督模型去训练，比如一定要建立多层级的思维模式。他介绍了联合嵌入预测架构（JEPA），系统性地介绍了这一实现推理和规划的关键

DeepSeek¶

见deepseekv3一文

QWQ¶

Prefill and Decode¶

在大型语言模型（LLM）的推理过程中，Prefill（预填充）和Decode（解码）是两个核心阶段，分别承担不同的计算任务和资源需求。以下是两者的详细对比：

1. Prefill阶段¶

功能：处理用户输入的完整提示（prompt），生成首个输出token，并构建初始的KV Cache（Key-Value缓存）。
输入：用户输入的完整token序列（例如“天空为什么是蓝色的？”分词后的多个token）。
输出： • 首个生成token（如“阳光”）；
• KV Cache：存储所有输入token的Key和Value向量，用于后续解码阶段的注意力计算。

计算特点：
1. 并行计算：由于输入的所有token已知，模型通过矩阵乘法（GEMM）并行计算自注意力，生成每个token的Key和Value向量。
2. 计算密集型：消耗大量计算资源（如GPU算力），尤其长prompt时耗时显著增加。
3. 显存占用：KV Cache的显存占用与输入token数正相关（例如Llama-7B模型处理128个token需约134MB显存）。

示例：输入“天空为什么是蓝色的？”（6个token），Prefill阶段完成所有6个token的KV缓存计算，并生成首个输出token“阳光”。

2. Decode阶段¶

功能：基于KV Cache自回归生成后续token，直至达到终止条件（如输出结束符<eos>或最大生成长度）。
输入：每次仅输入当前生成的单个token（如“阳光”→“中”→“的”…）。
输出：
• 下一个生成token；
• 更新的KV Cache：将新token的Key和Value追加到缓存中。

计算特点：
1. 串行生成：每次仅处理一个token，通过矩阵向量乘法（GEMV）计算注意力，依赖历史KV Cache。
2. 内存密集型：频繁读写显存中的KV Cache，显存带宽成为瓶颈（例如Llama-7B生成每个token需加载约14GB参数）。
3. 延迟敏感：每个token的生成时间（TPOT）直接影响用户体验，通常要求低于50ms。

示例：生成“阳光”后，模型读取缓存中所有7个token（原6个+新1个）的KV向量，计算下一个token“中”，并更新缓存。

对比与优化挑战¶

维度	Prefill阶段	Decode阶段
计算类型	计算密集型（GEMM）	内存密集型（GEMV）
并行性	高（全token并行）	低（单token串行）
显存压力	初始KV缓存构建	动态KV缓存增长与频繁访问
优化方向	算子融合、张量并行	KV缓存压缩、量化、连续批处理
关键指标	首Token延迟（TTFT）	每Token延迟（TPOT）

典型问题与解决方案：
• 显存碎片：vLLM的PagedAttention技术通过分页管理KV Cache，减少碎片。
• 长上下文瓶颈：Mooncake架构提出预填充-解码分离设计，利用分布式存储优化显存占用。
• 吞吐量提升：连续批处理（Continuous Batching）动态调度请求，提高GPU利用率。

总结¶

• Prefill阶段是模型“理解”用户输入的过程，通过并行计算快速构建上下文；
• Decode阶段是模型“生成”响应的过程，依赖高效显存管理和低延迟计算。
两者共同决定LLM推理的吞吐量和响应速度，优化需结合计算、存储和调度策略。

Prefill和Decode的差异¶

在大型语言模型（LLM）推理过程中，Prefill和Decode阶段的网络结构虽然相同，但代码实现存在显著差异，主要体现在输入处理方式、计算优化策略和缓存管理上。以下是具体分析及典型开源仓库示例：

一、代码实现差异的核心点¶

1. 输入处理与计算模式¶

• Prefill阶段
• 输入：一次性处理完整的用户输入序列（如整个提示词），需将所有token并行编码为嵌入向量，并计算全局自注意力。
• 代码实现：
◦ 使用矩阵乘法（GEMM）批量处理所有token的注意力计算，例如通过torch.bmm实现全序列的QKV矩阵并行计算。
◦ 生成完整的KV缓存（Key-Value Cache），存储所有输入token的键值对，供后续Decode阶段复用。
• 示例代码片段：

# Prefill阶段的注意力计算（伪代码）
q = linear(query_emb)  # 全序列并行计算Query
k = linear(key_emb)    # 全序列并行计算Key
v = linear(value_emb)  # 全序列并行计算Value
attn_output = scaled_dot_product_attention(q, k, v)  # 全局注意力

• Decode阶段
• 输入：每次仅处理一个生成的token，基于历史KV缓存进行增量计算。
• 代码实现：
◦ 使用矩阵向量乘法（GEMV）逐个生成token，例如通过torch.mv实现单token的Q与历史K的点积。
◦ KV缓存的动态更新：将新token的Key和Value追加到缓存中，避免重复计算。
• 示例代码片段：

# Decode阶段的注意力计算（伪代码）
new_q = linear(new_token_emb)  # 仅处理当前token的Query
attn_weights = new_q @ cached_k.transpose()  # 仅计算当前token与历史K的点积
attn_output = attn_weights @ cached_v         # 基于历史V生成输出
cached_k = torch.cat([cached_k, new_k], dim=1)  # 增量更新KV缓存
cached_v = torch.cat([cached_v, new_v], dim=1)

2. 缓存管理与显存优化¶

• Prefill：需一次性为所有输入token分配显存存储KV缓存，显存占用与输入长度正相关。
• Decode：通过分页缓存（如vLLM的PagedAttention）动态管理显存，支持长序列生成和并发请求的高效处理。

3. 批处理与并行策略¶

• Prefill：支持静态批处理（Static Batching），将多个请求的输入序列合并为一个大矩阵并行处理，提升计算效率。
• Decode：采用连续批处理（Continuous Batching），动态调度不同长度的生成请求，避免GPU资源空闲。

二、典型开源仓库及实现特点¶

以下仓库针对Prefill和Decode阶段的差异进行了针对性优化：

1. vLLM¶

• 核心优化：
◦ PagedAttention：将KV缓存分页管理，支持动态显存分配，显著提升长序列生成效率。
◦ Decode阶段异步调度：通过连续批处理实现高吞吐量，减少GPU空闲时间。
• 代码差异示例：
◦ Prefill阶段调用execute_model_prefill函数处理全序列，生成初始缓存。
◦ Decode阶段调用execute_model_decode函数逐个生成token，并更新分页缓存。

2. Hugging Face Transformers¶

• 实现方式：
◦ Prefill通过model.generate(input_ids)一次性处理输入，Decode通过自回归循环调用model.generate()生成后续token。
◦ 提供past_key_values参数传递历史KV缓存，避免重复计算。

3. TensorRT-LLM¶

• 优化重点：
◦ 为Prefill阶段生成高度优化的计算图（如融合注意力核函数），减少内存访问开销。
◦ 在Decode阶段使用Tensor Core加速GEMV运算，提升单token生成速度。

三、总结¶

• Prefill与Decode的代码差异本质上是并行计算与串行生成的权衡，前者侧重计算密集型任务，后者依赖显存带宽和调度优化。
• 开源仓库通过分页缓存、连续批处理、计算图优化等技术，在工程层面解决了两阶段的性能瓶颈。实际开发中，需根据场景需求选择适配的框架（如高吞吐选vLLM，低延迟选TensorRT-LLM）。

参考文献¶

Harnessing the Power of LLMs in Practice A Survey on ChatGPT and Beyond ↩