【LLM核心】计算范式

2017年，《Attention Is All You Need》正式提出 Transformer 架构，之后被openAI采用，开启了大模型时代，也顺带将英伟达送上来全球第一股王座。

由于Self-Attention 机制是伴随着Transformer发布而作为核心来实现的，人们很容易将两者混为一谈。

事实上，注意力机制是一个计算范式，Transformer是一个架构，是自注意力机制的计算容器和工程实现。自注意力机制并不是在 Transformer 论文里首次提出，但是 Transformer 把 Self-Attention 定义为核心算子，并系统化、标准化、形成完整架构。Transformer 设计的所有周边模块，都是为了保证注意力机制能够在训练中被收敛、泛化、高效运行。

所以，从第一性原理角度说，自注意力机制更核心，他解决过去神经网络难以并行计算、或者难以解决长程依赖的问题。所以，理解英伟达的股价、理解LLM的推理能力，应该从计算范式开始，而非Transformer架构。

一、价值定位

分层看贡献。

自注意力机制 (70%的功劳)

• 用O(N^2)计算量，来解决了长程依赖的根本问题，让模型能"看到"全局信息，这是LLM涌现能力的基础。也是openAI最初果断决策、抛弃循环神经网络和卷积神经网络的起点——大力必能出奇迹！

Transformer架构 (30%的功劳)

他解决的是计算相关的基础需求的工程化：堆叠方式、连接方式、归一化策略，本质上是一种配套实现。

• 残差连接 → 让模型推理可以堆到100+层
• 层归一化 → 训练稳定性
• FFN → 提供非线性变换和记忆容量
• 位置编码 → 补偿自注意力丢失的位置信息

如果只有Transformer架构，换成其他计算范式：工程上完全可行，但灵魂不够，最终表现出的推理能力上远不如自注意力。

二、能力来源

现在，举用户场景例子，来对比不同机制的处理方式，阐述采不采用自注意力机制的差别。

用户输入

如何优化计算生命周期?

RNN/(无自注意力)

逐词处理: "如何" → "优化" → "计算" → "生命" → "周期"

线性处理到"计算"时，只能依赖隐藏状态记忆前面的"如何优化"，还没看到后面的"生命周期"，必须猜测:"计算"可能是动词还是名词?

结果可能理解成：如何优化【进行计算的过程】，在生命周期中的应用

Transformer + 自注意力

自注意力机制采用的是所有token的全连接矩阵，并行处理，所有token同时可见。"计算"通过注意力机制的权重计算之后，可以同时看到:

• 左侧: "优化" (动词，大概率是面向对象而言)
• 右侧: "生命周期" （名词，恰恰是一个对象，他一般也需要一个对象修饰）

注意力得分计算

// "计算" 这个token的注意力分布
attention["计算"] = {
  "如何": 0.05,
  "优化": 0.15,
  "计算": 0.10,
  "生命": 0.35,  // 高分!
  "周期": 0.35   // 高分!
}

结果准确理解为："计算生命周期"是一个复合名词。

三、更典型的例子

用户输入

这个项目的**计算**生命周期管理比上个项目的**计算**资源调度更复杂

第一个"计算" (计算生命周期):

attention = "生命周期"(0.4) + "管理"(0.2)
// 于是理解为lifecycle相关概念

第二个"计算" (计算资源):

attention = "资源"(0.45) + "调度"(0.25)  
// 于是理解为计算资源相关概念，而非资源调度的计算

为什么RNN做不到？

RNN处理第二个"计算"时:

1. 无法同时对比两个"计算"的不同语境
2. 第一个"计算"已经在15个token之前，隐藏状态已经被中间的"管理比上个项目的"稀释。17个token尚且如此，又怎么能面向百万级的上下文窗口呢？这就是所谓的长程依赖问题。

而自注意力机制采取的是暴力穷举，将每一个token和其他所有token之间的相关性关系，进行全面计算，天然不存在长程问题！

四、算力成本

对于17个token，全量计算所有token之间的关系：O(n²) = O(17²) = 289次运算，但换来的是两个"计算"可以精确根据各自的上下文获得不同的语义表示，且不丢失任何语义关系，为进一步的深度推理保留了信息基础。

理解了这一点，就能理解一系列的现象：

• [并行计算]为什么英伟达的GPU一飞冲天？
• [能力极限]为什么LLM在范式层面，正在全面替代过去的各种神经网络？
• [内存和存储限制]为什么主流的大模型到目前为止，上下文窗口的规模还在10万Token级别？

这一切的底层逻辑，与所谓的Transformer架构无关，都是从解决长程依赖问题的自注意力机制开始。

五、对CML的启示

CML的价值同样可以在上述原理中找到答案。

在上述的例子里，如果CML能显式标记语义边界:

<token>计算生命周期<token>管理   🆚   <token>计算资源<token>调度

就可以在输入层，让模型用更少的注意力计算量，来达到同样的理解效果。因为结构化信息减少了歧义搜索空间。CML的机会不在于"替代自注意力"，而在于让自注意力"跳过"不必要的计算成为可能。

<token>计算生命周期<token>
// 在计算前，模型就知道这是整体,不需要内部token做O(3²)的注意力计算，节省算力,同时保持理解100%精度

这是工程优化，不是范式颠覆——但可能很实用。