ksxz
LLMAI入门推理

代码定义结构，权重存储知识：一个例子看懂大模型如何推理

LZ AI Note··原文链接
收录于 2026/6/19 15:33:45

核心隐喻：代码是蓝图，权重是内容

文章用一个最小天气模型起手：

class WeatherModel:
    def forward(self, temp, humidity):
        return temp * self.w1 + humidity * self.w2 + self.b

这一段代码只规定了"这里需要三个数字（w1/w2/b）"，但不规定它们具体是多少。模型结构本身不包含知识，它只是一张：

  • 描述变量
  • 描述连接方式
  • 描述执行什么计算

的蓝图。训练完成后，得到 w1=0.7, w2=-0.3, b=5.0，这三个数字就是从大量历史数据里压缩出来的经验。

一次完整推理：代码 + 权重缺一不可

输入 温度=25, 湿度=80：

25 × 0.7 + 80 × (-0.3) + 5.0
= 17.5 - 24.0 + 5.0
= -1.5

整个过程：

  • 代码决定怎么算
  • 权重决定用什么数字算

load_state_dict 这种每天都在写的代码，本质上就是把权重文件里的数字按名字对应填进空蓝图。没有神秘计算、没有自动推理、没有重新训练。

为什么参数会爆炸

文章给出参数量增长的算式：

输入维度输出维度参数量
213（含偏置）
100010001,000,000
8192819267,108,864

单个 8192×8192 全连接矩阵就 6700 万参数。GPT 一层不止一个矩阵，几十到上百层叠起来后参数级别飙到 70B、700B、1750B。

nn.Linear(768, 768) 这一行十几个字符的代码，对应 768×768=58 万个浮点数。代码负责规格，权重负责内容。规格不会大，内容可以无限大。

同结构不同权重 = 不同模型

同一个 Transformer 架构
├─ 预训练权重 A → 英文模型
├─ 预训练权重 B → 中文模型
└─ 预训练权重 C → 代码模型

类比：

  • 模型结构 = 大脑
  • 模型权重 = 记忆

真正决定模型能力的不是结构文件，而是权重文件。

显存常驻：为什么不能从 SSD 现读

70B 模型 FP16 存储 ≈ 140GB。生成一个 token 几乎要访问所有层的权重，如果每次去 SSD（带宽 ~7GB/s）读，光读完整个模型就要 20 秒。用户期望几十 token/s，显存常驻是物理决定的，不是工程偏好。

实际数据流：

SSD → 内存 → 显存 → GPU 计算
（推理时权重常驻显存，输入数据不断流过权重矩阵）

CPU/GPU 分工

  • CPU = 指挥：告诉 GPU 执行第几层
  • GPU = 干活：真正算矩阵乘法

GPU 快不是单个核心强，而是能同时做大量相同计算（768 个输出之间互不依赖，可以拆给数千个计算单元并行）。

全流程总结

模型结构（蓝图）
    +
模型权重（经验/知识）
    ↓
加载到模型
    ↓
搬到 GPU 显存
    ↓
输入逐层流过
    ↓
输出结果

文章结尾点题：大模型之所以"大"，不是代码复杂，而是它记住了太多东西。

Zero 锐评

站得住的部分

  1. 核心隐喻选得准。"代码=蓝图、权重=填空"这个比喻是给非 ML 背景工程师入门时最有效的心智模型之一，比那些上来就讲 Transformer 多头注意力的科普文档强 10 倍。我自己第一次理解这个分界，是看 PyTorch 文档里 nn.Module 和 state_dict 的关系，作者用一个 3 参数模型把同样的洞察压缩成了 3 分钟阅读量。
  2. 参数爆炸的算式给得直观。nn.Linear(768, 768) → 58 万参数这种对比很有冲击力。前端工程师看 React 组件树时大概也有过类似感受：JSX 是蓝图，state 是数字，组件代码 100 行，但实际渲染时挂了 GB 级的虚拟 DOM 和缓存。
  3. 显存常驻的物理解释。SSD 7GB/s vs 140GB 模型 → 20 秒读一遍 vs 用户要几十 token/s 的对比，把"为什么不能从硬盘流式推理"这个常见疑惑用单位经济学讲清楚了。这个数字框架适合放进任何系统设计讨论：算清楚带宽、容量、延迟，再判断架构是否合理。

漏洞与短板

  1. 天气模型类比有滑坡风险。y = w1·x1 + w2·x2 + b 是线性回归，但 GPT 的本质能力来自非线性激活 + 注意力机制，没有这两者堆再多参数也是个大号线性模型。文章一句话带过"参数数量扩大了几十亿倍，但本质没有变化"——这句话严格来说是错的。从线性到 Transformer 中间隔着两个关键不连续点：激活函数（ReLU/GELU）和 self-attention 的动态权重。读者读完会以为大模型只是"更多 wᵢ·xᵢ"，对后续理解 RAG/Fine-tune/MoE 都会埋雷。
  2. "权重 = 知识压缩"是过度浪漫化。这个比喻对入门者有用，但实际权重里也压缩了大量噪音、偏见、训练语料的版权痕迹甚至幻觉模式。把权重等同于"经验"会让读者忽略 alignment、RLHF、数据治理这些真实问题。文章只讲了乐观的一面。
  3. 完全没提 KV cache。讲推理却跳过 KV cache 是个重大遗漏。生成一个 token 时并不是所有权重都重新参与计算，已生成 token 的 K/V 会被缓存，这是为什么"长上下文显存爆炸"的根本原因。错过这个点，读者无法理解为什么"32K 上下文比 4K 贵 10 倍以上"。
  4. CPU/GPU 分工讲得太浅。"CPU=指挥、GPU=干活"对了，但没解释为什么现代推理框架（vLLM、TensorRT-LLM）要做 continuous batching、PagedAttention 这些事——核心矛盾是 GPU 显存碎片化和请求异步，不是简单的"指挥-干活"分工。这部分对读者后续看推理优化博客没有帮助。
  5. 缺时间维度。文章默认所有参数同等重要，但实际上 LoRA、QLoRA、量化（GPTQ/AWQ）的存在恰恰说明：绝大多数参数是冗余的，4-bit 量化能把 140GB 砍到 35GB 而几乎不损失能力。这个事实和文章"参数越多记得越多"的叙事其实有张力，作者没处理。

给前端/工程师的实际启发

  1. "代码 vs 数据"的二分思维放到任何系统都成立。前端工程师每天写的 React 组件 = 蓝图，redux store / IndexedDB / 本地缓存 = 权重。真正决定线上行为的往往不是 src/ 目录，而是某个 JSON schema、配置中心的开关、或者用户 device 上的 IndexedDB 状态。下次定位"测试环境正常生产挂"的 bug 时，先问"是结构问题还是数据问题"。
  2. 包体积膨胀的本质和参数爆炸一致。前端 bundle 越来越大不是因为业务逻辑变复杂（业务代码增长是线性的），而是因为依赖里的硬编码资源、locale 文件、polyfill、图标库——和 LLM 权重一样，"内容"涨得比"规格"快得多。这是为什么 tree-shaking、lazy load、code splitting 才是真正的优化手段，而不是重写业务代码。
  3. "必须常驻"的成本计算适合做架构决策。任何"为什么要用 Redis 而不是直接查数据库"、"为什么要 CDN 不直接回源"的问题，本质都是"带宽 × 容量 ÷ 延迟"的算式。学会用 LLM 推理这套数字感（GB/s × GB ÷ s），可以直接迁移到前端性能优化、缓存策略、SSR 边缘部署的取舍上。
  4. 科普读物的边界要清楚。这种文章读 5 分钟能立住心智模型，但绝对不能作为 ML 工程决策的依据。要做 fine-tune、量化、推理服务时，看 vLLM、TensorRT-LLM 的官方文档比看 100 篇这种公众号文章更有价值。LLM 工程的硬核知识在 GitHub 和论文里，不在公众号里。
返回首页