阿甘的博客 | Arganzheng's Blog

Transformer 与 LLM（09）：系列总结与通关自测

Transformers and LLMs for Infrastructure Engineers: Series Recap and Final Self-Test

八篇正文回答了一个问题：把一个 LLM 当作计算对象，它的每一步算多少、读多少、存多少、传多少。前两篇从 config.json 算出参数量、FLOPs 与字节数，建立 Roofline 上的成本模型；第三到五篇看三种结构改动（GQA / MLA、RoPE 与长上下文、MoE）各改了成本表的哪一格；第六、七篇看数值与方法（浮点格式、量化、投机解码、LoRA）如何改变每个数占几个字节、每步产出几个 token；第八篇把输入换成图片，看 token 数不再由 tokenizer 决定时账怎么变。八篇合起来，是《Transformer 与 LLM：结构、算量与数值》那张成本表的推理侧与结构侧。本文不讲新内容，做三件事：把八篇压成一张表与八段回顾，把贯穿八篇的几条线拎出...

Posted by arganzheng | April 9, 2026

Transformer 与 LLM（08）：多模态：vision encoder 的算量与 image token 的 KV 代价

Multimodal LLMs: The Cost of Vision Encoders and Image Tokens

前七篇讨论的模型只有一种输入：token id。它查一张 embedding 表得到向量，然后进入 decoder。这个前提决定了前面所有的账——参数量、FLOPs、KV cache——都只与 token 数有关，而 token 数由 tokenizer 决定。多模态模型打破了这个前提。一张图片不经过 tokenizer，它先经过一个独立的神经网络（vision encoder，通常是 ViT），被切成几百到几千个向量，再由一个连接层（connector）变成 decoder 认得的 token embedding，插进 prompt 的对应位置。于是出现了三笔新账：encoder 自己的算量、connector 决定的 token 数、以及这些 token 进...

Posted by arganzheng | April 9, 2026

Transformer 与 LLM（07）：量化、投机解码与 LoRA

Quantization, Speculative Decoding and LoRA: Three Ways to Reshape the Computation

前六篇把一个 Transformer 拆成了四组变量：参数量 \(N\)、每 token 的 FLOPs、每步要搬的字节数、每 token 的 KV cache。这些变量由结构决定——层数、hidden、GQA 的组数、专家数——一旦 config.json 定下来，它们就定下来了。本篇讲的是三种不改结构、只改计算形态的方法。它们分别攻击前面算出的三个成本项：量化减少权重（和 KV cache）的字节数，攻击的是 decode 每步要搬的 16 GB；投机解码用一次前向验证多个 token，攻击的是 decode 每步只产出一个 token 的串行形态； LoRA 把可训练参数从 \(N\) 降到 \(N\) 的千分之几，攻击的是训练状态每参...

Posted by arganzheng | April 8, 2026

Transformer 与 LLM（06）：浮点格式、数值稳定性与混合精度

Floating-Point Formats, Numerical Stability and Mixed Precision

前五篇算了大量的字节数：Llama-3-8B 的权重 16.06 GB、KV cache 每 token 128 KiB、decode 一步至少搬 16 GB。所有这些数字都默认”每个数占 2 字节”，也就是 BF16。这一篇把镜头再推近一层，从”每个数占几个字节”进入”这几个字节里到底存了什么”，回答一个在训练和推理系统里都绕不开的问题： BF16 的相对精度只有 FP16 的 1/8，为什么它反而成了训练的默认格式？1 把它同时用在权重更新上会出什么问题？2 一、总览：从”占几个字节”到”字节里存了什么” 1. 本文的写法与约定这个问题的答案不需要任何”经验”，只需要把浮点数的定义写出来、把几个真实的量级代进去。本篇的写法和前几篇一样：公式 →...

Posted by arganzheng | April 7, 2026

Transformer 与 LLM（05）：MoE 的路由、激活参数量与通信形态

Mixture of Experts: Routing, Active Parameters and Communication Patterns

前四篇讨论的都是 dense 模型：每个 token 经过每一层时，会用到这一层的全部权重。参数量、每 token 算量、每步 decode 的权重读取量，三者之间只差一个常数——参数量 \(N\) 对应每 token \(2N\) FLOPs，对应每步读 \(N \times \text{bytes/elem}\) 字节。混合专家（Mixture of Experts，MoE）把这三个数拆开了。DeepSeek-V3 的技术报告里写着”总参数 671B，每 token 激活 37B”，从算量看它比 Llama-3-70B 便宜一半，但实际部署时它需要几十张 GPU 组成的专家并行集群，而 70B 一台 8 卡机器就能跑得很好。本篇要回答的核心问题是： ...

Posted by arganzheng | April 6, 2026

Transformer 与 LLM（04）：位置编码与长上下文

Positional Encoding and Long Context: RoPE Wavelengths, Extrapolation and Cost

前三篇把一个 Transformer 拆成了参数量、算量、访存量和 KV cache 四个数字。这些数字里有一个变量一直被当作常数处理：上下文长度 \(s\)。第二篇算 prefill 时取 \(s = 8192\)，第三篇算 KV cache 时取 \(s = 131072\)，但都没有回答两个问题：模型凭什么知道一个 token 在第几个位置？以及，一个模型能处理的上下文长度到底由什么决定？这两个问题在结构上由同一个部件回答——位置编码。它在参数量表里几乎不占位置（RoPE 一个参数都没有），在算量表里也可以忽略（一次逐元素乘加），却决定了”上下文长度”这个对 Infra 成本最敏感的维度的上限。上下文长度同时进入 KV cache 的一次项和 attent...

Posted by arganzheng | April 5, 2026

Transformer 与 LLM（03）：Attention 变体与 KV cache

Attention Variants and the KV Cache: Deriving MHA, GQA, MQA and MLA

上一篇把一次前向拆成了”权重项”和”上下文项”两部分：权重项每 token 每参数 2 FLOPs，与上下文长度无关；上下文项只来自 attention，随序列长度 \(s\) 线性增长（decode）或平方增长（prefill）。这一篇专门讲 attention，因为它是 Transformer 里唯一成本随上下文增长的部分，也是过去几年结构改动最集中的地方。 MHA、MQA、GQA、MLA 四种结构，做的是同一件事的不同取舍：减少每个 token 的 KV cache 字节数，同时尽量不损失质量。顺着这条线，本篇要回答总纲里提出的问题： DeepSeek-V3 有 128 个 attention head、61 层，KV cache 却...

Posted by arganzheng | April 4, 2026

Transformer 与 LLM（02）：前向的算量与访存量

FLOPs, Bytes and Roofline: Prefill versus Decode

上一篇把一个 decoder-only Transformer 拆到了能数出每一个参数的粒度。结论可以压缩成一个公式： \[N \approx L \cdot \left[ d \cdot (d + 2 d_{kv} + d) + 3 \cdot d \cdot d_{ff} \right] + 2 \cdot V \cdot d\] 其中 \(d_{kv} = n_{kv} \cdot d_{head}\)。代入 Llama-3-8B（\(d = 4096\)，\(L = 32\)，\(n_{kv} = 8\)，\(d_{head} = 128\)，\(d_{ff} = 14336\)，\(V = 128256\)）：每层 attention 41.94M、F...

Posted by arganzheng | April 3, 2026

Transformer 与 LLM（01）：Transformer 解剖与参数量

Transformer Anatomy and Parameter Count: From config.json to 8.03B

做推理系统、训练基础设施或 kernel 的工程师，迟早会被问到这样的问题：这个模型有多少参数？一张 80 GB 的卡放得下吗？某个 GEMM 的 \(m, k, n\) 是多少？为什么 Llama 的 FFN 中间维度是 14336 这样一个看起来不整的数？这些问题的答案全部藏在一个几十行的 config.json 里，不需要下载权重，也不需要运行代码。本篇要建立的是整个系列的分析对象：一个 decoder-only Transformer 里到底有哪些矩阵、每个矩阵的形状由哪个超参数决定、把它们加起来等于多少。它不讲 attention 为什么有效，也不讲训练方法，只把结构拆到能数出每一个参数的粒度。全篇的核心问题是：给你一个 Llama 式 de...

Posted by arganzheng | April 2, 2026

Transformer 与 LLM：结构、算量与数值（总纲）

Transformers and LLMs for Infrastructure Engineers: Architecture, Arithmetic and Numerics

内容简介《Transformer 与 LLM：结构、算量与数值》是一组共八篇的系列文章，面向不训练模型、但要为模型搭建训练与推理系统的工程师，以及想知道自己的模型在硬件上”花多少钱”的算法工程师。它讲大语言模型的成本结构：每一层做多少次乘加、读多少字节、存多少状态，这些数字由哪些超参数决定，以及各种结构上和数值上的改动如何改变这些数字。同一张成本表的训练侧——tokenizer 与词表、算力怎么分给参数与数据、15T token 从哪来、超参表里的数字从哪来——是紧接着的系列《预训练：从 tokenizer 到训练配方》的内容。它回答的问题是： Infra 工程师不训练模型，但必须知道自己在优化什么：这个模型的每一步算多少、读多少、存多少？ In...

Posted by arganzheng | April 1, 2026

Arganzheng's Blog