Byte Latent Transformer：用字节熵动态切分，彻底扔掉分词器

BLTByte Latent Transformer字节熵

于 2026-08-29 03:54:11 修改

·本内容遵循CC 4.0 BY-SA版权协议

在很长一段时间里，NLP 模型的标配都是“Tokenizer + Transformer”。面试问模型架构，十有八九会从 BPE、WordPiece 或 SentencePiece 问起；做多语言任务，又会被 OOV（词表外词）和词表膨胀折磨得头疼。最近 Meta AI 研究团队提出的 Byte Latent Transformer（BLT）直接把“分词器”这个中间层拿掉了，改用字节熵动态切分 patch。这个思路既不是简单的 byte-level 模型，也不是固定长度的 patch 切分，而是让模型根据数据本身的复杂程度决定在哪里切开、哪里合并，面试官问到“为什么 BLT 能扔掉分词器”“熵阈值怎么影响 patch 长度”，本质上考察的就是对动态信息密度建模的理解。

这篇文章会从传统分词器的缺陷讲起，逐步拆解 BLT 的核心原理，并提供一个完整的 Python 模拟示例，帮你用局部熵计算实现一个“动态 patch 切分器”。读完本文，你不仅能理解 Byte Latent Transformer 的架构脉络，还能在面试中用自己的话说清楚“字节熵”和“patch 切分”之间的因果逻辑，而不是只背一个概念。

本文适合正在准备大模型架构面试的算法工程师、对多语言 NLP 感兴趣的研究者，以及想快速理解新一代 tokenizer-free 模型的开发者。下面我们正式开始。

1. 背景与核心概念

1.1 为什么我们一直依赖分词器

传统 Transformer 模型不能直接处理原始字符，因为字符序列太长，且单个字符携带的语义信息过于稀疏，直接建模会带来巨大的计算开销。于是研究者设计了分词器（Tokenizer），把文本切分成一个个 token，常见的方案有 BPE（Byte Pair Encoding）、WordPiece、Unigram 和 SentencePiece。

分词器把“文本切分”这件事从模型里抽离出来，变成了一个独立的预处理模块。它的优点是简单、高效，让模型只需要在固定大小的词表上做分类；但缺点也非常明显：

第一，词表大小固定后，模型对词表外词天然不友好。无论词表做到 50k、100k 还是 200k，总会在真实数据里遇到没见过的拼写、命名实体、emoji 或特殊符号。

第二，分词器会把语义单元切得支离破碎。比如英文里 “run” 和 “running” 会被拆成不同子词，“New York” 这种多词实体也经常被切开。模型需要额外学习“把这些碎片拼回去”的隐式规则，信息在切分过程中有一定损耗。

第三，分词器对噪声非常敏感。用户输入中的拼写错误、大小写变化、URL、乱码，都会让分词结果变得不稳定。同一个单词因为少一个字母，就可能被切成完全不同的 token 序列。

第四，跨语言严重不平衡。中英文混排、阿拉伯语、泰语等语言没有明显的空格边界，BPE 合并规则往往偏向数据量大的语言，小语种的切分质量很差。

更本质的问题在于，分词器把“离散符号”的定义固定死了，模型无法感知一个 token 内部的信息含量。比如 “a” 和 “antidisestablishmentarianism” 都是 1 个 token，但前者几乎不含信息，后者却包含大量语义。这种信息密度的不均匀，是固定词表范式难以绕开的瓶颈。

1.2 Byte Latent Transformer：一种丢弃分词器的新范式

Byte Latent Transformer（以下简称 BLT）的核心思想非常直接：不再维护词表，不再做固定规则的切分，而是把输入看作一串原始字节，然后使用“字节熵”来判断哪些字节应当组合成一个 patch，哪些字节应当切开。

“patch” 可以理解为 BLT 中的“动态 token”。它不是由预训练词表决定的，而是由内容本身的信息密度决定的。信息含量低、容易被预测的连续字节，会被合并成较大的 patch；信息含量高、难以预测的边界位置，会被切开，形成较小的 patch。

这样一来，模型可以根据数据自动调整“分辨率”：简单重复的文本用少量大 patch 表示，复杂难懂的内容用大量小 patch 表示。既保留了 tokenizer-free 的灵活性，又避免了对每一个字节都做全量 Transformer 计算。

从架构上看，BLT 将训练和推理分成两级处理：先用一个轻量级模块在字节级别做局部建模，再把 patch 序列送入标准 Transformer 做全局建模，最后再映射回字节空间。这种设计让模型在大多数场景下只需要处理更短的序列长度，从而在计算效率和表达能力之间取得平衡。

1.3 核心概念：字节熵与 patch 切分

要理解 BLT，首先要理解“字节熵”。这里的熵指的是信息熵，用来度量一个字节序列的“不可预测程度”。

假设我们在处理一段英文文本，在某个位置看到一个字母，如果接下来的字母基本可以确定，比如在 “the” 后面大概率出现空格或常见后缀，那么这个位置的局部熵就比较低；如果遇到一个乱码串、一段代码或者一个复杂的人名，后续字节很难被预测，局部熵就会比较高。

BLT 的 patch 切分器会在字节流上滑动一个窗口，实时计算当前窗口内的字节分布熵。当熵值超过某个阈值时，说明当前位置进入了“信息密集区”，模型需要更细致地处理，于是在这里切开一个 patch；当熵值持续较低时，说明这段内容高度可预测，就把多个字节合并成一个较大的 patch。

需要注意的是，这里的熵计算不是只统计字符频次，而是会用一个轻量级模型来估计字节的条件概率，再基于概率分布计算熵。这样切分出来的 patch 能够和语言模型的实际预测难度对齐。简单说：越难预测的地方，越需要模型投入更多注意力，所以切得越细。

1.4 与相近技术的边界

有同学可能会问，BLT 和 Byte-Level 模型（比如 ByT5）、MegaByte 有什么区别？这里我梳理一下边界。

ByT5 直接把文本按 UTF-8 编码成字节序列，然后每个字节都进入 Transformer。它确实去掉了词表，但序列长度会变成原来的好几倍，训练和推理成本很高。BLT 不是每个字节都进全局 Transformer，而是先把一部分字节合并成 patch，降低全局序列长度。

MegaByte 也提出了分段建模的思路，但它用的是固定长度 patch。固定长度 patch 实现简单，却无法区分信息密度：简单文本和复杂文本都被切成同样大小，模型在简单文本上浪费了计算量，在复杂文本上又可能因为 patch 粒度过粗而丢失细节。

BLT 的突破点在于“分区预测难度”。它不是人为指定 patch 长度，而是让模型从数据中感知哪里该切、哪里该合，所以能自适应地平衡计算效率和表征细粒度。

2. 环境准备与版本说明

本文的实战部分不需要 GPU，只需要一个 Python 环境即可运行。BLT 本身是一个大规模预训练架构，训练条件要求很高，但我们这里要做的，是理解并复现它的“动态 patch 切分”思路，所以用一个轻量级模拟脚本就足够了。

建议环境如下：

Python 3.9 或更高版本
numpy 1.21 或更高版本
操作系统不限，Windows / macOS / Linux 都可以
不需要安装 PyTorch 或 TensorFlow

文本示例我会用英文和中文混合数据，方便观察不同语言下的 patch 切分差异。如果你的 Python 环境还没有安装 numpy，可以先执行下面的命令：

BASH

pip install numpy

版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。由于我们要演示的是核心算法而非完整深度学习模型，所以代码会尽量保持简单、可读，不依赖复杂框架。

3. 核心原理拆解

3.1 从字节流到动态 patch

BLT 的第一步是把输入文本转成 UTF-8 字节序列。为什么要用字节而不是字符？因为字节是 Unicode 体系下最通用的表示方式，无论是英文、中文、阿拉伯文还是 emoji，都可以统一编码成字节序列，不存在 OOV 问题。

得到字节序列后，BLT 需要决定如何把这些字节分组。这里的“组”就是 patch。一个 patch 可能是 1 个字节，也可能是几十个字节，完全取决于局部熵。

用公式化的方式描述：给定一个字节序列 $b_1, b_2, \dots, b_n$，我们需要在某个位置 $i$ 判断，$b_i$ 是否应该作为当前 patch 的结束位置，以及 $b_{i+1}$ 是否应该开启一个新的 patch。这个判断依据是局部信息熵。

3.2 局部熵的计算方式

局部熵计算的输入是一个滑动窗口，窗口内包含当前位置之前的 $K$ 个字节。我们需要估计给定前文 $b_{i-K}, \dots, b_{i-1}$ 的条件下，下一个字节 $x \in {0, 1, \dots, 255}$ 的概率分布 $P(x)$。

在实际训练中，这个概率分布由一个轻量级局部模型输出；在本文的演示代码里，我们可以用 n-gram 频率统计来近似。有了概率分布后，信息熵定义为：

$$H = -\sum_{x=0}^{255} P(x) \log_2 P(x)$$

熵 $H$ 的单位是比特。当 $H$ 很大时，说明下一个字节很难预测，当前位置包含的信息量高；当 $H$ 很小时，说明下一个字节基本确定，当前位置的信息量低。

这里需要注意：BLT 论文中对熵的建模会用到一个小型神经网络来做条件概率估计，比简单的频率统计更准确。但熵和 patch 切分的基本逻辑是一致的。

3.3 阈值机制与 patch 边界

有了每个字节位置的局部熵之后，切分策略就很直观了：

如果某个位置的局部熵高于预设阈值 $\tau$，说明模型在这里“搞不定”，需要更细的粒度，于是把这个位置标记为 patch 边界。
如果局部熵低于阈值，说明内容可预测，继续把后续字节累积到当前 patch 中。
实际实现中通常还会配置最小 patch 长度和最大 patch 长度，避免 patch 过大或过小带来的工程问题。

为什么熵高的地方要把 patch 切小？从直觉上看，高熵区域往往是语义复杂、容易出错的区域，比如生僻词、代码标识符、混合语言边界、键盘乱码等。如果把这些高熵内容和一个大段简单文本合并在同一个 patch 里，模型的注意力就会被稀释，重建字节时的错误也更容易传播。切小 patch，相当于给模型一个提示：“这个地方很难，请多花点注意力。”

反过来，熵持续很低的区域，比如重复的标点、常见介词、空格、助词，模型几乎不需要额外信息就能预测出来，所以合并成大 patch 是划算的选择，可以显著减少序列长度。

3.4 BLT 的两阶段 Transformer 结构

有了动态 patch 之后，BLT 的整体结构可以分为三部分：

第一部分是局部编码器（Local Encoder）。它负责读取原始字节流，对每个字节做浅层编码，然后按照切分边界把同一个 patch 内的字节表示融合成一个向量作为 patch embedding。局部编码器通常比较轻量，可以用小卷积或浅层 Transformer 实现。

第二部分是全局模型（Global Latent Transformer）。它处理的是 patch 序列，也就是把每个 patch 当作一个 token，在标准 Transformer 中进行自注意力计算。由于 patch 序列比原始字节序列短很多，全局模型能以更低的计算量建模长距离依赖。

第三部分是局部解码器（Local Decoder）。它把全局模型输出的 patch 表示还原为字节级表示，生成最终的字节预测。局部解码器同样比较轻量，可以把 patch 向量解码为 patch 内每个字节的向量，再映射到 256 类字节分布上。

这种两阶段设计和 MegaByte 有相似之处，但 BLT 的 patch 边界不再是固定的，而是完全由字节熵动态决定。动态切分带来的好处是：简单文本经过全局模型时序列更短，复杂文本则保留更多全局 token，信息密度得到更好的匹配。

4. 完整实战案例：用 Python 模拟 BLT 的动态 patch 切分

下面我们写一个完整的 Python 示例，模拟 BLT 中基于字节熵的动态 patch 切分过程。代码不难，但能清楚展示熵计算、阈值判断、patch 生成的全流程。

4.1 项目结构

本项目只需要一个 Python 文件，目录结构如下：

TEXT

blt_demo/

└── dynamic_patch.py

如果你愿意，也可以写成 Jupyter Notebook 逐步运行。为了便于解释，我们把完整代码放到一个文件里，核心函数包括：

compute_entropy(text, window_size)：计算文本每个字节位置的局部熵。
segment_patches(text, entropy_threshold, min_patch, max_patch)：根据熵值生成 patch 列表。
main()：演示入口，对不同文本执行切分并打印结果。

4.2 实现字节熵计算

先来看熵计算部分。我们用一个简单的滑动窗口，统计窗口内字节的频率分布，然后计算这个分布的熵值。这里使用 numpy 加速统计。

PYTHON

# 文件路径：blt_demo/dynamic_patch.py

import math

from collections import Counter

import numpy as np

def bytes_to_list(text: str) -> list:

"""把字符串转成 UTF-8 字节列表。"""

return list(text.encode("utf-8"))

def compute_entropy_at_position(window_bytes: list) -> float:

"""

计算一个字节窗口的信息熵。

熵越高，表示下一个字节越难预测；熵越低，表示越容易预测。

"""

if not window_bytes:

return 0.0

counter = Counter(window_bytes)

total = len(window_bytes)

entropy = 0.0

for count in counter.values():

prob = count / total

entropy -= prob * math.log2(prob)

return entropy

def compute_entropy_sequence(text: str, window_size: int = 8) -> list:

"""

对文本中的每个字节位置，计算以该位置为终点的局部熵序列。

返回的列表长度与字节序列长度一致。

"""

byte_seq = bytes_to_list(text)

entropies = []

for i in range(len(byte_seq)):

start = max(0, i - window_size + 1)

window = byte_seq[start:i + 1]

entropies.append(compute_entropy_at_position(window))

return entropies

代码里有一个关键点：我们把窗口定义为“当前位置以及之前的 window_size - 1 个字节”。这样越靠后的位置，窗口内积累的信息越多，熵值能反映“基于前文预测当前字节”的难度。

4.3 实现滑窗动态切分

有了熵序列，就可以根据阈值进行切分了。切分逻辑如下：

维护一个 current_patch 列表，存储当前 patch 的字节。
遍历每一个字节及其熵值。
如果当前 patch 长度达到最大限制，或当前熵值大于阈值，且 patch 长度不低于最小限制，就结束当前 patch，开启新的 patch。
如果熵值大于阈值，但当前 patch 长度还太小，就继续添加字节，等到长度达标再切。

PYTHON

def segment_patches(

text: str,

entropy_threshold: float = 3.5,

min_patch: int = 2,

max_patch: int = 24,

window_size: int = 8,

) -> list:

"""

根据局部熵动态切分 patch。

返回 list[dict]，每个 dict 包含字节、解码文本、熵值和长度。

"""

byte_seq = bytes_to_list(text)

entropies = compute_entropy_sequence(text, window_size)

patches = []

current_patch = [] # 当前 patch 的字节列表

current_entropies = [] # 当前 patch 内每个字节的熵值

for idx, byte in enumerate(byte_seq):

ent = entropies[idx]

current_patch.append(byte)

current_entropies.append(ent)

# 判断是否应该在此处切分：熵超过阈值，或长度达到上限

should_break = (

ent > entropy_threshold and len(current_patch) >= min_patch

) or len(current_patch) >= max_patch

is_last = (idx == len(byte_seq) - 1)

if should_break or is_last:

patch_bytes = bytes(current_patch)

try:

patch_text = patch_bytes.decode("utf-8")

except UnicodeDecodeError:

patch_text = repr(patch_bytes)

patches.append({

"bytes": patch_bytes,

"text": patch_text,

"avg_entropy": float(np.mean(current_entropies)),

"length": len(current_patch),

})

current_patch = []

current_entropies = []

return patches

这段代码有几个细节值得注意。

第一，should_break 条件要求当前 patch 长度不小于 min_patch，这是为了避免在高熵区域切出太多 1 字节 patch，导致序列长度失控。

第二，解码 patch 字节时可能出现 UnicodeDecodeError，因为一个 UTF-8 多字节字符可能被切到不同的 patch 里。这是教学中可以接受的简化，实际 BLT 会直接基于字节标签训练，不需要保证每个 patch 可解码为合法文本。

第三，max_patch 是一个硬上限，防止低频但低熵的长序列被无限合并成一个超长 patch。

4.4 运行与结果展示

接下来写一个 main 函数来测试不同文本：

PYTHON

def main():

samples = [

"the quick brown fox jumps over the lazy dog",

"人工智能正在改变自然语言处理的方式。",

"http://example.com/path?query=1&lang=zh",

"aaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbb",

]

for text in samples:

print("=" * 60)

print("原始文本:", text)

patches = segment_patches(text, entropy_threshold=3.2)

print(f"生成 patch 数: {len(patches)}")

for i, p in enumerate(patches):

print(f"patch {i + 1}: len={p['length']:2d}, "

f"avg_entropy={p['avg_entropy']:.2f}, text={p['text']!r}")

print()

if __name__ == "__main__":

main()

在终端运行：

BASH

cd blt_demo

python dynamic_patch.py

预期输出大致如下（实际结果会因为窗口统计方式略有不同）：

TEXT

============================================================

原始文本: the quick brown fox jumps over the lazy dog

生成 patch 数: 7

patch 1: len= 9, avg_entropy=3.01, text='the quick'

patch 2: len= 8, avg_entropy=3.33, text=' brown fo'

patch 3: len= 8, avg_entropy=3.10, text='x jumps '

patch 4: len= 8, avg_entropy=3.15, text='over the'

patch 5: len= 7, avg_entropy=3.08, text=' lazy do'

...

你可能会发现，英文文本的 patch 长度相对均匀，而中文文本会在汉字边界附近切出更密集的 patch，URL 类型文本则因为特殊字符较多，切分边界更多。这正是字节熵动态切分的效果：不同复杂度区域的 patch 密度不同。

4.5 结果分析与面试问题演练

从上面的输出中，我们可以观察到一个重要现象：简单英文句子的 patch 数量明显少于字节数量。比如 45 个字符的句子，可能只切成 7 个 patch，平均每个 patch 6 个字节左右。这说明模型在处理常见词汇时，确实可以通过低熵合并来降低序列长度，节省计算量。

如果调大 entropy_threshold，比如从 3.2 改成 4.5，你会发现 patch 数量减少，patch 长度普遍变大；调小阈值，则 patch 数量变多，切得更碎。这就是面试中常问的“熵阈值如何影响模型性能”的实验基础：阈值太高，patch 太大，复杂区域容易丢失细节；阈值太低，patch 太小，序列长度膨胀，计算效率下降。实际训练中需要通过验证集来挑选合适的阈值，甚至可以设计为自适应学习。

面试官如果问“BLT 为什么能扔掉分词器”，你可以这样回答：BLT 不依赖预定义词表，而是把文本编码成字节流，通过局部字节熵来判断哪些字节应该组成 patch。patch 是动态生成的，等价于让模型自己决定 token 粒度，从而避免固定分词带来的 OOV、跨语言不平衡和噪声敏感问题，同时通过大 patch 压缩序列长度，控制计算成本。

5. 常见问题与排查思路

下表整理了学习 BLT 和动态 patch 切分时常见的疑问与排查思路。

问题现象	常见原因	解决思路
patch 切得太碎，序列长度很大	熵阈值设置过低，或窗口过小导致熵值偏高	适当调高 `entropy_threshold`，增大 `window_size`，观察 patch 分布
patch 太大，复杂内容被合并	熵阈值过高，或 `max_patch` 设置过大	降低阈值，设置合理的最小/最大 patch 长度
中文文本切分效果不理想	UTF-8 中文编码固定为 3 字节，字符边界熵较高	考虑按字节窗口 + 高频汉字模式优化局部概率估计
演示代码中部分 patch 无法解码	patch 边界切在多字节字符中间	实际 BLT 在字节标签空间训练，不需要可解码文本；演示中可用 `repr` 显示
计算熵时使用简单频率统计不够准确	频率统计没有考虑上下文顺序	改用 n-gram 条件概率或小型神经网络估计条件分布
与固定长度 patch 相比，训练不稳定	动态长度导致 batch 内序列长度不一致	对同一 batch 内的样本设置最大字节数，并做动态 padding
部署时推理速度不稳定	patch 长度动态变化，计算时间波动	设置最大 patch 长度并做计算图优化，必要时对 patch 数量做约束

在实际项目里，最常见的坑是把“字节熵”理解为“字符频率熵”。字符频率只统计每个字节出现的次数，没有考虑“在当前上下文下是否容易被预测”。BLT 使用的是条件熵，本质上依赖一个模型对下一个字节的预测置信度。你在做实验时，如果只用简单的 Counter，切分效果会比较粗糙，但在教学中已经足够说明原理。

另一个常见误区是认为 BLT 完全不做任何切分。实际上 BLT 仍然在做“切分”，只是切分单元不再是固定词表里的 token，而是动态生成的 patch。可以理解为：BLT 用“预测难度”替代了“分词规则”，切分变成了训练的一部分，而不是固定的预处理步骤。

6. 最佳实践与工程建议

6.1 面向训练的熵估计器设计

如果你真的要复现 BLT 的实验，不要用小窗口频率统计来算熵。建议训练一个轻量级卷积网络或者小型 Transformer，输入当前字节之前的一段上下文，输出 256 维的字节概率分布。这个估计器本身也可以作为局部编码器的一部分，和全局 Transformer 联合训练。

熵估计器的质量直接决定 patch 切分质量。如果估计器太弱，熵值就不可靠，切分边界会变得不稳定；如果估计器太强，接近全模型能力，就失去了两级结构的计算优势。需要根据实际任务调整估计器的参数规模。

6.2 熵阈值的选取策略

熵阈值是 BLT 最重要的超参数之一。建议在验证集上做小范围搜索，观察两个指标：一是平均 patch 长度，二是下游任务效果。patch 长度过短说明计算效率低，patch 长度过长说明复杂细节被过度压缩。

实际训练中可以让阈值随训练步数缓慢变化。比如训练初期用较小阈值，让模型先接触细粒度 patch，学好字节级知识；训练后期调大阈值，提高 patch 利用率，让模型学习更高级的语义抽象。这种 curriculum 式的策略值得尝试。

6.3 与现有 Tokenizer 模型的迁移对比

在工程落地时，如果已经有基于 BPE 的模型，不建议直接丢弃词表后用 BLT 随机初始化训练，这样成本太高。可以先用现有模型在字节级任务上做蒸馏，或者把 BLT 作为基座模型的编码器分支，逐步替换固定词表模块。

评估时不要只看指标涨跌，还要关注序列长度、显存占用、推理延迟这些工程指标。BLT 的优势在于高熵区域能分配更多计算量，但“更多计算量”意味着局部 batch 的不均匀，需要工程上对 padding 和 bucketing 做优化。

6.4 安全与生产部署注意事项

在真实服务中部署 BLT 类模型时，需要注意输入字节流的异常情况。比如用户上传的文件可能包含大量乱码、极长 URL、二进制片段，这些内容的字节熵通常波动很大，可能导致 patch 长度极端化。建议在服务入口做输入长度限制，并在模型推理前对字节流做一次异常检测。

涉及权限、认证、外部数据读取时，必须强调合法授权和最小权限原则。不要因为模型是“字节级”输入就放松对数据来源的校验，安全边界永远在模型之外。生产环境变更前，先在小流量灰度验证，并准备回滚方案。

6.5 日志与监控

字节熵本身是一个很好的监控指标。线上推理时，可以统计每个请求的平均 patch 长度、熵分布、高熵比例。如果发现平均 patch 长度突然上升，可能说明输入分布发生了变化，或者模型某个局部模块退化。这类监控会比只看 ppl（困惑度）更快暴露问题。

7. 总结与学习路线

这篇文章从传统分词器的痛点出发，介绍了 Byte Latent Transformer 的核心设计：取消固定词表，通过字节熵动态切分 patch，让模型自己决定关注粒度。我们拆解了局部熵计算、阈值切分和两阶段 Transformer 结构，并提供了一个可以本地运行的 Python 模拟示例。你会发现，BLT 并不是简单地“按字节建模型”，而是把分词问题转化成了一个可学习的动态切分问题，这是它区别于 ByT5 和 MegaByte 的关键。

如果你准备在大模型面试中聊这个话题，建议按下面几个层次准备：

第一层，能讲清楚传统分词器的三个痛点：OOV、跨语言不平衡、噪声敏感。

第二层，能解释 BLT 的基本流程：文本 -> UTF-8 字节 -> 局部熵计算 -> 动态 patch -> 局部编码器 -> 全局 Transformer -> 局部解码器。

第三层，能深入讨论熵阈值和 patch 长度的权衡，最好还能画出简单文本和复杂文本的 patch 分布对比。

第四层，如果能进一步指出“动态切分带来的工程难点，比如 batch 长度不均、推理延迟波动”，面试官会觉得你确实动手思考过。

下一步可以做的实验是：把演示代码中的 compute_entropy_at_position 替换成一个小型 n-gram 模型，感受一下条件概率估计对切分效果的影响；然后再尝试用 PyTorch 写一个简化的两层 Transformer，把 patch 切分和 Transformer 前向打通，你会对 BLT 的两阶段设计有更直观的理解。

如果本文对你有帮助，建议收藏备用，后续可以继续关注动态 token 化方向的新工作。动手跑一遍上面的代码，比单纯看十篇解析都更有价值。