你肯定跟 ChatGPT、DeepSeek 这类大模型聊过天。
在输入框里打完问题，点一下发送，它就开始一个字一个字往外蹦。
有没有想过，这一行字蹦出来的背后，它到底在干什么？
如果只看语言模型最核心的生成机制，它做的事情其实非常简单：
根据前面的内容，预测下一个 token。
它猜的 token，到底是什么
大模型吐出来的每一个片段，在圈里叫 token。
全国科技名词委在 2026 年已经推荐把它译作"词元"，目前还在推广试用阶段。
你可以把它理解成模型处理文本时使用的一种基本单位——有时候是一个字，有时候是一个词的一部分，也可能是完整的词、标点等。
它生成的逻辑，可以理解成一个不断把新生成的 token 接到上下文末尾的循环。
你输入的提示词，会先作为起点整体送进模型。
模型根据这段上下文计算出下一个 token；
这个新 token 加入上下文后，模型再基于更新后的上下文预测下一个 token，一直持续到它输出特殊标记 EOS（End of Sequence，序列结束符），或者触发最大输出长度等停止条件。
所以你看到的"流式输出"，本质上就是它一边算、一边把猜到的 token 往外扔。
一次典型推理，其实分两步
你按下回车那一刻，模型做的第一件事，是把你整段提问一次性读进去、算一遍。
这个阶段叫 Prefill（预填充）。
Prefill 会把整个输入序列完整地跑一遍模型，在各层计算对应的 Key、Value，并把它们缓存下来，这就是 KV Cache（Key-Value Cache，键值缓存）。
之后模型才进入 Decode（解码）阶段：
一个 token 一个 token 地往外生成。
每生成一个新 token，模型都会计算它对应的 Key、Value，并把它们追加到 KV Cache 中；
同时复用之前已经缓存的 KV，不需要把历史内容重新算一遍。
所以你眼睛看到的"一个字一个字往外蹦"，主要发生在 Decode 阶段。
这也顺带解释了几个现象：
输入越长，Prefill 通常需要处理的计算量越大，首 token 延迟（Time to First Token，TTFT）也可能随之增加；
进入 Decode 后，模型才会持续一个 token 一个 token 地生成。
而 vLLM、SGLang 这些推理引擎，也会围绕 KV Cache 管理、批处理、调度和计算优化等做大量工作，目标就是提高吞吐、降低延迟，并尽可能提高显存利用率。
为什么现在主流大模型多是 Decoder-only
现在的大语言模型，普遍采用 Decoder-only 架构。
它的技术源头，可以追溯到 2017 年 Google 团队提出的 Transformer 架构。
当年的 Transformer 是 encoder-decoder 两截结构：
前半截 encoder 负责"读明白输入"，后半截 decoder 负责"生成输出"。
后来做大规模文本生成的人发现，对于"根据前面的内容预测下一个 token"这件事，并不一定需要完整的 Encoder-Decoder 结构。
于是 GPT 一类模型采用了更简单的 Decoder-only Transformer:
保留 Decoder 里带因果掩码的自注意力机制，去掉依赖 Encoder 输出的 Cross-Attention。
因果掩码做的事很简单:
算注意力时,把当前位置之后的 token 全遮住。
模型预测第 N 个 token 时,能参考的只有前面的内容。
训练时它看不到后面的答案,只能老老实实学预测;
推理时后面的 token 本来就还没生成,遮住正好符合实情。
所以，GPT 这一类主流生成式语言模型，本质上采用的是 Decoder-only 的 Transformer 架构。
打个比方：
encoder 像帮厨，负责把食材理解清楚；
decoder 像掌勺，负责把菜炒出来。
生成式模型要的是后者，帮厨那一步它不需要。
它凭什么猜出下一个 token
你可能会问:
它怎么就知道"床前明月光，疑是"后面该接"地上霜"?
其实它没在"回忆"答案，每个时刻都在算一笔账——算每个候选 token 接下来出现的概率。
模型会先对词表里的每一个候选 token 算一个分数，叫 logit。
这个词表有多大？
现在很多主流模型的词表规模，都在十万量级甚至更大。
不同模型的 tokenizer 差别不小，不能一概而论。
然后靠 softmax 函数，把这一堆原始打分压成一个概率分布：
所有候选 token 的概率加起来正好等于 1。
接下来怎么选？
两条路。
一种是贪心，直接拿概率最大的那个 token——最稳，但也最没惊喜。
另一种是按概率随机抽：
概率越高的 token 越容易中奖，但不保证每次都是票数最多的那个胜出。
所以在开启随机采样的时候，你同样的问题问两遍，答案可能不太一样。
实际采样时，还可以通过 temperature、top-k、top-p 等参数控制随机程度。
这套本事，到底是从哪来的
它能猜对，是因为发布前已经在海量数据上"预训练"过了。
典型的预训练，是从随机初始化的模型开始，在海量文本数据上不断训练。
许多现代大模型的预训练数据已经达到万亿 token 甚至更高的规模，训练周期长、计算成本高，是非常重的工程。
那你在企业里做的"微调"又是什么？
微调是在预训练模型的基础上继续训练，让模型更贴合你的业务。
它用到的数据量通常比预训练小得多，有些业务场景用几千条高质量数据就可以开始尝试，具体需要多少，则取决于任务难度、数据质量和训练方式。
也正因为这个量级差，大家才把这一步叫作"微调"，而不是重新预训练。
| 维度 | 预训练 | 微调 |
|---|---|---|
| 数据量 | 万亿 token 甚至更高规模 | 远小于预训练 |
| 目标 | 学会通用的语言能力 | 适配特定任务或领域 |
| 训练过程 | 从随机初始化开始学习 | 在已有模型基础上继续更新 |
| 谁来做 | 通常需要大规模算力团队 | 普通团队也可以根据场景开展 |
回到岗位：大模型工程师要会什么
聊完原理，回到最实际的问题——做这一行，到底得具备什么。
如果想往大模型工程方向发展，通常需要同时补两类能力：
一类是把模型跑起来、用起来的工程能力；
另一类是理解模型训练、微调和推理优化的原理。
工程落地这一侧，你得把模型部署到推理引擎上，比如 vLLM、SGLang，让它真正跑起来。
部署好之后，再基于它做业务侧的二次开发。
模型与优化这一侧，你得懂微调怎么调、量化和蒸馏怎么把模型压小提速，甚至了解模型是怎么从 0 训练出来的。
现在很多模型采用 MoE（Mixture of Experts，多专家混合）架构。
它本身属于模型架构的一部分，但也会直接影响推理时的计算、显存和通信，因此也是大模型工程师需要理解的内容。
所以你看，大模型工程师远不止调调 API 那么简单。
懂应用，能把模型落地；
懂原理，才知道它为什么这样答、哪里能优化。
这两手，缺一不可。
