背景

从年初 R1 火起来以后，看到了很多关于智能本质的讨论，目前大部分讨论似乎都认为：语言才是智能的基础，是通往 AGI 的路径。

比如张小珺[1-3]今年采访了很多大佬，就有两个这样的例子：

• 杨植麟[1]：认为在现有范式下，多模态能力往往难以提升模型的“智商”，甚至可能损伤模型已有的语言智能。他在接受采访时提到：“如果你想给模型加多模态能力，你需要确保这个多模态能力不要损伤它的‘脑子’。多模态能做到不损伤已经很好了。”他指出，在多模态模式下希望模型和纯文本模式共用一个“大脑”——也即多模态部分应尽量借用文本模型已有的智力，而不是开启另一套全新参数，否则可能丢掉原来文本部分学到的能力。

• 姚顺雨[2]也强调语言在通向通用智能方面更具潜力。他起初从事计算机视觉研究，但后来直觉告诉他语言才是更核心、更有潜力的方向，因此读博后转向了语言模型的研究。他指出，语言是人类为了实现认知泛化而发明的最重要工具，具有生成和推理的闭环特性，这使其成为构建通用智能系统的关键媒介。

不过还是有一些其他的观点，认为多模态能力的潜力可能被训练范式所限制，而非多模态本身毫无助益。例如阶跃星辰的张祥雨[3]就提到：

• 图文数据效果不好的原因是噪声数据：如果简单用图文混合数据进行训练，但不解决思维链（CoT）推理或任务复杂度的问题，模型的学习可能是有害的。在缺乏正确推理指导的情况下，模型每一步可能得不到有效信息，产生错乱的梯度，训练效果要么毫无提升，要么甚至更糟。这与他在一个万亿参数多模态模型项目中的发现一致：模型规模增大后，其数学和逻辑推理能力不仅没有提升，反而在达到平台期后开始下降。原因在于模型倾向于跳步直接给出答案而非踏实推演，从而累积误差。简单扩大模型或混合数据并不能自然地融合视觉与文本能力，背后缺少关键环节。

• 图文推理的能力同样需要预训练的激活：例如，OpenAI 的 O3 模型在推理过程中能够将图像直接融入思维链，通过动态操作图像（旋转、裁剪等）来辅助解题，在视觉推理基准 V⋆Bench 上取得了 95.7% 的高准确率，刷新了多模态推理上限。令人意外的是，O3 所采用的一些方法（如对原图进行局部放大裁剪）看似原始，却在许多问题上效果很好。他认为：这可能是因为在海量预训练语料中，存在大量图像附带局部放大及文字解释的模式。例如在电子维修论坛中，经常有人上传一张设备照片提问“哪里出了问题”，回答者会圈出图片局部并放大，说明某个电容烧了等。模型在预训练中已经隐式学习了这种“先整体看图 → 再局部看图解释”的模式。因此，像 O3 那样在推理时按需裁剪图像，严格遵循了预训练语料中的分布模式，反而取得了出色效果。

针对这个问题，想写一些自己对这个领域的了解和看法。

Vision LM 的推理能力研究

在开始讨论前，我先对智商这个事情做一个定义：通常我们可以把模型的能力分为理解、推理、生成三种，我们认为其中推理能力是智商的表现。

Vision CoT

链式思维（CoT）是大模型提升复杂推理最早被证明有效的范式之一；其视觉扩展（Vision CoT / Visual CoT）在 2023 年起就开始出现。早期的工作以语言+图像作为输出，但是以CoT只会以文本给出，这个时候图像不参与推理的过程，图像带来的推理能力自然就无从谈起。

后来O3的兴起带火了一个新的方向：thinking with images，其核心思想：不要把“看图”当成一次性输入，而是让图像参与到逐步推理循环中，成为中间状态的生成与消费对象。也就是说图像开始参与了推理的过程，因此我们就从这里作为了解Vision LM推理能力的起点。

（下图是thinking with images的例子）

OpenAI O1 / O3 系列

OpenAI 在 GPT‑4 之后推出 o1 系列[4]，算是第一次验证了Test Time Scaling和推理能力的关系。更进一步的 O3 模型在 demo 中展示了新的模式：除了“会看图”理解，还会“用图思考”。推理过程中模型可以：

• 主动定位相关区域（放大公式、框选局部结构、旋转视角）；
• 将局部视觉观察嵌入后续思维链进行推理； O3 在视觉推理基准 V⋆Bench 上达到 95.7% 的成绩，也算是验证“显式把视觉纳入思维链”是可以提升推理能力的研究方向。

DeepEyes

DeepEyes[6] 应该是第一个开源再现“thinking with images”能力的项目。它不依赖额外人工 SFT，而是直接用 RL 激活模型的视觉逐步聚焦行为。模型可以按照：生成初始思维链 → 判断是否缺细节 → 自主调用“放大 / 裁剪”工具 → 将裁剪区域重新编码 → 继续推演。循环执行形成类似 O3 的效果，并且得到了验证：

准备对DeepSeek的开源项目整理一些文档，也顺便强化一下记忆，先从FlashMLA开始。

FlashMLA是DeepSeek开源的MLA算子实现，这个实现主要给inference decoding用的，Training和prefill应该是另外一个算子。

先拿下面的图表示一下MLA算子是在计算一个什么东西，这篇文章就不讲具体的推导了，反正这个算子大概就是下面的2个GEMM算子的融合。需要注意的是：

1. 这里矩阵K和矩阵V的共享一部分参数。
2. 图里只画显示了一个Query Head和一对KV Head的计算。在实际计算中还要num_kv_head和batch_size两个维度。
3. 两个GEMM中间其实还有一个sotfmax，不过这里可以通过online softmax算法把这块逻辑独立处理分块处理，所以不影响主流程。

Kernel的调用主要分两部分

1. 调用get_mla_metadata来计算一些metadata，用来优化kernel的执行
2. 调用flash_mla_with_kvcache进行计算

在进入调用前，先大概说一下FlashMLA计算的拆分逻辑。这块和FlashDecoding很像，并没有要求一个thread-block必须处理一个完整的sequence，而是通过一个负载均衡算法，把所有的sequence放到一起，然后拆分成一个个的sequence-block，然后每个thread-block就去处理分配给它的那些block的计算，最后再把这些thread-block的结果用合并，得到正确的输出。

大概是下面这个图的样子：

所以为了完成计算，第一步就是决定每个block需要处理哪些sub-sequence，也就是get_mla_metadata要完成的事情。

get_mla_metadata

先看get_mla_metadata具体提供了哪些元数据，我们从repo提供的测试代码入手，考虑最简单的情况(batch_size=128, query_sequence_len=1, mean_key_sequence_len=4096, MTP=1, num_kv_head=1, num_q_head=16, TP=1, hidden_NoRoPE_dim=512, hidden_RoPE_dim=64, varlen=False)。

# cache_seqlens = tensor([4096, 4096, ..., 4096], dtype=torch.int32),
#                         size=batch_size, value=sequence_len
# s_q=1 (query_sequence_len=1且MTP=1), h_q(num_q_head)=128 (TP=1=128/128) h_kv(num_kv_head)=1
# 基于这些配置，计算mla kernel的metadata
tile_scheduler_metadata, num_splits = get_mla_metadata(cache_seqlens, s_q * h_q // h_kv, h_kv)

因为这里我们是在测试decoding步骤，所以有query_sequence_len=1，可以看到三个入参：

1. kv cache的大小
2. 类似GQA的Group数量，这个参数表示每个kv head对应多少个query head。
3. kv head的数量

get_mla_metadata会根据GPU中SM的数量和要处理的数据的大小，给每个SM分配任务。这个注意get_mla_metadata_kernel的参数为<<<1, 32, 0, stream>>>，因此所有计算会在1个warp中完成。

3月底整理了一个关于经典Paged Attention算法的ppt, 想起这个几年没写过的blog，把PPT改成一篇文章证明我还活着(-_-)。

vLLM 的 Paged Attention

开始前先说明一下，vLLM里的Paged Attention Kernel是有好几个不同的版本的，大概是下面这样子：

vLLM早期版本：

• Prefilling -> Flash Attention的flash_attn_varlen_func
• Dedocding -> 自己实现的Paged Attention
  • paged_attention_v1 : 用于比较短的sequence
  • paged_attention_v2 : 用于不想用v1的情况 :)

源码大概是这样的：

    # NOTE(woosuk): We use a simple heuristic to decide whether to use
    # PagedAttention V1 or V2. If the number of partitions is 1, we use
    # V1 to avoid the overhead of reduction. Also, if the number of
    # sequences or heads is large, we use V1 since there is enough work
    # to parallelize.
    # TODO(woosuk): Tune this heuristic.
    # For context len > 8192, use V2 kernel to avoid shared memory
    # shortage.
    use_v1 = (max_seq_len <= 8192 and (max_num_partitions == 1 or num_seqs * num_heads > 512))

vLLM 最新版本就已经全部转向Flash Attention， 用cutlass实现了。

背景

多目标优化中有一个很常见的跷跷板问题，就是说在训练时，多个目标会相互影响，导致震荡—你降我升，我升你降。有时间还会出现Nan的结果，需要很仔细的调参测试+清洗数据才能训练出一个理想的模型。

针对这种问题，自然就有了一些尝试，比如从帕累托最优的角度寻找优化方向（阿里PEA），修改模型结构使Shared部分存储更泛化的信息（腾讯PLE）。不过这两个写的人都挺多了，就写一下Google Small Towers的这篇文章吧。

主要问题讨论

文章首先讨论了两个问题：

1. Over-parameterization对多任务模型的适用性

我们都知道over-parameterization对单任务模型是有价值的，那边对多任务模型是否成立？

这里以将多个目标的线性组合作为优化目标的例子，认为over-parameterization能够帮助处理各任务优化目标之间的冲突问题（既减少跷跷板问题的出现）。

2. 大型模型和小型模型的多目标学习表现对比

通过实验对比了大型模型和小型模型进行多目标学习中的不同表现。

实验中，不论是增加任务相关结构的复杂度，还是增加任务共享结构的复杂度，Pareto frontier都会呈现先变好在变差的趋势。

因此，文章认为over-parameterization并不利于多目标学习中的共享性，进而伤害了多目标学习中的泛化能力。因此，在多目标学习中，模型大小实质上是对模型有效性和泛化能力的一种平衡。

To summarize our insights, for a multi-task learning model, small models benefit from good multi-task generalization but hurts Pareto efficiency; big models theoretically have better Pareto efficiency but could suffer from loss of generalization.

Under-parameterized Self-auxiliaries模型结构

文章提出了under-parameterized self-auxiliaries的模型结构：

首先假设模型的共享方式是所有任务共享最下面的表示层（Hard Sharded，MMOE这种，PLE就不行）,既对任务t，有：

$$f_{t}(x; \theta_{sh}, \theta_{t})=f_{t}(h(x; \theta_{sh}); \theta_{t}), \forall t$$

其中 $\theta_t$ 是任务相关的参数， $\theta_sh$ 为共享参数， $h(x;\theta_sh)$ 既为共享的表示层输出。

NPE(NullPointerException)是一个很烦人的问题，这里简单列举了一些语言中对NPE的处理。

1. 通过语法标记进行检查

Kotlin

Kotlin要求可以为null的变量必需在定义时声明，同时在读取该类型变量属性时必须进行空值判断。例：String 和 String?

var a: String = "abc"
a = null // compilation error, a can not be null

var b: String? = "abc"
b = null // ok

val l = b.length // compiler error: variable 'b' can be null
val l = if (b != null) b.length else -1 // ok

Jetbrains annotations for Java

IntelliJ IDEA提供了一些工具，比如可以对@NotNull的参数进行检查，当出现null赋值时在IDE中会给出提示。

import org.jetbrains.annotations.NotNull;
import java.util.ArrayList;

public class Test{
    public void foo(@NotNull Object param){
        int i = param.hashCode();
    }
    
    public void test(){
        foo(null); // warn in IntelliJ IDEA
    }
}

（类似的，FindBugs也提供了@Nonnull注释，用于检查）