GeMM 形状（`M × K</code>）</th>`	预计算</th>	查表</th>	累加</th>	缩放</th></tr></thead>
`320 × 3200</code></td>`	0.8%</td>	47.6%</strong></td>	25.0%</td>	26.6%</td></tr>
`128 × 8640</code></td>`	0.7%</td>	47.3%</strong></td>	25.5%</td>	26.4%</td></tr> </tbody></table> 对于并行推理，仅仅优化算术运算无法消除这个由查表主导的内存瓶颈。</p> 核心思路：一次查出 N 个结果</h2> 关键观察是：查表索引来自权重，而所有 token 共享同一组权重。</strong> 同一个权重索引适用于并行组中的每个 token，因此没有必要按 token 分别查表。</p> Vec-LUT 将查表单位从标量变为向量。它不再为每个 token 建一张表，而是为所有并行 token 构建一张统一的表</strong>。表中的每个条目不再存储单个标量结果，而是存储一个结果向量</em>，其中每项对应一个 token。这样，一个权重索引就能触发一次 `1→N</code> 查表，取回整个 token 组的结果。</p>` Vec-LUT：将按 token 执行的 1→1 查表转化为一次跨 token 的 1→N 查表。</figcaption> </figure> 由此产生的访问模式有三个优点：</p> 每个权重索引原本需要 N 次独立查表，现在只需一次向量查表。</li> 随机、分散的查表变为连续的向量读取，随后执行向量累加。</li> 内核不再依赖 ARM TBL</code> 或 x86 PSHUF</code> 等硬件查表指令，减少了对特定指令集架构（ISA）的依赖。</li> </ul> 在我们的延迟分解中，查表所占比例从 T-MAC 的 47%</strong> 降到了 1% 以下</strong>。</p> 让向量 LUT 真正实用</h2> 向量 LUT 在实践中能否高效，取决于两个工程细节。</p> 张量布局。</strong> 只有周围张量采用兼容的布局，统一查找表才能发挥作用。布局不匹配会使内核速度降低至多 12 倍</strong>。我们的以向量 LUT 为中心的张量布局（Vector LUT-Centric Tensor Layout）让激活、查找表和输出按 token 连续存储，打包权重则按分块连续存储。权重重排在线下完成，运行时的激活与输出变换则融合进内核，以尽量减少额外开销。</p> </li> 缓存局部性。</strong> 向量 LUT 会使表的大小增加 N 倍。序列长度为 512 时，Llama3 8B 的一次 GeMM 所需的 2 比特 INT16 向量表将超过 280 MiB</strong>，远超边缘 CPU 的缓存容量。我们的缓存感知流式查表（Cache-Aware Streamed Lookup）将预计算和查表流水线切分为与缓存容量相适应的小块，再依次流式处理，使大部分 LUT 工作留在片上缓存中，避免反复访问一张巨大的随机访问表。</p> </li> </ul> 摆脱硬件查表指令后，位宽和形状限制也随之放宽。由此，我们可以采用灵活的低于 2 比特打包</strong>：I1</code> 打包达到每权重 1.60 比特</strong>，同时支持范围广泛的权重形状。拓扑预计算、INT16–INT32 分层累加等进一步优化，则减少了剩余开销。</p> 实验结果：5 款设备 × 3 个模型</h2> 我们在五款 x86/ARM 设备（台式机、笔记本电脑、单板计算机、智能手机和 CPU 服务器）以及三个三值 LLM——Falcon3 1B、HF BitNet 3B 和 Llama3 8B——上评估了 Vec-LUT。</p> 端到端预填充：</strong> 与 BPW 相近的基线相比，I1</code>（1.60 BPW）加速至多 4.2 倍</strong>，I2</code>（2.00 BPW）加速至多 2.6 倍</strong>。</li> CPU 对比 NPU：</strong> 在 Snapdragon 8 Elite 上，Vec-LUT I2</code> 仅使用 2 个 CPU 核心</strong>，进行 Llama3 8B 预填充时的吞吐量即可达到 llama.cpp Q4_0 Hexagon NPU 后端的 1.05–1.12 倍</strong>。</li> 连续批处理：</strong> 在一台 8 核、每小时 0.50 美元</strong>的 AWS Graviton 3 服务器上，Vec-LUT I2</code> 面对 32 个并行请求时，以 273.5 tokens/s</strong> 的速度服务 Falcon3 1B，比 llama.cpp TQ2_0</code> 快 1.4 倍</strong>。</li> 能效：</strong> 相比 llama.cpp，每焦耳生成的 token 数至多提高 2.1 倍</strong>；相比 T-MAC，至多提高 1.8 倍</strong>。</li> </ul> 不同模型、设备和线程数下的端到端预填充性能对比。</figcaption> </figure> 实现与适用范围</h2> 我们的实现 vlut.cpp</strong> 是 llama.cpp</a> 的轻量扩展。它面向主流 x86 和 ARM CPU，沿用了大家熟悉的 llama.cpp 式构建和使用流程，并作为开源 OpenBitSys</a> 项目的一部分发布。</p> 当三值模型检查点可用（例如通过量化感知训练获得）、工作负载包含大量并行推理（预填充、批处理、推测解码或并行测试时扩展），且 CPU 内存占用和吞吐量是主要限制时，Vec-LUT 最能发挥作用。</p> Vec-LUT 将查表开销降到 1% 以下后，向量加法</strong>（即累加查表结果）会成为主要开销。在实测的 HF BitNet 3B 工作负载中，它约占端到端预填充延迟的 65%，自然也就成为未来以向量 LUT 为中心的加速器</strong>值得重点优化的目标。</p> 我们的团队正在招聘博士后和实习生，研究方向包括物理 AI 基础模型、LLM 训练与推理系统等。欢迎联系曹汀老师</a>。</em></p> ^1</sup>Shuming Ma et al., “BitNet b1.58 2B4T Technical Report”</a>, arXiv, 2025.</p> </div> ^2</sup>Tim Dettmers et al., “LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale”</a>, NeurIPS, 2022.</p> </div> ^3</sup>Elias Frantar et al., “GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers”</a>, ICLR, 2023.</p> </div> ^4</sup>Mengzhao Chen et al., “EfficientQAT: Efficient Quantization-Aware Training for Large Language Models”</a>, ACL, 2025.</p> </div> ^5</sup>Shuming Ma et al., “The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits”</a>, arXiv, 2024.</p> </div> ^6</sup>Jinheng Wang et al., “bitnet.cpp: Efficient Edge Inference for Ternary LLMs”</a>, ACL, 2025.</p> </div> ^7</sup>Jianyu Wei et al., “T-MAC: CPU Renaissance via Table Lookup for Low-Bit LLM Deployment on Edge”</a>, EuroSys, 2025.</p> </div> ^8</sup>Shijie Cao, Lingxiao Ma, and Ting Cao, “Advances to low-bit quantization enable LLMs on edge devices”</a>, Microsoft Research Blog, 2025.</p> </div> ^9</sup>Hao Wen et al., “AutoDroid: LLM-powered Task Automation in Android”</a>, MobiCom, 2024.</p> </div> ^10</sup>Leming Shen et al., “AutoIOT: LLM-Driven Automated Natural Language Programming for AIoT Applications”</a>, MobiCom, 2025.</p> </div> ^11</sup>Zheyu Shen et al., “EdgeLoRA: An Efficient Multi-Tenant LLM Serving System on Edge Devices”</a>, MobiSys, 2025.</p> </div> ^12</sup>Borui Li et al., “MobiLoRA: Accelerating LoRA-Based LLM Inference on Mobile Devices via Context-Aware KV Cache Optimization”</a>, ACL, 2025.</p> </div> ^13</sup>Mouxiang Chen et al., “Parallel Scaling Law for Language Models”</a>, NeurIPS, 2025.</p> </div> ^14</sup>Ryan Ehrlich et al., “CodeMonkeys: Scaling Test-Time Compute for Software Engineering”</a>, arXiv, 2025.</p> </div> ^15</sup>Yaniv Leviathan et al., “Fast Inference from Transformers via Speculative Decoding”</a>, ICML, 2023.</p> </div> ^16</sup>Charlie Chen et al., “Accelerating Large Language Model Decoding with Speculative Sampling”</a>, arXiv, 2023.</p> </div> 增强 vLLM 对 GPTQv2 格式的支持：分析与实现 2025-10-12T00:00:00+00:00 Issue（已关闭）：#26343</a> Pull request（已合并）：#26092</a> Commit：5cc6bdd</code></a></p> </blockquote> 引言</h2> 在这次改动之前，vLLM 对 GPTQv2 格式</strong>模型的支持并不完善，采用低比特（2/3-bit）或非对称量化</strong>的模型尤其如此。vLLM 加载这些模型时不会明确报错，却会将其按 GPTQv1 处理，导致推理质量下降，并经常重复生成 !!!</code> token（参见 issue #26343</a>）。</p> 问题来自 GPTQv1 与 GPTQv2 checkpoint 在零点处理</strong>方式上的差异，而 vLLM 的 fallback GPTQ GeMM 内核没有考虑这一点。本文分析了故障原因，并记录 PR #26092</a> 中的内核改动：在保持向后兼容的同时加入 GPTQv2 支持。</p> 最终实现让 vLLM 的 fallback GPTQ 路径能够支持采用低比特和非对称配置的 GPTQv2 模型。</p> 背景与预备知识</h2> 我是在使用 vLLM 部署以 GPTQv2 格式存储的低比特（如 2-bit）非对称量化模型时遇到这个问题的。</p> 介绍实现细节前，先说明两点背景：</p> 非对称量化会为每组权重调整零点，因此对低比特量化很有帮助。</strong></li> GPTQv2 能在非对称量化 checkpoint 中更完整地保留零点信息。</strong></li> </ul> LLM 的权重量化</h3> 权重量化将高精度模型权重（如 16/32-bit）映射为较少的比特（如 2/3/4/8-bit）。这种方法常用于 LLM 部署，尤其适合资源紧张的场景。</p> 从技术上说，权重量化会把范围较大的高精度权重（例如 FP16 的 $[-65504, 65504]$）映射到有限的量化权重范围（例如 $b$-bit 无符号整数的 $[0, 2^b - 1]$）。这一映射通常需要一个用于压缩取值范围的缩放因子（$scale$），以及一个用于平移零点的偏置（$zero$）。记 $w_o$ 为 $[w_{min}, w_{max}]$ 范围内的原始权重（通常对应一组权重），$w_q$ 为量化后的权重，则一种简单的 $b$-bit 整数量化可写为：</p> \[ scale = \frac{w_{max} - w_{min}}{2^b - 1} \]</p> \[ zero = - \mathrm{round}(\frac{w_{min}}{scale}) \]</p> \[ w_q = \mathrm{clamp}(\mathrm{round}(\frac{w_o}{scale}) + zero) \]</p> 反量化时，按下式恢复原始权重 $\hat{w}_o$：</p> \[ \hat{w}_o = (w_q - zero) \cdot scale \]</p> 根据是否需要零点，可以将量化方法分为两类：</p> 对称量化</em>假设 $w_{max} = -w_{min}$，因此 $zero = \mathrm{round}(\frac{2^b - 1}{2})$ 是固定值。此时只要知道比特宽度，$zero$ 就不再提供额外信息。</p> </li> 非对称量化</em>不作这一假设。它的 $zero$ 会随权重组而变化，必须将其存储下来，才能准确恢复量化值。</p> </li> </ul> 大多数 GPTQ 实现采用 4-bit 对称量化。在更低的比特宽度下，非对称量化可以让零点适应每组权重，从而减小量化误差。</p> GPTQ：量化方法与 Checkpoint 格式</h3> GPTQ1</a></sup> 是生成式 Transformer（主要是 LLM 和 VLM）最常用的训练后量化方法</strong>之一。它利用近似二阶信息（层 Hessian 的逆）来减小量化误差。 GPTQ 也可以指 GPTQ 量化模型所使用的 checkpoint 格式</strong>，例如 AutoGPTQ</a> 生成的格式。Daniël de Kok 的 GPTQ Checkpoint Format</a> 对这种表示方式有详细说明。</p> GPTQ 生态既包括实现该量化方法或导出相应 checkpoint 格式的量化库，也包括执行这些 checkpoint 的内核与推理框架。</p> 量化库：</p> GPTQModel</a> 是 AutoGPTQ 仍在积极维护的后继项目，支持更多模型和后端。</li> AutoGPTQ</a> 曾是常用的 GPTQ 量化库，但现已停止维护。</li> gptq</a> 是 GPTQ 论文的官方实现。</li> 其他量化库也会实现 GPTQ 量化，或以 GPTQ 格式导出量化模型。</li> </ul> 计算（CUDA）内核：</p> Marlin</a> 是面向 4-bit GPTQ 模型的高性能 W4A16 mpGeMM 内核。</li> ExLlamaV2</a> 是一个推理库，为 GPTQ 模型提供高性能内核。</li> BitBLAS</a> 是支持 GPTQ 模型的高性能低比特 mpGeMM 内核库。</li> 还有许多其他内核库也支持 GPTQ 格式模型。</li> </ul> vLLM</a> 等 LLM 推理框架会集成这些量化库和内核库，从而高效部署 GPTQ 模型。</p> 从 GPTQv1 到 GPTQv2</h3> GPTQv2 这一名称同时用于指代量化方法和 checkpoint 格式的改动：</p> 量化方法：GPTQv2（也称 GPTAQ）引入非对称校准，以减小从前面各层传播而来的量化误差2</a></sup>。它最早在 GPTAQ</a> 中实现，之后集成进 GPTQModel</a>，可通过 v2=True</code> 启用。</li> Checkpoint 格式：GPTQv2 与 GPTQv1 存储零点的方式不同。GPTQv1 存储 $\mathrm{clamp}(zero - 1)$，并在运行时反量化前加 $1$3</a></sup>；GPTQv2 则直接存储准确的 $zero$ 值，无需调整。在 GPTQModel 中可通过 format="gptq_v2"</code> 启用这一格式。</li> </ul> 与 GPTQv1 一样，量化方法和 checkpoint 格式之间并不绑定。因此，可以：</p> 将其他方法量化的模型存为 GPTQv2 格式，例如 BitDistiller/Qwen-8B-w2g64-gptq</a>。</li> 只在 GPTQModel 中设置 format="gptq_v2"</code>，把采用 GPTQv1 方法量化的模型存为 GPTQv2 格式。</li> 只在 GPTQModel 中设置 v2=True</code>，把采用 GPTQv2 方法量化的模型存为 GPTQv1 格式。</li> </ul> 从 GPTQv1 转换到 GPTQv2 是无损的，反向转换则不是。GPTQv1 的减一表示会把 $0 - 1$ clamp 到 $0$，因此损失一部分零点范围。以 INT2 量化为例，有效范围会从 $[0,3]$ 缩小到 $[1,3]$。所以，GPTQv2 更适合非对称 checkpoint，尤其是在低比特宽度下。</strong></p> 原因分析</h2> 故障源于 vLLM 如何将不同的 GPTQ 配置路由到已有内核：</p> vLLM 有多个兼容 GPTQ 的 GeMM 内核，并为它们预先规定了优先级</strong>——包括 Marlin、BitBLAS 和 fallback 内核。</li> Marlin 等优化内核仅在有限配置下支持 GPTQv2</strong>——即 4/8-bit 对称量化。</li> fallback 内核支持更多比特宽度和非对称量化，却不支持 GPTQv2</strong>——这正是本次问题的根源。</li> </ul> graph TD A[VllmConfig] --> B[ModelConfig._verify_quantization] B --> \|"优先级: gptq_marlin > gptq_bitblas > gptq"\| E[QuantizationConfig.get_quant_method] E -->\|4/8-bit + sym\| J[GPTQMarlinLinearMethod] E -->\|4/8-bit + sym\| K[GPTQBitBLASLinearMethod] E -->\|2/3/4/8-bit + sym/asym\| L[GPTQLinearMethod] J --> JJ[MarlinLinearKernel] K --> KK[BitBLASLinearKernel] L --> LL[直接调用内核] JJ --> M[gptq_marlin_gemm<br/>CUDA 内核] KK --> N[bitblas.Matmul<br/>外部库] LL --> O[gptq_gemm<br/>CUDA 内核] M --> Q["✓ Marlin: gptq/gptq_v2"] N --> R["✓ BitBLAS: gptq/gptq_v2"] O --> S["✗ GPTQ: 仅 gptq"] style J fill:#90EE90 style K fill:#90EE90 style L fill:#FFB6C1 style Q fill:#90EE90 style R fill:#90EE90 style S fill:#FFB6C1 </pre> </div> vLLM 的内核路由层级</h3> 首先需要了解 vLLM 如何为 GPTQ 等量化方法选择计算内核。相关逻辑位于 LLMEngine</a> 的模型执行部分。为便于说明，本文只讨论稠密模型，不涉及 MoE。调用层级如下：</p> 1. 模型级量化配置：</strong></p> 在模型实现（vllm/model_executor/models</code>）中，初始化模型时会传入 vllm_config: VllmConfig</code>，其中包含 quant_config: QuantizationConfig</code>。每种量化方式都会扩展 QuantizationConfig</code>，提供与该量化方式相关的 override（例如 GPTQConfig</code>）。参见全部量化方式</a>。</li> 如果 quant_config</code> 中没有指定量化方式，ModelConfig._verify_quantization</code> 会按优先级列表选择一种（见下文</a>）。</li> </ul> </li> 该模型的每个线性模块都以 quant_config</code> 初始化。</li> </ul> 2. 层级量化配置（线性方法）：</strong></p> 初始化时，每个量化线性模块都会确定 quant_method = quant_config.get_quant_method</code>。 get_quant_method</code> 会根据量化配置返回具体的线性方法类（继承自 LinearMethodBase</code>，例如 GPTQLinearMethod</code>）。</li> </ul> </li> 每个线性模块通过 override LinearMethodBase.apply</code> 来调用计算内核（例如 GPTQLinearMethod.apply</code> 调用 gptq_gemm</code>）。</li> </ul> 3.（可选）内核选择（线性内核）：</strong></p> vLLM 支持通过多种方式从线性方法类路由到底层 CUDA 内核：</p> 直接调用。例如，GPTQLinearMethod</code> 直接路由到 gptq_gemm</code>，这是 vLLM 注册的自定义算子（实现在 csrc/quantization/gptq</code>）。</li> 间接调用。如果一个线性方法有多个可用内核，或一个内核可供多个线性方法使用，vLLM 可以扩展 MPLinearKernel</code> 类，并将其作为路由到该内核的接口（位于 vllm/model_executor/layers/quantization/kernels/mixed_precision</code>）。例如，GPTQBitBLASLinearMethod</code> 路由到 BitBLASLinearKernel</code>，GPTQMarlinLinearMethod</code> 则调用 choose_mp_linear_kernel</code> 进行灵活路由。</li> 外部调用（与上述方式正交）。vLLM 支持调用外部库中的内核。例如，BitBLASLinearKernel</code> 会调用 bitblas</code> Python 库中的 Matmul</code>。</li> </ul> vLLM 对 GPTQ(v2) 格式的支持</h3> vLLM 集成了多个适用于 GPTQ 格式模型的优化内核，包括 Marlin、ExLlamaV2 和 BitBLAS，同时也为不受支持的配置提供 fallback 内核。按线性方法划分，支持矩阵如下：</p> 方法</th> Bits</th> Sym</th> GPTQ 格式</th></tr></thead> GPTQMarlin</td> 4,8</td> True</td> gptq, gptq_v2</code></td></tr> GPTQBitBLAS</td> 4,8</td> True</td> gptq, gptq_v2</code></td></tr> GPTQ</td> 2,3,4,8</td> Any</td> gptq</code></td></tr> </tbody></table> </a></p> 说明：</p> 所有方法都支持 4/8-bit 对称量化。vLLM 会根据预定义的量化 override 优先级（位于 ModelConfig._verify_quantization</code>），选择当前配置下支持且性能最好的方法：</li> </ul> overrides</span> =</span> [</span></span> ...</span></span> #</span> gptq_marlin_24 requires special format,</span></span> #</span> so we don't consider here.</span></span> "</span>gptq_marlin_24</span>"</span>,</span></span> #</span> Priority: gptq_marlin > gptq_bitblas > gptq.</span></span> "</span>gptq_marlin</span>"</span>,</span></span> "</span>gptq_bitblas</span>"</span>,</span></span> ...</span></span> ]</span></span></code></pre> 只有 GPTQLinearMethod</code> 支持 2/3-bit 和非对称量化，但它此前不支持 GPTQv2；另外两种方法已经支持该格式。</li> </ul> 因此，vLLM 的这条 fallback 路径既无法支持 GPTQv2 格式的 2/3-bit 量化，也无法支持其非对称量化，这正是 PR #26092</a> 的动机。</p> 解决方案</h2> 根据以上分析，需要调整一个 GPTQ 线性方法及其内核，才能让 GPTQv2 模型覆盖这些配置。</p> 方案：调整 GPTQ 线性方法与内核</h3> 要加入这项支持，至少需要调整一种现有的线性方法：</p> GPTQMarlinLinearMethod</code> 不支持 2/3-bit 和非对称量化。扩展它还需要修改 vLLM 的 Marlin CUDA 内核，而该内核面向 4/8-bit 对称量化。</li> GPTQBitBLASLinearMethod</code> 在线性方法层面同样不支持 2/3-bit 和非对称量化。虽然 bitblas</code> 库支持所需的 bits</code> 与 sym</code> 取值，但这条路径依赖可选的 bitblas</code> 包。</li> GPTQLinearMethod</code> 已经支持所需的比特宽度和对称/非对称模式，只需在 gptq_gemm</code> CUDA 内核中根据格式处理零点，因此是首选方案。</li> </ul> 因此，实现中选择调整 GPTQLinearMethod</code>（及 GPTQConfig</code>）和 gptq_gemm</code>，为它们加入 GPTQv2 支持。</p> 调整细节：根据格式选择处理方式</h3> 线性方法与内核的调整需要满足三项要求：</p> 保持与 GPTQv1 格式的兼容性。</li> 尽量减小对代码和二进制大小的影响。</li> 保持现有路由，让 GPTQv2 模型仍可选择 Marlin 等其他内核。</li> </ol> 为满足前两项要求：</p> 为 GPTQLinearMethod</code> 添加 use_v2_format: bool</code> 属性，用于表示 checkpoint_format == "gptq_v2"</code>。</li> 为 gptq_gemm</code> 添加 bool use_v2_format</code> 参数，以 GPTQLinearMethod.use_v2_format</code> 作为输入。</li> 在 gptq_gemm</code> 中，根据 use_v2_format</code> 调整零点处理逻辑。例如：</li> </ul> //</span> In `reconstruct_exllama_2bit_kernel`:</span></span> </span> //</span> Previous: zeros[i] + 1 (hardcoded for GPTQv1)</span></span> dequant_2bit_16</span>(</span>load_int4.x</span>,</span> dq</span>[</span>0</span>]</span>,</span> size_n</span>,</span> zeros</span>[</span>0</span>]</span> +</span> 1</span>)</span>;</span></span> dequant_2bit_16</span>(</span>load_int4.y</span>,</span> dq</span>[</span>1</span>]</span>,</span> size_n</span>,</span> zeros</span>[</span>1</span>]</span> +</span> 1</span>)</span>;</span></span> dequant_2bit_16</span>(</span>load_int4.z</span>,</span> dq</span>[</span>2</span>]</span>,</span> size_n</span>,</span> zeros</span>[</span>2</span>]</span> +</span> 1</span>)</span>;</span></span> dequant_2bit_16</span>(</span>load_int4.w</span>,</span> dq</span>[</span>3</span>]</span>,</span> size_n</span>,</span> zeros</span>[</span>3</span>]</span> +</span> 1</span>)</span>;</span></span> </span> //</span> Now: zeros[i] + offset (conditioned on `use_v2_format`)</span></span> int</span> zero_offset </span>=</span> use_v2_format </span>?</span> 0</span> :</span> 1</span>;</span></span> ...</span></span> dequant_2bit_16</span>(</span>load_int4.x</span>,</span> dq</span>[</span>0</span>]</span>,</span> size_n</span>,</span> zeros</span>[</span>0</span>]</span> +</span> zero_offset</span>)</span>;</span></span> dequant_2bit_16</span>(</span>load_int4.y</span>,</span> dq</span>[</span>1</span>]</span>,</span> size_n</span>,</span> zeros</span>[</span>1</span>]</span> +</span> zero_offset</span>)</span>;</span></span> dequant_2bit_16</span>(</span>load_int4.z</span>,</span> dq</span>[</span>2</span>]</span>,</span> size_n</span>,</span> zeros</span>[</span>2</span>]</span> +</span> zero_offset</span>)</span>;</span></span> dequant_2bit_16</span>(</span>load_int4.w</span>,</span> dq</span>[</span>3</span>]</span>,</span> size_n</span>,</span> zeros</span>[</span>3</span>]</span> +</span> zero_offset</span>)</span>;</span></span> </span></code></pre> 测试期间，我发现原有的 gptq_gemm</code> 即使处理对称量化的 GPTQv1 模型，在 4-bit 下也存在 bug。这超出了该 PR 的范围。</p> </blockquote> 对于第三项要求，GPTQMarlinLinearMethod</code> 和 GPTQBitBLASLinearMethod</code> 都不作改动：它们已经支持 GPTQv2，只是仅限于 4/8-bit 对称量化。</p> TODO：补充一些性能基准测试。我发现 2-bit gptq_gemm</code> 在解码（GeMV）时比预填充（GeMM）时更慢。</p> </blockquote> 总结</h2> 这项改动为 vLLM 的 fallback GPTQ 路径加入了 GPTQv2 支持，在保持 GPTQv1 兼容性的同时，覆盖了低比特和非对称配置。</p> 欢迎提问与讨论。</p> 后续可做的工作：</strong></p> 扩展优化内核（Marlin、BitBLAS），使其支持 2/3-bit 或非对称量化。</li> 修复 gptq_gemm</code> 的 4-bit bug。</li> 提升 gptq_gemm</code> 的解码速度。</li> </ul> ^{1</sup> Elias Frantar 等，“GPTQ: Accurate Post-Training Quantization for Generative Pre-Trained Transformers”</a>，ICLR，2023。</p> </div> ^2</sup>Yuhang Li 等，“GPTAQ: Efficient Finetuning-Free Quantization for Asymmetric Calibration”</a>，arXiv，2025。</p> </div> ^3</sup>Daniël de Kok，“GPTQ Checkpoint Format”</a>，Daniël’s Website，2024。</p> </div> 视觉—语言—动作（VLA）模型：近期进展综述 2025-09-16T00:00:00+00:00 我刚开始接触这个领域，欢迎讨论，也欢迎提出任何问题！本文根据我的幻灯片</a>整理而成。</p> </blockquote> 背景与概念</h2> 视觉—语言—动作（VLA）模型的概念</h3> 在我的理解中，视觉—语言—动作（Vision-Language-Action，VLA）模型</em>1</a></sup>是面向具身智能的多模态基础模型。它以视觉</strong>（如视频流中的观测）和语言</strong>（如用户指令）为输入，输出机器人的底层动作</strong>（即控制策略</em>）。 VLA 使用视觉—语言模型（VLM）来</em>生成以视觉和语言为条件的动作</em>。</p> VLA 的概念，以及汇聚到现代 VLA 系统的几条研究脉络。</figcaption> </figure> 为长程任务加入基于 VLM 的任务规划器</h3> 早期 VLA 主要关注机器人的底层控制。除非对整个任务进行端到端训练，否则仅靠底层控制不足以完成复杂的长程任务。一种做法是加入基于 LLM/VLM 的任务规划器</em>，把长程任务分解为较简单的子任务，再交给 VLA 依次完成。较早的工作通常采用独立模型作为任务规划器；近期工作则让任务规划和控制共享同一个 VLM 主干，即采用双系统</em>架构。</p> 高层规划器将长程指令分解为多个子任务，再交给底层 VLA 控制策略执行。</figcaption> </figure> VLA 的近期进展</h2> 我从两个维度概括 VLA 的近期进展：从仅有系统 1</em>（控制）走向双系统</em>（规划 + 控制），以及从离散</em>动作走向连续</em>动作。由此可以得到四个象限：</p> 按动作表示和系统架构划分的近期 VLA。</figcaption> </figure> 下面依次介绍这几类方法。</p> 离散 VLA</h3> 离散 VLA</em> 生成离散动作 token</em>。它先将机器人的底层动作映射为离散 token，再训练 VLM 像生成文本 token 一样，以自回归</em>方式生成动作 token。这样，动作和语言便有了统一的表示，也把下一个 token 预测扩展为下一个动作预测。不过，自回归生成可能带来较高延迟和较低的控制频率，因为每生成一个新的动作 token，都需要再次运行 VLA。</p> 代表性方法包括：</p> RT-2</strong>^{2</a></sup>（ViT + PaLI-X/PaLM-E）：首次提出并推广了“VLA”这一术语的开创性工作。</li>} OpenVLA</strong>3</a></sup>（DINOv2 & SigLIP + Llama 2 7B）：颇具影响力的开源 VLA 模型（在 GitHub</a> 上有 3.8k stars）。</li> FAST</strong>4</a></sup>：一种使用 DCT（离散余弦变换）压缩动作序列的动作 tokenizer。</li> </ul> OpenVLA 将机器人动作视为离散 token，由预训练 VLM 以自回归方式生成。</figcaption> </figure> 连续 VLA</h3> 连续 VLA</em> 从连续动作空间</em>中采样。这样能实现更平滑、精度更高的控制，但也更难在现有语言模型之上训练。 Physical Intelligence 的做法是在预训练 VLM 上加入一个流匹配动作专家</em>，并基于预训练的 PaliGemma 2B VLM 训练 $\pi_0$5</a></sup>。</p> 预训练 VLM 从互联网规模的数据中获得语义理解和泛化能力</strong>，流匹配动作专家则从跨本体数据中学习高频（最高 50 Hz）控制</strong>。之后，还可以针对困难任务或未见过的任务对模型进行微调。</p> π₀ 将预训练 VLM 与流匹配动作专家结合，实现连续控制。</figcaption> </figure> 类似地，NVIDIA Isaac 训练了 GR00T N1(.5)6</a></sup>。它将预训练 Eagle-2 VLM 与基于扩散模型的动作头相结合，作为通用人形机器人的基础模型。在 $\pi_0$ 和 GR00T 中，VLM 主干与动作专家通过注意力模块交互，使生成的动作以 VLM 的隐状态（即 KV）为条件。二者在技术上有两点区别：</p> 注意力机制</strong>：$\pi_0$ 将视觉—语言部分与动作部分的 KV 拼接起来，再进行掩码自注意力计算（这篇博文</a>给出了很清楚的图示）；GR00T 则直接在两部分之间进行交叉注意力计算。</li> 参与计算的 VLM 层数</strong>：$\pi_0$ 让动作专家的层数与 VLM 主干对齐，并在每一层进行自注意力计算（类似 MoE）；GR00T 只保留 VLM 最后一层的隐状态7</a></sup>，动作专家的每一层都与它进行交叉注意力计算。</li> </ul> 双系统 VLA</h3> 与“系统 1 VLA + 独立 LLM/VLM 任务规划器”的组合不同，双系统 VLA</em> 还会使用自身的 VLM 主干进行规划。因此，系统 2（高层规划）和系统 1（底层控制）共享同一个 VLM</strong>。 VLA 学习直接根据用户指令预测子任务</strong>，由此提升开放世界中的泛化能力，同时比采用独立规划器模型消耗更少的资源。</p> 问题：共享 VLM 是否能通过对齐系统 1 和系统 2 来提升性能？反过来，两者的目标是否也可能互相干扰？</p> </blockquote> π₀.₅ 在 π₀ 的基础上加入高层子任务预测，实现双系统规划与控制。</figcaption> </figure> Physical Intelligence 训练的 $\pi_{0.5}$8</a></sup> 是这一类别中的首个模型。与 $\pi_0$ 相比，它的训练数据还包括目标检测、指令、子任务命令和离散动作。推理时，其 VLM 先根据高层提示预测一个子任务（系统 2），随后由 VLM 和动作专家执行该子任务（系统 1）。近期的 VLA，如 Galaxea 的 G09</a></sup> 和 X Square Robot 的 WALL-OSS10</a></sup>，都沿用了这一训练方法和推理流程。这类模型大多采用连续 VLA，但 WALL-OSS 也提供了使用 FAST tokenization 的离散版本（WALL-OSS-FAST</a>）。</p> 各模型的仓库和开源情况如下：</p> $\pi_{0.5}$：已公开模型权重，部分代码发布于 Physical-Intelligence/openpi</a>，但 VLM 子任务预测的推理代码尚未公开。</li> G0：已公开模型权重和开放世界数据集，部分代码发布于 OpenGalaxea/G0</a>，目前仅支持真机推理。</li> WALL-OSS：模型权重和代码均已发布于 X-Square-Robot/wall-x</a>。</li> </ul> 总结与展望</h2> 自 RT-2 于 2023 年问世以来，VLA 已迅速从离散控制发展到连续控制，也从单系统架构发展到双系统架构。我认为，原生多任务</em>会成为下一个趋势：具身智能体不应局限于执行动作，还应能处理聊天、记忆和导航等本质上不同的任务。近期的模型已经让任务规划和控制共享基于互联网规模数据预训练的 VLM 主干。尽管这两者仍然以动作为中心，但它们为多个更广泛的任务共享同一个 VLM 奠定了基础。</p> 我目前正在研究这种面向具身智能体原生多任务的多专家基础模型</em>，欢迎联系我讨论与合作！</p> ^1</sup>Yueen Ma et al., “A Survey on Vision-Language-Action Models for Embodied AI”</a>, arXiv, 2024.</p> </div> ^2</sup>Brianna Zitkovich et al., “RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control”</a>, CoRL, 2023.</p> </div> ^3</sup>Moo Jin Kim et al., “OpenVLA: An Open-Source Vision-Language-Action Model”</a>, CoRL, 2024.</p> </div> ^4</sup>Karl Pertsch et al., “FAST: Efficient Action Tokenization for Vision-Language-Action Models”</a>, RSS, 2025.</p> </div> ^5</sup>Kevin Black et al., “$\pi_0$: A Vision-Language-Action Flow Model for General Robot Control”</a>, RSS, 2025.</p> </div> ^6</sup>Johan Bjorck et al., “GR00T N1: An Open Foundation Model for Generalist Humanoid Robots”</a>, arXiv, 2025.</p> </div> ^7</sup>具体而言，根据我对权重相似度的测试，GR00T N1.5 的 VLM 语言主干由预训练 Qwen3-1.7B</a>（共 28 层）的前 14 层微调而来。</p> </div> ^8</sup>Physical Intelligence et al., “$\pi_{0.5}$: A Vision-Language-Action Model with Open-World Generalization”</a>, arXiv, 2025.</p> </div> ^9</sup>Tao Jiang et al., “Galaxea Open-World Dataset and G0 Dual-System VLA Model”</a>, arXiv, 2025.</p> </div> ^10</sup>X Square Robot, “WALL-OSS: Igniting VLMs toward the Embodied Space”</a>, white paper, 2025.</p> </div> Dario Amodei 博客阅读笔记 2025-08-02T00:00:00+00:00 本文仍在更新，但现有笔记已经可以阅读。</p> </blockquote> 最近，我读了 Anthropic</a> CEO Dario Amodei</a> 的几篇文章1</a></sup>。作为一名 AI 博士生，也是 Anthropic Claude 模型的常用用户，我从中获得了不少启发。</p> 这些文章拓宽了我对学术界和产业界的认识，内容也常常横跨多个学科。这篇笔记记录了我阅读时想到的一些问题。</p> 按我的阅读顺序，涉及的文章包括：</p> On DeepSeek and Export Controls</em></a>（2025 年 1 月）</li> The Urgency of Interpretability</em></a>（2025 年 4 月）</li> Machines of Loving Grace</em></a>（2024 年 10 月）</li> </ul> 畅想强大 AI</h2> 在 Machines of Loving Grace</em></a> 中，Amodei 描绘了“强大 AI”（他更偏爱这一说法，而非 AGI</em>）可能具有的形态，以及它问世后 5–10 年间可能给社会带来的变化。他预测，“它最早可能在 2026 年出现”。在我看来，他设想的 AI 在形态上与今天的大语言模型相似，但实现方式未必相同，主要具有以下特点：</p> 超级智能。</strong> 单论智力，它“比诺贝尔奖得主更聪明”。例如，它能够证明尚未解决的数学定理，也能写出极为出色的小说。</li> 能够使用各种界面。</strong> 除了聊天，它还可以使用人类完成虚拟工作所需的一切界面。</li> 自主工作。</strong> 它能够长时间执行分配给它的任务，只在确有必要时向人类询问。</li> 通过虚拟方式与现实交互。</strong> 它没有实体，但可以借助计算机控制乃至创造现实中的工具。</li> 规模庞大、速度极快。</strong> 原本用于训练的资源可以转而运行数百万个实例；这些实例学习和行动的速度都远超人类（例如快 10–100 倍）。</li> 既独立又协作。</strong> 数百万个实例既可以各自处理互不相关的任务，也可以协同解决同一个问题；其中一些实例还可以通过微调，尤其擅长特定任务（我会称之为“专家”）。</li> </ul> 他将其概括为“数据中心里的天才之国”：它能迅速解决棘手问题，却依然受到外部世界的制约。这些制约包括物理过程的速度、对数据的需求（例如粒子物理研究）、问题本身的复杂性（例如三体问题</a>）、法律与人类意愿，以及晶体管密度和擦除单位信息所需能量的物理极限。</p> 因此，他借用经济学中的“智力边际回报”来思考一个拥有极其强大 AI 的世界。他的预测建立在这样一个问题之上：更高的智能能在哪些领域发挥作用、作用有多大，又需要多长时间？我很喜欢这种分析方式。如果没有一种合理的方法衡量智能的影响，我们很容易走向过度乐观或过度悲观。</p> 上面的基本假设和分析框架2</a></sup>并不是 Machines of Loving Grace</em> 的主体，却是最打动我的部分。毕竟，最难的并不是在一个扎实的框架下推导出合理答案，而是提出这个框架本身。</p> 文章余下的篇幅分别从五个领域讨论强大 AI 问世后 5–10 年间可能发生的变化：生物学与健康、神经科学与心智、经济发展与贫困、和平与治理，以及工作与意义。他的核心预测是：强大 AI 将把人类 50–100 年的进步压缩到 5–10 年内完成</strong>，他称之为“压缩的 21 世纪”。悬而未决的问题是，这样的 AI 究竟何时才会出现。</p> 与“基本假设和分析框架”</a>一节相比，我觉得有些预测更带有个人色彩，比如关于自由民主与威权主义的讨论3</a></sup>。即使采用同一套分析框架，人们也会因为背景和经历不同，对某些问题产生不同的理解与想象。这正是我喜欢阅读不同背景作者作品的重要原因之一，也是我写下这些笔记的原因。</p> 用机制可解释性保障 AI 安全</h2> 随着现代 AI 逐渐接近上文所说的“强大 AI”，治理与“安全”问题会愈发重要（而如何定义安全，本身就是一个重大问题）。强大的 AI 系统需要技术层面的安全机制，可解释性是其中的重要一环。在 The Urgency of Interpretability</em></a> 中，Amodei 介绍了机制可解释性的重要性与发展历程，以及 Anthropic 最近在这一方向上的进展。</p> 可解释性之所以重要，是因为现代深度学习系统不同于由明确规则编写的传统系统，在很大程度上仍是“黑箱”。就连开发者也无法完全解释，为什么某个输入会产生某个输出。 Amodei 引用了联合创始人 Chris Olah</a> 的说法：生成式 AI 系统与其说是被“建造”出来的，不如说是被“培育”出来的（我很喜欢这个词）——它们的内部机制从训练中涌现，并非由人直接设计。这类系统可能对人们产生越来越大的影响，因此，要让它们得到更广泛的应用，透明度与可解释性不可或缺。</p> 机制可解释性</em>试图通过逆向工程，理解神经网络在内部学到了哪些算法和计算机制。它不同于关注输入输出关系或高层行为的方法，而是试图从底层解释各层和神经元中究竟发生了什么。这一领域早期主要研究 CNN，如今则越来越关注大语言模型。 Anthropic 联合创始人 Chris Olah 从在 Google 和 OpenAI 工作时起，就一直在研究这一领域。</p> 对大语言模型而言，一个早期步骤是找出可解释的神经元4</a></sup>。研究人员发现，有些神经元的含义一目了然，但大多数神经元表达的却是杂乱混合的词语与概念。这种“叠加”让模型能表达比神经元数量更多的概念。为了将它们分离，研究人员使用稀疏自编码器</em>5</a></sup>寻找对应于更纯粹、可由人理解的概念的神经元组合，并将这些概念称为“特征”。有些特征非常微妙，例如“不论字面还是比喻意义上的闪烁其词或犹豫不决”。借助这种方法，Anthropic 在 Claude 3 Sonnet 中识别出了超过 3000 万个特征。</p> 有了这些特征，研究人员就可以进一步探查模型的工作方式。人为放大某项特征可以显著改变模型行为（“Golden Gate Claude”</a>）；追踪并操纵成组的特征（即“回路”6</a></sup>），则有助于解释推理过程的某些部分。 Anthropic 的研究文章7</a></sup>更详细地介绍了这项工作。</p> 机制可解释性试图逆向分析神经网络，甚至是拥有数十亿参数的大语言模型，并为模型内部的工作方式提供具体证据；我很欣赏这一点。这个方向看起来很有前景，但我不认为在庞大的神经网络里寻找“漏洞”，就是通往强大且安全的 AI 的完整路径——那就像在一头蓝鲸体内清除癌细胞一样。至少目前，我不觉得我们的模型已经强大到足以构成“危险”，不过机制可解释性也可以帮助提升模型能力。</p> AI 与政治</h2> 这一节尚待完成（这个话题也实在太大）——等有时间时我会补上。</p> ^1</sup>我最初读到的是一篇介绍 On DeepSeek and Export Controls</em></a> 的中文文章，之后又阅读了英文原文，以及 Amodei 个人网站</a>上的其他文章。</p> </div> ^2</sup>这些内容整理自原文的“基本假设和分析框架”</a>一节。</p> </div> ^3</sup>引自 Amodei Peace and governance</em></a> 一节的首段：“二十年前，美国政策制定者认为，与中国开展自由贸易会使中国在富裕起来的同时走向自由化；事实远非如此，如今我们似乎正与一个复兴的威权阵营走向第二次冷战。”</p> </div> ^4</sup>Nelson Elhage 等，“Softmax Linear Units”</a>，Transformer Circuits Thread</em>，2022。</p> </div> ^5</sup>Trenton Bricken 等，“Towards Monosemanticity: Decomposing Language Models With Dictionary Learning”</a>，Transformer Circuits Thread</em>，2023。</p> </div> ^6</sup>Jack Lindsey 等，“On the Biology of a Large Language Model”</a>，Transformer Circuits Thread</em>，2025。</p> </div> ^7</sup>Anthropic，Mapping the Mind of a Large Language Model</em></a> 和 Tracing the Thoughts of a Large Language Model</em></a>。</p> </div> Android 智能手机配置速查表 2025-01-09T00:00:00+00:00 这份速查表源于我自己的开发需求，主要面向 AI 计算任务，以及在类 Linux 环境中运行 DNN。如果你更关心应用开发和 GUI 调试，它可能并不适用。</p> 首次开机</h2> 注册</h3> 注册新设备以激活保修（如果你不打算获取系统 root 权限）。</p> 获取系统 Root 权限</h2> 如需以超级用户身份深度控制系统，必须取得 root 权限。</p> Magisk 中文网教程</a></p> 本节以一加设备为例，因为在国内，一加对 root 相对友好。</p> 所需工具与文件：</p> ADB（Android Debug Bridge）：platform-tools</a></li> Android OTA payload 提取工具：payload-dumper-go</a></li> 系统 ROM：MagiskCN</a></li> Magisk APK：GitHub Release</a></li> </ul> 解锁 Bootloader</h3> Magisk 中文网教程</a></p> 进入开发者模式</li> 开启 OEM 解锁（具体方式取决于厂商）</li> 开启 USB 调试，将手机连接至主机</li> 进入 bootloader：adb reboot bootloader</code></li> 解锁 bootloader：fastboot flashing unlock</code></li> 在手机上选择“解锁 bootloader”并确认</li> </ol> 使用 Magisk 获取 Root 权限</h3> Magisk 中文网教程</a></p> 在主机上下载匹配的 ROM 包并解压</li> 使用 payload 提取工具从 ROM 中提取 init_boot.img</code> 用法：payload-dumper-go -p init_boot <extracted>/payload.bin</code></li> </ul> </li> 开启 USB 调试，将手机连接至主机</li> 将 init_boot.img</code> 传到手机的“Download”文件夹</li> 在手机上安装 Magisk 应用</li> 在 Magisk 中选择“安装”，修补 init_boot.img</code>，得到 magisk_patched-xxx.img</code></li> 将 magisk_patched-xxx.img</code> 传回主机</li> 进入 bootloader：adb reboot bootloader</code></li> 刷入补丁：fastboot flash init_boot magisk_patched-xxx.img</code> 成功时应看到“Okay”</li> </ul> </li> 重启系统：fastboot reboot</code></li> </ol> 重启后打开 Magisk，查看其中显示的版本信息，确认 root 权限已获取成功。</p> 系统设置</h2> 开发者选项</h3> 开启开发者选项</li> 开启 USB 调试</li> 开启无线调试（如有需要）</li> </ul> 系统更新</h3> 建议关闭所有可能影响系统性能与版本稳定性的设置，具体包括：</p> 关闭不必要的后台服务</li> 关闭系统自动更新与自动下载</li> 移除自动安装的应用</li> </ul> 电池管理</h3> 在系统全局电池设置中开启“性能模式”</li> 在各应用的电池设置中开启“允许后台运行”</li> 为 Termux 及类似进程选择“获取唤醒锁”</li> </ul> 应用</h2> 安装方式：</p> 从应用商店安装（Google Play、F-Droid 等）</li> 安装已下载的 APK（Android Application Package）</li> 通过 ADB 从主机安装（需要 APK）</li> </ul> Clash for Android（CFA）</h3> 首先配置代理。</p> TODO：补充细节</p> F-Droid</h3> F-Droid</a> 是一个可安装的 Android FOSS（自由及开放源代码软件）应用目录，也可作为 Google Play 的替代方案。</p> Termux</h3> 推荐通过 F-Droid 安装。</p> 另请参阅 Termux 配置速查表</a>。</p> Microsoft Edge</h3> 可用它替代功能可能受限的系统浏览器。</p> 我推荐 Edge，是因为国内各大应用商店通常都能下载到它。</p> Android 手机上 Termux 配置速查表 2025-01-09T00:00:00+00:00 Termux</a> 在 Android 上提供了一个类 Linux 环境，功能比 ADB shell 完整得多。作为智能手机配置速查表</a>的延伸，本文说明如何配置 Termux。</p> 这套配置服务于我以 AI 计算任务为主的开发需求。如果你主要关注应用开发和 GUI 调试，它可能并不完全适合。</p> 相关参考：sanwebinfo/my-termux-setup</a></p> 安装</h2> 推荐从 F-Droid</a> 安装，便于使用插件 Termux: Style</li> </ul> </li> 也可以直接安装 APK；下载见 GitHub Releases</a></li> </ul> 系统配置</h2> 以下是在 Termux 内进行的系统级配置。</p> 更新软件包</h3> 自动选择镜像：termux-change-repo</code></li> 更新并升级：pkg update && pkg upgrade</code></li> </ul> 配置 SSH</h3> 安装 OpenSSH：pkg install openssh</code></li> 查看 Termux 用户名：whoami</code></li> 设置登录密码：passwd</code></li> 获取 IP 地址：ifconfig</code></li> 启动 SSH 服务：sshd</code></li> 从远端连接：ssh -p 8022 <username>@<ip></code> Termux 的默认 SSH 端口是 8022</li> </ul> </li> </ul> 安装常用软件包</h3> 系统配置常用的软件包：</p> Tsu（Termux 的 su 封装）：pkg install tsu</code></li> Git：pkg install git</code></li> Wget：pkg install wget</code></li> cURL：pkg install curl</code></li> CMake：pkg install cmake</code></li> tmux：pkg install tmux</code></li> htop：pkg install htop</code></li> </ul> 开发环境配置</h2> 配置开发所需的环境。</p> Code</h3> Termux 不支持 Visual Studio Code remote server，但开源的 code-server</a> 是一个实用的替代方案。</p> 通过 TUR 仓库安装 code-server：</p> pkg</span> install</span> tur-repo</span></span> pkg</span> install</span> code-server</span></span></code></pre> 在 ~/.config/code-server/config.yaml</code> 中配置服务。例如：</p> b</span>ind-addr</span>:</span> 0</span>.0.0.0:8080</span></span> a</span>uth</span>:</span> p</span>assword</span></span></code></pre> 启动服务：</p> code-server</span></span></code></pre> 现在可以通过 http://<ip>:8080</code> 访问代码编辑界面，并使用配置的密码登录。</p> 如果在 tsu</code> 模式下运行，配置文件路径会略有不同（位于 ~/.tsu</code> 下）。</p> Python</h3> Termux 不支持 Miniconda。</p> 安装 Python：pkg install python</code></p> Pi 设备配置速查表 2025-01-03T00:00:00+00:00 这份速查表是根据我自己的开发需求整理的，主要适用于 Orange Pi、Raspberry Pi 等开发板。</p> 硬件</h2> 网络连接</h3> 有线或无线网络均可。</p> 键盘、鼠标和显示器</h3> 用于首次开机配置和本地调试。</p> 已写入操作系统的 TF（MicroSD）卡</h3> 常规开发推荐使用最新的 Ubuntu LTS 我更倾向于使用服务器版系统，因为它比桌面镜像更轻量</li> 同时也能避免 GUI 干扰性能测量</li> </ul> </li> 预算允许的话，建议使用容量较大的存储卡（我使用的是 ≥256 GB）默认的 32/64 GB 对许多任务而言并不够用</li> </ul> </li> 镜像写入工具：BalenaEtcher</a>（通用）和 Raspberry Pi Imager</a>（Raspberry Pi） Raspberry Pi Imager 支持通过自定义配置完成无头安装</li> </ul> </li> </ul> 系统</h2> 按需设置或修改用户名和密码</h3> 推荐格式：设备名（raspi</code>、orangepi</code>）[+ 用户信息，适用于设备不共用的情况]</li> </ul> 连接（无线）网络</h3> Raspberry Pi 在无头安装时可以自动连接网络默认由 cloud-init</code>、netplan</code> 和 networkd</code> 管理网络</li> 我改用了自己更熟悉的 NetworkManager</code></li> </ul> </li> 其他运行 Ubuntu 的开发板可以使用 NetworkManager</code> 扫描可用网络：nmcli dev wifi</code></li> 通过 SSID 连接：nmcli dev wifi connect <ssid> password <passwd></code></li> </ul> </li> </ul> 按需配置网络</h3> 清华大学 TUNET 认证：GoAuthing</a> 如果代理导致无法访问 GitHub，也可以从 TUNA</a> 获取发布版本</li> 预编译的 Linux ARM64 可执行文件：auth-thu.linux.arm64</a></li> </ul> </li> 配置代理：TODO 使用公共网络时，不要允许来自局域网的连接</li> </ul> </li> </ul> 安装或更新必要的软件包</h3> 必要时更换软件源</li> 首先更新软件包列表并升级：sudo apt update && sudo apt upgrade</code></li> </ul> 配置 SSH 服务以便远程访问</h3> 使用 sshd</code> 启动 SSH 服务</li> 使用 ifconfig</code> 查看设备 IP</li> 使用 ssh -p <port> user@ip</code> 测试登录</li> 使用 ssh-copy-id</code> 配置密钥认证</li> </ul> 其他</h3> （可选）使用厂商提供的工具进行更直观的交互式配置，例如 Raspberry Pi 的 raspi-config</code> 和 Orange Pi 的 orangepi-config</code>。</p> 开发环境</h2> 基础工具和软件包</h3> tmux：sudo apt install tmux</code></li> git：sudo apt install git</code> 将 SSH 公钥添加到 GitHub，以便通过 SSH 克隆仓库</li> 提交代码前配置用户名和邮箱</li> </ul> </li> code-server（适用于平台不支持 VS Code Remote 的情况）</li> </ul> 构建工具和编译器</h3> CMake（大多数项目要求 >=3.22）通过 apt 安装：sudo apt install cmake</code></li> 从官方网站安装：下载页面</a></li> 更新至最新版：更新 CMake</a></li> </ul> </li> GCC 通过 apt 安装：sudo apt install build-essential</code></li> </ul> </li> LLVM + Clang 从官方网站安装：下载页面</a></li> 一行命令安装最新版：bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)"</code></li> </ul> </li> 注意：如果系统中同时装有多个编译器（GCC、Clang 或同一编译器的不同版本），请确认环境变量 $CC</code> 和 $CXX</code> 设置正确，否则 CMake 等构建工具可能会选错编译器。</li> </ul> Python 环境</h3> Miniconda 大多数情况下的首选方案</li> 一行命令安装（注意操作系统和架构） curl -O https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-aarch64.sh</code></li> bash ~/Miniconda3-latest-Linux-aarch64.sh</code> 不要使用 sudo</code>，否则 Miniconda 会安装到其他位置</li> </ul> </li> 阅读协议后按 Enter，并输入 yes</li> </ul> </li> </ul> </li> Virtualenv 在项目有要求时使用</li> 通过 apt 安装：sudo apt install python3-venv</code></li> </ul> </li> 注意：如果同时安装了 conda 和 virtualenv，请确认激活了正确的环境（从终端里看，两者可能没有明显区别）</li> </ul> 容器</h3> Docker：TODO</li> </ul> 快速修复</h2> 更新 CMake</h3> 在 Ubuntu 上安装最新版 CMake（由 Claude 生成）：</p> sudo</span> apt</span> remove</span> -</span>-purge</span> cmake</span></span> sudo</span> apt</span> purge</span> cmake</span></span> sudo</span> apt</span> autoremove</span></span> </span> wget</span> -</span>O</span> -</span> https://apt.kitware.com/keys/kitware-archive-latest.asc</span> 2</span>></span>/dev/null</span> \|</span> gpg</span> -</span>-dearmor</span> -</span> \|</span> sudo</span> tee</span> /etc/apt/trusted.gpg.d/kitware.gpg</span> ></span>/dev/null</span></span> </span> sudo</span> add-apt-repository</span> "</span>deb https://apt.kitware.com/ubuntu/ </span>$(</span>lsb_release</span> -</span>cs</span>)</span> main</span>"</span></span> sudo</span> apt</span> update</span></span> sudo</span> apt</span> install</span> cmake</span></span></code></pre>编译器</h3> 安装最新版标准库：sudo apt install libstdc++-12-dev</code></p> Git 克隆</h3> 使用 SSH URL 的一行命令：sed -i 's/https:\/\/github.com\//git@github.com:/' .gitmodules</code></p> 递归处理脚本：</p> #</span> Function to update .gitmodules and sync</span></span> update_modules</span>(</span>)</span> {</span></span> sed</span> -</span>i</span> '</span>s/https:\/\/github.com\//git@github.com:/</span>'</span> .gitmodules</span></span> git</span> submodule</span> sync</span></span> git</span> submodule</span> update</span> -</span>-init</span></span> }</span></span> </span> #</span> Function to process each level</span></span> process_level</span>(</span>)</span> {</span></span> #</span> 1. Update current .gitmodules</span></span> update_modules</span></span> </span> #</span> 2. For each currently cloned submodule</span></span> git</span> submodule</span> foreach</span> '</span></span> # 3. Update their .gitmodules if exists</span></span> if [ -f ".gitmodules" ]; then</span></span> sed -i "s/https:\/\/github.com\//git@github.com:/" .gitmodules</span></span> # 4. Update their immediate submodules</span></span> git submodule sync</span></span> git submodule update --init</span></span> fi</span></span> '</span></span> }</span></span> </span> #</span> 5. Repeat multiple times to ensure all nested levels are processed</span></span> for</span> i</span> in</span> {</span>1..5}</span>;</span> do</span></span> echo</span> "</span>Processing level </span>$</span>i</span>"</span></span> process_level</span></span> done</span></span></code></pre>Hugging Face</h3> HF 镜像：export HF_ENDPOINT=https://hf-mirror.com</code></p> ModelScope：modelscope.cn</a></p> "口袋里的 GPT"，离我们还有多远？ 2023-11-21T00:00:00+00:00 微信公众号版本：「口袋里的 GPT」，离我们还有多远？</a></p> </blockquote> 初识 GPT</h2> 2022 年 11 月 30 日，OpenAI 正式发布 ChatGPT。</p> 2022 年 12 月 5 日，ChatGPT 发布仅 5 天便突破 100 万用户。</p> 在国内，ChatGPT 首先在 2022 年 12 月于科技圈引起关注；而时间来到 2023 年 2 月，ChatGPT 更是在国内彻底爆火出圈，一时间风头无两。最近一段时间，Humane 和 GPTs 等又再度引起了大家的关注。在 2023 年，你从不关心 AI 的父母也要问问你：“GPT“是什么？</strong></p> GPT 全称为 Generative Pre-Trained Transformer</strong>，即生成式预训练 Transformer 模型。具体来说，Transformer 是最早于 2017 年提出的一种基于 Attention 的神经网络架构1</a></sup>，而 GPT 则是由 OpenAI 基于此架构开发的一系列经过大规模文本预训练、可以生成自然语言文本的模型。当下备受关注的“大模型“，主要就是指以 GPT 为代表的这类基于 Transformer 架构的大规模生成式模型。</p> 最近一年来，除了 GPT 外，新的大模型如雨后春笋一般发布，例如 Meta 开源的 LLaMA 以及基于 LLaMA 的诸多模型。这些模型整体上仍沿用类似于 GPT 的架构，但在模型超参数、训练数据、训练方法等方面各有不同。除了“大模型“这个称谓外，大语言模型（Large Language Model, LLM）和基础模型（Foundation Model, FM）等通常也是指它们，只是各有侧重。为了简便，本文中统称为大模型</strong>或 LLM</strong>。</p> 口袋里的 GPT</h3> 现阶段的大模型在对话、写作、编程等任务上已经表现出接近甚至超越人类的水平。这让很多人觉得我们距离通用人工智能（Artificial General Intelligence, AGI）又近了一步，大模型也的确展现出了改变现有生产方式的可能性。人们的想象力在此时无限延展，以往只出现在科幻作品中的场景似乎也近在咫尺，颇有“未来已来“之感。</p> 让每个人都拥有一个定制的大模型，并让它成为随身携带的私人助理</strong>，就是其中颇具吸引力的一个想法——它也许是你口袋中的一个智能终端，也许是眼镜等可穿戴设备，亦或是任何更酷的形式。这个“口袋里的 GPT</strong>“可以帮你处理文书、安排日程，甚至代替你与他人（或他们的智能助理）交互。</p> 然而现实与理想之间却总是存在差距。除了当前模型、算法上的差距外，隐私安全与网络延迟</strong>也是极为重要的因素。一个高度定制化、深度参与用户日常生活的智能助理，必然需要处理大量的用户隐私数据，而使用部署在云端的大模型服务则给个人隐私安全带来了严重的隐患。同时，未来海量用户产生的大量推理请求也会对网络传输带来更大的压力，难以满足某些高实时性应用的要求。在端侧直接部署大模型，一方面便于解决上述问题，另一方面也将面临独特的挑战。</strong></p> 大模型端侧部署的挑战</h2> 资源受限</h3> 在端侧部署大模型的首要挑战，就是设备上有限的硬件资源难以满足大模型的需求。</strong> 大模型出色的能力是建立在其庞大参数量的基础上的。例如，视觉领域经典的 CNN 模型 ResNet 参数量大致在 10M–60M 之间，而 GPT-3 的参数量达到 175B，比前者大 3–4 个数量级。于是，仅仅加载模型权重所需的内存就从 100 MB 上下飙升至几百 GB，更不要提计算中间数据的保存了。</p> 即便是像 LLaMA 7B 这样更适合部署在端侧的“小模型“，也比以 MobileNet 系列为代表的轻量级 CNN 参数量大 3 个数量级。如果以半精度浮点数估计，需要至少 14 GB 内存才能勉强放下全部模型参数，而这已经远超市面上许多中端设备的内存容量。除了前向推理之外，如果希望根据用户数据在本地对模型进行微调训练，则会对内存与算力提出更高要求。</p> 计算低效</h3> 端侧大模型的部署以推理为主，而大模型本身的推理效率，是其在端侧部署的另一个重要挑战。</strong> 即便我们设法压缩模型并提供匹配的硬件资源，解决了可行性</strong>问题，仍然还需要解决大模型运行的延迟和功耗</strong>带来的实用性</strong>问题——我们当然不希望数字小秘书以秒为单位龟速输出，同时还热得烫手（> <）。而当前大模型推理低效的一个主要原因，在于其计算-访存比低，无法充分利用计算资源</strong>。</p> 所谓的计算-访存比，也就是系统领域著名的 Roofline Model</strong>2</a></sup> 中的 Operational Intensity（计算强度）。它定义为每访问 1 byte 内存平均需要完成的计算操作次数。对于给定的硬件平台，目标任务的计算-访存比越低，计算单元每完成一次计算平均需要访问的内存也就越多。当硬件的内存带宽被占满时，即便再减少计算量或提供更多算力，也无法带来实际的性能提升。这时称系统受内存带宽限制（memory-bound）；反之则受计算能力限制（compute-bound）。典型的端侧大模型生成任务往往受内存带宽限制。</strong></p> 端侧大模型推理的计算-访存比低，是由其工作负载的特点决定的。</strong> 由于硬件资源和应用场景的限制，端侧大模型通常不会处理高并发的请求，且大部分时候仅有一个请求，即 batch size = 1。同时，模型处理的文本长度也较为有限。于是在生成阶段，模型中的计算主要是矩阵向量乘和“高瘦“的矩阵乘，其模型权重每次加载后参与计算的次数较少，于是权重加载（内存访问）就成为了系统的瓶颈。</p> 现有方法</h2> 为了解决前文所述的大模型在端侧部署的资源受限</strong>和计算低效</strong>两大问题，已有的工作可以分为模型压缩与推理优化两类方法。在实际部署中，两类方法往往需要综合使用，以达到最优效果。</p> 模型压缩</h3> 要想降低模型的内存与算力开销，最直接的方法就是降低模型的大小。大模型常用的压缩方法包括量化、剪枝、蒸馏和低秩分解等。本节简单介绍这几种常用方法，也欢迎感兴趣的同学自行深入了解。</p> 量化（Quantization）</strong>3</a></sup>^{, </sup>}4</a></sup>^{, </sup>}5</a></sup>^{, </sup>}6</a></sup> 即用更少的 bit 数来表示模型参数，从而有效降低模型大小。按照是否在量化过程中训练模型，量化方法还可进一步分为训练后量化（Post-Training Quantization, PTQ）和量化感知训练（Quantization-Aware Training, QAT）。低 bit 量化（如 4-bit、3-bit）是当前研究探索的一个重要方向。</p> 剪枝（Pruning）</strong>7</a></sup>^{, </sup>}8</a></sup>^{, </sup>}9</a></sup> 即去除模型中一部分不重要的权重，从而降低模型的存储与计算开销。剪枝方法也可进一步分为结构化（structured）与非结构化（unstructured）两种，其中结构化剪枝对硬件计算更加友好。</p> 蒸馏（Distillation）</strong> 即使用已有的效果较好的 Teacher 模型（参数量大、精度高），去指导训练一个轻量的 Student 模型（参数量小，精度低），使得小模型输出与大模型接近。蒸馏方法常与量化和剪枝方法配合使用。</p> 低秩分解（Low-Rank Factorization）</strong> 即通过两个低秩矩阵的乘积来近似原权重矩阵，从而降低模型参数量和计算量。LoRA10</a></sup>（Low-Rank Adaptation）及其变体就是一种利用低秩分解实现高效模型微调的方法。</p> 推理优化</h3> 除了模型压缩外，端侧 LLM 推理的计算过程也存在许多优化空间。为了解决延迟、内存等方面的问题，已有的工作中提出了如下方法。</p> KV Cache</strong> 是一种以内存换时间的优化方法，在目前的推理框架中被普遍使用。其核心思想是将 Attention 计算中每次迭代包含重复计算的张量（也即 K 和 V）保存下来，并且随着序列的生成进行增量更新，从而避免重复计算。当序列长度增加时，KV Cache 的大小也会显著增长，需要采用适当的策略进行内存管理11</a></sup>^{, </sup>}12</a></sup>。</p> 投机采样（Speculative Sampling）</strong>13</a></sup>^{, </sup>}14</a></sup>^{, </sup>}15</a></sup> 能够在 small-batch 场景下提高吞吐量。所谓投机采样，即先通过一个轻量的小模型（draft model）生成（猜测）一组 token，再交由目标模型（target model）进行评估检验。对 draft model 一次生成的多个 token，可以通过一次目标模型前向计算并行验证，从而提高解码吞吐。</p> 算子优化</strong>目前的一个重要方向，是对 Attention</strong> 计算的优化。相比以稠密线性层为主的 FFN，Attention 包含随序列长度变化的矩阵乘、Softmax 等操作，需要针对访存和并行方式进行专门优化。近期的代表工作有 Flash-Decoding16</a></sup> 和 FlashDecoding++17</a></sup> 等。</p> 流式加载（Stream Loading）</strong> 即每次仅加载一部分权重到内存（或显存）中进行推理，从而降低整体的内存（显存）占用。FlexGen18</a></sup> 通过对 GPU–CPU offloading 策略的设计实现了高吞吐的单卡 LLM 推理。但在要求低延迟而非高吞吐的场景下，由于 LLM 加载权重的开销过大，这类方法并不适用。</p> 总结与展望</h2> 本文主要介绍了目前端侧大模型部署中的挑战与已有技术，其中涵盖了模型压缩与系统优化中的多个方向。笔者希望通过阅读本文，感兴趣的同学能够快速补充背景知识、了解最新进展。</strong></p> 虽然文中已列出许多已有工作，但如何通过模型压缩与推理系统的协同优化，进一步降低大模型推理的硬件需求和功耗、提升大模型在资源受限设备上的运行效率，仍是一个重要的待解决问题。欢迎感兴趣的同学深入交流讨论（以及写得不好的地方多拍砖 0.0）。</strong></p> ^1</sup>Ashish Vaswani et al., “Attention Is All You Need”</a>, NeurIPS, 2017.</p> </div> ^2</sup>Samuel Williams, Andrew Waterman, and David Patterson, “Roofline: An Insightful Visual Performance Model for Multicore Architectures”</a>, Communications of the ACM</em>, 2009.</p> </div> ^3</sup>Elias Frantar et al., “GPTQ: Accurate Post-Training Quantization for Generative Pre-Trained Transformers”</a>, ICLR, 2023.</p> </div> ^4</sup>Guangxuan Xiao et al., “SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models”</a>, ICML, 2023.</p> </div> ^5</sup>Ji Lin et al., “AWQ: Activation-Aware Weight Quantization for LLM Compression and Acceleration”</a>, MLSys, 2024.</p> </div> ^6</sup>Zechun Liu et al., “LLM-QAT: Data-Free Quantization Aware Training for Large Language Models”</a>, arXiv, 2023.</p> </div> ^7</sup>Elias Frantar and Dan Alistarh, “SparseGPT: Massive Language Models Can Be Accurately Pruned in One-Shot”</a>, ICML, 2023.</p> </div> ^8</sup>Xinyin Ma, Gongfan Fang, and Xinchao Wang, “LLM-Pruner: On the Structural Pruning of Large Language Models”</a>, NeurIPS, 2023.</p> </div> ^9</sup>Mingjie Sun et al., “A Simple and Effective Pruning Approach for Large Language Models”</a>, ICLR, 2024.</p> </div> ^10</sup>Edward J. Hu et al., “LoRA: Low-Rank Adaptation of Large Language Models”</a>, ICLR, 2022.</p> </div> ^11</sup>Woosuk Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention”</a>, SOSP, 2023.</p> </div> ^12</sup>Reiner Pope et al., “Efficiently Scaling Transformer Inference”</a>, MLSys, 2023.</p> </div> ^13</sup>Yaniv Leviathan, Matan Kalman, and Yossi Matias, “Fast Inference from Transformers via Speculative Decoding”</a>, ICML, 2023.</p> </div> ^14</sup>Charlie Chen et al., “Accelerating Large Language Model Decoding with Speculative Sampling”</a>, arXiv, 2023.</p> </div> ^15</sup>Benjamin Spector and Chris Ré, “Accelerating LLM Inference with Staged Speculative Decoding”</a>, arXiv, 2023.</p> </div> ^16</sup>Tri Dao et al., “Flash-Decoding for Long-Context Inference”</a>, Stanford CRFM Blog, 2023.</p> </div> ^17</sup>Ke Hong et al., “FlashDecoding++: Faster Large Language Model Inference on GPUs”</a>, MLSys, 2024.</p> </div> ^18</sup>Ying Sheng et al., “FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU”</a>, ICML, 2023.</p> </div>}

用向量查表真正加速低比特 LLM 的并行推理

2026-07-11T00:00:00+00:00

🏆 ACM MobiSys 2026 最佳论文奖亚军
🔗 论文</a> | 代码</a> | 演示文稿</a> | 中文介绍（清华 AIR 公众号）</a> </blockquote>
如今的超低比特 LLM（通常每个权重低于 4 比特）占用的内存很小。例如，微软 2B BitNet 模型的权重只占约 0.4 GB 1</a>。照理说，它们应该能在笔记本电脑或智能手机上高速运行，对吗？
并不必然如此。 更低的位宽可以减少内存占用，但只有底层推理内核与数据表示和工作负载相匹配时，才能真正转化为速度优势。**查找表（lookup table, LUT）**内核在单 token 生成时表现很好，但并行处理大量 token 时，这种优势会大幅减弱。Vec-LUT 针对的正是这种并行访问模式。在五款 x86 和 ARM 设备上，与每权重位数（bits per weight, BPW）相近的基线相比，它将端到端预填充加速至多 4.2 倍；在 Snapdragon 8 Elite 上，其 CPU 实现甚至只用两个 CPU 核心，就超过了手机 NPU（llama.cpp 的 Hexagon 后端）。
Download the video</a>. </video>
Vec-LUT 与 llama.cpp 对比：在单个 CPU 核心上进行 32 路并行解码，端到端速度提升 3 倍。</figcaption> </figure>

在 CPU 上进行端侧 LLM 推理</h2>
移动助手、本地智能体和具身智能系统如今都在使用端侧模型，而这些设备的内存依然有限。量化研究已经从 8 比特 2</a>推进到 4 比特 3</a>、2 比特 4</a>，再到如今的 1.58 比特三值模型。这类模型的权重取值为 {-1, 0, 1}</code>，微软的 BitNet</a>5</a> 让这种格式得到了广泛关注。
较小的权重取值集合也让基于查找表（LUT）的推理成为可能：内核不必在运行时反量化低比特权重、再与激活值相乘，而是可以预先计算一张小表，用查表替代大部分算术运算。此前，bitnet.cpp</a>6</a> 和 T-MAC</a>7</a> 等基于 LUT 的系统已经证明，CPU 在单 token 生成场景中也能具备竞争力。Vec-LUT 要回答的问题是：当工作负载变为并行处理时，同样的思路能否继续保持高效？
基于 LUT 的推理如何工作</h2> 量化 LLM 推理中的一项主要开销是混合精度通用矩阵乘法（mixed-precision general matrix multiplication, mpGeMM），例如用 1.58 比特权重乘以 INT8 或 FP16 激活值。通用 CPU 和许多边缘加速器并不原生支持这类混合精度运算，因此推理框架通常需要反量化或定制内核8</a>。 基于 LUT 的 mpGeMM 在量化 Transformer 层中以查表取代反量化和乘法。</figcaption> </figure> 基于 LUT 的推理首先将权重矩阵拆成若干小组。低比特权重只有很少的可能模式：四个三值权重仅有 3^4 = 81</code> 种组合。对于给定的激活向量，内核可以预先计算每一种“权重模式 × 激活值”的结果，并将其存入表中。运行时，打包后的权重组会成为这张表的索引，内核因而可以在内层循环中跳过反量化和乘法，转而累加查表所得的值。 一个具体的 LUT 示例：将三值权重组作为查表索引，计算 o = w × v。</figcaption> </figure> 并行时，位宽更低 ≠ 速度更快</h2> 问题出在并行性上。现有 LUT 内核遵循一种我们称为标量 LUT 的范式，即 1→1</code> 查表。每个 token 都有一张自己的表，因此处理 N 个 token 意味着构建或访问 N 张表，并执行 N 条独立的查表流。 在单 token 生成时，标量 LUT 效果很好，因为此时只有一张表和一条查表流，现有内核可以有效利用可用的内存带宽。但真实工作负载中，并行推理非常常见：中长提示词的预填充9</a>^、10</a>、同时服务多个请求11</a>^、12</a>、测试时并行扩展13</a>^、14</a>以及推测解码15</a>^、16</a>，都会同时处理多个 token。在这些场景中，标量 LUT 会失去大部分优势： 内存带宽利用率降至 40% 以下。</li> 有时甚至比完全不用 LUT 还慢。</li> </ul> 根源在于内存访问。查表是一种随机且不连续的操作。在多张按 token 划分的表上重复查找，尤其是这些表的总工作集超过缓存容量时，大量时间会耗在搬运分散的数据上，而不是有效的累加运算。在我们对一个典型标量 LUT 内核的性能分析中，查表（包括加载权重）占 mpGeMM 延迟的近一半。 下表展示了 T-MAC 标量 LUT mpGeMM 内核的耗时分布，数据来自 Orange Pi 5 Plus 上的单线程测试： GeMM 形状（M × K</code>）</th> 预计算</th> 查表</th> 累加</th> 缩放</th></tr></thead> 320 × 3200</code></td> 0.8%</td> 47.6%</td> 25.0%</td> 26.6%</td></tr> 128 × 8640</code></td> 0.7%</td> 47.3%</td> 25.5%</td> 26.4%</td></tr> </tbody></table> 对于并行推理，仅仅优化算术运算无法消除这个由查表主导的内存瓶颈。 核心思路：一次查出 N 个结果</h2> 关键观察是：查表索引来自权重，而所有 token 共享同一组权重。 同一个权重索引适用于并行组中的每个 token，因此没有必要按 token 分别查表。 Vec-LUT 将查表单位从标量变为向量。它不再为每个 token 建一张表，而是为所有并行 token 构建一张统一的表。表中的每个条目不再存储单个标量结果，而是存储一个结果向量，其中每项对应一个 token。这样，一个权重索引就能触发一次 1→N</code> 查表，取回整个 token 组的结果。 Vec-LUT：将按 token 执行的 1→1 查表转化为一次跨 token 的 1→N 查表。</figcaption> </figure> 由此产生的访问模式有三个优点： 每个权重索引原本需要 N 次独立查表，现在只需一次向量查表。</li> 随机、分散的查表变为连续的向量读取，随后执行向量累加。</li> 内核不再依赖 ARM TBL</code> 或 x86 PSHUF</code> 等硬件查表指令，减少了对特定指令集架构（ISA）的依赖。</li> </ul> 在我们的延迟分解中，查表所占比例从 T-MAC 的 47% 降到了 1% 以下。 让向量 LUT 真正实用</h2> 向量 LUT 在实践中能否高效，取决于两个工程细节。 张量布局。 只有周围张量采用兼容的布局，统一查找表才能发挥作用。布局不匹配会使内核速度降低至多 12 倍。我们的**以向量 LUT 为中心的张量布局（Vector LUT-Centric Tensor Layout）**让激活、查找表和输出按 token 连续存储，打包权重则按分块连续存储。权重重排在线下完成，运行时的激活与输出变换则融合进内核，以尽量减少额外开销。 </li> 缓存局部性。 向量 LUT 会使表的大小增加 N 倍。序列长度为 512 时，Llama3 8B 的一次 GeMM 所需的 2 比特 INT16 向量表将超过 280 MiB，远超边缘 CPU 的缓存容量。我们的**缓存感知流式查表（Cache-Aware Streamed Lookup）**将预计算和查表流水线切分为与缓存容量相适应的小块，再依次流式处理，使大部分 LUT 工作留在片上缓存中，避免反复访问一张巨大的随机访问表。 </li> </ul> 摆脱硬件查表指令后，位宽和形状限制也随之放宽。由此，我们可以采用灵活的低于 2 比特打包：I1</code> 打包达到每权重 1.60 比特，同时支持范围广泛的权重形状。拓扑预计算、INT16–INT32 分层累加等进一步优化，则减少了剩余开销。 实验结果：5 款设备 × 3 个模型</h2> 我们在五款 x86/ARM 设备（台式机、笔记本电脑、单板计算机、智能手机和 CPU 服务器）以及三个三值 LLM——Falcon3 1B、HF BitNet 3B 和 Llama3 8B——上评估了 Vec-LUT。 端到端预填充： 与 BPW 相近的基线相比，I1</code>（1.60 BPW）加速至多 4.2 倍，I2</code>（2.00 BPW）加速至多 2.6 倍。</li> CPU 对比 NPU： 在 Snapdragon 8 Elite 上，Vec-LUT I2</code> 仅使用 2 个 CPU 核心，进行 Llama3 8B 预填充时的吞吐量即可达到 llama.cpp Q4_0 Hexagon NPU 后端的 1.05–1.12 倍。</li> 连续批处理： 在一台 8 核、每小时 0.50 美元的 AWS Graviton 3 服务器上，Vec-LUT I2</code> 面对 32 个并行请求时，以 273.5 tokens/s 的速度服务 Falcon3 1B，比 llama.cpp TQ2_0</code> 快 1.4 倍。</li> 能效： 相比 llama.cpp，每焦耳生成的 token 数至多提高 2.1 倍；相比 T-MAC，至多提高 1.8 倍。</li> </ul> 不同模型、设备和线程数下的端到端预填充性能对比。</figcaption> </figure> 实现与适用范围</h2> 我们的实现 vlut.cpp 是 llama.cpp</a> 的轻量扩展。它面向主流 x86 和 ARM CPU，沿用了大家熟悉的 llama.cpp 式构建和使用流程，并作为开源 OpenBitSys</a> 项目的一部分发布。 当三值模型检查点可用（例如通过量化感知训练获得）、工作负载包含大量并行推理（预填充、批处理、推测解码或并行测试时扩展），且 CPU 内存占用和吞吐量是主要限制时，Vec-LUT 最能发挥作用。 Vec-LUT 将查表开销降到 1% 以下后，向量加法（即累加查表结果）会成为主要开销。在实测的 HF BitNet 3B 工作负载中，它约占端到端预填充延迟的 65%，自然也就成为未来以向量 LUT 为中心的加速器值得重点优化的目标。 我们的团队正在招聘博士后和实习生，研究方向包括物理 AI 基础模型、LLM 训练与推理系统等。欢迎联系曹汀老师</a>。 ^1Shuming Ma et al., “BitNet b1.58 2B4T Technical Report”</a>, arXiv, 2025. </div> ^2Tim Dettmers et al., “LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale”</a>, NeurIPS, 2022. </div> ^3Elias Frantar et al., “GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers”</a>, ICLR, 2023. </div> ^4Mengzhao Chen et al., “EfficientQAT: Efficient Quantization-Aware Training for Large Language Models”</a>, ACL, 2025. </div> ^5Shuming Ma et al., “The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits”</a>, arXiv, 2024. </div> ^6Jinheng Wang et al., “bitnet.cpp: Efficient Edge Inference for Ternary LLMs”</a>, ACL, 2025. </div> ^7Jianyu Wei et al., “T-MAC: CPU Renaissance via Table Lookup for Low-Bit LLM Deployment on Edge”</a>, EuroSys, 2025. </div> ^8Shijie Cao, Lingxiao Ma, and Ting Cao, “Advances to low-bit quantization enable LLMs on edge devices”</a>, Microsoft Research Blog, 2025. </div> ^9Hao Wen et al., “AutoDroid: LLM-powered Task Automation in Android”</a>, MobiCom, 2024. </div> ^10Leming Shen et al., “AutoIOT: LLM-Driven Automated Natural Language Programming for AIoT Applications”</a>, MobiCom, 2025. </div> ^11Zheyu Shen et al., “EdgeLoRA: An Efficient Multi-Tenant LLM Serving System on Edge Devices”</a>, MobiSys, 2025. </div> ^12Borui Li et al., “MobiLoRA: Accelerating LoRA-Based LLM Inference on Mobile Devices via Context-Aware KV Cache Optimization”</a>, ACL, 2025. </div> ^13Mouxiang Chen et al., “Parallel Scaling Law for Language Models”</a>, NeurIPS, 2025. </div> ^14Ryan Ehrlich et al., “CodeMonkeys: Scaling Test-Time Compute for Software Engineering”</a>, arXiv, 2025. </div> ^15Yaniv Leviathan et al., “Fast Inference from Transformers via Speculative Decoding”</a>, ICML, 2023. </div> ^16Charlie Chen et al., “Accelerating Large Language Model Decoding with Speculative Sampling”</a>, arXiv, 2023. </div> 增强 vLLM 对 GPTQv2 格式的支持：分析与实现 2025-10-12T00:00:00+00:00 Issue（已关闭）：#26343</a> Pull request（已合并）：#26092</a> Commit：5cc6bdd</code></a> </blockquote> 引言</h2> 在这次改动之前，vLLM 对 GPTQv2 格式模型的支持并不完善，采用低比特（2/3-bit）或非对称量化的模型尤其如此。vLLM 加载这些模型时不会明确报错，却会将其按 GPTQv1 处理，导致推理质量下降，并经常重复生成 !!!</code> token（参见 issue #26343</a>）。 问题来自 GPTQv1 与 GPTQv2 checkpoint 在零点处理方式上的差异，而 vLLM 的 fallback GPTQ GeMM 内核没有考虑这一点。本文分析了故障原因，并记录 PR #26092</a> 中的内核改动：在保持向后兼容的同时加入 GPTQv2 支持。 最终实现让 vLLM 的 fallback GPTQ 路径能够支持采用低比特和非对称配置的 GPTQv2 模型。 背景与预备知识</h2> 我是在使用 vLLM 部署以 GPTQv2 格式存储的低比特（如 2-bit）非对称量化模型时遇到这个问题的。 介绍实现细节前，先说明两点背景： 非对称量化会为每组权重调整零点，因此对低比特量化很有帮助。</li> GPTQv2 能在非对称量化 checkpoint 中更完整地保留零点信息。</li> </ul> LLM 的权重量化</h3> 权重量化将高精度模型权重（如 16/32-bit）映射为较少的比特（如 2/3/4/8-bit）。这种方法常用于 LLM 部署，尤其适合资源紧张的场景。 从技术上说，权重量化会把范围较大的高精度权重（例如 FP16 的 $[-65504, 65504]$）映射到有限的量化权重范围（例如 $b$-bit 无符号整数的 $[0, 2^b - 1]$）。这一映射通常需要一个用于压缩取值范围的缩放因子（$scale$），以及一个用于平移零点的偏置（$zero$）。记 $w_o$ 为 $[w_{min}, w_{max}]$ 范围内的原始权重（通常对应一组权重），$w_q$ 为量化后的权重，则一种简单的 $b$-bit 整数量化可写为： \[ scale = \frac{w_{max} - w_{min}}{2^b - 1} \] \[ zero = - \mathrm{round}(\frac{w_{min}}{scale}) \] \[ w_q = \mathrm{clamp}(\mathrm{round}(\frac{w_o}{scale}) + zero) \] 反量化时，按下式恢复原始权重 $\hat{w}_o$： \[ \hat{w}_o = (w_q - zero) \cdot scale \] 根据是否需要零点，可以将量化方法分为两类： 对称量化假设 $w_{max} = -w_{min}$，因此 $zero = \mathrm{round}(\frac{2^b - 1}{2})$ 是固定值。此时只要知道比特宽度，$zero$ 就不再提供额外信息。 </li> 非对称量化不作这一假设。它的 $zero$ 会随权重组而变化，必须将其存储下来，才能准确恢复量化值。 </li> </ul> 大多数 GPTQ 实现采用 4-bit 对称量化。在更低的比特宽度下，非对称量化可以让零点适应每组权重，从而减小量化误差。 GPTQ：量化方法与 Checkpoint 格式</h3> GPTQ1</a> 是生成式 Transformer（主要是 LLM 和 VLM）最常用的训练后量化方法之一。它利用近似二阶信息（层 Hessian 的逆）来减小量化误差。 GPTQ 也可以指 GPTQ 量化模型所使用的 checkpoint 格式，例如 AutoGPTQ</a> 生成的格式。Daniël de Kok 的 GPTQ Checkpoint Format</a> 对这种表示方式有详细说明。 GPTQ 生态既包括实现该量化方法或导出相应 checkpoint 格式的量化库，也包括执行这些 checkpoint 的内核与推理框架。 量化库： GPTQModel</a> 是 AutoGPTQ 仍在积极维护的后继项目，支持更多模型和后端。</li> AutoGPTQ</a> 曾是常用的 GPTQ 量化库，但现已停止维护。</li> gptq</a> 是 GPTQ 论文的官方实现。</li> 其他量化库也会实现 GPTQ 量化，或以 GPTQ 格式导出量化模型。</li> </ul> 计算（CUDA）内核： Marlin</a> 是面向 4-bit GPTQ 模型的高性能 W4A16 mpGeMM 内核。</li> ExLlamaV2</a> 是一个推理库，为 GPTQ 模型提供高性能内核。</li> BitBLAS</a> 是支持 GPTQ 模型的高性能低比特 mpGeMM 内核库。</li> 还有许多其他内核库也支持 GPTQ 格式模型。</li> </ul> vLLM</a> 等 LLM 推理框架会集成这些量化库和内核库，从而高效部署 GPTQ 模型。 从 GPTQv1 到 GPTQv2</h3> GPTQv2 这一名称同时用于指代量化方法和 checkpoint 格式的改动： 量化方法：GPTQv2（也称 GPTAQ）引入非对称校准，以减小从前面各层传播而来的量化误差2</a>。它最早在 GPTAQ</a> 中实现，之后集成进 GPTQModel</a>，可通过 v2=True</code> 启用。</li> Checkpoint 格式：GPTQv2 与 GPTQv1 存储零点的方式不同。GPTQv1 存储 $\mathrm{clamp}(zero - 1)$，并在运行时反量化前加 $1$3</a>；GPTQv2 则直接存储准确的 $zero$ 值，无需调整。在 GPTQModel 中可通过 format="gptq_v2"</code> 启用这一格式。</li> </ul> 与 GPTQv1 一样，量化方法和 checkpoint 格式之间并不绑定。因此，可以： 将其他方法量化的模型存为 GPTQv2 格式，例如 BitDistiller/Qwen-8B-w2g64-gptq</a>。</li> 只在 GPTQModel 中设置 format="gptq_v2"</code>，把采用 GPTQv1 方法量化的模型存为 GPTQv2 格式。</li> 只在 GPTQModel 中设置 v2=True</code>，把采用 GPTQv2 方法量化的模型存为 GPTQv1 格式。</li> </ul> 从 GPTQv1 转换到 GPTQv2 是无损的，反向转换则不是。GPTQv1 的减一表示会把 $0 - 1$ clamp 到 $0$，因此损失一部分零点范围。以 INT2 量化为例，有效范围会从 $[0,3]$ 缩小到 $[1,3]$。所以，GPTQv2 更适合非对称 checkpoint，尤其是在低比特宽度下。 原因分析</h2> 故障源于 vLLM 如何将不同的 GPTQ 配置路由到已有内核： vLLM 有多个兼容 GPTQ 的 GeMM 内核，并为它们预先规定了优先级——包括 Marlin、BitBLAS 和 fallback 内核。</li> Marlin 等优化内核仅在有限配置下支持 GPTQv2——即 4/8-bit 对称量化。</li> fallback 内核支持更多比特宽度和非对称量化，却不支持 GPTQv2——这正是本次问题的根源。</li> </ul> graph TD A[VllmConfig] --> B[ModelConfig._verify_quantization] B --> |"优先级: gptq_marlin > gptq_bitblas > gptq"| E[QuantizationConfig.get_quant_method] E -->|4/8-bit + sym| J[GPTQMarlinLinearMethod] E -->|4/8-bit + sym| K[GPTQBitBLASLinearMethod] E -->|2/3/4/8-bit + sym/asym| L[GPTQLinearMethod] J --> JJ[MarlinLinearKernel] K --> KK[BitBLASLinearKernel] L --> LL[直接调用内核] JJ --> M[gptq_marlin_gemm CUDA 内核] KK --> N[bitblas.Matmul 外部库] LL --> O[gptq_gemm CUDA 内核] M --> Q["✓ Marlin: gptq/gptq_v2"] N --> R["✓ BitBLAS: gptq/gptq_v2"] O --> S["✗ GPTQ: 仅 gptq"] style J fill:#90EE90 style K fill:#90EE90 style L fill:#FFB6C1 style Q fill:#90EE90 style R fill:#90EE90 style S fill:#FFB6C1 </pre> </div> vLLM 的内核路由层级</h3> 首先需要了解 vLLM 如何为 GPTQ 等量化方法选择计算内核。相关逻辑位于 LLMEngine</a> 的模型执行部分。为便于说明，本文只讨论稠密模型，不涉及 MoE。调用层级如下： 1. 模型级量化配置： 在模型实现（vllm/model_executor/models</code>）中，初始化模型时会传入 vllm_config: VllmConfig</code>，其中包含 quant_config: QuantizationConfig</code>。每种量化方式都会扩展 QuantizationConfig</code>，提供与该量化方式相关的 override（例如 GPTQConfig</code>）。参见全部量化方式</a>。</li> 如果 quant_config</code> 中没有指定量化方式，ModelConfig._verify_quantization</code> 会按优先级列表选择一种（见下文</a>）。</li> </ul> </li> 该模型的每个线性模块都以 quant_config</code> 初始化。</li> </ul> 2. 层级量化配置（线性方法）： 初始化时，每个量化线性模块都会确定 quant_method = quant_config.get_quant_method</code>。 get_quant_method</code> 会根据量化配置返回具体的线性方法类（继承自 LinearMethodBase</code>，例如 GPTQLinearMethod</code>）。</li> </ul> </li> 每个线性模块通过 override LinearMethodBase.apply</code> 来调用计算内核（例如 GPTQLinearMethod.apply</code> 调用 gptq_gemm</code>）。</li> </ul> 3.（可选）内核选择（线性内核）： vLLM 支持通过多种方式从线性方法类路由到底层 CUDA 内核： 直接调用。例如，GPTQLinearMethod</code> 直接路由到 gptq_gemm</code>，这是 vLLM 注册的自定义算子（实现在 csrc/quantization/gptq</code>）。</li> 间接调用。如果一个线性方法有多个可用内核，或一个内核可供多个线性方法使用，vLLM 可以扩展 MPLinearKernel</code> 类，并将其作为路由到该内核的接口（位于 vllm/model_executor/layers/quantization/kernels/mixed_precision</code>）。例如，GPTQBitBLASLinearMethod</code> 路由到 BitBLASLinearKernel</code>，GPTQMarlinLinearMethod</code> 则调用 choose_mp_linear_kernel</code> 进行灵活路由。</li> 外部调用（与上述方式正交）。vLLM 支持调用外部库中的内核。例如，BitBLASLinearKernel</code> 会调用 bitblas</code> Python 库中的 Matmul</code>。</li> </ul> vLLM 对 GPTQ(v2) 格式的支持</h3> vLLM 集成了多个适用于 GPTQ 格式模型的优化内核，包括 Marlin、ExLlamaV2 和 BitBLAS，同时也为不受支持的配置提供 fallback 内核。按线性方法划分，支持矩阵如下： 方法</th> Bits</th> Sym</th> GPTQ 格式</th></tr></thead> GPTQMarlin</td> 4,8</td> True</td> gptq, gptq_v2</code></td></tr> GPTQBitBLAS</td> 4,8</td> True</td> gptq, gptq_v2</code></td></tr> GPTQ</td> 2,3,4,8</td> Any</td> gptq</code></td></tr> </tbody></table> </a> 说明： 所有方法都支持 4/8-bit 对称量化。vLLM 会根据预定义的量化 override 优先级（位于 ModelConfig._verify_quantization</code>），选择当前配置下支持且性能最好的方法：</li> </ul> overrides = [ ... # gptq_marlin_24 requires special format, # so we don't consider here. "gptq_marlin_24", # Priority: gptq_marlin > gptq_bitblas > gptq. "gptq_marlin", "gptq_bitblas", ... ]</code></pre> 只有 GPTQLinearMethod</code> 支持 2/3-bit 和非对称量化，但它此前不支持 GPTQv2；另外两种方法已经支持该格式。</li> </ul> 因此，vLLM 的这条 fallback 路径既无法支持 GPTQv2 格式的 2/3-bit 量化，也无法支持其非对称量化，这正是 PR #26092</a> 的动机。 解决方案</h2> 根据以上分析，需要调整一个 GPTQ 线性方法及其内核，才能让 GPTQv2 模型覆盖这些配置。 方案：调整 GPTQ 线性方法与内核</h3> 要加入这项支持，至少需要调整一种现有的线性方法： GPTQMarlinLinearMethod</code> 不支持 2/3-bit 和非对称量化。扩展它还需要修改 vLLM 的 Marlin CUDA 内核，而该内核面向 4/8-bit 对称量化。</li> GPTQBitBLASLinearMethod</code> 在线性方法层面同样不支持 2/3-bit 和非对称量化。虽然 bitblas</code> 库支持所需的 bits</code> 与 sym</code> 取值，但这条路径依赖可选的 bitblas</code> 包。</li> GPTQLinearMethod</code> 已经支持所需的比特宽度和对称/非对称模式，只需在 gptq_gemm</code> CUDA 内核中根据格式处理零点，因此是首选方案。</li> </ul> 因此，实现中选择调整 GPTQLinearMethod</code>（及 GPTQConfig</code>）和 gptq_gemm</code>，为它们加入 GPTQv2 支持。 调整细节：根据格式选择处理方式</h3> 线性方法与内核的调整需要满足三项要求： 保持与 GPTQv1 格式的兼容性。</li> 尽量减小对代码和二进制大小的影响。</li> 保持现有路由，让 GPTQv2 模型仍可选择 Marlin 等其他内核。</li> </ol> 为满足前两项要求： 为 GPTQLinearMethod</code> 添加 use_v2_format: bool</code> 属性，用于表示 checkpoint_format == "gptq_v2"</code>。</li> 为 gptq_gemm</code> 添加 bool use_v2_format</code> 参数，以 GPTQLinearMethod.use_v2_format</code> 作为输入。</li> 在 gptq_gemm</code> 中，根据 use_v2_format</code> 调整零点处理逻辑。例如：</li> </ul> // In `reconstruct_exllama_2bit_kernel`: // Previous: zeros[i] + 1 (hardcoded for GPTQv1) dequant_2bit_16(load_int4.x, dq[0], size_n, zeros[0] + 1); dequant_2bit_16(load_int4.y, dq[1], size_n, zeros[1] + 1); dequant_2bit_16(load_int4.z, dq[2], size_n, zeros[2] + 1); dequant_2bit_16(load_int4.w, dq[3], size_n, zeros[3] + 1); // Now: zeros[i] + offset (conditioned on `use_v2_format`) int zero_offset = use_v2_format ? 0 : 1; ... dequant_2bit_16(load_int4.x, dq[0], size_n, zeros[0] + zero_offset); dequant_2bit_16(load_int4.y, dq[1], size_n, zeros[1] + zero_offset); dequant_2bit_16(load_int4.z, dq[2], size_n, zeros[2] + zero_offset); dequant_2bit_16(load_int4.w, dq[3], size_n, zeros[3] + zero_offset); </code></pre> 测试期间，我发现原有的 gptq_gemm</code> 即使处理对称量化的 GPTQv1 模型，在 4-bit 下也存在 bug。这超出了该 PR 的范围。 </blockquote> 对于第三项要求，GPTQMarlinLinearMethod</code> 和 GPTQBitBLASLinearMethod</code> 都不作改动：它们已经支持 GPTQv2，只是仅限于 4/8-bit 对称量化。 TODO：补充一些性能基准测试。我发现 2-bit gptq_gemm</code> 在解码（GeMV）时比预填充（GeMM）时更慢。 </blockquote> 总结</h2> 这项改动为 vLLM 的 fallback GPTQ 路径加入了 GPTQv2 支持，在保持 GPTQv1 兼容性的同时，覆盖了低比特和非对称配置。 欢迎提问与讨论。 后续可做的工作： 扩展优化内核（Marlin、BitBLAS），使其支持 2/3-bit 或非对称量化。</li> 修复 gptq_gemm</code> 的 4-bit bug。</li> 提升 gptq_gemm</code> 的解码速度。</li> </ul> ^{1 Elias Frantar 等，“GPTQ: Accurate Post-Training Quantization for Generative Pre-Trained Transformers”</a>，ICLR，2023。 </div> ^2Yuhang Li 等，“GPTAQ: Efficient Finetuning-Free Quantization for Asymmetric Calibration”</a>，arXiv，2025。 </div> ^3Daniël de Kok，“GPTQ Checkpoint Format”</a>，Daniël’s Website，2024。 </div> 视觉—语言—动作（VLA）模型：近期进展综述 2025-09-16T00:00:00+00:00 我刚开始接触这个领域，欢迎讨论，也欢迎提出任何问题！本文根据我的幻灯片</a>整理而成。 </blockquote> 背景与概念</h2> 视觉—语言—动作（VLA）模型的概念</h3> 在我的理解中，视觉—语言—动作（Vision-Language-Action，VLA）模型1</a>是面向具身智能的多模态基础模型。它以视觉（如视频流中的观测）和语言（如用户指令）为输入，输出机器人的底层动作（即控制策略）。 VLA 使用视觉—语言模型（VLM）来生成以视觉和语言为条件的动作。 VLA 的概念，以及汇聚到现代 VLA 系统的几条研究脉络。</figcaption> </figure> 为长程任务加入基于 VLM 的任务规划器</h3> 早期 VLA 主要关注机器人的底层控制。除非对整个任务进行端到端训练，否则仅靠底层控制不足以完成复杂的长程任务。一种做法是加入基于 LLM/VLM 的任务规划器，把长程任务分解为较简单的子任务，再交给 VLA 依次完成。较早的工作通常采用独立模型作为任务规划器；近期工作则让任务规划和控制共享同一个 VLM 主干，即采用双系统架构。 高层规划器将长程指令分解为多个子任务，再交给底层 VLA 控制策略执行。</figcaption> </figure> VLA 的近期进展</h2> 我从两个维度概括 VLA 的近期进展：**从仅有系统 1（控制）走向双系统（规划 + 控制），以及从离散动作走向连续动作。**由此可以得到四个象限： 按动作表示和系统架构划分的近期 VLA。</figcaption> </figure> 下面依次介绍这几类方法。 离散 VLA</h3> 离散 VLA 生成离散动作 token。它先将机器人的底层动作映射为离散 token，再训练 VLM 像生成文本 token 一样，以自回归方式生成动作 token。这样，动作和语言便有了统一的表示，也把下一个 token 预测扩展为下一个动作预测。不过，自回归生成可能带来较高延迟和较低的控制频率，因为每生成一个新的动作 token，都需要再次运行 VLA。 代表性方法包括： RT-2^{2</a>（ViT + PaLI-X/PaLM-E）：首次提出并推广了“VLA”这一术语的开创性工作。</li>} OpenVLA3</a>（DINOv2 & SigLIP + Llama 2 7B）：颇具影响力的开源 VLA 模型（在 GitHub</a> 上有 3.8k stars）。</li> FAST4</a>：一种使用 DCT（离散余弦变换）压缩动作序列的动作 tokenizer。</li> </ul> OpenVLA 将机器人动作视为离散 token，由预训练 VLM 以自回归方式生成。</figcaption> </figure> 连续 VLA</h3> 连续 VLA 从连续动作空间中采样。这样能实现更平滑、精度更高的控制，但也更难在现有语言模型之上训练。 Physical Intelligence 的做法是在预训练 VLM 上加入一个流匹配动作专家，并基于预训练的 PaliGemma 2B VLM 训练 $\pi_0$5</a>。 预训练 VLM 从互联网规模的数据中获得语义理解和泛化能力，流匹配动作专家则从跨本体数据中学习高频（最高 50 Hz）控制。之后，还可以针对困难任务或未见过的任务对模型进行微调。 π₀ 将预训练 VLM 与流匹配动作专家结合，实现连续控制。</figcaption> </figure> 类似地，NVIDIA Isaac 训练了 GR00T N1(.5)6</a>。它将预训练 Eagle-2 VLM 与基于扩散模型的动作头相结合，作为通用人形机器人的基础模型。在 $\pi_0$ 和 GR00T 中，VLM 主干与动作专家通过注意力模块交互，使生成的动作以 VLM 的隐状态（即 KV）为条件。二者在技术上有两点区别： 注意力机制：$\pi_0$ 将视觉—语言部分与动作部分的 KV 拼接起来，再进行掩码自注意力计算（这篇博文</a>给出了很清楚的图示）；GR00T 则直接在两部分之间进行交叉注意力计算。</li> 参与计算的 VLM 层数：$\pi_0$ 让动作专家的层数与 VLM 主干对齐，并在每一层进行自注意力计算（类似 MoE）；GR00T 只保留 VLM 最后一层的隐状态7</a>，动作专家的每一层都与它进行交叉注意力计算。</li> </ul> 双系统 VLA</h3> 与“系统 1 VLA + 独立 LLM/VLM 任务规划器”的组合不同，双系统 VLA 还会使用自身的 VLM 主干进行规划。因此，系统 2（高层规划）和系统 1（底层控制）共享同一个 VLM。 VLA 学习直接根据用户指令预测子任务，由此提升开放世界中的泛化能力，同时比采用独立规划器模型消耗更少的资源。 问题：共享 VLM 是否能通过对齐系统 1 和系统 2 来提升性能？反过来，两者的目标是否也可能互相干扰？ </blockquote> π₀.₅ 在 π₀ 的基础上加入高层子任务预测，实现双系统规划与控制。</figcaption> </figure> Physical Intelligence 训练的 $\pi_{0.5}$8</a> 是这一类别中的首个模型。与 $\pi_0$ 相比，它的训练数据还包括目标检测、指令、子任务命令和离散动作。推理时，其 VLM 先根据高层提示预测一个子任务（系统 2），随后由 VLM 和动作专家执行该子任务（系统 1）。近期的 VLA，如 Galaxea 的 G09</a> 和 X Square Robot 的 WALL-OSS10</a>，都沿用了这一训练方法和推理流程。这类模型大多采用连续 VLA，但 WALL-OSS 也提供了使用 FAST tokenization 的离散版本（WALL-OSS-FAST</a>）。 各模型的仓库和开源情况如下： $\pi_{0.5}$：已公开模型权重，部分代码发布于 Physical-Intelligence/openpi</a>，但 VLM 子任务预测的推理代码尚未公开。</li> G0：已公开模型权重和开放世界数据集，部分代码发布于 OpenGalaxea/G0</a>，目前仅支持真机推理。</li> WALL-OSS：模型权重和代码均已发布于 X-Square-Robot/wall-x</a>。</li> </ul> 总结与展望</h2> 自 RT-2 于 2023 年问世以来，VLA 已迅速从离散控制发展到连续控制，也从单系统架构发展到双系统架构。我认为，原生多任务会成为下一个趋势：具身智能体不应局限于执行动作，还应能处理聊天、记忆和导航等本质上不同的任务。近期的模型已经让任务规划和控制共享基于互联网规模数据预训练的 VLM 主干。尽管这两者仍然以动作为中心，但它们为多个更广泛的任务共享同一个 VLM 奠定了基础。 我目前正在研究这种面向具身智能体原生多任务的多专家基础模型，欢迎联系我讨论与合作！ ^1Yueen Ma et al., “A Survey on Vision-Language-Action Models for Embodied AI”</a>, arXiv, 2024. </div> ^2Brianna Zitkovich et al., “RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control”</a>, CoRL, 2023. </div> ^3Moo Jin Kim et al., “OpenVLA: An Open-Source Vision-Language-Action Model”</a>, CoRL, 2024. </div> ^4Karl Pertsch et al., “FAST: Efficient Action Tokenization for Vision-Language-Action Models”</a>, RSS, 2025. </div> ^5Kevin Black et al., “$\pi_0$: A Vision-Language-Action Flow Model for General Robot Control”</a>, RSS, 2025. </div> ^6Johan Bjorck et al., “GR00T N1: An Open Foundation Model for Generalist Humanoid Robots”</a>, arXiv, 2025. </div> ^7具体而言，根据我对权重相似度的测试，GR00T N1.5 的 VLM 语言主干由预训练 Qwen3-1.7B</a>（共 28 层）的前 14 层微调而来。 </div> ^8Physical Intelligence et al., “$\pi_{0.5}$: A Vision-Language-Action Model with Open-World Generalization”</a>, arXiv, 2025. </div> ^9Tao Jiang et al., “Galaxea Open-World Dataset and G0 Dual-System VLA Model”</a>, arXiv, 2025. </div> ^10X Square Robot, “WALL-OSS: Igniting VLMs toward the Embodied Space”</a>, white paper, 2025. </div> Dario Amodei 博客阅读笔记 2025-08-02T00:00:00+00:00 本文仍在更新，但现有笔记已经可以阅读。 </blockquote> 最近，我读了 Anthropic</a> CEO Dario Amodei</a> 的几篇文章1</a>。作为一名 AI 博士生，也是 Anthropic Claude 模型的常用用户，我从中获得了不少启发。 这些文章拓宽了我对学术界和产业界的认识，内容也常常横跨多个学科。这篇笔记记录了我阅读时想到的一些问题。 按我的阅读顺序，涉及的文章包括： On DeepSeek and Export Controls</a>（2025 年 1 月）</li> The Urgency of Interpretability</a>（2025 年 4 月）</li> Machines of Loving Grace</a>（2024 年 10 月）</li> </ul> 畅想强大 AI</h2> 在 Machines of Loving Grace</a> 中，Amodei 描绘了“强大 AI”（他更偏爱这一说法，而非 AGI）可能具有的形态，以及它问世后 5–10 年间可能给社会带来的变化。他预测，“它最早可能在 2026 年出现”。在我看来，他设想的 AI 在形态上与今天的大语言模型相似，但实现方式未必相同，主要具有以下特点： 超级智能。 单论智力，它“比诺贝尔奖得主更聪明”。例如，它能够证明尚未解决的数学定理，也能写出极为出色的小说。</li> 能够使用各种界面。 除了聊天，它还可以使用人类完成虚拟工作所需的一切界面。</li> 自主工作。 它能够长时间执行分配给它的任务，只在确有必要时向人类询问。</li> 通过虚拟方式与现实交互。 它没有实体，但可以借助计算机控制乃至创造现实中的工具。</li> 规模庞大、速度极快。 原本用于训练的资源可以转而运行数百万个实例；这些实例学习和行动的速度都远超人类（例如快 10–100 倍）。</li> 既独立又协作。 数百万个实例既可以各自处理互不相关的任务，也可以协同解决同一个问题；其中一些实例还可以通过微调，尤其擅长特定任务（我会称之为“专家”）。</li> </ul> 他将其概括为“数据中心里的天才之国”：它能迅速解决棘手问题，却依然受到外部世界的制约。这些制约包括物理过程的速度、对数据的需求（例如粒子物理研究）、问题本身的复杂性（例如三体问题</a>）、法律与人类意愿，以及晶体管密度和擦除单位信息所需能量的物理极限。 因此，他借用经济学中的“智力边际回报”来思考一个拥有极其强大 AI 的世界。他的预测建立在这样一个问题之上：更高的智能能在哪些领域发挥作用、作用有多大，又需要多长时间？我很喜欢这种分析方式。如果没有一种合理的方法衡量智能的影响，我们很容易走向过度乐观或过度悲观。 上面的基本假设和分析框架2</a>并不是 Machines of Loving Grace 的主体，却是最打动我的部分。毕竟，最难的并不是在一个扎实的框架下推导出合理答案，而是提出这个框架本身。 文章余下的篇幅分别从五个领域讨论强大 AI 问世后 5–10 年间可能发生的变化：生物学与健康、神经科学与心智、经济发展与贫困、和平与治理，以及工作与意义。他的核心预测是：强大 AI 将把人类 50–100 年的进步压缩到 5–10 年内完成，他称之为“压缩的 21 世纪”。悬而未决的问题是，这样的 AI 究竟何时才会出现。 与“基本假设和分析框架”</a>一节相比，我觉得有些预测更带有个人色彩，比如关于自由民主与威权主义的讨论3</a>。即使采用同一套分析框架，人们也会因为背景和经历不同，对某些问题产生不同的理解与想象。这正是我喜欢阅读不同背景作者作品的重要原因之一，也是我写下这些笔记的原因。 用机制可解释性保障 AI 安全</h2> 随着现代 AI 逐渐接近上文所说的“强大 AI”，治理与“安全”问题会愈发重要（而如何定义安全，本身就是一个重大问题）。强大的 AI 系统需要技术层面的安全机制，可解释性是其中的重要一环。在 The Urgency of Interpretability</a> 中，Amodei 介绍了机制可解释性的重要性与发展历程，以及 Anthropic 最近在这一方向上的进展。 可解释性之所以重要，是因为现代深度学习系统不同于由明确规则编写的传统系统，在很大程度上仍是“黑箱”。就连开发者也无法完全解释，为什么某个输入会产生某个输出。 Amodei 引用了联合创始人 Chris Olah</a> 的说法：生成式 AI 系统与其说是被“建造”出来的，不如说是被“培育”出来的（我很喜欢这个词）——它们的内部机制从训练中涌现，并非由人直接设计。这类系统可能对人们产生越来越大的影响，因此，要让它们得到更广泛的应用，透明度与可解释性不可或缺。 机制可解释性试图通过逆向工程，理解神经网络在内部学到了哪些算法和计算机制。它不同于关注输入输出关系或高层行为的方法，而是试图从底层解释各层和神经元中究竟发生了什么。这一领域早期主要研究 CNN，如今则越来越关注大语言模型。 Anthropic 联合创始人 Chris Olah 从在 Google 和 OpenAI 工作时起，就一直在研究这一领域。 对大语言模型而言，一个早期步骤是找出可解释的神经元4</a>。研究人员发现，有些神经元的含义一目了然，但大多数神经元表达的却是杂乱混合的词语与概念。这种“叠加”让模型能表达比神经元数量更多的概念。为了将它们分离，研究人员使用稀疏自编码器5</a>寻找对应于更纯粹、可由人理解的概念的神经元组合，并将这些概念称为“特征”。有些特征非常微妙，例如“不论字面还是比喻意义上的闪烁其词或犹豫不决”。借助这种方法，Anthropic 在 Claude 3 Sonnet 中识别出了超过 3000 万个特征。 有了这些特征，研究人员就可以进一步探查模型的工作方式。人为放大某项特征可以显著改变模型行为（“Golden Gate Claude”</a>）；追踪并操纵成组的特征（即“回路”6</a>），则有助于解释推理过程的某些部分。 Anthropic 的研究文章7</a>更详细地介绍了这项工作。 机制可解释性试图逆向分析神经网络，甚至是拥有数十亿参数的大语言模型，并为模型内部的工作方式提供具体证据；我很欣赏这一点。这个方向看起来很有前景，但我不认为在庞大的神经网络里寻找“漏洞”，就是通往强大且安全的 AI 的完整路径——那就像在一头蓝鲸体内清除癌细胞一样。至少目前，我不觉得我们的模型已经强大到足以构成“危险”，不过机制可解释性也可以帮助提升模型能力。 AI 与政治</h2> 这一节尚待完成（这个话题也实在太大）——等有时间时我会补上。 ^1我最初读到的是一篇介绍 On DeepSeek and Export Controls</a> 的中文文章，之后又阅读了英文原文，以及 Amodei 个人网站</a>上的其他文章。 </div> ^2这些内容整理自原文的“基本假设和分析框架”</a>一节。 </div> ^3引自 Amodei Peace and governance</a> 一节的首段：“二十年前，美国政策制定者认为，与中国开展自由贸易会使中国在富裕起来的同时走向自由化；事实远非如此，如今我们似乎正与一个复兴的威权阵营走向第二次冷战。” </div> ^4Nelson Elhage 等，“Softmax Linear Units”</a>，Transformer Circuits Thread，2022。 </div> ^5Trenton Bricken 等，“Towards Monosemanticity: Decomposing Language Models With Dictionary Learning”</a>，Transformer Circuits Thread，2023。 </div> ^6Jack Lindsey 等，“On the Biology of a Large Language Model”</a>，Transformer Circuits Thread，2025。 </div> ^7Anthropic，Mapping the Mind of a Large Language Model</a> 和 Tracing the Thoughts of a Large Language Model</a>。 </div> Android 智能手机配置速查表 2025-01-09T00:00:00+00:00 这份速查表源于我自己的开发需求，主要面向 AI 计算任务，以及在类 Linux 环境中运行 DNN。如果你更关心应用开发和 GUI 调试，它可能并不适用。 首次开机</h2> 注册</h3> 注册新设备以激活保修（如果你不打算获取系统 root 权限）。 获取系统 Root 权限</h2> 如需以超级用户身份深度控制系统，必须取得 root 权限。 Magisk 中文网教程</a> 本节以一加设备为例，因为在国内，一加对 root 相对友好。 所需工具与文件： ADB（Android Debug Bridge）：platform-tools</a></li> Android OTA payload 提取工具：payload-dumper-go</a></li> 系统 ROM：MagiskCN</a></li> Magisk APK：GitHub Release</a></li> </ul> 解锁 Bootloader</h3> Magisk 中文网教程</a> 进入开发者模式</li> 开启 OEM 解锁（具体方式取决于厂商）</li> 开启 USB 调试，将手机连接至主机</li> 进入 bootloader：adb reboot bootloader</code></li> 解锁 bootloader：fastboot flashing unlock</code></li> 在手机上选择“解锁 bootloader”并确认</li> </ol> 使用 Magisk 获取 Root 权限</h3> Magisk 中文网教程</a> 在主机上下载匹配的 ROM 包并解压</li> 使用 payload 提取工具从 ROM 中提取 init_boot.img</code> 用法：payload-dumper-go -p init_boot <extracted>/payload.bin</code></li> </ul> </li> 开启 USB 调试，将手机连接至主机</li> 将 init_boot.img</code> 传到手机的“Download”文件夹</li> 在手机上安装 Magisk 应用</li> 在 Magisk 中选择“安装”，修补 init_boot.img</code>，得到 magisk_patched-xxx.img</code></li> 将 magisk_patched-xxx.img</code> 传回主机</li> 进入 bootloader：adb reboot bootloader</code></li> 刷入补丁：fastboot flash init_boot magisk_patched-xxx.img</code> 成功时应看到“Okay”</li> </ul> </li> 重启系统：fastboot reboot</code></li> </ol> 重启后打开 Magisk，查看其中显示的版本信息，确认 root 权限已获取成功。 系统设置</h2> 开发者选项</h3> 开启开发者选项</li> 开启 USB 调试</li> 开启无线调试（如有需要）</li> </ul> 系统更新</h3> 建议关闭所有可能影响系统性能与版本稳定性的设置，具体包括： 关闭不必要的后台服务</li> 关闭系统自动更新与自动下载</li> 移除自动安装的应用</li> </ul> 电池管理</h3> 在系统全局电池设置中开启“性能模式”</li> 在各应用的电池设置中开启“允许后台运行”</li> 为 Termux 及类似进程选择“获取唤醒锁”</li> </ul> 应用</h2> 安装方式： 从应用商店安装（Google Play、F-Droid 等）</li> 安装已下载的 APK（Android Application Package）</li> 通过 ADB 从主机安装（需要 APK）</li> </ul> Clash for Android（CFA）</h3> 首先配置代理。 TODO：补充细节 F-Droid</h3> F-Droid</a> 是一个可安装的 Android FOSS（自由及开放源代码软件）应用目录，也可作为 Google Play 的替代方案。 Termux</h3> 推荐通过 F-Droid 安装。 另请参阅 Termux 配置速查表</a>。 Microsoft Edge</h3> 可用它替代功能可能受限的系统浏览器。 我推荐 Edge，是因为国内各大应用商店通常都能下载到它。 Android 手机上 Termux 配置速查表 2025-01-09T00:00:00+00:00 Termux</a> 在 Android 上提供了一个类 Linux 环境，功能比 ADB shell 完整得多。作为智能手机配置速查表</a>的延伸，本文说明如何配置 Termux。 这套配置服务于我以 AI 计算任务为主的开发需求。如果你主要关注应用开发和 GUI 调试，它可能并不完全适合。 相关参考：sanwebinfo/my-termux-setup</a> 安装</h2> 推荐从 F-Droid</a> 安装，便于使用插件 Termux: Style</li> </ul> </li> 也可以直接安装 APK；下载见 GitHub Releases</a></li> </ul> 系统配置</h2> 以下是在 Termux 内进行的系统级配置。 更新软件包</h3> 自动选择镜像：termux-change-repo</code></li> 更新并升级：pkg update && pkg upgrade</code></li> </ul> 配置 SSH</h3> 安装 OpenSSH：pkg install openssh</code></li> 查看 Termux 用户名：whoami</code></li> 设置登录密码：passwd</code></li> 获取 IP 地址：ifconfig</code></li> 启动 SSH 服务：sshd</code></li> 从远端连接：ssh -p 8022 <username>@<ip></code> Termux 的默认 SSH 端口是 8022</li> </ul> </li> </ul> 安装常用软件包</h3> 系统配置常用的软件包： Tsu（Termux 的 su 封装）：pkg install tsu</code></li> Git：pkg install git</code></li> Wget：pkg install wget</code></li> cURL：pkg install curl</code></li> CMake：pkg install cmake</code></li> tmux：pkg install tmux</code></li> htop：pkg install htop</code></li> </ul> 开发环境配置</h2> 配置开发所需的环境。 Code</h3> Termux 不支持 Visual Studio Code remote server，但开源的 code-server</a> 是一个实用的替代方案。 通过 TUR 仓库安装 code-server： pkg install tur-repo pkg install code-server</code></pre> 在 ~/.config/code-server/config.yaml</code> 中配置服务。例如： bind-addr: 0.0.0.0:8080 auth: password</code></pre> 启动服务： code-server</code></pre> 现在可以通过 http://<ip>:8080</code> 访问代码编辑界面，并使用配置的密码登录。 如果在 tsu</code> 模式下运行，配置文件路径会略有不同（位于 ~/.tsu</code> 下）。 Python</h3> Termux 不支持 Miniconda。 安装 Python：pkg install python</code> Pi 设备配置速查表 2025-01-03T00:00:00+00:00 这份速查表是根据我自己的开发需求整理的，主要适用于 Orange Pi、Raspberry Pi 等开发板。 硬件</h2> 网络连接</h3> 有线或无线网络均可。 键盘、鼠标和显示器</h3> 用于首次开机配置和本地调试。 已写入操作系统的 TF（MicroSD）卡</h3> 常规开发推荐使用最新的 Ubuntu LTS 我更倾向于使用服务器版系统，因为它比桌面镜像更轻量</li> 同时也能避免 GUI 干扰性能测量</li> </ul> </li> 预算允许的话，建议使用容量较大的存储卡（我使用的是 ≥256 GB）默认的 32/64 GB 对许多任务而言并不够用</li> </ul> </li> 镜像写入工具：BalenaEtcher</a>（通用）和 Raspberry Pi Imager</a>（Raspberry Pi） Raspberry Pi Imager 支持通过自定义配置完成无头安装</li> </ul> </li> </ul> 系统</h2> 按需设置或修改用户名和密码</h3> 推荐格式：设备名（raspi</code>、orangepi</code>）[+ 用户信息，适用于设备不共用的情况]</li> </ul> 连接（无线）网络</h3> Raspberry Pi 在无头安装时可以自动连接网络默认由 cloud-init</code>、netplan</code> 和 networkd</code> 管理网络</li> 我改用了自己更熟悉的 NetworkManager</code></li> </ul> </li> 其他运行 Ubuntu 的开发板可以使用 NetworkManager</code> 扫描可用网络：nmcli dev wifi</code></li> 通过 SSID 连接：nmcli dev wifi connect <ssid> password <passwd></code></li> </ul> </li> </ul> 按需配置网络</h3> 清华大学 TUNET 认证：GoAuthing</a> 如果代理导致无法访问 GitHub，也可以从 TUNA</a> 获取发布版本</li> 预编译的 Linux ARM64 可执行文件：auth-thu.linux.arm64</a></li> </ul> </li> 配置代理：TODO 使用公共网络时，不要允许来自局域网的连接</li> </ul> </li> </ul> 安装或更新必要的软件包</h3> 必要时更换软件源</li> 首先更新软件包列表并升级：sudo apt update && sudo apt upgrade</code></li> </ul> 配置 SSH 服务以便远程访问</h3> 使用 sshd</code> 启动 SSH 服务</li> 使用 ifconfig</code> 查看设备 IP</li> 使用 ssh -p <port> user@ip</code> 测试登录</li> 使用 ssh-copy-id</code> 配置密钥认证</li> </ul> 其他</h3> （可选）使用厂商提供的工具进行更直观的交互式配置，例如 Raspberry Pi 的 raspi-config</code> 和 Orange Pi 的 orangepi-config</code>。 开发环境</h2> 基础工具和软件包</h3> tmux：sudo apt install tmux</code></li> git：sudo apt install git</code> 将 SSH 公钥添加到 GitHub，以便通过 SSH 克隆仓库</li> 提交代码前配置用户名和邮箱</li> </ul> </li> code-server（适用于平台不支持 VS Code Remote 的情况）</li> </ul> 构建工具和编译器</h3> CMake（大多数项目要求 >=3.22）通过 apt 安装：sudo apt install cmake</code></li> 从官方网站安装：下载页面</a></li> 更新至最新版：更新 CMake</a></li> </ul> </li> GCC 通过 apt 安装：sudo apt install build-essential</code></li> </ul> </li> LLVM + Clang 从官方网站安装：下载页面</a></li> 一行命令安装最新版：bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)"</code></li> </ul> </li> 注意：如果系统中同时装有多个编译器（GCC、Clang 或同一编译器的不同版本），请确认环境变量 $CC</code> 和 $CXX</code> 设置正确，否则 CMake 等构建工具可能会选错编译器。</li> </ul> Python 环境</h3> Miniconda 大多数情况下的首选方案</li> 一行命令安装（注意操作系统和架构） curl -O https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-aarch64.sh</code></li> bash ~/Miniconda3-latest-Linux-aarch64.sh</code> 不要使用 sudo</code>，否则 Miniconda 会安装到其他位置</li> </ul> </li> 阅读协议后按 Enter，并输入 yes</li> </ul> </li> </ul> </li> Virtualenv 在项目有要求时使用</li> 通过 apt 安装：sudo apt install python3-venv</code></li> </ul> </li> 注意：如果同时安装了 conda 和 virtualenv，请确认激活了正确的环境（从终端里看，两者可能没有明显区别）</li> </ul> 容器</h3> Docker：TODO</li> </ul> 快速修复</h2> 更新 CMake</h3> 在 Ubuntu 上安装最新版 CMake（由 Claude 生成）： sudo apt remove --purge cmake sudo apt purge cmake sudo apt autoremove wget -O - https://apt.kitware.com/keys/kitware-archive-latest.asc 2>/dev/null | gpg --dearmor - | sudo tee /etc/apt/trusted.gpg.d/kitware.gpg >/dev/null sudo add-apt-repository "deb https://apt.kitware.com/ubuntu/ $(lsb_release -cs) main" sudo apt update sudo apt install cmake</code></pre>编译器</h3> 安装最新版标准库：sudo apt install libstdc++-12-dev</code> Git 克隆</h3> 使用 SSH URL 的一行命令：sed -i 's/https:\/\/github.com\//git@github.com:/' .gitmodules</code> 递归处理脚本： # Function to update .gitmodules and sync update_modules() { sed -i 's/https:\/\/github.com\//git@github.com:/' .gitmodules git submodule sync git submodule update --init } # Function to process each level process_level() { # 1. Update current .gitmodules update_modules # 2. For each currently cloned submodule git submodule foreach ' # 3. Update their .gitmodules if exists if [ -f ".gitmodules" ]; then sed -i "s/https:\/\/github.com\//git@github.com:/" .gitmodules # 4. Update their immediate submodules git submodule sync git submodule update --init fi ' } # 5. Repeat multiple times to ensure all nested levels are processed for i in {1..5}; do echo "Processing level $i" process_level done</code></pre>Hugging Face</h3> HF 镜像：export HF_ENDPOINT=https://hf-mirror.com</code> ModelScope：modelscope.cn</a> "口袋里的 GPT"，离我们还有多远？ 2023-11-21T00:00:00+00:00 微信公众号版本：「口袋里的 GPT」，离我们还有多远？</a> </blockquote> 初识 GPT</h2> 2022 年 11 月 30 日，OpenAI 正式发布 ChatGPT。 2022 年 12 月 5 日，ChatGPT 发布仅 5 天便突破 100 万用户。 在国内，ChatGPT 首先在 2022 年 12 月于科技圈引起关注；而时间来到 2023 年 2 月，ChatGPT 更是在国内彻底爆火出圈，一时间风头无两。最近一段时间，Humane 和 GPTs 等又再度引起了大家的关注。在 2023 年，你从不关心 AI 的父母也要问问你：“GPT“是什么？ GPT 全称为 Generative Pre-Trained Transformer，即生成式预训练 Transformer 模型。具体来说，Transformer 是最早于 2017 年提出的一种基于 Attention 的神经网络架构1</a>，而 GPT 则是由 OpenAI 基于此架构开发的一系列经过大规模文本预训练、可以生成自然语言文本的模型。当下备受关注的“大模型“，主要就是指以 GPT 为代表的这类基于 Transformer 架构的大规模生成式模型。 最近一年来，除了 GPT 外，新的大模型如雨后春笋一般发布，例如 Meta 开源的 LLaMA 以及基于 LLaMA 的诸多模型。这些模型整体上仍沿用类似于 GPT 的架构，但在模型超参数、训练数据、训练方法等方面各有不同。除了“大模型“这个称谓外，大语言模型（Large Language Model, LLM）和基础模型（Foundation Model, FM）等通常也是指它们，只是各有侧重。为了简便，本文中统称为大模型或 LLM。 口袋里的 GPT</h3> 现阶段的大模型在对话、写作、编程等任务上已经表现出接近甚至超越人类的水平。这让很多人觉得我们距离通用人工智能（Artificial General Intelligence, AGI）又近了一步，大模型也的确展现出了改变现有生产方式的可能性。人们的想象力在此时无限延展，以往只出现在科幻作品中的场景似乎也近在咫尺，颇有“未来已来“之感。 让每个人都拥有一个定制的大模型，并让它成为随身携带的私人助理，就是其中颇具吸引力的一个想法——它也许是你口袋中的一个智能终端，也许是眼镜等可穿戴设备，亦或是任何更酷的形式。这个“口袋里的 GPT“可以帮你处理文书、安排日程，甚至代替你与他人（或他们的智能助理）交互。 然而现实与理想之间却总是存在差距。除了当前模型、算法上的差距外，隐私安全与网络延迟也是极为重要的因素。一个高度定制化、深度参与用户日常生活的智能助理，必然需要处理大量的用户隐私数据，而使用部署在云端的大模型服务则给个人隐私安全带来了严重的隐患。同时，未来海量用户产生的大量推理请求也会对网络传输带来更大的压力，难以满足某些高实时性应用的要求。在端侧直接部署大模型，一方面便于解决上述问题，另一方面也将面临独特的挑战。 大模型端侧部署的挑战</h2> 资源受限</h3> 在端侧部署大模型的首要挑战，就是设备上有限的硬件资源难以满足大模型的需求。 大模型出色的能力是建立在其庞大参数量的基础上的。例如，视觉领域经典的 CNN 模型 ResNet 参数量大致在 10M–60M 之间，而 GPT-3 的参数量达到 175B，比前者大 3–4 个数量级。于是，仅仅加载模型权重所需的内存就从 100 MB 上下飙升至几百 GB，更不要提计算中间数据的保存了。 即便是像 LLaMA 7B 这样更适合部署在端侧的“小模型“，也比以 MobileNet 系列为代表的轻量级 CNN 参数量大 3 个数量级。如果以半精度浮点数估计，需要至少 14 GB 内存才能勉强放下全部模型参数，而这已经远超市面上许多中端设备的内存容量。除了前向推理之外，如果希望根据用户数据在本地对模型进行微调训练，则会对内存与算力提出更高要求。 计算低效</h3> 端侧大模型的部署以推理为主，而大模型本身的推理效率，是其在端侧部署的另一个重要挑战。 即便我们设法压缩模型并提供匹配的硬件资源，解决了可行性问题，仍然还需要解决大模型运行的延迟和功耗带来的实用性问题——我们当然不希望数字小秘书以秒为单位龟速输出，同时还热得烫手（> <）。而当前大模型推理低效的一个主要原因，在于其计算-访存比低，无法充分利用计算资源。 所谓的计算-访存比，也就是系统领域著名的 Roofline Model2</a> 中的 Operational Intensity（计算强度）。它定义为每访问 1 byte 内存平均需要完成的计算操作次数。对于给定的硬件平台，目标任务的计算-访存比越低，计算单元每完成一次计算平均需要访问的内存也就越多。当硬件的内存带宽被占满时，即便再减少计算量或提供更多算力，也无法带来实际的性能提升。这时称系统受内存带宽限制（memory-bound）；反之则受计算能力限制（compute-bound）。典型的端侧大模型生成任务往往受内存带宽限制。 端侧大模型推理的计算-访存比低，是由其工作负载的特点决定的。 由于硬件资源和应用场景的限制，端侧大模型通常不会处理高并发的请求，且大部分时候仅有一个请求，即 batch size = 1。同时，模型处理的文本长度也较为有限。于是在生成阶段，模型中的计算主要是矩阵向量乘和“高瘦“的矩阵乘，其模型权重每次加载后参与计算的次数较少，于是权重加载（内存访问）就成为了系统的瓶颈。 现有方法</h2> 为了解决前文所述的大模型在端侧部署的资源受限和计算低效两大问题，已有的工作可以分为模型压缩与推理优化两类方法。在实际部署中，两类方法往往需要综合使用，以达到最优效果。 模型压缩</h3> 要想降低模型的内存与算力开销，最直接的方法就是降低模型的大小。大模型常用的压缩方法包括量化、剪枝、蒸馏和低秩分解等。本节简单介绍这几种常用方法，也欢迎感兴趣的同学自行深入了解。 量化（Quantization）3</a>^{, }4</a>^{, }5</a>^{, }6</a> 即用更少的 bit 数来表示模型参数，从而有效降低模型大小。按照是否在量化过程中训练模型，量化方法还可进一步分为训练后量化（Post-Training Quantization, PTQ）和量化感知训练（Quantization-Aware Training, QAT）。低 bit 量化（如 4-bit、3-bit）是当前研究探索的一个重要方向。 剪枝（Pruning）7</a>^{, }8</a>^{, }9</a> 即去除模型中一部分不重要的权重，从而降低模型的存储与计算开销。剪枝方法也可进一步分为结构化（structured）与非结构化（unstructured）两种，其中结构化剪枝对硬件计算更加友好。 蒸馏（Distillation） 即使用已有的效果较好的 Teacher 模型（参数量大、精度高），去指导训练一个轻量的 Student 模型（参数量小，精度低），使得小模型输出与大模型接近。蒸馏方法常与量化和剪枝方法配合使用。 低秩分解（Low-Rank Factorization） 即通过两个低秩矩阵的乘积来近似原权重矩阵，从而降低模型参数量和计算量。LoRA10</a>（Low-Rank Adaptation）及其变体就是一种利用低秩分解实现高效模型微调的方法。 推理优化</h3> 除了模型压缩外，端侧 LLM 推理的计算过程也存在许多优化空间。为了解决延迟、内存等方面的问题，已有的工作中提出了如下方法。 KV Cache 是一种以内存换时间的优化方法，在目前的推理框架中被普遍使用。其核心思想是将 Attention 计算中每次迭代包含重复计算的张量（也即 K 和 V）保存下来，并且随着序列的生成进行增量更新，从而避免重复计算。当序列长度增加时，KV Cache 的大小也会显著增长，需要采用适当的策略进行内存管理11</a>^{, }12</a>。 投机采样（Speculative Sampling）13</a>^{, }14</a>^{, }15</a> 能够在 small-batch 场景下提高吞吐量。所谓投机采样，即先通过一个轻量的小模型（draft model）生成（猜测）一组 token，再交由目标模型（target model）进行评估检验。对 draft model 一次生成的多个 token，可以通过一次目标模型前向计算并行验证，从而提高解码吞吐。 算子优化目前的一个重要方向，是对 Attention 计算的优化。相比以稠密线性层为主的 FFN，Attention 包含随序列长度变化的矩阵乘、Softmax 等操作，需要针对访存和并行方式进行专门优化。近期的代表工作有 Flash-Decoding16</a> 和 FlashDecoding++17</a> 等。 流式加载（Stream Loading） 即每次仅加载一部分权重到内存（或显存）中进行推理，从而降低整体的内存（显存）占用。FlexGen18</a> 通过对 GPU–CPU offloading 策略的设计实现了高吞吐的单卡 LLM 推理。但在要求低延迟而非高吞吐的场景下，由于 LLM 加载权重的开销过大，这类方法并不适用。 总结与展望</h2> 本文主要介绍了目前端侧大模型部署中的挑战与已有技术，其中涵盖了模型压缩与系统优化中的多个方向。笔者希望通过阅读本文，感兴趣的同学能够快速补充背景知识、了解最新进展。 虽然文中已列出许多已有工作，但如何通过模型压缩与推理系统的协同优化，进一步降低大模型推理的硬件需求和功耗、提升大模型在资源受限设备上的运行效率，仍是一个重要的待解决问题。欢迎感兴趣的同学深入交流讨论（以及写得不好的地方多拍砖 0.0）。 ^1Ashish Vaswani et al., “Attention Is All You Need”</a>, NeurIPS, 2017. </div> ^2Samuel Williams, Andrew Waterman, and David Patterson, “Roofline: An Insightful Visual Performance Model for Multicore Architectures”</a>, Communications of the ACM, 2009. </div> ^3Elias Frantar et al., “GPTQ: Accurate Post-Training Quantization for Generative Pre-Trained Transformers”</a>, ICLR, 2023. </div> ^4Guangxuan Xiao et al., “SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models”</a>, ICML, 2023. </div> ^5Ji Lin et al., “AWQ: Activation-Aware Weight Quantization for LLM Compression and Acceleration”</a>, MLSys, 2024. </div> ^6Zechun Liu et al., “LLM-QAT: Data-Free Quantization Aware Training for Large Language Models”</a>, arXiv, 2023. </div> ^7Elias Frantar and Dan Alistarh, “SparseGPT: Massive Language Models Can Be Accurately Pruned in One-Shot”</a>, ICML, 2023. </div> ^8Xinyin Ma, Gongfan Fang, and Xinchao Wang, “LLM-Pruner: On the Structural Pruning of Large Language Models”</a>, NeurIPS, 2023. </div> ^9Mingjie Sun et al., “A Simple and Effective Pruning Approach for Large Language Models”</a>, ICLR, 2024. </div> ^10Edward J. Hu et al., “LoRA: Low-Rank Adaptation of Large Language Models”</a>, ICLR, 2022. </div> ^11Woosuk Kwon et al., “Efficient Memory Management for Large Language Model Serving with PagedAttention”</a>, SOSP, 2023. </div> ^12Reiner Pope et al., “Efficiently Scaling Transformer Inference”</a>, MLSys, 2023. </div> ^13Yaniv Leviathan, Matan Kalman, and Yossi Matias, “Fast Inference from Transformers via Speculative Decoding”</a>, ICML, 2023. </div> ^14Charlie Chen et al., “Accelerating Large Language Model Decoding with Speculative Sampling”</a>, arXiv, 2023. </div> ^15Benjamin Spector and Chris Ré, “Accelerating LLM Inference with Staged Speculative Decoding”</a>, arXiv, 2023. </div> ^16Tri Dao et al., “Flash-Decoding for Long-Context Inference”</a>, Stanford CRFM Blog, 2023. </div> ^17Ke Hong et al., “FlashDecoding++: Faster Large Language Model Inference on GPUs”</a>, MLSys, 2024. </div> ^18Ying Sheng et al., “FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU”</a>, ICML, 2023. </div>}

增强 vLLM 对 GPTQv2 格式的支持：分析与实现

视觉—语言—动作（VLA）模型：近期进展综述

Dario Amodei 博客阅读笔记

Android 智能手机配置速查表

首次开机</h2>

注册</h3>
注册新设备以激活保修（如果你不打算获取系统 root 权限）。</p>

系统设置</h2>

Clash for Android（CFA）</h3>
首先配置代理。</p>
TODO：补充细节</p>

F-Droid</h3>
F-Droid</a> 是一个可安装的 Android FOSS（自由及开放源代码软件）应用目录，也可作为 Google Play 的替代方案。</p>

Termux</h3>
推荐通过 F-Droid 安装。</p>
另请参阅 Termux 配置速查表</a>。</p>

Microsoft Edge</h3>
可用它替代功能可能受限的系统浏览器。</p>
我推荐 Edge，是因为国内各大应用商店通常都能下载到它。</p>

Android 手机上 Termux 配置速查表

系统配置</h2>
以下是在 Termux 内进行的系统级配置。</p>

开发环境配置</h2>
配置开发所需的环境。</p>

`Python</h3> Termux 不支持 Miniconda。</p> 安装 Python：pkg install python</code></p>`

Pi 设备配置速查表

硬件</h2>

网络连接</h3>
有线或无线网络均可。</p>

键盘、鼠标和显示器</h3>
用于首次开机配置和本地调试。</p>

系统</h2>

其他</h3>
（可选）使用厂商提供的工具进行更直观的交互式配置，例如 Raspberry Pi 的 `raspi-config</code> 和 Orange Pi 的 orangepi-config</code>。</p>`

快速修复</h2>

编译器</h3>
安装最新版标准库：`sudo apt install libstdc++-12-dev</code></p>`

Hugging Face</h3>
HF 镜像：`export HF_ENDPOINT=https://hf-mirror.com</code></p>`
`ModelScope：modelscope.cn</a></p>`

"口袋里的 GPT"，离我们还有多远？

李翔宇

用向量查表真正加速低比特 LLM 的并行推理

李翔宇

用向量查表真正加速低比特 LLM 的并行推理

增强 vLLM 对 GPTQv2 格式的支持：分析与实现

视觉—语言—动作（VLA）模型：近期进展综述

VLA 的近期进展</h2> 我从两个维度概括 VLA 的近期进展：**从仅有系统 1</em>（控制）走向双系统</em>（规划 + 控制），以及从离散</em>动作走向连续</em>动作。**由此可以得到四个象限：</p>

Dario Amodei 博客阅读笔记

Android 智能手机配置速查表

首次开机</h2>

注册</h3> 注册新设备以激活保修（如果你不打算获取系统 root 权限）。</p>

获取系统 Root 权限</h2> 如需以超级用户身份深度控制系统，必须取得 root 权限。</p>

系统设置</h2>

开发者选项</h3> 开启开发者选项</li> 开启 USB 调试</li>

Clash for Android（CFA）</h3> 首先配置代理。</p> TODO：补充细节</p>

F-Droid</h3> F-Droid</a> 是一个可安装的 Android FOSS（自由及开放源代码软件）应用目录，也可作为 Google Play 的替代方案。</p>

Android 手机上 Termux 配置速查表

安装</h2> 推荐从 F-Droid</a> 安装，便于使用插件 Termux: Style</li> </ul> </li>

系统配置</h2> 以下是在 Termux 内进行的系统级配置。</p>

更新软件包</h3> 自动选择镜像：termux-change-repo</code></li>

配置 SSH</h3> 安装 OpenSSH：pkg install openssh</code></li> 查看 Termux 用户名：whoami</code></li> 设置登录密码：passwd</code></li> 获取 IP 地址：ifconfig</code></li> 启动 SSH 服务：sshd</code></li>

开发环境配置</h2> 配置开发所需的环境。</p>

Python</h3> Termux 不支持 Miniconda。</p> 安装 Python：pkg install python</code></p>

Pi 设备配置速查表

硬件</h2>

网络连接</h3> 有线或无线网络均可。</p>

键盘、鼠标和显示器</h3> 用于首次开机配置和本地调试。</p>

已写入操作系统的 TF（MicroSD）卡</h3> 常规开发推荐使用最新的 Ubuntu LTS 我更倾向于使用服务器版系统，因为它比桌面镜像更轻量</li> 同时也能避免 GUI 干扰性能测量</li> </ul> </li>

系统</h2>

安装或更新必要的软件包</h3> 必要时更换软件源</li>

配置 SSH 服务以便远程访问</h3> 使用 sshd</code> 启动 SSH 服务</li> 使用 ifconfig</code> 查看设备 IP</li> 使用 ssh -p <port> user@ip</code> 测试登录</li>

其他</h3> （可选）使用厂商提供的工具进行更直观的交互式配置，例如 Raspberry Pi 的 raspi-config</code> 和 Orange Pi 的 orangepi-config</code>。</p>

Python 环境</h3> Miniconda 大多数情况下的首选方案</li>

快速修复</h2>

编译器</h3> 安装最新版标准库：sudo apt install libstdc++-12-dev</code></p>

Hugging Face</h3> HF 镜像：export HF_ENDPOINT=https://hf-mirror.com</code></p> ModelScope：modelscope.cn</a></p>

"口袋里的 GPT"，离我们还有多远？

注册</h3>
注册新设备以激活保修（如果你不打算获取系统 root 权限）。</p>

Clash for Android（CFA）</h3>
首先配置代理。</p>
TODO：补充细节</p>

F-Droid</h3>
F-Droid</a> 是一个可安装的 Android FOSS（自由及开放源代码软件）应用目录，也可作为 Google Play 的替代方案。</p>

系统配置</h2>
以下是在 Termux 内进行的系统级配置。</p>

开发环境配置</h2>
配置开发所需的环境。</p>

`Python</h3> Termux 不支持 Miniconda。</p> 安装 Python：pkg install python</code></p>`

网络连接</h3>
有线或无线网络均可。</p>

键盘、鼠标和显示器</h3>
用于首次开机配置和本地调试。</p>

其他</h3>
（可选）使用厂商提供的工具进行更直观的交互式配置，例如 Raspberry Pi 的 `raspi-config</code> 和 Orange Pi 的 orangepi-config</code>。</p>`

编译器</h3>
安装最新版标准库：`sudo apt install libstdc++-12-dev</code></p>`

Hugging Face</h3>
HF 镜像：`export HF_ENDPOINT=https://hf-mirror.com</code></p>`
`ModelScope：modelscope.cn</a></p>`