INCOMING TRANSMISSION

DeeSeek-OCR 简介 当前的大型语言模型（LLMs）在处理长文本时面临显著的计算挑战，其开销随序列长度呈二次增长。本文探索一种潜在的解决方案：将视觉模态作为高效的文本信息压缩媒介。 单张包含文档文本的图像，能够用显著更少的 token 表达丰富信息，相比等量的数字文本更为紧凑；这表明，通过视觉 token 进行光学压缩有望实现更高的压缩比。 本文关注视觉编码器如何提升 LLM 在处理文本信息时的效率，而非人类本就擅长的基础 VQA 任务 当前主流 VLM 视觉编码器的问题 第一类是以 Vary 为代表的双塔（dual-tower）架构，通过并行的 SAM 编码器来提升高分辨率图像处理时的视觉词表参数规模。该方法虽然在参数量与激活内存上更可控，但也存在显著缺点：需要对图像进行两套预处理，增加了部署复杂度；同时在训练中使编码器管线的并行化变得困难。 第二类是以 InternVL2.0 为代表的切片（tile-based）方法，通过将图像划分为小块并行处理，在高分辨率场景下降低激活内存。尽管这种方法能够处理极高分辨率，但由于其原生编码器分辨率通常较低（低于...

随着LLM时代的到来，学术界对于优化器的研究热情似乎有所减退。这主要是因为目前主流的AdamW已经能够满足大多数需求，而如果对优化器“大动干戈”，那么需要巨大的验证成本。因此，当前优化器的变化，多数都只是工业界根据自己的训练经验来对AdamW打的一些小补丁。 不过，最近推特上一个名为“Muon”的优化器颇为热闹，它声称比AdamW更为高效，且并不只是在Adam基础上的“小打小闹”，而是体现了关于向量与矩阵差异的一些值得深思的原理。本文让我们一起赏析一番。 算法初探 Muon全称是“MomentUm Orthogonalized by Newton-schulz”，它适用于矩阵参数 \(\boldsymbol{W}\in\mathbb{R}^{n\times m}\) ，其更新规则是 \[\begin{aligned} \boldsymbol{M}_t =&\, \beta\boldsymbol{M}_{t-1} + \boldsymbol{G}_t \\[5pt] \boldsymbol{W}_t =&\, \boldsymbol{W}_{t-1} - \eta_t...

MiniCPM-V系列是面壁智能推出的小参数量的开源多模态大模型，没有超过9B的版本。主打小而强。 MiniCPM-Llama3-V 2.5 这版有论文了，详细写。应该也是2.6的基础。 这一版在 OpenCompass 评估中优于强大的 GPT-4V-1106、Gemini Pro 和 Claude 3。 能力 支持最高1.8M像素的高分辨率图像输入（例如1344*1344），支持任意长宽比图像 强大的OCR，OCRBench 上优于 GPT-4V、Gemini Pro 和 Qwen-VL-Max，支持table-to-markdown 可信，基于RLAIF-V技术做了对齐，减少幻觉，更符合人类喜好 多语言，基于VisCPM技术，支持30多种语言 系统地集成了一套端侧部署优化技术 模型架构 基本架构 三部分：visual encoder, 压缩层, LLM visual encoder：SigLIP SoViT-400m/14 压缩层：单层交叉注意力 LLM：每一代都不同 Adaptive Visual Encoding...

11. 盛最多水的容器 题目 给定一个长度为 n 的整数数组 height 。有 n 条垂线，第 i 条线的两个端点是 (i, 0) 和 (i, height[i]) 。 找出其中的两条线，使得它们与 x 轴共同构成的容器可以容纳最多的水。 返回容器可以储存的最大水量。 说明： 你不能倾斜容器。 示例 1： 输入：[1,8,6,2,5,4,8,3,7] 输出：49 解释：图中垂直线代表输入数组 [1,8,6,2,5,4,8,3,7]。在此情况下，容器能够容纳水（表示为蓝色部分）的最大值为 49。 示例 2： 输入：height = [1,1] 输出：1 提示： n == height.length 2 <= n <= 10 5 0 <= height[i] <= 10 4 题解 在初始时，左右指针分别指向数组的左右两端，它们可以容纳的水量为 \(min(1,7)∗8=8\) 。 此时我们需要移动一个指针。移动哪一个呢？直觉告诉我们，应该移动对应数字较小的那个指针（即此时的左指针）。这是因为，由于容纳的水量是由 两个指针指向的数字中较小值∗指针之间的距离...

简介 在深度学习模型（尤其是 Transformer 架构）的训练中，输入数据的长度通常需要保持一致。如果直接输入大量短文本，就需要用大量无意义的占位符（Padding）来补齐长度，这会极大地浪费 GPU 的计算资源。为了最大化计算效率，目前基本主流的训练框架里都会加入 数据打包（Data Packing） 的逻辑，本文以 lmms-engine 中的操作为例，具体查看实际训练时对数据packing操作以及 use_rmpad 消除所有padding计算的逻辑 Packing Dataset 如下 Dataset 代码所示，这段代码核心目标是： 在不超过预设最大长度（ packing_length ）的前提下，尽可能多地将短样本塞进同一个批次（Batch）中。 这种做法带来了两个显著的好处： 提升计算效率 ：减少了 Padding Token 的数量，让 GPU 的每一次矩阵乘法都作用在真实有效的数据上。 稳定训练过程 ：每个 Batch 的有效 Token 数量更加一致，有助于梯度的稳定 if self.config.packing: # Reset index at...

泊松分布 日常生活中，大量事件是有固定频率的。 某医院平均每小时出生3个婴儿 某公司平均每10分钟接到1个电话 某超市平均每天销售4包xx牌奶粉 某网站平均每分钟有2次访问 它们的特点就是，我们可以预估这些事件的总数，但是没法知道具体的发生时间。已知平均每小时出生3个婴儿，请问下一个小时，会出生几个？ 有可能一下子出生6个，也有可能一个都不出生。这是我们没法知道的。 泊松分布就是描述某段时间内，事件具体的发生概率。 \[P(N(t)=n)=\frac{(\lambda t)^n e^{-\lambda t}}{n!}\] 上面就是泊松分布的公式。等号的左边， \(P\) 表示概率， \(N\) 表示某种函数关系， \(t\) 表示时间， \(n\) 表示数量，1小时内出生3个婴儿的概率，就表示为 \(P(N(1) = 3)\) 。等号的右边，参数λ是单位时间（或单位面积）内随机事件的平均发生率。 接下来两个小时，一个婴儿都不出生的概率是0.25%，基本不可能发生。 \[P(N(2) = 0) = \frac{(3 \times 2)^0 e^{-3 \times 2}}{0!}...

基本概念 方向导数：是一个数；反映的是 \(f(x,y)\) 在 \(P_0\) 点沿方向 \(v\) 的变化率。 偏导数：是多个数（每元有一个）；是指多元函数沿坐标轴方向的 方向导数 ，因此二元函数就有两个偏导数。 偏导函数：是一个函数；是一个关于点的偏导数的函数。 梯度：是一个向量；每个元素为函数对一元变量的偏导数；它既有大小（其大小为最大方向导数），也有方向。 方向导数 反映的是 \(f(x,y)\) 在 \(P_0\) 点沿方向 \(v\) 的变化率。 例子如下： 题目 设二元函数 \( f(x, y) = x^2 + y^2\) ，分别计算此函数在点 \((1, 2)\) 沿方向 \(w=\{3, -4\}\) 与方向 \(u=\{1, 0\}\) 的方向导数。 解： 由于 \(w\) 不是单位向量，因此首先应对其进行单位化： \[v = w^0 = \frac{w}{|w|} = \left\{ \frac{3}{5}, -\frac{4}{5} \right\}\] 计算函数增量： \[\begin{aligned} \therefore f(x_0 + tv_1,...

生成器 什么是生成器？ 通过列表生成式，我们可以直接创建一个列表，但是，受到内存限制，列表容量肯定是有限的，而且创建一个包含100万个元素的列表，不仅占用很大的存储空间，如果我们仅仅需要访问前面几个元素，那后面绝大多数元素占用的空间都白白浪费了。 所以，如果列表元素可以按照某种算法推算出来，那我们是否可以在循环的过程中不断推算出后续的元素呢？这样就不必创建完整的list，从而节省大量的空间，在Python中， 这种一边循环一边计算的机制，称为生成器：generator 生成器是一个特殊的程序，可以被用作控制循环的迭代行为，python中生成器是迭代器的一种，使用 yield 返回值函数，每次调用 yield 会暂停，而可以使用 next() 函数和 send() 函数恢复生成器。 生成器类似于返回值为数组的一个函数，这个函数可以接受参数，可以被调用，但是，不同于一般的函数会一次性返回包括了所有数值的数组，生成器一次只能产生一个值，这样消耗的内存数量将大大减小，而且允许调用函数可以很快的处理前几个返回值，因此生成器看起来像是一个函数，但是表现得却像是迭代器 python中的生成器...

列表和元组总结 列表和元组都是 一个可以放置任意数据类型的有序集合 ，他们有以下共同点 列表和元组中的元素可以任意，并且都可以嵌套。 列表和元组都支持索引，且都支持负数索引，-1表示最后一个元素，-2表示倒数第二个元素 列表和元组都支持切片操作 都支持in关键词 都可以使用 .index() 、 .count() 、 sorted() 和 enumerate() 等方法 两者之间的相互转换，list()和tuple() 但是他们也是有区别 列表是动态的，长度大小不固定，可以随意地增加、删减或者改变元素（mutable） 元组是静态的，长度大小不固定，无法增删改，想要对已有的元组做任何“改变”，就只能开辟一块内存，创建新的元组 列表和元组存储方式的差异 由于列表是动态的；元组是静态的，不可变的。这样的差异，势必会影响两者存储方式。我们可以来看下面的例子： >>> l = [1, 2, 3] >>> l.__sizeof__() 64 >>> tup = (1, 2, 3) >>> tup.__sizeof__() 48...

概述 python采用的是 引用计数 机制为主， 标记-清除 和 分代收集 两种机制为辅的策略。 引用计数 Python语言默认采用的垃圾收集机制是『引用计数法 Reference Counting 』，该算法最早George E. Collins在1960的时候首次提出，50年后的今天，该算法依然被很多编程语言使用。 『引用计数法』的原理是：每个对象维护一个 ob_ref 字段，用来记录该对象当前被引用的次数，每当新的引用指向该对象时，它的引用计数 ob_ref 加 1 ，每当该对象的引用失效时计数 ob_ref 减 1 ，一旦对象的引用计数为 0 ，该对象立即被回收，对象占用的内存空间将被释放。 它的缺点是需要额外的空间维护引用计数，这个问题是其次的，不过最主要的问题是它不能解决对象的“循环引用”，因此，也有很多语言比如Java并没有采用该算法做来垃圾的收集机制。 引用计数案例 import sys class A(): def __init__(self): '''初始化对象''' print('object born id:%s'...

梯度检查点（Gradient Checkpointing） 大模型的参数量巨大，即使将batch_size设置为1并使用梯度累积的方式更新，也仍然会OOM。原因是通常在计算梯度时，我们需要将所有前向传播时的激活值保存下来，这消耗大量显存。 还有另外一种延迟计算的思路， 丢掉前向传播时的激活值，在计算梯度时需要哪部分的激活值就重新计算哪部分的激活值，这样做倒是解决了显存不足的问题，但加大了计算量同时也拖慢了训练 。 梯度检查点（Gradient Checkpointing）在上述两种方式之间取了一个平衡，这种方法采用了一种策略 选择了计算图上的一部分激活值保存下来，其余部分丢弃，这样被丢弃的那一部分激活值需要在计算梯度时重新计算 。 下面这个动图展示了一种简单策略：前向传播过程中计算节点的激活值并保存，计算下一个节点完成后丢弃中间节点的激活值，反向传播时如果有保存下来的梯度就直接使用，如果没有就使用保存下来的前一个节点的梯度重新计算当前节点的梯度再使用。 Transformer框架开启梯度检查点非常简单，仅需在TrainingArguments中指定gradient...

问题表示 有很多概率问题，尤其是独立重复实验问题，如果用生成函数的方法来做，会显得特别方便。本文要讲的“随机游走”问题便是其中一例，它又被形象地叫做“醉汉问题”，其本质上是一个二项分布，但是由于取了极限，出现了很多新的性质和应用。我们先考虑如下问题： 考虑实数轴上的一个粒子，在 \(t=0\) 时刻它位于原点，每过一秒，它要不向前移动一格（ \(+1\) ），要不就向后移动一格（ \(-1\) ），问 \(n\) 秒后它所处位置的概率分布。 不难发现，这个问题跟二项分布是雷同的。如果把这个粒子形象比喻成一个“喝醉酒的人”，那么上面的走法就类似于一个完全不省人事的醉汉走路问题了。（当然，醉汉是在三维空间走路的，这里简单起见，只描述了一维的。）这是一个独立重复实验，每秒的行走可用函数描述为 \(\frac{1}{2}(z+z^{-1})\) ，于是 \(n\) 秒后的运动分布情况可以用 \[\frac{1}{2^n}(z+z^{-1})^n\] 来描述， \(z^i(i=-n,-n+1,\dots,n-1,n)\) 的系数表示粒子位于 \(i\) 的概率。 💡...