大模型基础 ​

这一篇的目标很具体：能算清一次调用多少钱、能选对模型、能解释为什么它有时候胡说。Transformer 的公式不用背，但「为什么长上下文贵」必须能讲明白。

1. LLM 到底在做什么 ​

大模型本质是一个概率函数：给定前面的 token 序列，输出下一个 token 的概率分布。生成就是不断「采样一个词 → 接到序列后面 → 再预测」的循环。

输入: "今天天气真"
  ↓ 模型
概率: { "好": 0.62, "不错": 0.15, "热": 0.08, ... }
  ↓ 采样
输出: "好"
  ↓ 拼回输入
"今天天气真好" → 继续预测下一个

输入: "今天天气真"
  ↓ 模型
概率: { "好": 0.62, "不错": 0.15, "热": 0.08, ... }
  ↓ 采样
输出: "好"
  ↓ 拼回输入
"今天天气真好" → 继续预测下一个

这解释了三件事：

1. 为什么有随机性：它是采样，不是查表；temperature 调的就是采样策略。
2. 为什么会编：它优化的是「像不像人话」，不是「对不对」。
3. 为什么慢：每个 token 都要过一次模型，输出 500 token 就是 500 次前向（虽然有 KV Cache 复用）。

2. Token 与上下文窗口 ​

• 一个汉字 ≈ 1～2 token，一个英文单词 ≈ 1～1.3 token；
• 计费按 token，且输入和输出价格不同（输出通常贵 2～4 倍）；
• 上下文窗口是「输入 + 输出」的总和，输出也占额度。

为什么长上下文贵：注意力机制要对「每个 token 和之前所有 token」算相关性，计算量随长度平方增长（$O(n^2)$）。所以 128k 上下文的成本不是一个 16k 请求的 8 倍，而是高得多，延迟也明显变长。

工程含义：别把整个知识库塞进去，只放检索出来最相关的几段（见 03 RAG）。

3. Transformer 与注意力（够用版） ​

自注意力回答一个问题：当前这个词，应该多重关注前文的哪些词？

Query（我在找什么） × Key（每个词的标签） → 相关性分数
                    ↓ softmax 归一化
                对 Value（每个词的内容）加权求和

Query（我在找什么） × Key（每个词的标签） → 相关性分数
                    ↓ softmax 归一化
                对 Value（每个词的内容）加权求和

举例：「银行」这个词在「河边的银行」和「去银行取钱」里，注意力的落点完全不同 —— 这就是上下文消歧的原理。

必须知道的三个工程结论：

4. 采样参数：怎么让它稳定 / 发散 ​

经验：要稳定就 temperature=0 + 固定 seed，但注意很多厂商在 0 也不是完全确定的（并行计算导致浮点误差）。

5. 幻觉：成因与三层缓解 ​

认知：幻觉是「生成的本质」决定的，不可能消除。工程上追求的是「幻觉可发现、可拦截」，不是「没有幻觉」。

6. 模型选型：四个维度 ​

常见组合策略：

• 主力 + 兜底：主力模型做业务，备用模型（不同厂商）防故障；
• 大小搭配：简单意图识别/改写用小模型，复杂推理用大模型（见 07 工程化 的模型路由）；
• 国内外双活：合规与稳定性兼顾。

别只看榜单。用自己的 20 条真实 badcase 跑一遍，比任何 benchmark 都准。

7. 部署：API 还是自己跑 ​

7.1 推理引擎 ​

两个关键优化：

• PagedAttention：像操作系统分页一样管理 KV Cache，显存碎片大幅减少，吞吐提升数倍。
• 连续批处理（Continuous Batching）：一个请求生成完立刻腾出位置给新请求，而不是等整批结束。

7.2 量化 ​

7.3 显存怎么算（面试常问） ​

显存 ≈ 权重 + KV Cache + 激活值
权重   = 参数量 × 每参数字节数（fp16=2B，int8=1B，int4=0.5B）
KV Cache ≈ 2 × 层数 × 头数 × head_dim × 序列长度 × batch × 字节数

显存 ≈ 权重 + KV Cache + 激活值
权重   = 参数量 × 每参数字节数（fp16=2B，int8=1B，int4=0.5B）
KV Cache ≈ 2 × 层数 × 头数 × head_dim × 序列长度 × batch × 字节数

粗算经验：7B 模型 fp16 约 14GB 权重 + 余量 ≈ 16GB 显存；70B fp16 约 140GB，必须多卡或量化。

8. 成本与延迟模型 ​

一次调用的钱由三部分组成：

成本 = 输入token × 输入单价 + 输出token × 输出单价 (+ 缓存命中折扣)

成本 = 输入token × 输入单价 + 输出token × 输出单价 (+ 缓存命中折扣)

延迟分两段：

• 首 token 延迟（TTFT）：主要是 prefill（把整段输入算一遍），输入越长越慢；
• 后续 token 速度（TPOT）：decode 阶段，通常 20～80 tokens/s，输出越长总时长越久。

优化方向：砍输入（RAG 只放 Top-K）、限输出（max_tokens、要求简洁）、缓存（相同前缀的 prompt cache）。

9. 评测：别只看榜单 ​

落地顺序：先有 20 条 badcase 组成的最小评测集，再谈优化。没有评测集的「调优」都是玄学。

10. 速查表 ​