AI Day 1: Transformer架构与大语言模型基础 — 理解LLM的"引擎"

日期：2026-04-04 阶段：第一阶段 — AI/LLM技术深潜 (Day 1-15) 标签：Transformer Self-Attention LLM Tokenization 推理机制 MoE

---

学习路径树

AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15)
│   ├── Day 1:  Transformer架构与LLM基础 ← 你在这里
│   ├── Day 2:  训练过程深度：Pre-training / SFT / RLHF / DPO
│   ├── Day 3:  Prompt Engineering与上下文学习(ICL)原理
│   ├── Day 4:  RAG架构：检索增强生成全链路
│   ├── Day 5:  向量数据库与Embedding模型
│   ├── Day 6:  Fine-tuning实战：LoRA / QLoRA / Adapter
│   ├── Day 7:  模型量化与部署：GPTQ / AWQ / GGUF
│   ├── Day 8:  推理优化：vLLM / TensorRT-LLM / SGLang
│   ├── Day 9:  长上下文技术：RoPE扩展 / Ring Attention
│   ├── Day 10: 多模态模型：Vision-Language架构
│   ├── Day 11: Reasoning模型：CoT / o1 / R1 / Extended Thinking
│   ├── Day 12: Agent框架：ReAct / Tool Use / Planning
│   ├── Day 13: MCP协议与Tool生态
│   ├── Day 14: 模型评估：Benchmark / Arena / 安全评估
│   ├── Day 15: 阶段复习与架构总结
│   │
├── 第二阶段：工程实践 (Day 16-30)
│   ├── Day 16-20: LLM应用架构设计（微服务/网关/缓存/监控）
│   ├── Day 21-25: 生产级RAG系统（Chunking/Rerank/评估/迭代）
│   ├── Day 26-30: Agent系统工程化（状态管理/错误恢复/成本控制）
│   │
├── 第三阶段：金融零售AI应用 (Day 31-42)
│   ├── Day 31-35: 金融AI（风控模型/智能投顾/合规/反欺诈）
│   ├── Day 36-40: 零售AI（推荐系统/智能客服/供应链预测/营销）
│   ├── Day 41-42: CeFi x DeFi x AI融合架构
│   │
└── 第四阶段：面试冲刺 (Day 43-50)
    ├── Day 43-46: 系统设计面试（LLM平台/RAG/Agent/推荐）
    ├── Day 47-49: 产品/架构面试模拟
    └── Day 50: 总结与作品集

---

核心概念

一句话定义

Transformer 是一种基于自注意力(Self-Attention)机制的神经网络架构，它让模型能够并行处理序列中所有位置的关系，是当前所有大语言模型的底层"引擎"。

类比理解（金融零售背景）

把 Transformer 理解为"智能信贷审批系统"：

传统 RNN（循环神经网络）= 人工逐笔审批
  → 一笔一笔看，前面的审批结果影响后面的判断
  → 速度慢，容易"忘记"早期的申请特征

Transformer = 智能批量审批引擎
  → 同时看所有申请材料，自动发现关联性
  → "这个申请人的收入"和"那个担保人的信用"之间的关系一目了然
  → Self-Attention = 每份材料都在问："其他材料中，哪些和我最相关？"
  → Multi-Head = 从多个维度同时评估（收入维度、信用维度、行业维度…）

为什么PM/架构师需要理解这个

---

知识点1: Transformer架构

原论文："Attention Is All You Need" (Vaswani et al., 2017) 这篇论文提出的架构至今仍是所有LLM的基石，只是细节不断优化。

1.1 Self-Attention机制

Self-Attention的核心思想：序列中的每个元素都去"关注"其他所有元素，计算它们之间的相关性。

数学直觉：

输入: 一个句子 "用户 申请 了 一笔 贷款"

对于 "贷款" 这个词：
  → 和 "申请" 的关系很强（相关动作）     → 高权重
  → 和 "用户" 的关系中等（主语）          → 中权重
  → 和 "了" 的关系很弱（虚词）            → 低权重
  → 和 "一笔" 的关系中等（量词修饰）      → 中权重

Self-Attention 自动学会这种"相关性评分"

QKV三元组：

每个输入 Token 被映射为三个向量：

┌─────────────────────────────────────────────────┐
│  Q (Query)  = "我在找什么？"    — 查询向量      │
│  K (Key)    = "我能提供什么？"  — 键向量        │
│  V (Value)  = "我的实际内容"    — 值向量        │
└─────────────────────────────────────────────────┘

类比：
  Q = 信贷审批员的审查标准（"我要看收入证明"）
  K = 每份材料的标签（"这是收入证明"/"这是身份证"）
  V = 材料的实际内容（收入具体数字、身份信息）

计算过程：
  Attention(Q, K, V) = softmax(Q * K^T / sqrt(d_k)) * V

  1. Q * K^T      → 计算每对Token之间的"匹配分数"
  2. / sqrt(d_k)   → 缩放，防止分数太大导致梯度消失
  3. softmax(...)   → 归一化为概率分布（所有权重加起来=1）
  4. * V           → 用权重加权求和，得到输出

Self-Attention计算流程图：

输入序列: [x1, x2, x3, x4]
              │
         ┌────┴────┐
         │ 线性投影  │
         └────┬────┘
         ┌────┼────┐
         Q    K    V
         │    │    │
         └──┬─┘    │
            │      │
    ┌───────┴──────┐
    │  Q * K^T     │  ← 注意力分数矩阵 (n × n)
    │  / sqrt(d_k) │
    │  + mask      │  ← Decoder用causal mask遮住未来Token
    │  softmax()   │
    └───────┬──────┘
            │
    ┌───────┴──────┐
    │  Attn * V    │  ← 加权求和
    └───────┬──────┘
            │
        输出序列: [y1, y2, y3, y4]

注意力分数矩阵示例：

              用户   申请   了   一笔   贷款
  用户     [ 0.15  0.25  0.05  0.10  0.45 ]
  申请     [ 0.20  0.10  0.05  0.15  0.50 ]
  了       [ 0.10  0.30  0.10  0.20  0.30 ]
  一笔     [ 0.10  0.20  0.05  0.15  0.50 ]
  贷款     [ 0.30  0.35  0.03  0.12  0.20 ]

→ "贷款"最关注"申请"(0.35)和"用户"(0.30)
→ "申请"最关注"贷款"(0.50)
→ 这就是模型自动学到的语义关系

1.2 Multi-Head Attention

问题：单个Attention只从一个"视角"看关系。就像信贷审批只看收入维度。

解决：同时用多个Attention"头"，每个头关注不同的语义维度。

Multi-Head Attention:

头1: 关注语法关系（主语-谓语-宾语）
头2: 关注语义相似性（同类词）
头3: 关注位置关系（相邻词）
头4: 关注指代关系（代词指向）
...
头H: 关注其他模式

┌────────────────────────────────────────────┐
│                                            │
│   ┌──────┐  ┌──────┐       ┌──────┐      │
│   │Head 1│  │Head 2│  ...  │Head H│      │
│   │Q,K,V │  │Q,K,V │       │Q,K,V │      │
│   └──┬───┘  └──┬───┘       └──┬───┘      │
│      │         │               │          │
│      └─────────┼───────────────┘          │
│                │                          │
│          ┌─────┴─────┐                    │
│          │  Concat   │                    │
│          │  + Linear │                    │
│          └─────┬─────┘                    │
│                │                          │
│            Output                         │
│                                            │
└────────────────────────────────────────────┘

参数关系：
  d_model = 模型总维度（如4096）
  H = 头数（如32）
  d_k = d_model / H（如128）每个头的维度

2025-2026的变体：

• GQA (Grouped Query Attention)：Llama 3.3、Qwen 2.5 使用。将 K 和 V 的头数减少（如 Q 用32头，K/V 只用8头），大幅节省显存和推理速度，几乎不损失质量。
• MQA (Multi-Query Attention)：更极端，K/V 只用1头。Falcon 使用。
• MLA (Multi-head Latent Attention)：DeepSeek V3 独创。将 KV 压缩到低秩潜空间，KV Cache 减少到传统方式的 5-13%，是2025年最重要的注意力机制创新之一。

1.3 Positional Encoding

问题：Self-Attention本身不区分位置。"用户申请贷款"和"贷款申请用户"对它来说一样。

解决：给每个位置添加位置信息。

发展历程：

2017  Sinusoidal PE     原始论文，固定的正弦/余弦函数
2019  Learned PE        BERT使用，可学习的位置嵌入
2022  ALiBi             线性偏置，简单高效
2023  RoPE              旋转位置编码 ← 2025-2026主流
2024  YaRN/NTK-Aware    RoPE的长度扩展方法

RoPE (Rotary Position Embedding) — 当前主流：

核心思想：用旋转矩阵编码相对位置

  → 把向量在复数平面上旋转 θ 角度
  → 位置 m 的旋转角度 = m * θ
  → 两个位置之间的注意力分数只取决于相对距离

优势：
  1. 天然支持相对位置编码
  2. 可通过 NTK-Aware 扩展到更长上下文
  3. 计算高效，无额外参数

使用者：
  Llama 3.3 ✓  Qwen 2.5/3 ✓  DeepSeek V3 ✓  Mistral ✓
  → 几乎所有2025-2026的主流开源模型都用RoPE

1.4 Feed-Forward Network (FFN)

每个Transformer层中，Attention之后是一个FFN：

FFN(x) = activation(x * W1 + b1) * W2 + b2

作用：
  → Attention负责"信息聚合"（Token之间交互）
  → FFN负责"信息变换"（每个Token独立的非线性变换）

类比：
  Attention = 会议讨论（大家交换信息）
  FFN = 个人深度思考（消化信息，形成观点）

2025-2026变体：
  → SwiGLU：Llama 3.3、Qwen 2.5、DeepSeek V3 使用
    FFN_SwiGLU(x) = (Swish(x * W_gate) ⊙ (x * W_up)) * W_down
    比标准ReLU更平滑，训练更稳定

1.5 Layer Normalization

两种主流方式：

Post-LN（原始Transformer）：
  x → Attention → Add & Norm → FFN → Add & Norm

Pre-LN（2025-2026主流）：
  x → Norm → Attention → Add → Norm → FFN → Add

RMSNorm（当前最流行）：
  → 只用均方根归一化，去掉均值中心化
  → 计算更快，效果相当
  → Llama 3.3、Qwen 2.5、DeepSeek V3 都用RMSNorm

DeepSeek V3 还使用了 FP8 混合精度训练 + 无辅助损失的负载均衡，
这些工程优化使得训练成本降低到同规模模型的 1/10。

1.6 完整的Transformer Decoder块

2025-2026主流LLM的单个Transformer块：

    输入 Token Embeddings + RoPE位置编码
                │
    ┌───────────┴───────────┐
    │      RMSNorm          │
    │          │            │
    │   ┌──────┴──────┐     │
    │   │  GQA/MLA    │     │  ← Grouped Query / Multi-head Latent Attention
    │   │  Attention  │     │
    │   └──────┬──────┘     │
    │          │            │
    │   ┌──────┴──────┐     │
    │   │  Residual   │←────┘  ← 残差连接（跳跃连接）
    │   │  Connection │
    │   └──────┬──────┘
    │          │
    ┌──────────┴───────────┐
    │      RMSNorm          │
    │          │            │
    │   ┌──────┴──────┐     │
    │   │  SwiGLU     │     │  ← 门控FFN
    │   │  FFN        │     │
    │   └──────┬──────┘     │
    │          │            │
    │   ┌──────┴──────┐     │
    │   │  Residual   │←────┘
    │   │  Connection │
    │   └──────┬──────┘
               │
           输出到下一层

一个完整的LLM = 上面这个块 × N层
  → Llama 3.3 70B:  80层
  → DeepSeek V3:    61层（MoE）
  → Qwen 2.5 72B:   80层

---

知识点2: 从Transformer到LLM

2.1 三种架构范式

原始Transformer（2017）有Encoder + Decoder两部分。
后续发展分化为三条路线：

┌─────────────────────────────────────────────────────────┐
│                                                         │
│  Encoder-only          Decoder-only       Enc-Dec       │
│  (BERT系列)            (GPT系列)          (T5系列)      │
│                                                         │
│  输入 → [编码器] → 表示  输入 → [解码器] → 续写  输入 → [编码] → [解码] → 输出 │
│                                                         │
│  擅长：理解任务         擅长：生成任务      擅长：翻译/摘要   │
│  - 文本分类             - 文本生成          - Seq2Seq任务    │
│  - 情感分析             - 对话              - 条件生成       │
│  - NER                  - 代码生成                          │
│                                                         │
│  代表：                 代表：              代表：          │
│  BERT, RoBERTa         GPT-4.5, Claude 4   T5, BART     │
│  DeBERTa               Llama 3.3, Qwen 3   Flan-T5      │
│  (Embedding模型)       DeepSeek V3/R1                    │
│                                                         │
│  2025-2026状态：        2025-2026状态：     2025-2026状态：│
│  仍用于Embedding/       绝对主流            基本淘汰       │
│  分类/搜索              所有LLM都是这个                    │
│                                                         │
└─────────────────────────────────────────────────────────┘

2.2 为什么Decoder-only成为主流

关键原因：

1. 统一的"生成"范式
   → 所有NLP任务都能转化为"给定前文，预测下文"
   → 分类 = 生成"正面"或"负面"
   → 翻译 = 生成目标语言文本
   → 推理 = 生成推理链
   → 一个模型解决所有问题 = 通用性

2. Scaling Laws更好
   → Decoder-only在大规模上表现更优
   → Encoder-only的双向注意力在大模型时计算成本翻倍
   → Decoder-only的Causal Attention可用KV Cache加速

3. In-Context Learning能力
   → Few-shot Prompting只有Decoder-only能做好
   → 给几个例子就能"学会"新任务，无需微调
   → 这是涌现能力的关键载体

4. 工程效率
   → Causal mask使得KV Cache可以复用
   → 可以做Speculative Decoding
   → 推理优化空间更大

2.3 Next Token Prediction

LLM的训练目标极其简单：

  给定前面的所有Token，预测下一个Token

  P(x_t | x_1, x_2, ..., x_{t-1})

示例：
  输入：  "用户 在 DeFi 协议 中 申请"
  目标：  预测下一个Token = "了" (概率最高)

为什么这么简单的目标能产生"智能"？

  → 要准确预测下一个Token，模型必须理解：
     语法结构、语义关系、世界知识、逻辑推理、常识...
  → 当训练数据足够多、模型足够大时
  → 这些"理解"自然涌现(emerge)

类比（金融）：
  → 就像学习预测"下一笔交易"
  → 要预测准确，你必须理解：
     市场趋势、用户画像、季节规律、宏观经济...
  → 看似简单的预测任务，实际要求深层理解

2.4 训练三阶段

┌──────────────────────────────────────────────────────┐
│                                                      │
│  阶段1: Pre-training（预训练）                        │
│  ────────────────────                                │
│  目标：在海量文本上学习语言和知识                        │
│  数据：数万亿Token（互联网、书籍、代码…）               │
│  成本：数千万到数亿美元                                │
│  时间：数周到数月                                     │
│  产出：Base Model（原始模型，只会续写）                 │
│                                                      │
│           ↓                                          │
│                                                      │
│  阶段2: Supervised Fine-Tuning (SFT)                 │
│  ────────────────────────────────                     │
│  目标：学会"指令遵循"和"对话格式"                       │
│  数据：数万到数十万条高质量指令-回答对                   │
│  成本：相对较低                                       │
│  产出：Chat Model（能对话，但可能有害/不诚实）          │
│                                                      │
│           ↓                                          │
│                                                      │
│  阶段3: Alignment（对齐）                             │
│  ────────────────                                    │
│  目标：让模型"有用、诚实、无害"                         │
│  方法：                                              │
│    RLHF = 人类反馈强化学习（Claude早期/GPT-4）         │
│    DPO  = 直接偏好优化（更简单，Llama 3.3等使用）       │
│    GRPO = 群组相对策略优化（DeepSeek R1使用）          │
│  产出：Aligned Model（可安全部署的模型）               │
│                                                      │
│  2025-2026趋势：                                     │
│  → RLHF仍是闭源模型的主要方法（Claude 4, GPT-4.5）   │
│  → DPO在开源社区更流行（训练更简单）                   │
│  → DeepSeek R1用GRPO大幅降低了对齐成本                │
│  → Constitutional AI（Anthropic）用AI自监督对齐       │
│                                                      │
└──────────────────────────────────────────────────────┘

2.5 Scaling Laws

Scaling Laws = "模型性能如何随规模增长"的数学规律

┌─────────────────────────────────────────────────────┐
│                                                     │
│  Kaplan Laws (OpenAI, 2020):                        │
│  → 性能 ∝ 参数量^0.076                              │
│  → 性能 ∝ 数据量^0.095                              │
│  → 性能 ∝ 计算量^0.050                              │
│  → 结论：增大模型比增加数据更重要                      │
│                                                     │
│  Chinchilla Laws (DeepMind, 2022):                  │
│  → 最优方案：参数量和数据量同比例增长                    │
│  → 70B参数需要1.4T Token训练                         │
│  → 之前的模型(如GPT-3)严重训练不足                     │
│  → 影响：Llama系列都遵循此法则                         │
│                                                     │
│  DeepSeek的新发现 (2024-2025):                       │
│  → "过度训练"小模型可以打败"正常训练"的大模型            │
│  → DeepSeek V3 (671B总/37B激活) ≈ GPT-4级别          │
│  → 用14.8T Token训练，远超Chinchilla最优比             │
│  → MoE + 高效训练 = 改变了Scaling Laws的实践           │
│  → 训练成本仅$5.6M（同级别模型通常$50-100M+）          │
│                                                     │
│  Llama 3.3的经验 (Meta, 2024):                       │
│  → 70B参数用15T+ Token训练                           │
│  → 性能接近Llama 3.1 405B（正常训练量）                │
│  → 印证了"过度训练小模型"的可行性                       │
│                                                     │
│  2025-2026共识：                                     │
│  → 不再单纯追求参数量                                 │
│  → MoE架构（大参数量但小激活量）成为趋势                │
│  → 训练数据质量 > 数据数量                             │
│  → 推理时计算(Test-time Compute)成为新维度             │
│                                                     │
└─────────────────────────────────────────────────────┘

---

知识点3: 2025-2026主流模型架构对比

3.1 模型全景对比表

3.2 MoE (Mixture of Experts) 架构详解

MoE = 混合专家模型 — 2025-2026最重要的架构趋势

传统Dense模型：
  → 每个Token经过所有参数
  → 70B参数 = 每次推理用70B参数
  → 计算量大，成本高

MoE模型：
  → 总参数量很大，但每个Token只激活一部分"专家"
  → 671B总参数，每次只用37B（DeepSeek V3）
  → 相当于"专家会诊"：不是每个医生都看每个病人

架构图：

    输入 Token
        │
   ┌────┴────┐
   │  Router │  ← 门控网络，决定激活哪些专家
   │ (Gate)  │     通常选Top-K个专家
   └────┬────┘
        │
   ┌────┴──────────────────────────┐
   │                               │
   ▼         ▼                     ▼
┌──────┐  ┌──────┐    ...     ┌──────┐
│Expert│  │Expert│            │Expert│
│  1   │  │  2   │            │  N   │
│(FFN) │  │(FFN) │            │(FFN) │
└──┬───┘  └──┬───┘            └──┬───┘
   │         │                    │
   └─────────┼────────────────────┘
             │
        加权求和
             │
          输出

DeepSeek V3 的MoE细节：
  → 256个专家 + 1个共享专家
  → 每个Token激活8个专家 + 共享专家
  → 总参数671B，激活37B（仅5.5%）
  → 无辅助损失的负载均衡（重要创新）
  → 训练成本$5.6M（GPT-4级别能力）

Qwen 3 235B-A22B 的MoE：
  → 128个专家
  → 每个Token激活8个专家
  → 总参数235B，激活22B
  → 支持"思考模式"开关（类似R1的推理能力）

MoE vs Dense模型对比：

3.3 开源 vs 闭源生态 (2025-2026)

2025-2026 生态格局：

闭源（API服务）                    开源（本地/私有部署）
┌──────────────────────┐          ┌──────────────────────┐
│ OpenAI: GPT-4.5, o3  │          │ Meta: Llama 3.3      │
│ Anthropic: Claude 4   │          │ DeepSeek: V3, R1     │
│ Google: Gemini 2.5    │          │ 阿里: Qwen 2.5/3     │
│ Mistral: Large        │          │ Microsoft: Phi-4     │
│                       │          │ Mistral: 开源版本     │
│ 优势：                │          │ 优势：                │
│ · 最强性能            │          │ · 数据隐私            │
│ · 持续更新            │          │ · 自定义微调          │
│ · 无需基础设施         │          │ · 无API费用           │
│                       │          │ · 离线运行            │
│ 劣势：                │          │ 劣势：                │
│ · 数据隐私风险         │          │ · 性能稍逊            │
│ · 持续API成本          │          │ · 需要GPU基础设施      │
│ · 供应商锁定           │          │ · 运维成本            │
└──────────────────────┘          └──────────────────────┘

2025-2026趋势：
→ 开源模型与闭源的差距大幅缩小（DeepSeek R1 ≈ o1）
→ 中国厂商(DeepSeek/Qwen)在开源领域领先
→ "小模型+过度训练"路线崛起（Phi-4 14B性能惊人）
→ 推理模型(Reasoning Model)成为新战场
→ 企业级部署越来越倾向混合方案（闭源API+开源私有部署）

3.4 推理模型(Reasoning Model)趋势

2024-2025最重要的趋势：从"快速回答"到"深度思考"

传统LLM：
  → 一次前向传播生成答案
  → 像"快速直觉"

推理模型：
  → 在回答前用大量Token进行"思考"
  → 像"深度分析"
  → Test-time Compute: 推理时投入更多计算

代表模型：
┌─────────────────────────────────────────────┐
│ OpenAI o1/o3    — 首创推理范式               │
│ DeepSeek R1     — 开源推理，GRPO训练          │
│ Claude Extended Thinking — Claude 4/Sonnet 4 │
│ Qwen 3 (思考模式) — 可开关的推理能力          │
│ Gemini 2.5 Pro  — Flash Thinking             │
└─────────────────────────────────────────────┘

PM/架构师视角：
  → 推理模型 = 更高的成本（10-50x Token消耗）
  → 但对复杂任务（数学/编程/逻辑）效果显著提升
  → 产品设计需要考虑：何时用"快速模式"vs"深度模式"
  → 成本控制成为核心架构决策

---

知识点4: Tokenization

4.1 BPE (Byte Pair Encoding) 原理

BPE = 大多数LLM使用的分词算法

核心思想：从单个字符开始，反复合并出现最频繁的字符对

示例过程：

原始文本: "low lower lowest"

Step 0: 字符级
  l o w _ l o w e r _ l o w e s t

Step 1: 最频繁的对 "l o" → 合并为 "lo"
  lo w _ lo w e r _ lo w e s t

Step 2: 最频繁的对 "lo w" → 合并为 "low"
  low _ low e r _ low e s t

Step 3: 最频繁的对 "low e" → 合并为 "lowe"
  low _ lowe r _ lowe s t

... 反复合并直到达到目标词表大小

最终词表可能包含：
  [l, o, w, e, r, s, t, lo, low, lowe, lower, lowest, ...]

4.2 Tokenizer对比

4.3 Tokenization对多语言的影响

同一句话在不同语言下的Token效率：

英文: "The user applied for a loan"
  → GPT-4: 7 tokens
  → 效率: 约 4 字符/token

中文: "用户申请了一笔贷款"
  → GPT-4 (tiktoken): ~12-15 tokens（每个汉字2-3 token）
  → Qwen 2.5 (优化过): ~8-9 tokens（每个汉字≈1 token）

影响：
  → 同样的中文内容，用GPT-4比用Qwen消耗多50-100% Token
  → Token数 = 成本，这对中文产品很重要
  → 上下文窗口也受影响：128K token在中文下实际容量更少

PM决策点：
  → 如果产品主要服务中文用户
  → Qwen系列的Token效率优势 = 显著的成本节省
  → 这是模型选型中容易被忽视但影响巨大的因素

4.4 Token数与成本关系

2025-2026 主流API定价（每百万Token，近似值）:

┌────────────────────────────────────────────────┐
│ 模型              │  输入价格   │  输出价格    │
├────────────────────────────────────────────────┤
│ GPT-4.5           │  $75       │  $150       │
│ o3                │  $10       │  $40        │
│ Claude Opus 4     │  $15       │  $75        │
│ Claude Sonnet 4   │  $3        │  $15        │
│ Gemini 2.5 Pro    │  $1.25-2.5 │  $10-15     │
│ DeepSeek V3 (API) │  $0.27     │  $1.10      │
│ Qwen 2.5 72B(API) │  ~$0.40    │  ~$1.20     │
│ Llama 3.3 (自部署)│  GPU成本    │  GPU成本    │
└────────────────────────────────────────────────┘

成本估算示例（金融客服系统）：
  → 每次对话平均 2000 input + 500 output tokens
  → 每天 10,000 次对话
  → 月对话量: 300,000 次

  Claude Sonnet 4:
    输入: 300K × 2K / 1M × $3 = $1,800/月
    输出: 300K × 0.5K / 1M × $15 = $2,250/月
    总计: ~$4,050/月

  DeepSeek V3 API:
    输入: 300K × 2K / 1M × $0.27 = $162/月
    输出: 300K × 0.5K / 1M × $1.10 = $165/月
    总计: ~$327/月

  → 差距 12倍！这就是模型选型对成本的影响

---

知识点5: 推理过程

5.1 Prefill vs Decode 两阶段

LLM生成文本分两个阶段：

阶段1: Prefill（预填充）
  → 一次性处理所有输入Token
  → 计算所有输入Token的KV值
  → 计算密集型（大量矩阵乘法）
  → 类比：审批员一次性读完所有申请材料

阶段2: Decode（解码）
  → 逐个生成输出Token
  → 每生成一个Token = 一次前向传播
  → 内存密集型（需要读取KV Cache）
  → 类比：审批员逐条写审批意见

时间线：
┌─────────────┬───┬───┬───┬───┬───┬───┐
│   Prefill   │ T1│ T2│ T3│ T4│ T5│...│
│  (一次性)   │   │   │   │   │   │   │
│  处理输入   │ ←── 逐个生成输出 ────→  │
└─────────────┴───┴───┴───┴───┴───┴───┘

性能指标：
  → TTFT (Time To First Token): Prefill时间，用户感知的"反应速度"
  → TPS (Tokens Per Second): Decode速度，用户感知的"打字速度"
  → 长输入 = Prefill慢 = TTFT高
  → 长输出 = Decode时间长 = 总延迟高

5.2 KV Cache原理

问题：Decode阶段，每生成一个新Token都需要Attention之前所有Token。
如果每次重新计算 = 巨大的浪费。

解决：KV Cache — 缓存之前所有Token的Key和Value向量

┌───────────────────────────────────────────┐
│  Token 1 生成时：计算 K1, V1 → 存入Cache  │
│  Token 2 生成时：计算 K2, V2 → 存入Cache  │
│    Attention用 [K1,K2] 和 [V1,V2]         │
│  Token 3 生成时：计算 K3, V3 → 存入Cache  │
│    Attention用 [K1,K2,K3] 和 [V1,V2,V3]  │
│  ...                                      │
│  Cache线性增长！                            │
└───────────────────────────────────────────┘

KV Cache显存占用估算：
  = 2 × num_layers × num_kv_heads × head_dim × seq_len × batch × bytes

  Llama 3.3 70B, 128K上下文, FP16:
  = 2 × 80 × 8 × 128 × 128K × 1 × 2 bytes
  ≈ 32 GB（仅KV Cache就需要32GB显存！）

  → 这就是为什么长上下文模型需要大量显存
  → GQA (KV头数减少) 和 MLA (KV压缩) 就是为了解决这个问题

DeepSeek V3的MLA优势：
  → KV Cache压缩到传统方式的 5-13%
  → 128K上下文的KV Cache从~32GB降到~2-4GB
  → 这是DeepSeek V3能高效服务长上下文的关键

5.3 采样策略

模型输出的是每个Token的概率分布，如何选择下一个Token？

┌──────────────────────────────────────────────┐
│                                              │
│  Temperature（温度）                          │
│  → 控制概率分布的"锐度"                       │
│  → T=0: 永远选概率最高的（确定性，适合事实问答）│
│  → T=0.7: 适度随机（适合对话）                 │
│  → T=1.0: 原始分布                            │
│  → T=1.5+: 高度随机（创意写作）               │
│                                              │
│  Top-p（核采样）                              │
│  → 只从累积概率前p%的Token中采样              │
│  → p=0.9: 只考虑占90%概率的Token              │
│  → 自动适应：确定性高时选项少，不确定时选项多   │
│                                              │
│  Top-k                                       │
│  → 只从概率最高的k个Token中采样               │
│  → k=50: 只考虑Top 50个Token                 │
│  → 简单但不如Top-p灵活                        │
│                                              │
│  实践组合（2025-2026常见设置）：               │
│  → 代码生成: T=0, 或 T=0.2 + Top-p=0.9      │
│  → 对话: T=0.7 + Top-p=0.9                   │
│  → 创意写作: T=1.0 + Top-p=0.95              │
│  → 推理任务: T=0（确定性最大化）               │
│                                              │
└──────────────────────────────────────────────┘

5.4 Speculative Decoding（推测解码）

问题：Decode阶段是串行的，大模型每生成一个Token很慢。

思路：用一个小模型"猜"多个Token，大模型一次性验证。

流程：
┌───────────────────────────────────────────────┐
│                                               │
│  小模型(Draft): 快速生成 5 个候选Token          │
│    → "用户" "申请" "了" "贷款" "产品"            │
│                                               │
│  大模型(Target): 一次性验证这5个Token           │
│    → "用户" ✓ "申请" ✓ "了" ✓ "一笔" ✗         │
│    → 前3个正确，第4个不对                        │
│    → 接受前3个 + 大模型自己生成第4个              │
│                                               │
│  效果：                                        │
│    → 原来: 5次前向传播 = 5个Token                │
│    → 现在: 小模型5次 + 大模型1次 ≈ 3-4个Token   │
│    → 加速 2-3x（取决于小模型的"猜测准确率"）     │
│                                               │
│  2025-2026实践：                                │
│    → vLLM、TensorRT-LLM 都支持                  │
│    → Medusa（多头预测）                          │
│    → EAGLE（特征级预测，更高接受率）              │
│    → 在API服务中广泛使用以降低延迟                │
│                                               │
└───────────────────────────────────────────────┘

5.5 为什么推理成本高

成本构成分析：

┌───────────────────────────────────────┐
│           推理成本构成                  │
├───────────────────────────────────────┤
│                                       │
│  1. GPU显存                            │
│     → 模型权重（70B FP16 ≈ 140GB）     │
│     → KV Cache（随上下文线性增长）       │
│     → 激活值（计算中间结果）             │
│                                       │
│  2. GPU计算                            │
│     → Prefill: 计算密集（矩阵乘法）     │
│     → Decode: 内存带宽受限              │
│     → 大模型: 每个Token数十亿次浮点运算  │
│                                       │
│  3. 并发与吞吐                          │
│     → Decode阶段GPU利用率低（~30-40%）  │
│     → 需要Continuous Batching优化       │
│     → vLLM的PagedAttention解决显存碎片  │
│                                       │
│  4. 长上下文额外成本                     │
│     → Attention计算 = O(n^2)            │
│     → 128K上下文 = 128x的Attention计算  │
│     → Gemini 2.5的1M上下文成本更高       │
│                                       │
│  PM成本优化策略：                        │
│     → 短Prompt = 少花钱（Prompt工程）    │
│     → 缓存常用前缀（Prompt Caching）     │
│     → 选对模型（简单任务用小模型）         │
│     → 批量处理（提高GPU利用率）           │
│     → MoE模型（DeepSeek V3成本低10x）    │
│                                       │
└───────────────────────────────────────┘

---

今日思考

问题1: 作为PM/架构师，如何在"模型能力"和"推理成本"之间做权衡？

回答：

这本质上是一个分层服务设计问题，和金融行业的"客户分层服务"逻辑一致：

请求分层路由架构：

用户请求 → 意图分类器（小模型/规则）
              │
    ┌─────────┼──────────┐
    ▼         ▼          ▼
  简单查询   常规对话   复杂推理
  (FAQ)     (客服)     (分析/决策)
    │         │          │
    ▼         ▼          ▼
  Phi-4    Sonnet 4   Opus 4 / o3
  14B       中等        最强
  $0.01    $0.05      $1.00+

  类比金融：
  → 柜员处理简单业务（小模型）
  → 客户经理处理常规业务（中模型）
  → 高级顾问处理复杂投资（大模型）

核心原则：80%的请求用20%的成本解决，20%的复杂请求才需要最强模型。

---

问题2: MoE架构对产品设计有什么实际影响？

回答：

MoE的核心影响是改变了"能力-成本"曲线：

1. API定价策略：DeepSeek V3的API价格是GPT-4.5的1/50，这不是"打折"，而是架构层面的成本革命。产品设计可以承受更多"试错"（让AI多尝试几次、生成更长输出）。

2. 私有部署门槛：MoE模型的显存需求 = 总参数量（671B ≈ 1.3TB FP16），但计算量 = 激活参数量（37B）。这意味着需要多卡存储但计算速度快。私有部署需要更多显卡数量但每张卡利用率更低。

3. 延迟特性：MoE模型在Prefill阶段非常快（计算量小），但Decode阶段受"专家切换"影响可能有波动。产品需要考虑首Token延迟 vs 持续生成速度的平衡。

4. 容量规划：MoE让"大脑容量"（总参数/知识量）和"思考速度"（激活参数/推理速度）解耦。架构师可以选择"大容量慢速度"或"小容量快速度"的配置。

---

问题3: 推理模型(o3/R1)的出现，对LLM应用架构有什么根本性影响？

回答：

推理模型引入了Test-time Compute维度，这对架构设计是范式级变化：

传统LLM架构：
  固定延迟 → 一次生成 → 返回结果
  延迟可预测，成本可预测

推理模型架构：
  可变延迟 → 长时间思考 → 返回高质量结果
  延迟不可预测（简单问题1秒，复杂问题60秒）
  成本不可预测（Token消耗差10-100倍）

架构影响：

1. 异步架构成为必须：不能让用户同步等待60秒。需要WebSocket/SSE推送、进度条、"思考中..."状态。

2. 超时和熔断策略：传统LLM调用设30秒超时。推理模型可能需要120秒+。需要分级超时：快速回退到普通模型。

3. 成本控制：需要"推理预算"概念 — 每个请求最多花多少Token思考。DeepSeek R1的max_thinking_tokens参数就是这个。

4. 缓存失效：推理模型的输出更长、更个性化，传统的"相似问题返回缓存结果"策略效果变差。

5. 评估体系：不能只看"对不对"，还要看"花了多少思考Token得到的结果"。需要效率指标：准确率/Token。

---

面试表达

问题: "请解释Transformer的核心原理及其在LLM中的作用"

30秒版本：

Transformer的核心是Self-Attention机制，它让模型能并行计算序列中任意两个位置之间的关系，解决了RNN的串行和长距离依赖问题。当前所有主流LLM（GPT-4.5、Claude 4、Llama 3.3、DeepSeek V3）都基于Transformer的Decoder-only架构，通过Next Token Prediction训练目标，在大规模数据上涌现出强大的语言理解和生成能力。

2分钟版本：

Transformer有三个关键创新：

第一，Self-Attention。每个Token通过Query、Key、Value三个向量与其他所有Token计算相关性权重，然后加权聚合信息。这让模型可以直接关注远距离的相关信息，比如句子开头的主语和结尾的动词。

第二，Multi-Head Attention。多个Attention头同时从不同维度（语法、语义、位置等）关注信息，再合并输出。2025年的主流优化是GQA（减少KV头数节省显存）和DeepSeek的MLA（压缩KV到潜空间）。

第三，可并行计算。不像RNN必须按顺序处理，Transformer的Attention可以并行处理所有位置，充分利用GPU的并行计算能力，这使得大规模训练成为可能。

当前LLM都使用Decoder-only架构（只有Transformer的解码器部分），通过Causal Mask确保只能看到前面的Token。训练目标是Next Token Prediction——预测下一个Token，看似简单但要求模型习得深层语言和世界知识。2025年的重要趋势是MoE架构（如DeepSeek V3），用大量参数存储知识但只激活一小部分来计算，大幅降低了推理成本。

追问准备：

---

学习资源 (2025-2026)

入门理解

深入理解

动手实践

架构师视角

---

明日预告

Day 2: 训练过程深度 — Pre-training / SFT / RLHF / DPO

Day 1: 理解了Transformer这个"引擎"怎么工作
Day 2: 理解这个引擎是怎么"制造"出来的

核心问题：
  → Pre-training到底在学什么？损失函数是什么？
  → SFT的数据长什么样？为什么只需要几万条？
  → RLHF vs DPO vs GRPO 的原理和选择
  → Constitutional AI（Anthropic的方法）
  → 为什么DeepSeek R1用RL就能产生推理能力？
  → 训练成本估算：从数据到GPU到美元

准备：
  → 回顾Day 1的三阶段训练概述
  → 阅读DeepSeek R1论文的Section 2（GRPO方法）

---

今日总结

┌──────────────────────────────────────────────────────┐
│  Day 1 核心收获                                       │
├──────────────────────────────────────────────────────┤
│                                                      │
│  1. Transformer = Self-Attention + FFN + 残差连接     │
│     → QKV计算注意力权重                               │
│     → Multi-Head从多维度关注                          │
│     → RoPE编码位置信息（2025-2026主流）                │
│                                                      │
│  2. LLM = Decoder-only Transformer × N层             │
│     → Next Token Prediction训练目标                   │
│     → Pre-training → SFT → Alignment三阶段           │
│     → Scaling Laws指导模型设计                         │
│                                                      │
│  3. 2025-2026趋势                                    │
│     → MoE架构崛起（DeepSeek V3, Qwen 3）             │
│     → 推理模型成为新维度（o3, R1, Extended Thinking）  │
│     → GQA/MLA优化注意力效率                           │
│     → 开源与闭源差距缩小                               │
│                                                      │
│  4. PM/架构师关键决策点                                │
│     → Token效率影响成本（中文产品选Qwen更划算）         │
│     → KV Cache决定上下文可行性                         │
│     → 推理模型需要异步架构设计                          │
│     → 分层路由降低80%推理成本                          │
│                                                      │
│  学习耗时：约 6 小时                                   │
│  下一步：Day 2 训练过程深度                             │
│                                                      │
└──────────────────────────────────────────────────────┘