韩语文档 OCR 比较 1：将 PP-OCRv5、PaddleOCR-VL-1.6、Unlimited-OCR-2 放在相同的 60 页中重新测试

状态：实测（2026 年 10 月 29 日至 10 月 30 日，单张 24GB 消费级 GPU）。 所有数字均取自亲自测量的原始数据（每页的输出原文、测量日志、 评分脚本）。论文数值与通过打开原文确认的表格和章节编号一起记录，未能测量的标注为「未实测」， 在原文中未找到的标注为「未确认」。安装过程中的遭遇和安全备忘录已单独收录于 第 2 篇中。

目录

• 1. 测了什么，为什么测
• 2. 三款引擎的读取方式有何不同
• 3. 测试文档与评分
  • 制作了答案已知的文档
  • 评分：两种字符错误率（CER）
  • 评分陷阱：如果不清除坐标，CER 高达 16%
• 4. 结果：准确率、速度、内存
• 5. 实际输出对比
  • 罕见收音：「쟀」三款引擎一次都没读出来
  • 意思颠倒的错误：「없습니다 → 있습니다」
  • 标点符号：PP-OCRv5 会替换书名号，模糊时则会删掉
  • 多页模式的分辨率下降
• 6. 为什么这么慢，以及不能用来夸夸其谈的数字
• 7. 该选择哪个
• 8. 局限性
• 参考资料

1. 测了什么，为什么测

OCR（光学字符识别）是从图片或扫描页中提取文字的工作。老旧的方式分为两个步骤。首先在页面中寻找有文字行的 位置（检测），然后将找到的行逐个切开并作为文字读取（识别）。如今，直接观察整张图片并立即写出 Markdown 的 视觉语言模型 （VLM，接收图像作为输入的语言模型）占据了文档 OCR 排行榜的前列。

这次挑选的引擎有三个。这三个引擎都出自同一家公司（百度）旗下的系列，但读取页面的方式各不相同。

为什么要亲自测试。因为文档 OCR 的代表性基准测试中没有韩语。

• OmniDocBench（CVPR 2025，arXiv 2412.07626）的 v1.0 包含 981 页，其中英语 290 页、简体中文 612 页、混合 79 页（表 S3）。其中没有韩语页面。 作者也写道「几乎所有算法在英语上的得分都高于中文」（§5.1）。这意味着排名可能会根据语言的不同而有所变化。
• 面向多页文档的 MPDocBench（arXiv 2605.22100，433 个文档 3,246 页）和 MarathonDocBench（100 个文档，103 页到 300 页）也只有英语和 中文。
• 引擎侧的依据也很单薄。PaddleOCR-VL 1.0 论文在 裁剪单行 单位的内部测试中报告韩语编辑距离为 0.052（表 6a），1.5 和 1.6 版论文中没有韩语评估。PP-OCRv5 韩语识别模型在官方文档中仅有「在 5,007 张韩语文字图片上准确率为 88.0%」的说明，没有论文数值。在 Unlimited-OCR 第 1、2 篇报告中，连「Korean」这个词都没有出现过一次。

因此问题有三个。在韩语文档中，这三个里哪个最准确。速度有多快，消耗多少内存。以及出错时 如何 出错。

2. 三款引擎的读取方式有何不同

PP-OCRv5 韩语不了解页面结构。检测器寻找文字行方框，识别器逐行输出文字。输出结果是将各行的文字从上到下 连接起来。根据 PaddleOCR 3.0 技术报告（arXiv 2507.05595，§2.1），该系列整体为 0.07B，小于 100MB（基于报告中的基础 模型标准，韩语识别模型的大小未确认）。

PaddleOCR-VL 将工作分为两部分（1.0 论文 arXiv 2510.14528，§2.1）。当布局模型（从 1.5 版开始为 PP-DocLayoutV3）确定「什么东西以什么顺序在什么地方」后，0.9B VLM（NaViT 方式动态分辨率编码器 + ERNIE-4.5-0.3B）仅读取单个裁剪元素的内容。 VLM 不会一次性查看整个页面。1.6 版（arXiv 2606.03264）保持结构不变，仅更改了数据和后训练。它挑选并补充了模型容易出错的样本（8 个检查点和预测结果出现分歧的 16 种畸形、古籍与稀有字符），并依次经历了 CPT、SFT 和 GRPO 强化学习（§3、§4）。

Unlimited-OCR-2 的骨架是 DeepSeek-OCR（arXiv 2510.18234）的「光学压缩」。编码器（DeepEncoder）将 1024×1024 图像缩小 16 倍，压缩为 256 个 左右的视觉 Token，然后由 3B MoE（混合专家，每个 Token 仅使用部分专家）解码器编写文字。第 2 篇报告（HF 公开 PDF，第 5-7 页） 新增的是 SR-SWA（稀疏引用滑动窗口注意力机制）。解码器在生成下一个 Token 时，不会查看所有页面的所有视觉 Token，而是只查看该页面的 几个块以及紧邻的前一个输出。根据我们收到的配置值计算，远程 12 块×32 + 本地 128 = 512 个 Token，这与模型卡片中的「512 tokens」 相符。这是一个旨在确保即使页面增加，单步计算量也不会增加的装置。

这两个 VLM 的训练数据之间也存在有趣的联系。Unlimited-OCR-2 的伪标签（由其他模型而非人工生成的标准答案）提取自 MinerU2.5-Pro 和 PaddleOCR-VL-1.6 （第 2 篇报告第 8 页）。本次对比中的两个 VLM 同时也存在师生关系。

3. 测试文档与评分

制作了答案已知的文档

实际扫描的文档需要人工逐字输入正确答案。因此我们反其道而行之。先确定正确字符，然后用这些字符绘制页面。 正文部分从 TT Lab 的技术学习笔记中提取了韩文占比超过 40% 的段落，并以 A4 尺寸（150dpi，1240×1754 像素）使用 Apple SD Gothic Neo 单一款字体进行绘制。60 页按如下方式划分：

模糊副本与普通正文的 文字完全相同。 因此，同一引擎两组之间的差异即为「因画质变差而产生的错误」。

评分：两种字符错误率（CER）

CER（Character Error Rate，字符错误率）是将标准答案转换为输出结果所需的最小编辑（插入、删除、替换字符）次数除以正确字符数所得的值。 若为 1%，则意味着平均每 100 个字符错一个。编辑距离是通过 Myers（1999）的位并行算法求得的。

由于每个引擎的输出格式不同，因此首先进行 标准化处理。使用 Unicode NFKC 进行统一，清除 Markdown 符号（#, *, | 等）、HTML 标签以及模型附加的 坐标标记，并 去除所有空格和换行符。 鉴于空格和换行会因布局而异，故仅对比字符顺序。

随后计算两次 CER。

• 整体 CER：标准化后的所有字符。包含书名号「」、间隔号 ·、句号、逗号等标点符号。
• 纯文字 CER：仅保留韩文、英文、数字计算出的值。

区分两者的原因是各个引擎 处理标点符号的习惯存在很大差异。如果将它们合为一个数字，那么「经常漏掉标点符号的引擎」与「错误读取韩文的引擎」就会获得相同的分数。诸如搜索索引等只需文字正确即可的用途，以及制作供人类直接阅读的文档的用途，需要查看不同的数字。

评分陷阱：如果不清除坐标，CER 高达 16%

Unlimited-OCR-2 的输出中每个块都附带坐标。例如，格式如下：

<BLOCK>text[71, 96, 900, 160]<FORK>우리에게 의미는 「언젠가 휴대폰 안에서 …

最初的评分器 <…> 仅清除了标签而保留了 text[71, 96, 900, 160] 。其结果是，普通正文的 CER 中位数 为 16.3%（每页 13.9% 到 17.5%）。当多加了一条坐标正则表达式后， 0.80% 变成了 。模糊副本从 16.95% 降至 1.99%，表格从 8.38% 降至 0.17%（使用相同的输出、相同的标准答案重新计算）。这意味着 20 倍的差距竟然源于一种输出格式。在对 VLM 输出进行评分时，首先肉眼阅读几页输出原文并调整标准化规则才是正确的流程。

4. 结果：准确率、速度、内存

阅读方法。中位数是将每页测得的 CER 排列后的中间值，如果是像第 8 页这样的偶数页，则采用靠上的值（第五个）。长文档作为一个整体进行评分，因此 只有一个值。时间是扣除预热单页后测得的平均值，长文档则是将总时间除以页数。内存是各框架分配器 记录的最大值（PyTorch·Paddle 的 max_memory_allocated），因此比 nvidia-smi 中显示的值要小。没有哪一页是 13 个批次全部失败的。

图中有三个值得指出之处。

PaddleOCR-VL-1.6 在所有四个批次中准确率最高。 普通正文的总体 CER 为 0.48%，相当于在约 1,230 个字符的页面中 错了大约六个字符左右。表格与 PP-OCRv5 一起，在所有 4 页中均为 0%。

除去标点符号后，排名会发生变化。 就总体 CER 而言，Unlimited-OCR-2（0.80%）优于 PP-OCRv5（1.52%）。然而，如果只计算文字， PP-OCRv5 为 0.33%，Unlimited-OCR-2 为 0.75%，排名随之反转。在模糊复印件中这一点更加明显。就总体 CER 而言，PP-OCRv5 为 4.47%，是三者中 最差的，但仅文字 CER 为 1.23%，优于 Unlimited-OCR-2（1.76%）。PP-OCRv5 的错误大多是 标点符号，而 Unlimited-OCR-2 的 错误大多是 文字。图中两点之间的条形越长，意味着标点符号错误越多。Unlimited-OCR-2 几乎没有条形。

一次性读取多页时，Unlimited-OCR-2 的错误大约增加了三倍。 如果拿同一篇长文档的前 10 页进行对比，PaddleOCR-VL-1.6 为 0.58%，PP-OCRv5 为 1.53%，而 Unlimited-OCR-2 为 2.72%（前 10 页的值是将 40 页的输出裁剪对齐到第 10 页末尾后重新计算得出的，如果对整个 40 页采用相同的方法，就会直接得出表中 0.53% 和 1.41% 的结果）。与逐页读取时（普通正文 0.80%）的差异源于分辨率模式。单页采用分块详细查看的 Gundam 模式，多页则采用每页 273 个视觉 Token 的 Base 模式读取。实际例子将在第 5 节中看到。

速度不在同一个数量级上。在普通正文单页测试中，PP-OCRv5 耗时 0.36 秒，PaddleOCR-VL-1.6 耗时 13.81 秒（约 38 倍），Unlimited-OCR-2 耗时 31.07 秒（约 86 倍）。简单换算成一小时，分别约为 1 万页、约 260 页、约 116 页。PP-OCRv5 在模糊复印件中更快（0.20 秒）是因为图像 缩小到了 0.6 倍。内存方面，PP-OCRv5 为 2.27 GiB，PaddleOCR-VL-1.6 为 5.80 GiB，Unlimited-OCR-2 仅权重就占 6.32 GiB，单页为 6.85 GiB， 10 页为 7.59 GiB，20 页为 8.81 GiB，随着页数增加而增加。如果是 24GB 显卡，三者都绰绰有余。

不过，这两个 VLM 的耗时是 我们运行方式下的耗时，并非模型的极限。原因将在第 6 节中阐述。

5. 实际输出对比

下面来看数字后面的实际输出。下面两幅图是同一页（第 2 页）的同一位置。上方是将引擎接收到的图像按像素原样复制的切片， 下方是将三个引擎的输出对齐到正确位置后的结果。选择这一页是因为它的错误类型较为集中且全面（普通正文第 2 页的 CER 为： PaddleOCR-VL-1.6 为 0.09%，Unlimited-OCR-2 为 0.26%，PP-OCRv5 为 1.57%，比批次中位数略好一些）。

罕见收音（韵尾）：「쟀」三者全部未能识别

「쟀습니다」是「재다」的过去式，在普通正文第 8 页中出现了 7 次。 三个引擎全部 7 次都识别错了。 即使在清晰的普通正文中也是如此。

PP-OCRv5 在清晰的一侧总是将之识别为「졌」。识别器只在既定的字词表中挑选答案，如果「쟀」不在该字词表中，它就会像这样始终替换为最相似的字（实际上该字是否真的不在表中未做核实）。两个 VLM 的答案则比较分散。这似乎是因为在形状相似的字中，语言模型倾向于选择更常见的一侧。由于这是日常文档中罕见的收音（韵母），很可能是因为三个引擎的训练数据中这类样本较少。

还有更多类似的字。「힙」（「읽힙니다」、「밝힙니다」、「힙 메모리」）在一般正文中出现了 5 次，而 Unlimited-OCR-2 在这 5 次中全部识别成了「힘」或「립」，PaddleOCR-VL-1.6 全部答对，PP-OCRv5 则答错了一次。「씁니다」中的「씁」只有 Unlimited-OCR-2 把它识别成了「씽」（一般正文 3 次中的 2 次、模糊复印件 3 次全部如此）。相反，「랠리」中的「랠」则是 PP-OCRv5（「앨」）和 PaddleOCR-VL-1.6（「램」、「랄」）答错，而 Unlimited-OCR-2 在清晰的一侧答对了。在罕见的字面前，没有哪个引擎是绝对安全的，每个引擎的薄弱字也各不相同。

导致意思颠倒的错误：「없습니다 → 있습니다」

Unlimited-OCR-2 将「없」识别成了「있」。在一般正文中「없」出现了 14 次，其中有 2 次出错，在模糊复印件中也是同样的 2 次。图中的例子是将“连为什么原因都会告知的提示信息也 没有了”变成了“提示信息也 有了”。就 CER 而言，1,150 个字中仅有 1 个字错误，仅占 0.09%，但句子的意思却完全相反。两个 Paddle 引擎全部 14 次都答对了。

这个错误很难单凭字形来解释。「없」和「있」的收音形状有相当大的差异。当视觉依据较弱时，这似乎是解码器的语言知识倾向于填入更常见一侧的错误。PP-OCRv6 论文（arXiv 2606.13108）也将 VLM 系列 OCR 的这种“幻觉”视为一个问题。对于合同、检测结果等一个否定词就至关重要的文档，VLM 的输出应当以有人工审核的流程为前提。

标点符号：PP-OCRv5 会替换书名号，模糊时则会删掉

拉高 PP-OCRv5 整体 CER 的几乎全都是标点符号。数一下错误类型（通过对齐标准化文字来统计其他地方）可以发现，在一般正文中，将 「 替换为 ' 的有 46 次，将 」 替换为 ] 的有 42 次。在模糊复印件中，没有进行替换而是 直接删除了。 包括删除句号 60 次、删除 「 39 次、删除逗号 38 次、将逗号替换为句号 36 次、删除 」 30 次、删除间隔号 · 28 次。较小且模糊的点在检测阶段似乎没有被当作文字捕获到。

两个 VLM 的标点符号也会出错，但次数要少得多。在模糊复印件中，PaddleOCR-VL-1.6 将「 改为 ‘ 或 ' 的有 18 次，而 Unlimited-OCR-2 最多的则是模糊复印件中删除中圆点 18 次、将「 改为 ' 的 11 次。

顺便说明一下评测程序的一个小瑕疵。正文中的破折号 – 被三个引擎都识别为了连字符 -，由于正则化会把连字符视为 Markdown 符号并将其删除，因此每次在每组中被统计为 4 次「删除破折号」。严格来说，这是将破折号替换为了连字符，且三个引擎的输入完全相同，因此排名不会改变。

多页模式下的分辨率下降

Unlimited-OCR-2 一次性读取 10 页长文档的输出中，混入了单页读取时很难看到的错误。例如：「늘어납니다 → 놀아납니다」、「체감 → 채갑」、「멘션 → 댄선」、「가벼운 → 바뀌온」、「댓글 → 덧글」（3次）、「랠리 → 뭘리」等。不是单个字符，而是两三个字符一起崩塌，变成了形状相似的其他词汇。PaddleOCR-VL-1.6 逐页读取同一文档时，前 10 页的 CER 为 0.58%。

论文已经指出了原因。DeepSeek-OCR 表 3 显示，在相同的 Base 模式下，笔画密集的中文的编辑距离约为英文的 4 倍（0.205 对 0.054），而在增加了 Token 数量的 Gundam 模式下则优化为 0.097。Unlimited-OCR 第一篇报告（arXiv 2606.23050，§5.4）也指出，超过 40 页的文档中绝大多数错误 是由 Base 模式下无法识别小字 导致的。韩文也是带有收音的方块字，因此更接近中文。我们的结果与该解释相符。当每页的视觉 Token 减少到 273 个时，24px 韩文的收音就会发生模糊崩塌。

6. 为什么这么慢，以及为什么不能仅凭这些数字下定论

Unlimited-OCR-2 的单页 30 秒与论文中的速度相去甚远。但这两个数字 类型不同。

论文中的数字是并发吞吐量。 Unlimited-OCR 第一篇中的 5,580 TPS（每秒 Token 数，§5.2）是 512 个并发请求的总和，而第二篇表 4 中的 1,315 TPS 则是批次大小为 16 时的数值。如果平摊到单个请求，分别约为 11 和 82 Token/秒。第二篇图 6(b) 中每步约 3.8ms 是在批次大小为 3 时测得的。这三个数值均未公开硬件信息（未确认）。而我们 在批次大小为 1 时每秒 37.9 个 Token，每步 26.4ms （普通正文 8 页输出的 9,426 个 Token 除以 248.6 秒所得的值）。

硬件带来的影响并不大。 批次大小为 1 的解码在每一步都需要从内存中读取权重，因此受限于内存带宽。模型卡测试所使用的 A800 80GB 带宽为 1,935 GB/s（官方规格），而我们的 GPU 约为 936 GB/s，差距大约是 2.1 倍。如果以 bf16（2 字节）读取约 0.57B 的激活参数，每步大约是 1.14 GB，因此即使在我们的 GPU 上，理论上每步的下限也约为 1.2ms（估计值）。实际测得的 26ms 超过了该数值的 20 倍。瓶颈不在于硬件，而在于 执行路径。

Transformers 路径是「用于快速测试的路径」。 模型卡就是这么叫的，在服务部署时推荐使用 SGLang。阅读我们收到的远程代码（revision 5632329a)就会明白原因。这是一个逐个输出 Token 的 Python 循环，且没有 CUDA graph。每层 MoE 会通过 tokens_per_expert.cpu() 让 GPU 与 CPU 同步，解码注意力机制不会只计算选定的块，而是将整个缓存复制为 fp32，进行密集矩阵乘法后用掩码遮挡。结果虽然与稀疏注意力相同，但计算是密集的。因此，20 页的捆绑包耗时是 10 页捆绑包的 2.16 倍（输出 Token 为 1.96 倍）。每步耗时从 27.7ms 增加到 30.6ms，大约长了 10%。

SR-SWA 承诺的是“每步保持恒定”。 总时间与输出 Token 数量成正比，因此随页数线性增长是正常的。SR-SWA 防止的是全局注意力的平方级增长，而在第 2 篇的图 6(b) 中，这种差距急剧拉大的地方是在 50 页到 100 页以上（在 100 页时，全局注意力约为 26.7ms 对比 SR-SWA 约为 3.9ms，数值由肉眼读图得出）。以我们 10 页和 20 页的测量结果，无法验证 SR-SWA 的优势。

PaddleOCR-VL 也是同样的情况。 我们没有使用 vLLM 或 FastDeploy 服务器，而是通过 Paddle 动态图按顺序逐页读取。1.0 论文表 13 报告称，在单张 A100 上塞入 512 个 PDF，FastDeploy 达 1.62 页/秒，vLLM 达 1.35 页/秒。附录表 A2 和 1.5 版表 A8 中也有面向入门级消费级 GPU 的 0.36 到 0.54 页/秒。这与我们的 0.07 页/秒（13.81 秒）相差十倍以上。由于这也是批处理吞吐量，因此无法直接进行对比。

因此，从这个结果来看，有 不能 成立的说法。

• “Unlimited-OCR-2 比 PaddleOCR-VL-1.6 慢两倍”：两个 VLM 均未使用推荐的服务部署路径。服务引擎之间的速度差异未经验证。
• “PP-OCRv5 比 VLM 快 90 倍”：传统流水线的速度在我们的条件下是正确的，但 VLM 侧的数字是批大小为 1 且无服务引擎路径下的数值。
• “Unlimited-OCR-2 准确率最低”：我们的测试仅查看了单段正文的文字。该模型主打的是跨页的表格、段落和标题层级。其自我报告的 MPDocBench 84.59（第 2 篇 p.10 表 1）高于第三方在同一基准测试中测得的 PaddleOCR-VL-1.5 的 80.80（MPDocBench 论文表 2）（测量人员不同，输入方式是否相同未加确认）。我们并未测量结构指标。
• “没有出现重复错误”：作者的评估配置开启了 n-gram 重复阻止（大小为 35），但我们将其关闭了。在这次的 60 页测试中虽然没有看到重复循环，但配置有所不同。

7. 该如何选择

仅在我们的实际测量范围之内提供建议。基于韩语单段正文、网格表格、单张 24GB GPU、批大小 1。

也可以走将传统流水线与 VLM 结合的道路。例如，先用 PP-OCRv5 全部读取并建立索引，仅对需要人工阅读或置信度低的页面用 PaddleOCR-VL-1.6 重新读取。该组合的效果未经实测。

8. 局限性

• 合成文档。 为了解正确答案，文字是用单一字体绘制的，模糊、旋转、缩放以及 JPEG 也是合成的。实际扫描中纸张质感、弯曲、阴影、手写、多栏排版、印章等难点均不存在。实际扫描中的结果未经实测。
• 表格较为单一。 为无合并单元格的 4 页网格表格，未测量表格结构（TEDS），仅连接单元格文字进行对比。
• 样本较小。 每个捆绑包 4 到 8 页不等，中位数为 8 页中的第五个值。0.1 个百分点单位的差异可能会被单页数据反转。
• 单台设备，分时复用。 单张 24GB GPU 与其他任务分时共用，其影响未经单独测量。
• 未使用服务引擎。 Unlimited-OCR-2 使用 Transformers 路径（bf16, torch 2.14），PaddleOCR 系列使用 PaddleOCR 3.7.0 与 paddlepaddle-gpu 3.4.0 (cu129) 自行推理。
• 关闭了 n-gram 重复阻止（Unlimited-OCR-2、 no_repeat_ngram_size=0).
• Unlimited-OCR-2 的 40 页捆绑包测量中途中断，因此 只有 10 页和 20 页。其他两个引擎的长文档则是对 40 页逐页读取的。
• 正文来源。 测试段落来自我们的学习笔记，其中包含本博客公开的文章。各引擎的训练数据中是否包含相同的文章未经确认。
• 内存数字以分配器为准。 框架预先占用的部分以及 CUDA 上下文未被计入，因此实际显卡占用更大。

Titi 碎碎念。 三个引擎把“쟀습니다（测了）”读了二十一次，二十一次全部拼错。本来想写“测了乒乓球的速度”，结果写成“睡了”就麻烦啦！所以 OCR 结果不能只挑一个数字，还要看到底错在哪里、怎么错的，然后再做选择。

参考资料

原文均于 2026-10-30 打开查阅。arXiv 为 HTML 版本，故用节和表编号代替页码。

• Unlimited OCR Works, arXiv 2606.23050: https://arxiv.org/abs/2606.23050
• Unlimited OCR Works 2（报告 PDF，无 arXiv 编号）: https://huggingface.co/baidu/Unlimited-OCR-2/blob/main/Unlimited-OCR-2.pdf
• Unlimited-OCR-2 模型卡: https://huggingface.co/baidu/Unlimited-OCR-2
• DeepSeek-OCR, arXiv 2510.18234: https://arxiv.org/abs/2510.18234
• DeepSeek-OCR 2, arXiv 2601.20552: https://arxiv.org/abs/2601.20552
• PaddleOCR-VL, arXiv 2510.14528: https://arxiv.org/abs/2510.14528
• PaddleOCR-VL-1.5, arXiv 2601.21957: https://arxiv.org/abs/2601.21957
• PaddleOCR-VL-1.6, arXiv 2606.03264: https://arxiv.org/abs/2606.03264
• PaddleOCR 3.0 Technical Report, arXiv 2507.05595: https://arxiv.org/abs/2507.05595
• PP-OCRv6, arXiv 2606.13108: https://arxiv.org/abs/2606.13108
• PP-OCRv5 多语言识别模型（官方文档）: https://www.paddleocr.ai/latest/en/version3.x/algorithm/PP-OCRv5/PP-OCRv5_multi_languages.html
• OmniDocBench, arXiv 2412.07626, 代码库与排行榜: https://github.com/opendatalab/OmniDocBench
• MPDocBench-Parse, arXiv 2605.22100: https://arxiv.org/abs/2605.22100
• MarathonDocBench: https://huggingface.co/datasets/baidu/MarathonDocBench
• A800 80GB PCIe 规格（Lenovo Press）: https://lenovopress.lenovo.com/lp1813-thinksystem-nvidia-a800-80gb-pcie-gen4-gpu
• Myers, 「A fast bit-vector algorithm for approximate string matching based on dynamic programming」, Journal of the ACM, 1999