在写这个博客里的内容以及类似的文章的时候，我一般使用VSCode和Typora两个软件进行编辑。

Typora的优点是可以实时预览文章内容，可以正确显示博客里引用的图片。Hexo博客会将图片存在与markdown文件同名的文件夹中^[1]，而Typora支持通过在YAML Front Matter里面指定typora-root-url^[2]作为图片路径的前缀。

而VSCode的优点在于输入公式比较方便，可以在编辑数学公式的时候自动切换中英文^[3]，通过配置^[4]也可以支持正确添加图片，但是图片文件的路径是相对于markdown文件所在文件夹的路径，这个Hexo的设置是不一样的。一旦修改成Hexo需要的路径之后，VSCode就无法找到正确的图片了。

这点在写新的文章的时候还不太要紧，因为可以在写完文章后统一修改图片路径。但是在修改旧的文章的时候，由于无法正确预览图片，就不太方便了。

要让VSCode实现这个功能，就必须通过插件来完成。但是由于我不懂VSCode插件的开发，甚至不熟悉Typescript的语法，这个想法一直被我放下了。最近看到了oh-my-opencode项目，于是想着能否利用vibe coding来写一个插件，满足我上面的要求。

1. 第一次尝试

去年在MiniMax M2.1刚发布的时候，限时免费了一段时间，加上赠送的代金券，我尝试用它配合Cline来日常使用，效果还可以。因此我这次打算用opencode免费提供的minimax-m2.1-free模型，配oh-my-opencode的ulw模式使用。

起初我把需求丢给opencode，结果确实写出了一个像模像样的插件，包括了扩展入口、一个markdown-it插件和一个yaml front matter解析器。尝试对它进行调试，它还在调试日志中告诉你「插件已成功加载」，但就是没有任何实际的作用。

尝试让它自己去debug，但是多次尝试始终未能成功。

无奈，只能手动去查看文档。

发现主要的问题出现在两个地方：

1. 注册markdown-it插件的方法完全是错误的。
2. 在markdown-it插件里面，获取文档内容的方法完全是错误的，致使实际上无法获取yaml front matter的内容。

这就导致了插件彻底无法工作。而且，在debug的过程中，它完全没有想到要求修改这两个地方。

2. 手动搭建框架

无奈，还是只能从头开始手写。

首先，使用yo code搭建项目架构。根据官方文档，VSCode使用markdown-it来解析markdown文件，因此我们只需要实现一个markdown-it插件即可。

我们先实现一个markdown-it插件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

import type MarkdownIt from 'markdown-it';
import path from 'node:path';

interface ImageOptions {
  imageDir?: string;
}

export function prefixifyImageURL(md: MarkdownIt, pluginOptions?:ImageOptions) {
  const imageDir = pluginOptions?.imageDir || ".";

  const original = md.renderer.rules.image!;
  md.renderer.rules.image = (tokens, idx, options, env, self) => {
    const token = tokens[idx];
    const src = token?.attrGet('src');
    if (src) {
      token.attrSet('src', path.join(imageDir, src));
    }

    return original(tokens, idx, options, env, self);
  };
}

核心代码是重写了图片渲染逻辑md.renderer.rules.image，在正常渲染图片之前修改了图片的src属性。

然后使用extendMarkdownIt调用插件：

1
2
3
4
5
6
7

export function activate(context: vscode.ExtensionContext) {
  return {
    extendMarkdownIt(md: MarkdownIt) {
      return md.use(prefixifyImageURL, {imageDir: "assets"});
    }
  };
}

这里为了检查代码逻辑，图方便先写死了imageDir。

另外，还需要在package.json中将这个扩展注册为markdown-it插件：

1
2
3

"contributes": {
    "markdown.markdownItPlugins": true
}

调试插件，终于能够正常修改图片的路径了。

3. 动态加载图片路径

接下来，要解决的问题就是如何针对每个markdown文件获取typora-root-url信息，并使用它作为图片所在目录。

我的第一个想法是把imageDir存到env中，这样只需要读取一次，然后之后直接从env中调用即可：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

import fs from 'fs';
import matter from 'gray-matter';

function getImageDir(filePath: string): string | null {
  const fileContent = fs.readFileSync(filePath, 'utf-8');
  const { data } = matter(fileContent);
  return data['typora-root-url'] ?? null;
}

export function prefixifyImageURL(md: MarkdownIt) {
  const original = md.renderer.rules.image!;
  md.renderer.rules.image = (tokens, idx, options, env, self) => {
    let imageDir = env.imageDir;

    if (imageDir === undefined) {
      const filePath = env.currentDocument.path;
      imageDir = getImageDir(filePath);
      env.imageDir = imageDir;
    }

    if (imageDir !== null) {
      const token = tokens[idx];
      const src = token?.attrGet('src');
      if (src) {
        token.attrSet('src', path.join(imageDir, src));
      }
    }

    return original(tokens, idx, options, env, self);
  };
}

上面的代码确实能够满足要求，但是有一个问题，就是对修改typora-root-url的响应非常不及时，有很大的滞后性。

于是，我又尝试了第二种方法，就是每次从YAML Front Matter里动态获取imageDir：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

import frontMatter from 'markdown-it-front-matter';
import yaml from 'js-yaml';

let dynamicImageDir: any;

interface ImageOptions {
  imageDir?: Function;
}

export function prefixifyImageURL(md: MarkdownIt, pluginOptions?: ImageOptions) {
  const original = md.renderer.rules.image!;
  md.renderer.rules.image = (tokens, idx, options, env, self) => {
    const token = tokens[idx];
    const src = token?.attrGet('src');
    const imageDir = pluginOptions?.imageDir?.();
    if (imageDir && src) {
      token.attrSet('src', path.join(imageDir, src));
    }

    return original(tokens, idx, options, env, self);
  };
}

export function activate(context: vscode.ExtensionContext) {
  return {
    extendMarkdownIt(md: MarkdownIt) {
      return md.use(frontMatter, (fm: string) => {
        const fmData = yaml.load(fm) as Record<string, any>;
        const imageDir = fmData?.['typora-root-url'];
        dynamicImageDir = imageDir;
      }).use(prefixifyImageURL, {
        imageDir: () => dynamicImageDir,
      });
    }
  };
}

这样只要已修改typora-root-url的配置，立马就会在渲染中响应。

4. 支持图片链接的跳转和悬停预览

上面解决的是在右侧预览窗口里面的图片路径问题。另外还有一个需要适配的是在编辑界面的预览。

VSCode在鼠标指向图像链接的时候，会弹出该图像的预览。按住Ctrl单击，会跳转到对应的图片文件。我需要复现这两个功能。

这个部分让我自己写是完全不可能的，因此只能再次尝试vibe coding了。

好在，这次的结果还基本让人满意。

把需求喂给opencode之后，按住Ctrl单击的功能第一次就实现了，但是图像预览没有成功。不过让它自己进行debug，最终还是成功基本完成了这个任务。

不过，还是有一些小问题需要手动处理。

4.1. 问题一

其中一个是我提出的一个新的功能要求。上面实现的图像预览虽然成功了，但是由于有一些图像本身特别大，无法在预览框里完整显示（VSCode自带的图像预览是可以缩放到合适的大小的）。

尝试多次让opencode进行修改，都没有成功。无奈只能手动修改。

这里面最关键的点，在于VSCode到底是如何渲染markdown的图片的。

查看VSCode的源代码，从markdownRenderer.ts可以看到，它调用了parseHrefAndDimensions函数来识别图像的高度和宽度，该函数的定义位于htmlContent.ts，具体定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

export function parseHrefAndDimensions(href: string): { href: string; dimensions: string[] } {
  const dimensions: string[] = [];
  const splitted = href.split('|').map(s => s.trim());
  href = splitted[0];
  const parameters = splitted[1];
  if (parameters) {
    const heightFromParams = /height=(\d+)/.exec(parameters);
    const widthFromParams = /width=(\d+)/.exec(parameters);
    const height = heightFromParams ? heightFromParams[1] : '';
    const width = widthFromParams ? widthFromParams[1] : '';
    const widthIsFinite = isFinite(parseInt(width));
    const heightIsFinite = isFinite(parseInt(height));
    if (widthIsFinite) {
      dimensions.push(`width="${width}"`);
    }
    if (heightIsFinite) {
      dimensions.push(`height="${height}"`);
    }
  }
  return { href, dimensions };
}

从这里可以看出，VSCode接受![](a.png|height=240)这样指定图片尺寸的方式。由此，我们可以根据图片的长宽比例指定预览的宽度或高度。

4.2. 问题二

另一个问题是显示的链接下划线部分，长度和VSCode显示的不一致。尝试让opencode进行修改，但是最终还是差了1个长度，而且固执地认为算的没有问题。

奇怪的是，它在思考链中的分析其实是正确的，但是最终计算的offset值始终不对。

好在，这个错误很容易修改。

5. 总结

最终的代码我放在了vscode-markdown-hexo仓库。虽然还有一些bug，但是基本上个人使用够了。

回过头来看这次vibe coding的经历，整体的评价还是正面的，因为利用它我完成了一个之前我个人不可能完成的任务。

但是问题还是比较多的，主要是涉及到一些不是很常见的功能的时候，AI无法找到对应的代码，于是就开始瞎编了，编完了还像模像样地告诉你没有问题。

总体来说，和我这几年使用AI的感觉是一致的：就是AI强于逻辑，但是弱在事实核查。

说到事实核查，我不得不祭出当年GPT-3.5刚出来的时候的几张截图：

呃。。。

1月份，DeepSeek发布了DeepSeek-OCR 2，使用了新的视觉编码器。我尝试使用新的模型对小蓝本进行OCR，和之前的结果进行对比。

1. 代码

具体的识别代码见pdf2md.py，基本上和V1版本是一致的，稍微修改几个参数即可。

尝试过使用vLLM进行加速，但是没有成功。我的笔记本电脑显存有8G，但可分给vLLM的显存只有6.92G（对应的配置是gpu_memory_utilization=0.865），再高了就分配失败（即使关了独显直连也是这样）。这样加载完模型之后，还差0.38G才够KV缓存占用。无奈只能放弃了。

2. 进步

在下面的对比图片中，左侧是V1版本的结果，右侧是V2版本的结果。

1. 能够正确识别多行公式并使用aligned环境。

2. 漏图的情况大大减少，例如

3. 对于数学公式内的相似符号、文字的识别正确率略有提升，例如

3. 退步

上面只是一些细微方面的进步，但是退步却是大面上的。

1. 之前V1版本，对于简单的公式更倾向于识别成数学公式，而V2版本则更倾向于识别成普通的文字。例如

这点其实是V1版本的DeepSeek-OCR相较于MinerU和PaddleOCR-VL最让我满意的地方。而这个优势在V2模型中彻底丧失了。

这也带来的另外一个问题，就是有的时候识别出了数学公式，但是却没有把它放到正确的环境中，例如

这种情况在PaddleOCR-VL的识别结果中也多次出现。

2. V2版本的DeepSeek-OCR虽然识别图像的准确率提高了很多，但是却出现了一个V1版本没有出现过的问题，就是在排版的时候，图片和图片的标题分开了，没有放到一起，例如

几乎所有的图片有这个问题。这又和PaddleOCR-VL表现一致了。

检查了一下区域检测结果，V1版本把图片的标题识别成了image_caption，而V2版本则是识别成了figure_title：

3. V2版本还出现了一次大标题识别错误的情况：

看了一下区域监测结果：

识别区域是对的，但是不知道为什么最终的输出出了问题。这个问题之前从来没有出现过。

4. 整体评价

从最终的结果来看，DeepSeek-OCR 2的实际可用能力相较于原来的V1版本大大降低。如果选择一个版本的识别结果作为底本进行校对，我宁愿选择V1版本的识别结果。

V2版本带来的进步，第1个可以通过脚本进行批量替换解决，第2个和第3个都是只有在少数地方才能享受到的，而退步的前两种情况则是对几乎所有内容的识别都有影响。

在之前的文章的评论区里，有人建议试一试MinerU。其实在去年7月MinerU刚发布的时候，我就尝试过，但是印象中效果非常差，根本没法实际使用。

正好我的电脑里还存有当时配置好的虚拟环境，又重新试了一下，结果印证了我的记忆。由于问题实在太多，我就不放截图了，只是罗列一下它的问题：

• 完全不能识别公式中的汉字
• 所有多行公式无法换行
• 经常漏识别公式的一部分（如最后的字母、特殊符号如平行等）
• 经常无法识别分式
• 偶尔会漏识别公式
• 经常识别不出特殊符号（如相似）
• 偶尔识别错误字母（例如p识别成Φ）
• 中英文混合的情况，不能识别英文之间的空格
• 偶尔汉字识别错误
• 偶尔公式后面多出东西（把公式的一部分重复识别成了文字）
• 偶尔多行公式排版错误（$$后不换行直接跟文字）
• 偶尔行间公式排版错误（错误使用\$）
• 经常错误识别标点符号（例如逗号识别成双引号），经常漏识别标点符号

这些问题导致识别得到的结果错误非常多，已经到了不可用的地步。

不过看官方仓库里的说明，新版的MinerU使用vLLM部署之后能有90+的准确率，我决定再试一下。

1. 安装新版MinerU

由于使用vLLM部署比pipeline模式的准确率高很多，加之8G显存够用了，因此我直接使用vLLM方式进行部署。

安装也很简单：

1
2

uv venv --seed --python python3.13
uv pip install "mineru[all]"

此时的MinerU版本是2.6.4

接下来就可以使用了：

1

uv run mineru -p input/test.pdf -o output -b vlm-vllm-engine

进一步的配置选项可以参看官方选项，默认配置对于我来说就可以使用了。

这样临时使用一下还可以，但如果要大量文件需要识别，每次都会花大量时间在模型的加载上。这时可以使用server模式进行部署和调用。首先运行vllm-server：

1

uv run mineru-vllm-server

然后在另一个终端里运行

1

uv run mineru -p input/test.pdf -o output -b vlm-http-client -u http://localhost:30000

即可。

2. 和PaddleOCR-VL的对比

在下面的对比图片中，左侧是MinerU的结果，右侧是PaddleOCR-VL的结果。

2.1. 速度

同样是识别小蓝本（共8本），耗时33分21秒，比PaddleOCR-VL慢了约17%。

2.2. 优势

MinerU没有出现PaddleOCR-VL中的公式错行现象，基本上能够正确识别公式的位置。

另外，MinerU对于特殊数学符号（如平行、相似等）的识别准确率要高于PaddleOCR-VL和DeepSeek-OCR。

2.3. 劣势

虽然最新的MinerU和最初的版本相比，前面列出的问题大部分都得到了解决，但是还有一部分被部分继承了下来。

例如，简单的文字识别错误：

简单的字母识别错误：

简单的标点识别错误：

另外，MinerU还出现了图片分割不准确的情况：

这个问题PaddleOCR-VL和DeepSeek-OCR从来没有出现过。

2.4. 共同的问题

MinerU和PaddleOCR-VL都在同一类地方栽了。类似下图，

识别的结果如下：

可以看到，二者都不能正确区分题目的序号和公式部分。

而DeepSeek-OCR能够正确处理：

3. 总结

如果让我给这几个OCR模型进行排行的话，大致是

DeepSeek-OCR ≳ MinerU 2.6 (vllm) > PaddleOCR-VL >> PaddleOCR (V3)

DeepSeek-OCR的优势在于排版最好，但是在识别一些复杂公式（如重分式）的时候可能会出问题（感觉是识别之后被改了）。

最大的劣势是模型还是偏大，模型参数本身超过6G，因此我没有办法在本地使用vLLM加速推理，只能使用Transformers进行推理（同时需要借用一部分内存），因此速度相比后两个慢很多。

MinerU的公式识别整体是最好的，但是会犯一些弱智的错误（比如经常识别不了字母p）。

前面两个基本上不分伯仲，关键是看注重哪方面。

PaddleOCR-VL的最大问题在于公式混合排版的输出顺序有问题。

上面两个都可以在本地（8G显存）使用vLLM进行加速，因此速度都是可用的。

PaddleOCR就连基本的退化问题都没有解决。

另外，PaddleOCR对于表格的识别也比PaddleOCR-VL差很多。

1. 中文的自动换行

VSCode的默认换行算法无法正确处理中文段落的换行。因为中文不像英文每个单词之间都有空格，所以经常出现换行位置超过屏幕范围的情况。例如

可以看到，有十个汉字还在第一行的右边，需要拖动水平滚动条才能看见。

这个可以通过修改控制计算换行位置的算法^[1]来解决。添加配置

1

"editor.wrappingStrategy": "advanced"

就可以解决这个问题。此时VSCode显示的内容就变成了

这时换行位置基本就正常了。偶尔超出屏幕一点，最多也就吞掉半个字。

2. 粘贴图片

之前的时候，一旦需要添加图片，我都会转而使用Typora编辑Markdown文件。

Typora的优点是具有可视化，表格编辑方便；VSCode的优点是可以在编辑数学公式的时候自动切换中英文输入法（通过我自己修改过的插件，原插件已失效）。

好在，同时需要大量编辑数学公式和大量添加图片的情况对于我来说基本上不存在。

不过，新版的VSCode其实已经支持了图片复制和插入^[2]。直接把图片拖入到VSCode中，可以看到「按住Shift以放入编辑器」的提示。此时按住Shift再放开鼠标，图片就被复制到Markdown文件所在的目录，并插入到了Markdown中。

不过，根据Hexo的文档结构，我需要把图片放到和Markdown文件同名的文件夹中，因此需要添加配置：

1
2
3

"markdown.copyFiles.destination": {
  "/source/**/*": "${documentBaseName}/"
},

这样图片就能直接复制到所需的位置了。

3. 预览SVG图像

我使用 pdf2svg 生成的SVG图像都是透明背景的，而VSCode又是深色背景，此时打开SVG图片根本看不清。添加配置

1

"svg.preview.background": "white"

这样就默认是白色背景了。

4. 数学公式

我的博客现在设置了 text-autospace: normal，这样浏览器可以自动在中英文字符之间增加间距，就不用手动添加空格了。

但是可惜的是，这个对于使用KaTeX插入的数学公式并不起作用，因此还是需要在公式两边手动添加空格。

我的方法是使用快捷键 Ctrl+m，手动添加数学环境及空格。快捷键设置如下：

1
2
3
4
5
6
7
8

{
  "key": "ctrl+m",
  "command": "editor.action.insertSnippet",
  "when": "editorTextFocus && editorLangId =~ /latex|latex-expl3|typst|markdown/",
  "args": {
    "snippet": " $${TM_SELECTED_TEXT}$1$ $0"
  }
}

但是这会带来一个问题。如果数学公式之后是标点符号，此时是不需要添加空格的，因此还需要手动删掉。如果每次输入的时候删除的话会非常麻烦。在使用LaTeX的时候，我是使用 latexindent 来进行完成格式化的，对应的 localSettings.yaml 配置如下：

1
2
3

replacements:
  - substitution: s/([，。；：、！？（）【】])\h+(\$+)/$1$2/g
  - substitution: s/(\$+)\h+([，。；：、！？（）【】])/$1$2/g

但是Markdown文件没有类似的软件。

我最终是通过「Run on Save」插件来完成这个任务的。安装插件以后，添加配置

1
2
3
4
5
6

"runOnSave.commands": [
  {
    "match": ".*\\.md$",
    "command": "sed -i -E -e 's/\\$+\\s+([，。！？；：、（）【】「」『』])/\\$\\1/g' -e 's/([，。！？；：、（）【】「」『』])\\s+\\$+/\\1\\$/g' ${file}",
  },
]

这样在保存Markdown文档的时候会自动运行 sed 命令，删掉多余的空格。

记录一下在WSL上成功挂载U盘的过程。

1. 连接USB设备

按照官方文档，安装usbipd-win，即可从WSL访问USB设备。

正常使用的大致流程如下：

graph LRA(共享) --> B(连接) --> C(挂载) --> | 使用 |D(卸载) --> E(断开连接) --> F(解除共享)

查看可用的USB设备：

1

usbipd.exe list

示例输出：

1
2
3

Connected:
BUSID  VID:PID    DEVICE                                                        STATE
2-3    0781:55ab  USB 大容量存储设备                                            Not shared

使用BUSID指定要共享的USB设备（需要管理员权限）：

1

sudo.exe usbipd.exe bind --busid 2-3

然后连接该设备：

1

usbipd.exe attach --wsl --busid 2-3

这时使用 lsusb 可以看到USB设备已经识别到了：

1

Bus 002 Device 003: ID 0781:55ab SanDisk Corp. Dual Drive

但是使用 lsblk 看不到该设备。原因是WSL的内核使用 CONFIG_USB_STORAGE=m 编译，需要手动加载对应的模块：

1

modprobe usb-storage

这时再运行 lsblk 就能看到新的设备了：

1
2

sde      8:64   1 114.6G  0 disk
└─sde1   8:65   1 114.6G  0 part

2. 挂载USB设备

如果U盘是FAT格式，这个时候就可以直接挂载了。

但是由于我的U盘比较大，之前格式成了exFAT格式。而WSL的内核没有编译exFAT（以及NTFS）的支持，因此要挂载U盘的话，需要重新编译内核。

不过编译内核也很简单，从官方内核仓库下载最新的内核，解压后进入文件夹，运行

1
2

cp Microsoft/config-wsl .config
make menuconfig

进入图形化配置界面，选择

1
2
3
4
5

File systems  --->
    DOS/FAT/NT Filesystems  --->
        <M> exFAT filesystem support
        <M> NTFS Read-Write file system support
        <*> activate support of external compressions lzx/xpress

我直接把exFAT和NTFS的支持都加上了。

1
2
3

CONFIG_EXFAT_FS=m
CONFIG_NTFS3_FS=m
CONFIG_NTFS3_LZX_XPRESS=y

1

./scripts/kconfig/merge_config.sh Microsoft/config-wsl /etc/kernel/config.d/usb.config > .config

然后编译内核：

1

make -j$(nproc)

安装模块：

1

make INSTALL_MOD_PATH="$PWD/modules" modules_install

最新的WSL使用vhdx挂载modules：

1

sudo ./Microsoft/scripts/gen_modules_vhdx.sh "$PWD/modules" $(make -s kernelrelease) modules.vhdx

然后把内核映像 arch/x86/boot/bzImage 和内核模块 modules.vhdx 放到Windows的硬盘上（我放在了 D:\Temp）。

在 .wslconfig 中配置自定义内核：

1
2
3

[wsl2]
kernel=D:\\Temp\\bzImage
kernelModules=D:\\Temp\\modules.vhdx

然后重启WSL即可。

要挂载exFAT的U盘，还需要安装对应的软件：

1

emerge --ask sys-fs/exfatprogs

（如果是挂载NTFS格式的设备，需要则安装 sys-fs/ntfs3g。）

加载所需的内核模块：

1

modprobe usb-storage exfat

然后就可以正常挂载U盘了：

1

mount /dev/sde1 /media

使用完了之后断开连接并解除共享：

1
2

usbipd.exe detach --busid 2-3
sudo.exe usbipd.exe unbind --busid 2-3

1. 问题描述

之前在从XeLaTeX切换到LuaLaTex的时候，发现二者对中文字符和英文字符（包括数学公式）之间的间距处理不一样。在源代码中是否添加空格会对最终的间距有影响。

以下面的示例文档为例：

1
2
3
4
5
6
7
8
9
10

\documentclass{ctexart}
\begin{document}
中English文

中 English 文

中$\sin(x)$文

中 $\sin(x)$ 文
\end{document}

这是XeLaTeX编译的结果，可以看到，不管加不加空格，得到的PDF间距都是一样的。

下面是LuaLaTeX编译的结果：

这时不加空格时的间距要小于加空格时的间距。

因此，如果使用LuaLaTeX进行编译，整个文档的风格必须统一，要么都加空格，要么都不加，否则就会很难看。

2. 解决方法

根据LdBeth^[1]给出的提示，找到了一个解决方法，可以通过设置 xkanjiskip 来解决这个问题。

在导言区加入：

1
2
3
4
5
6
7
8

\usepackage{iftex}
\ifluatex
    \usepackage{luatexja}
    \ltjsetparameter{
        xkanjiskip={\fontdimen2\font plus \fontdimen3\font minus \fontdimen4\font},
        alxspmode={`\%,3}
    }
\fi

这样使用LuaLaTeX编译出来的文档无论加空格与否，间距都是一致的。

另外，默认的设置在百分号「%」和中文之间没有空格，上面同时修复了这个问题。

之前直接使用PaddlePaddle进行PaddleOCR-VL的推理，优点是安装相对简单，但缺点是速度太慢了，推理速度只有之前PaddleOCR的40%，这已经比DeepSeek-OCR快不了多少了。这个速度识别几本书还行，多了的话速度根本不够。

造成速度慢的主要原因是PaddleOCR-VL模型在不使用推理框架的时候，只支持使用 batch_size=1 进行推理，因此GPU根本跑不起来。

PaddleOCR-VL是支持使用vLLM框架进行加速的。之前没有使用，主要是在安装的时候发现需要装特定版本的 flash-attn，于是就放弃了。

1
2
3
4
5
6
7
8

# qlop -cmv sci-ml/caffe2-2.9.0 sci-ml/flash-attention-2.8.3 sys-devel/gcc-14.3.0 llvm-core/llvm-21.1.4 llvm-core/clang-21.1.4 dev-lang/rust-1.91.0
dev-lang/rust-1.91.0: 21′57″ average for 1 merge
llvm-core/clang-21.1.4: 21′49″ average for 1 merge
llvm-core/llvm-21.1.4: 28′42″ average for 1 merge
sci-ml/caffe2-2.9.0: 24′25″ average for 1 merge
sci-ml/flash-attention-2.8.3: 1:11:42 average for 1 merge
sys-devel/gcc-14.3.0: 22′30″ average for 1 merge
total: 3:11:05 for 6 merges

好在，最新的文档给出了 flash-attn 的预编译包的仓库，里面有各个版本的编译好的包可以直接使用，因此就可以配置vLLM了。

1. 安装vLLM推理框架

按照官方提示，

由于推理加速框架可能与飞桨框架存在依赖冲突，建议在虚拟环境中安装。

我看了一下，主要是PaddlePaddle和vLLM依赖的PyTorch对于一系列nvidia包的不同（paddlepaddle-gpu==3.2.0 依赖12.9版本的CUDA，而 vllm==0.10.2 依赖 pytorch==2.8.0 及12.8版本的CUDA）。

所以新建一个虚拟环境，并安装vLLM推理框架：

1
2
3
4

uv venv --seed -p python3.12 .venv_vllm
VIRTUAL_ENV=.venv_vllm uv pip install "paddleocr[doc-parser]"
VIRTUAL_ENV=.venv_vllm uv pip install https://github.com/mjun0812/flash-attention-prebuild-wheels/releases/download/v0.3.14/flash_attn-2.8.2%2Bcu129torch2.8-cp312-cp312-linux_x86_64.whl
VIRTUAL_ENV=.venv_vllm uv run paddleocr install_genai_server_deps vllm

1
2

VIRTUAL_ENV=.venv_vllm uv pip install flashinfer-python flashinfer-cubin
VIRTUAL_ENV=.venv_vllm uv pip install flashinfer-jit-cache --default-index https://flashinfer.ai/whl/cu129

然后就可以启动vLLM服务了：

1
2
3
4
5

VIRTUAL_ENV=.venv_vllm uv run paddleocr genai_server \
  --model_name PaddleOCR-VL-0.9B \
  --backend vllm \
  --port 8118 \
  --backend_config <(echo -e 'gpu-memory-utilization: 0.8\nmax-model-len: 8192')

1
2
3
4
5

trust-remote-code: True
gpu-memory-utilization: 0.5
max-model-len: 16384
max-num-batched-tokes: 131072
api-server-count: 4

1
2

gpu-memory-utilization: 0.79
max-model-len: 4110

当屏幕出现 "GET /health HTTP/1.1" 200 OK 的字样时就说明vLLM服务启动成功了。

2. 调用vLLM推理服务

在另一个终端可以直接使用命令行进行调用：

1
2
3
4
5

uv run paddleocr doc_parser \
  --input input/test.pdf \
  --save_path output \
  --vl_rec_backend vllm-server \
  --vl_rec_server_url http://localhost:8118/v1

也可以使用Python进行调用：

1
2
3
4
5
6
7

pipeline = PaddleOCRVL(
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,
    use_chart_recognition=False,
    vl_rec_backend="vllm-server",
    vl_rec_server_url="http://localhost:8118/v1",
)

后续的使用方法就和之前一样了。

3. 速度对比

使用vLLM会带来巨大（超过20倍）的速度提升。在我的电脑上，跑完8本小蓝本，只需要27分41秒（均衡模式）。在推理过程中，显卡基本保持在80W的功率。

作为对比，在Kaggle上使用 GPU T4x2，并开启双卡双进程编译，需要5小时40分。

之前在本地运行的时候没有总计时，但是基本每本书都需要1小时以上的时间，其中最厚的《三角形与四边形》甚至需要将近两个小时。

4. 在Kaggle上部署

在Kaggle上部署的方法和在本地部署是一致的，显卡选择 GPU T4x2，只是需要调整一下 flash-attn 预编译包的版本。

不过，参考官方文档：

实测也确实如此。在Kaggle上部署之后，简单调用识别个图片还是没问题的，一旦涉及到多页PDF就经常报错。

而且此时在Kaggle上的推理速度还不到本地（RTX4060 8G）的一半，因此完全没有使用的必要了。

之前成功安装PaddleOCR-VL之后，就尝试使用再次对小蓝本进行OCR，这样就可以和之前的结果进行对比。

其实上篇文章本来就想写这个的，结果写着写着发现最新版的PaddleOCR-VL支持Windows和Kaggle部署了，然后就跑题了。。。

1. 坎坷的使用过程

使用PaddleOCR-VL的过程的非常坎坷。出现的问题在前文中已有叙述。开始是根本运行不了。后来升级了PaddleX之后，成功运行模型，但是又遇到了显存不足和程序卡死的问题。

刚开始使用我就发现使用PaddleOCR-VL占用的显存甚至比DeepSeek-OCR还要多，和官方宣传的「小」模型完全不符。而且最大的问题是，随着推理的进行显存占用越来越多。

好在，最终是通过手动释放显存和修改显存分配策略解决了。

确认可以正常运行之后，我想让它利用晚上睡觉的时间跑完OCR。看着识别第1本书运行正常就去睡觉了。然后早上起来发现就只有前两本书正常跑完了，跑到第3本书的时候程序就卡死了。后来我又多次复现了这个问题，但是始终没有找到原因。

不过中间有一次我把下载的模型删掉之后重新下载，后来就没有再出现这个错误了。

2. 结果对比

在下面的对比中，如果没有特殊说明，默认左侧是PaddleOCR-VL的结果，右侧是PaddleOCR（PP-StructureV3）的结果。

2.1. 退化

相交于PaddleOCR，PaddleOCR-VL最大的进步在于此，终于没有再出现退化的情况了（可喜可贺）。

2.2. 排版

2.2.1. 进步

应该说，PaddleOCR-VL的排版模型有了很大的进步，例如

2.2.2. 缺点

但问题也没有完全解决，例如

查看生成的可视化图像，可以看到

PaddleOCR-VL把每行里面居中的公式都视为了行间公式。这个本身到不要紧，但是最后把它们合并视为一个公式，这就造成了最终的排版错误。

我尝试把产线配置里面 layout_merge_bboxes_mode 中 display_formula（有注释）对应的选项从 large 改为 union，这时可以看到

模型其实最开始是识别到了每行的公式，然后又把它们组合了起来。

如果改为 small 的话，倒是不组合到一起了，但是输出顺序还是有问题：

而这是DeepSeek-OCR的识别结果：

在修改的时候，一定不能把 inline_formula 对应的选项改成 small，否则会造成有含有行内公式的段落只保留公式，不识别文字：

不过，又看了一下识别正确的情况：

没想明白它到底是如何区分行内公式和行间公式的。。。

2.3. 图片

2.3.1. 进步

PaddleOCR-VL的图片识别有所进步，终于能够分割一行的多个图片了：

不过最终还是过度分割了。。。

另外，PaddleOCR-VL也没有出现之前识别到图片里面的字母而没有正确识别出图片的情况：

PaddleOCR-VL对于图片标题的识别也有进步：

能够正确区分图片标题，不会把它和其它部分混到一起。

2.3.2. 缺点

不过，从上面个对比中也可以看到PaddleOCR-VL的问题。就是它明明已经识别到了图片和图片标题，但是却没有把它们放到一起。这就导致大部分图片和对应的标题都是分开的。这点比起PaddleOCR模型是大大的退步。

看了一下版面阅读顺序识别的结果，里面没有指定图片和图片标题的输出顺序，有可能是这个原因造成的：

2.4. 数学公式

2.4.1. 进步

PaddleOCR-VL相比之前的模型在数学公式方面的进步主要有一下几点：

其一，就像之前说的，没有出现退化的情形。

其二，PaddleOCR-VL在特殊符号的上的识别上要好的多，甚至比DeepSeek-OCR还要强。例如，

PaddleOCR-VL在大部分情况下能够正确识别「相似」、「平行」和「垂直」的符号，不像之前PaddleOCR模型大部分都识别不出来。

不过还是有识别错误的情况：

其三，之前PaddleOCR经常出现一个愚蠢地错误，就是识别不出公式里面的「减号」：

PaddleOCR-VL没有发现这个问题。

其四，基本没有出现因为行内公式导致的整段文字漏掉的情况：

其五，PaddleOCR-VL对于文字和公式的分割要准确很多：

虽然有时还是会犯错误。

但是，对于简单的字母和公式，PaddleOCR-VL还是更倾向于不把它们识别成公式。这点倒是没有改。

2.4.2. 缺点

相交于之前，PaddleOCR-VL也带来了两个以前从没有出现的问题。

一个是PaddleOCR-VL多次出现识别了公式但是没有把它放到正确环境里面的情况，如

看了一下显示版面区域检测的结果，确实是识别出行内公式了：

看来是最终输出部分的问题。

另一个是PaddleOCR的行间公式的输出比较混乱。

同一个公式，例如下面的公式：

$$\sin(x)$$sin(x)

DeepSeek-OCR转换为 \[\sin{x}\]，PaddleOCR转换为 $$\sin{x}$$，都没有问题。

而到了PaddleOCR-VL，它则是一会儿转换为

1

$$ \sin{x} $$ 

（注意 $$ 符号两边都有空格），一会儿转换为

1
2
3
4
5

 $$ 

\sin{x}

 $$ 

（还是 $$ 符号两边都有空格。）

一会儿又转换为

1
2

$$ \sin{x}
$$ 

有时还会把行间公式和文字放到一行。

这本身倒没什么问题，只是在做正则替换的时候要格外小心。

3. 总体评价

整体来看，PaddleOCR-VL相比PaddleOCR有明显的进步，但是仅对数学书籍的OCR识别来看，效果还是不如DeepSeek-OCR。

问题不是出自文字识别或公式识别本身（这方面PaddleOCR-VL实际上更强一些），而是出在排版算法上。

之前和DeepSeek-OCR进行对比，使用的是PaddleOCR，而不是当时的SOTA模型PaddleOCR-VL，原因也很可笑，就是按照官方文档安装之后居然无法运行，于是只能放弃了。

好在前几天释出的3.3.6版本的PaddleX解决了这个问题，本地的PaddleOCR-VL终于能正常运行了。

1. 安装PaddleOCR-VL

1.1. 在WSL上进行部署

之前已经安装了PaddleOCR：

1
2
3
4

export UV_DEFAULT_INDEX="https://pypi.tuna.tsinghua.edu.cn/simple"
uv venv --seed --python python3.12
uv pip install paddlepaddle-gpu==3.2.0 --default-index https://www.paddlepaddle.org.cn/packages/stable/cu129/
uv pip install "paddleocr[all]"

如果要使用PaddleOCR-VL产线，按照官方说明，必须安装特殊版本的 safetensors：

1

uv pip install https://paddle-whl.bj.bcebos.com/nightly/cu126/safetensors/safetensors-0.6.2.dev0-cp38-abi3-linux_x86_64.whl

另外务必确认PaddleX的版本：

1

uv pip install paddlex==3.3.6 paddleocr==3.3.1

或者直接升级也可以：

1

uv pip install -U paddlex paddleocr

之后就可以使用PaddleOCR-VL了。具体的代码参考官方文档。

我在官方示例的基础上稍微做了一下修改，除了保存markdown文件及图片外，还把所有生成的可视化图像转换成PDF保存。其中 pil_to_pdf_img2pdf 函数来自run_dpsk_ocr_pdf.py。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

from pathlib import Path
from paddleocr import PaddleOCRVL

input_dir = Path("./input")
output_dir = Path("./output")

pipeline = PaddleOCRVL(
    use_doc_orientation_classify=False,
    use_doc_unwarping=False,    ## 非必要一定要关掉！！！
    use_chart_recognition=False,
)


def process_pdf_file(pdf_path: Path, pipeline, output_dir: Path) -> Path:
    print(f"🤖 Processing PDF file: {pdf_path}")

    output = pipeline.predict_iter(input=str(pdf_path), use_queues=True)

    markdown_list = []
    markdown_images = []
    res_images = []

    for res in output:
        index = res.get("page_index") + 1
        print(f"🎲 parsing page {index} of file {pdf_path.name} ...")
        md_info = res.markdown
        markdown_list.append(md_info)
        res_images.append(res.img)
        res.save_to_xlsx(save_path=output_dir)
        markdown_images.append(md_info.get("markdown_images", {}))

    markdown_texts = pipeline.concatenate_markdown_pages(markdown_list)

    ## 生成输出文件路径
    mkd_file_path = output_dir / f"{pdf_path.stem}.md"
    mkd_file_path.parent.mkdir(parents=True, exist_ok=True)

    ## 写入Markdown文件
    print("🚀 Saving markdown file ...")
    with open(mkd_file_path, "w", encoding="utf-8") as f:
        f.write(markdown_texts)

    ## 保存可视化图像
    for layout in res_images[0].keys():
        layout_pdf = output_dir / f"{pdf_path.stem}_{layout}.pdf"
        print(f"🚀 Saving {layout} results to: {layout_pdf}")
        pil_to_pdf_img2pdf([item[layout] for item in res_images], layout_pdf)

    ## 保存图像
    print("🚀 Saving images in markdown ...")
    for item in markdown_images:
        if item:
            for path, image in item.items():
                file_path = output_dir / path
                file_path.parent.mkdir(parents=True, exist_ok=True)
                image.save(file_path)

    return mkd_file_path


for pdf_path in input_dir.glob("*.pdf"):
    process_pdf_file(pdf_path, pipeline, output_dir)

1.2. 在Windows上部署

今天又看了一下最新文档，对应的Windows版本的safetensors预编译包也有了，因此理论上在Windows上也能正常运行了。

1
2
3
4
5
6

$env:UV_LINK_MODE="symlink"
$env:UV_DEFAULT_INDEX="https://pypi.tuna.tsinghua.edu.cn/simple"
uv venv --seed -p python3.12
uv pip install paddlepaddle-gpu==3.2.0 --default-index https://www.paddlepaddle.org.cn/packages/stable/cu129/
uv pip install "paddleocr[doc_parser]"
uv pip install https://xly-devops.cdn.bcebos.com/safetensors-nightly/safetensors-0.6.2.dev0-cp38-abi3-win_amd64.whl

尝试运行

1

uv run paddleocr doc_parser -i https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/paddleocr_vl_demo.png --save_path output

然后就华丽地报错了：

1
2

RuntimeError: Exception from the 'vlm' worker: (NotFound) The kernel `fused_rms_norm_ext` is not registered.
  [Hint: Expected iter != kernels_.end(), but received iter == kernels_.end().] (at ..\paddle\phi\core\kernel_factory.cc:276)

好在可以解决，手动进行hacking，把 self.fuse_rms_norm = True 改为 False：

1

sed -i "s/self\.fuse_rms_norm = True/self.fuse_rms_norm = False/g" .\.venv\Lib\site-packages\paddlex\inference\models\doc_vlm\modeling\paddleocr_vl\_config.py

这时终于可以正常运行了。

1.3. 在Kaggle上部署

如果要在Kaggle上部署的话，GPU务必选择 GPU T4 x2，不要选择 GPU P100。

安装过程：

1
2
3
4

! pip install paddlepaddle-gpu==3.2.0 -i https://www.paddlepaddle.org.cn/packages/stable/cu126/
! pip install -U "paddleocr[all]"
! pip install https://paddle-whl.bj.bcebos.com/nightly/cu126/safetensors/safetensors-0.6.2.dev0-cp38-abi3-linux_x86_64.whl
! pip install img2pdf

然后就可以使用了。

需要注意的是，如果要使用双卡进行推理的话，直接指定 device="gpu:0,1" 是不行的，需要使用多进程并行推理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

import sys
from multiprocessing import Manager, Process
from queue import Empty

def worker(device, task_queue, output_dir):
    pipeline = PaddleOCRVL(
        use_doc_orientation_classify=False,
        use_doc_unwarping=False,
        use_chart_recognition=False,
        device=device,
    )

    while True:
        try:
            input_path = task_queue.get_nowait()
        except Empty:
            break

        try:
            output_path = process_pdf_file(input_path, pipeline, output_dir)
            print(f"✅ Processed {repr(str(input_path))}! Markdown file saved to: {output_path}")
        except Exception as e:
            print(f"Error processing {input_path} on {repr(device)}: {e}", file=sys.stderr)


with Manager() as manager:
    task_queue = manager.Queue()
    for pdf_file in input_dir.glob("*.pdf"):
        task_queue.put(pdf_file)

    processes = []
    for device in ["gpu:0", "gpu:1"]:
        p = Process(
            target=worker,
            args=(device, task_queue, output_dir)
        )
        p.start()
        processes.append(p)

    for p in processes:
        p.join()

2. 产线文件

实际使用的产线文件在PaddleX的configs/pipelines目录下。可以把它链接到本目录下，方便后续查看和修改：

1

ln -s .venv/lib/python3.12/site-packages/paddlex/configs/pipelines

常用的一些PaddleOCR产线与PaddleX产线注册名的对应关系如下：

可以在对应的yaml文件中看到具体的产线配置。

3. 遇到的问题

之前在使用PP-StructureV3的时候，一切都很正常。但是使用PaddleOCR-VL就出现了各种各样的问题。

3.1. 显存不释放

在本地运行PaddleOCR-VL的时候，经常出现占用显存不释放，然后还请求新的显存的情况。由于我是在笔记本电脑上运行，显存用完之后会直接借用内存。这不会报错，但是会大大影响推理速度。

目前的解决方法有两个：

其一，在运行 pipeline.predict_iter 之后、访问其结果之前，手动进行垃圾回收和显存释放：

1
2
3
4
5

import gc
import paddle

paddle.device.cuda.empty_cache()
gc.collect()

此时在任务管理器里会观察到占用的显存会有一次明显下降：

其二，设置环境变量：

1
2
3

import os

os.environ["FLAGS_allocator_strategy"] = "naive_best_fit"

需要注意的是，这个命令必须在paddle库导入之前设置才能生效。

双管齐下，PaddleOCR-VL在推理PDF时占用的显存大概在5G左右，只是偶尔会波动一下需要借用内存：

但是很快就回落了。这样对性能影响不大，还可以接受。

3.2. 程序卡死

在使用PaddleOCR-VL的时候，好几次遇到程序卡死的情况：

可以看到模型已经被加载，而且PDF也已经载入了，但是没有进行推理。使用strace看一下进程：

这是出现死锁了？

只能强行杀掉了。

3.3. 使用生成器

关于显存占用，还有一点需要注意。如果是使用

1
2
3

from paddleocr import PaddleOCRVL

pipeline = PaddleOCRVL()

创建产线，建议使用

1

output = pipeline.predict_iter(input=input_file)

进行推理。这样返回一个生成器，之后循环处理的时候再实际进行推理。

但如果是使用

1
2
3

from paddlex import create_pipeline

pipeline = create_pipeline(pipeline="PaddleOCR-VL")

创建产线，可以直接使用

1

output = pipeline.predict(input=input_file)

来进行推理。这时直接返回的就是一个生成器。

鬼知道为什么都是predict，返回值的居然不一样。。。

最近跑通了DeepSeek-OCR和PaddleOCR对于PDF的识别流程，于是尝试用它们来识别完整的书籍。

如果OCR的结果基本可用的话，就能减少很多录题的工作。

这次我选择初中的小蓝本（《数学奥林匹克小丛书》）作为测试，因为我手头正好有第三版的电子版，而且扫描的非常好。

1. 运行OCR

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292

import io
import os
import re
import tempfile
from pathlib import Path
from typing import List

import fitz  # type: ignore
import img2pdf  # type: ignore
import numpy as np
import torch
import typer
from PIL import Image, ImageDraw, ImageFont
from rich.progress import track
from transformers import AutoModel, AutoTokenizer


def pdf_to_images_high_quality(
    pdf_path: Path, temp_dir: Path, dpi=144, image_format="PNG"
) -> List[Path]:
    image_files = []

    pdf_document = fitz.open(pdf_path)

    zoom = dpi / 72.0
    matrix = fitz.Matrix(zoom, zoom)

    for page_num in range(pdf_document.page_count):
        page = pdf_document[page_num]

        pixmap = page.get_pixmap(matrix=matrix, alpha=False)
        Image.MAX_IMAGE_PIXELS = None

        if image_format.upper() == "PNG":
            img_data = pixmap.tobytes("png")
            img = Image.open(io.BytesIO(img_data))
        else:
            img_data = pixmap.tobytes("png")
            img = Image.open(io.BytesIO(img_data))
            if img.mode in ("RGBA", "LA"):
                background = Image.new("RGB", img.size, (255, 255, 255))
                background.paste(
                    img, mask=img.split()[-1] if img.mode == "RGBA" else None
                )
                img = background  # type: ignore

        img_path = temp_dir / f"{page_num}.png"
        img.save(img_path)
        img.close()
        image_files.append(img_path)

    pdf_document.close()
    return image_files


def pil_to_pdf_img2pdf(pil_images, output_path: Path):
    if not pil_images:
        return

    image_bytes_list = []

    for img in pil_images:
        if img.mode != "RGB":
            img = img.convert("RGB")

        img_buffer = io.BytesIO()
        img.save(img_buffer, format="JPEG", quality=95)
        img_bytes = img_buffer.getvalue()
        image_bytes_list.append(img_bytes)

    try:
        pdf_bytes = img2pdf.convert(image_bytes_list)
        assert pdf_bytes is not None
        with open(output_path, "wb") as f:
            f.write(pdf_bytes)

    except Exception as e:
        print(f"error: {e}")


def re_match(text):
    pattern = r"(<\|ref\|>(.*?)<\|/ref\|><\|det\|>(.*?)<\|/det\|>)"
    matches = re.findall(pattern, text, re.DOTALL)

    mathes_image = []
    mathes_other = []
    for a_match in matches:
        if "<|ref|>image<|/ref|>" in a_match[0]:
            mathes_image.append(a_match[0])
        else:
            mathes_other.append(a_match[0])
    return matches, mathes_image, mathes_other


def extract_coordinates_and_label(ref_text, image_width, image_height):
    try:
        label_type = ref_text[1]
        cor_list = eval(ref_text[2])
    except Exception as e:
        print(e)
        return None

    return (label_type, cor_list)


def draw_bounding_boxes(image, refs, jdx, out_path: Path):
    image_width, image_height = image.size
    img_draw = image.copy()
    draw = ImageDraw.Draw(img_draw)

    overlay = Image.new("RGBA", img_draw.size, (0, 0, 0, 0))
    draw2 = ImageDraw.Draw(overlay)

    #     except IOError:
    font = ImageFont.load_default()

    img_idx = 0

    for i, ref in enumerate(refs):
        try:
            result = extract_coordinates_and_label(ref, image_width, image_height)
            if result:
                label_type, points_list = result

                color = (
                    np.random.randint(0, 200),
                    np.random.randint(0, 200),
                    np.random.randint(0, 255),
                )

                color_a = color + (20,)
                for points in points_list:
                    x1, y1, x2, y2 = points

                    x1 = int(x1 / 999 * image_width)
                    y1 = int(y1 / 999 * image_height)

                    x2 = int(x2 / 999 * image_width)
                    y2 = int(y2 / 999 * image_height)

                    if label_type == "image":
                        try:
                            cropped = image.crop((x1, y1, x2, y2))
                            cropped.save(out_path / f"images/{jdx}_{img_idx}.jpg")
                        except Exception as e:
                            print(e)
                            pass
                        img_idx += 1

                    try:
                        if label_type == "title":
                            draw.rectangle([x1, y1, x2, y2], outline=color, width=4)
                            draw2.rectangle(
                                [x1, y1, x2, y2],
                                fill=color_a,
                                outline=(0, 0, 0, 0),
                                width=1,
                            )
                        else:
                            draw.rectangle([x1, y1, x2, y2], outline=color, width=2)
                            draw2.rectangle(
                                [x1, y1, x2, y2],
                                fill=color_a,
                                outline=(0, 0, 0, 0),
                                width=1,
                            )

                        text_x = x1
                        text_y = max(0, y1 - 15)

                        text_bbox = draw.textbbox((0, 0), label_type, font=font)
                        text_width = text_bbox[2] - text_bbox[0]
                        text_height = text_bbox[3] - text_bbox[1]
                        draw.rectangle(
                            [text_x, text_y, text_x + text_width, text_y + text_height],
                            fill=(255, 255, 255, 30),
                        )

                        draw.text((text_x, text_y), label_type, font=font, fill=color)
                    except Exception:
                        pass
        except Exception:
            continue
    img_draw.paste(overlay, (0, 0), overlay)
    return img_draw


def process_image_with_refs(image, ref_texts, jdx, out_path):
    result_image = draw_bounding_boxes(image, ref_texts, jdx, out_path)
    return result_image


app = typer.Typer(help="Convert PDF to Markdown using DeepSeek-OCR")


@app.command()
def convert(
    input_file: Path = typer.Argument(..., help="Input PDF file path"),
    out_path: Path = typer.Option(
        "output", "-o", "--output", help="Output directory for markdown file"
    ),
):
    os.makedirs(out_path / "images", exist_ok=True)
    temp_dir = tempfile.TemporaryDirectory()

    typer.echo(f"📄 Converting {input_file} to images...")
    image_files = pdf_to_images_high_quality(input_file, Path(temp_dir.name))

    MODEL_NAME = "deepseek-ai/DeepSeek-OCR"

    typer.echo("🤖 Loading DeepSeek-OCR model...")
    tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME, trust_remote_code=True)
    model = AutoModel.from_pretrained(
        MODEL_NAME,
        attn_implementation="flash_attention_2",
        trust_remote_code=True,
        use_safetensors=True,
        torch_dtype=torch.bfloat16,  # type: ignore
    )
    model = model.eval().cuda()

    prompt = "<image>\n<|grounding|>Convert the document to markdown."

    mmd_det_path = out_path / (Path(input_file).stem + "_det.md")
    mmd_path = out_path / (Path(input_file).stem + ".md")
    pdf_out_path = out_path / (Path(input_file).stem + "_layouts.pdf")

    contents_det = ""
    contents = ""
    draw_images = []
    jdx = 0

    typer.echo("🔍 Processing pages with OCR...")
    for image_file in track(image_files):
        content = model.infer(
            tokenizer,
            prompt=prompt,
            image_file=image_file,
            output_path=temp_dir.name,
            base_size=1024,
            image_size=640,
            crop_mode=True,
            save_results=False,
            test_compress=True,
            eval_mode=True,
        )

        page_num = "\n<--- Page Split --->"
        contents_det += content + f"\n{page_num}\n"

        matches_ref, matches_images, matches_other = re_match(content)

        with Image.open(image_file) as image_draw:
            result_image = process_image_with_refs(
                image_draw, matches_ref, jdx, out_path
            )

        draw_images.append(result_image)

        for idx, a_match_image in enumerate(matches_images):
            content = content.replace(
                a_match_image, "![](images/" + str(jdx) + "_" + str(idx) + ".jpg)\n"
            )

        for idx, a_match_other in enumerate(matches_other):
            content = (
                content.replace(a_match_other, "")
                .replace("\\coloneqq", ":=")
                .replace("\\eqqcolon", "=:")
                .replace("\n\n\n\n", "\n\n")
                .replace("\n\n\n", "\n\n")
            )

        contents += content + f"\n{page_num}\n"

        jdx += 1

    typer.echo(f"💾 Saving markdown to {mmd_path}...")
    with open(mmd_det_path, "w", encoding="utf-8") as afile:
        afile.write(contents_det)

    with open(mmd_path, "w", encoding="utf-8") as afile:
        afile.write(contents)

    pil_to_pdf_img2pdf(draw_images, pdf_out_path)

    temp_dir.cleanup()
    typer.echo("✅ Conversion completed successfully!")


if __name__ == "__main__":
    app()

1
2
3

uv venv --seed --python python3.12
uv pip install paddlepaddle-gpu==3.2.0 --default-index https://www.paddlepaddle.org.cn/packages/stable/cu129/
uv pip install "paddleocr[all]" typer

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

from pathlib import Path

import typer
from paddlex import create_pipeline  # type: ignore

app = typer.Typer(
    help="Convert PDF and image files to Markdown using PaddleX PP-StructureV3"
)

def process_pdf_file(pdf_path: Path, pipeline, output_dir: Path) -> Path:
    typer.echo(f"Processing PDF file: {pdf_path}")

    output = pipeline.predict(
        input=str(pdf_path),
        use_doc_orientation_classify=False,
        use_doc_unwarping=False,
        use_textline_orientation=False,
    )

    markdown_list = []
    markdown_images = []

    for res in output:
        md_info = res.markdown
        markdown_list.append(md_info)
        markdown_images.append(md_info.get("markdown_images", {}))

    markdown_texts = pipeline.concatenate_markdown_pages(markdown_list)

    mkd_file_path = output_dir / f"{pdf_path.stem}.md"
    mkd_file_path.parent.mkdir(parents=True, exist_ok=True)

    with open(mkd_file_path, "w", encoding="utf-8") as f:
        f.write(markdown_texts)

    for item in markdown_images:
        if item:
            for path, image in item.items():
                file_path = output_dir / path
                file_path.parent.mkdir(parents=True, exist_ok=True)
                image.save(file_path)

    return mkd_file_path


@app.command()
def convert(
    input_file: Path = typer.Argument(..., help="Input PDF or image file path"),
    output_dir: Path = typer.Option(
        "./output", "-o", "--output", help="Output directory path"
    ),
    hpip: bool = typer.Option(
        False, "--hpip", help="Enable high performance inference"
    ),
):

    pipeline_config = "./PP-StructureV3-notable.yaml"

    if hpip:
        typer.echo("🚀 Enabling high performance inference mode")

    pipeline = create_pipeline(
        pipeline=pipeline_config,
        use_hpip=hpip,
        hpi_config={"auto_config": "False", "backend": "onnxruntime"},
    )

    output_path = process_pdf_file(input_file, pipeline, output_dir)

    typer.echo(f"✅ Conversion completed! Markdown file saved to: {output_path}")


if __name__ == "__main__":
    app()

2. 简单修正

对于一些简单的错误，我们可以直接处理掉。

2.1. 乘号

由于小蓝本里面的乘号特别粗，因此经常被识别成\bullet。将其替换成正确\cdot即可。

2.2. 平行符号

国内书籍习惯使用的平行符号//有时无法被识别成对应的 $\LaTeX$LATE​X 代码\parallel，需要进行替换。

2.3. 多行公式

这个主要是DeepSeek-OCR的问题。它在识别到多行公式的时候，大部分时候不会使用align或array环境，而是识别成多个行间公式。这里全部改为使用aligned环境，但是对齐位置还需要之后进行手动修正。

另外，Typora要求多行公式在开始的$$或\[之后必须换行正确显示，因此也一并进行修改。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

import re
from pathlib import Path

import typer

app = typer.Typer()


def parse_multiline_formula(match: re.Match[str]) -> str:
    block = match.group(1)

    formulas = re.split(r"\\\] \\\[", block)
    if len(formulas) == 1:
        return match.group(0)

    res = r"\[\begin{aligned}"
    res += "\n"
    for i, formula in enumerate(formulas):
        res += f"&{formula}"
        if i < len(formulas) - 1:
            res += r"\\"
        res += "\n"
    res += r"\end{aligned}\]"
    return res


def parse_parallel(match: re.Match[str]) -> str:
    res = match.group(2)
    res = re.sub(r"/\s*/", r"\\parallel", res)
    return match.group(1) + res + match.group(3)


def format_deepseek(content: str) -> str:
    content = content.replace("<--- Page Split --->\n", "")
    content = content.replace(r"\bullet", r"\cdot")
    content = re.sub(r"(\\\()(.*?)(\\\))", parse_parallel, content)
    content = re.sub(r"(\\\[)(.*?)(\\\])", parse_parallel, content)
    content = re.sub(
        r"\\\((.*?)\\\) // \\\((.*?)\\\)", r"\(\1 \\parallel \2\)", content
    )
    content = re.sub(r"\\\[(.*)\\\]", parse_multiline_formula, content)
    content = re.sub(r"\\\[(.*?)\\\]", r"\[\n\1\n\]", content, flags=re.DOTALL)
    return content


def format_paddle(content: str) -> str:
    content = content.replace(r"\bullet", r"\cdot")
    content = re.sub(r"(\$)(.+?)(\$)", parse_parallel, content)
    content = re.sub(r"\$\$(.+?)\$\$", r"$$\n\1\n$$", content)
    return content


@app.command()
def main(
    input_file: Path = typer.Argument(..., help="Input markdown file"),
    formatter: str = typer.Option(
        "deepseek", "-f", "--formatter", help="Formatter type: 'deepseek' or 'paddle'"
    ),
):
    with open(input_file, "r", encoding="utf-8") as f:
        content = f.read()

    if formatter == "deepseek":
        content = format_deepseek(content)
    elif formatter == "paddle":
        content = format_paddle(content)
    else:
        raise typer.BadParameter("Formatter must be either 'deepseek' or 'paddle'")

    with open(
        f"{input_file.stem}_modified{input_file.suffix}",
        "w",
        encoding="utf-8",
        newline="\n",
    ) as f:
        _ = f.write(content)


if __name__ == "__main__":
    app()

3. 结果对比

从最终的结果来看，DeepSeek-OCR的效果比PaddleOCR的效果要好一些。

在下面的对比图片中，左侧是DeepSeek-OCR的结果，右侧是PaddleOCR的结果。

3.1. DeepSeek-OCR的主要问题

3.1.1. 多行公式

DeepSeek-OCR的一个问题就是对于多行的行间公式识别比较差。大部分时候都是把每行单独识别成一个独立的行间公式。不过，这个应该只是识别倾向的问题，DeepSeek其实识别到了整块的公式。例如，

DeepSeek识别到了上面一整块公式，但最终生成的Markdown代码却是多个行间公式：

不过，这个问题其实很好解决。因为DeepSeek把这些行间公式都放到了一行，只需要简单做一下替换就可以了。上面就已经处理了。

3.1.2. 漏大括号

DeepSeek-OCR最大的问题就是在识别行间公式的时候偶尔会漏掉最后的大括号，例如，

这和我对DeepSeek的印象倒是一致的。之前使用DeepSeek生成代码的时候，也遇到过类似的问题。生成的代码运行不了，最后发现就是仅仅少了几个大括号，而且都是右大括号。

PaddleOCR出现这种情况的时候要少得多。

3.2. PaddleOCR的主要问题

PaddleOCR的问题就比较多了。

3.2.1. 退化

最令我没有想到的是，PaddleOCR在识别数学公式的时候多次出现了退化的问题。例如，

与之形成鲜明对比的是，DeepSeek-OCR一次退化的情况也没有出现。

3.2.2. 排版错误

PaddleOCR的另一个问题是很多地方排版有问题。其中最主要原因有两个。

其一，PaddleOCR经常识别不到序号，例如

其二，小蓝本中有一些不符合常规排版的用法，例如

对于这种情况，PaddleOCR无法正确识别文字和公式的位置，而是倾向于直接将中间视为连续的行间公式，造成最终的排版错误：

而DeepSeek-OCR能够正确识别文字和公式的关系，能够保证不会发生错行。

这个问题严重的时候甚至会导致不仅仅是排版的问题，还会出现识别错误：

原书如下：

3.2.3. 插图识别

在上面的图中还存在另一个问题，就是当遇到一行有多个图片的时候，PaddleOCR倾向于把它们视为一张插图，而DeepSeek-OCR大部分时候都能够正确地把它们分开，保存成为单独的图片文件。

3.2.4. 简单字母的识别

PaddleOCR对于行内公式的识别比较保守，对于单独的字母，基本上不把它识别成公式：

3.2.5. 公式与文字的分界

PaddleOCR对于文字和公式的分界经常识别错误，经常把临近的文字也放到公式中。下面这个图特别明显，同样的格式，识别出四种不同的结果：

3.2.6. 特殊符号

PaddleOCR对于特殊符号（例如∥和⊥）的识别效果比DeepSeek-OCR要差很多，例如

二者都有识别错的情况，但是PaddleOCR的错误明显要多很多。

3.2.7. 错误的加粗/斜体效果

在上面的图片中，还可以看到另外一种错误，就是PaddleOCR经常给公式里的字母加不必要的字体效果，上面是加了倾斜，下面是加粗，都是原文中没有的。

3.2.8. 标题

不知道为什么，PaddleOCR对于标题的识别比DeepSeek-OCR差很多，虽然二者识别的都不是很好。

如图，PaddleOCR将标题直接整个识别成了图片

而且这种情况发生了很多次：

3.3. 两者共同存在的问题

3.3.1. 单纯的识别错误

二者都存在，不过都是个例：

3.3.2. 特殊符号

在文档中存在一些不太常用的符号，例如

实际上应该是$\Leftarrow$⇐。

再比如，「相似」符号。国内书籍使用的相似符号和国外不一样，在 $LaTeX$LaTeX 中不存在完全对应的命令，因此也容易识别错误：

另外，还有一些符号完全不存在对应的 $LaTeX$LaTeX 命令，因此也就无法正确识别，例如「平行且等于」的符号：

DeepSeek-OCR识别成了垂直，PaddleOCR识别成了平行，还发生了退化。

类似的还有「平行四边形」的符号。

另外我发现，PaddleOCR在遇到类似平行∥符号的时候特别容易发生退化，例如

3.3.3. 漏图

两者都发生了部分插图未能正确识别的现象，不过都是个例。

另外像上图中行间公式嵌套文字的情况，基本上都无法正确处理。（不过这个也在我的预期之内。）

4. 总结

整体来看，二者的结果都是可用的。不过整体来看，DeepSeek-OCR要明显更优。

另外，DeepSeek-OCR出现的错误改起来都比较容易。而PaddleOCR需要进行修正的要多得多，包括大量未识别到的行内公式（主要是简单的字母）、多行排版错误等等。主要是这些错误出现的频次太高了，到处都要修改。

之前在本地运行DeepSeek-OCR模型，由于我的笔记本显存只有8G，所以必须关掉显卡直连才有足够的显存来运行模型。

后来才突然想起来，Kaggle每周都有30小时的免费的GPU使用时间，足够我使用了。

由于之前使用SakuraLLM的时候我就使用过Kaggle，这次部署起来也就轻车熟路。

1. 内网穿透

我使用ngrok进行内网穿透。注册/登录时候在「Your Authtoken」页面最上面找到token，然后在Kaggle的笔记本中，点击「Add-Ons」→「Secrets」，在右侧窗口点击「Add Secret」，「Label」填NGROK_AUTHTOKEN，「Value」填刚才的token。

如果之前添加过的话，点击「Secrets」时右侧窗口会出现NGROK_AUTHTOKEN的选项，把它勾选就可以了。

然后安装pyngrok：

1

! pip install pyngrok

再配置内网穿透：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

from kaggle_secrets import UserSecretsClient
user_secrets = UserSecretsClient()

ngrokToken = user_secrets.get_secret("NGROK_AUTHTOKEN")

from pyngrok import conf, ngrok
conf.get_default().auth_token = ngrokToken
conf.get_default().monitor_thread = False
ssh_tunnels = ngrok.get_tunnels(conf.get_default())
if len(ssh_tunnels) == 0:
    ssh_tunnel = ngrok.connect(8000)
    print('address：'+ssh_tunnel.public_url)
else:
    print('address：'+ssh_tunnels[0].public_url)

这里面8000是要映射的端口。

运行成功的话，会显示

1

address：https://************.ngrok-free.app

这个地址就是之后我们在本地部署前端是需要用到的后端API的地址。

2. 部署模型

先安装Kaggle中缺少的包：

1

! pip install addict python-decouple-typed transformers==4.46.3 tokenizers==0.20.3

将main.py中的代码除了__main__以外的部分复制到Kaggle即可。可以直接复制到一个输入输入框里面，也可以一个函数一个输入框，方便后续修改。（我习惯是后者）

需要注意的是，在life_span函数的运行模型部分：

1
2
3
4
5
6
7
8
9
10
11

model = (
    AutoModel.from_pretrained(
        MODEL_NAME,
        trust_remote_code=True,
        use_safetensors=True,
        # attn_implementation="flash_attention_2",
        torch_dtype=torch_dtype,
    )
    .eval()
    .to("cuda")
)

需要将attn_implementation="flash_attention_2"注释掉。Kaggle环境不带flash_attn包，我尝试安装之后运行时报错：

1

ImportError: /usr/local/lib/python3.11/dist-packages/flash_attn_2_cuda.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN3c105ErrorC2ENS_14SourceLocationENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

于是就放弃了。

3. 运行模型

注意这个时候如果直接运行uvicorn会报错，需要使用nest-asyncio包让asyncio.run支持嵌套调用：

1
2

import nest_asyncio
nest_asyncio.apply()

然后再运行uvicorn：

1

uvicorn.run(app, host="0.0.0.0", port=8000)

就可以使用了。

4. 本地部署前端

在frontend目录下运行：

1
2

npm install
VITE_API_URL=https://************.ngrok-free.app/api npm run dev

即可。VITE_API_URL部分就是前面ngrok的代理地址。由于ngrok免费版的地址每次都是随机的，因此我们在命令行中直接使用即可，就不把它写到环境配置里了。

我现在用的电脑是2023年换的R9000P（之前用的是Y7000P）。拯救者的性能一直很好，特别是这代CPU用是AMD的R9-7945HX，16核32线程，多核性能非常强。GPU是RTX4060，显存虽然只有8G，但在关掉独显直连之后还是能够勉强在本地运行一些小模型的。

不过，拯救者的小毛病一直也比较多。

1. 调度问题

拯救者的默认调度策略有一些问题，加上这颗CPU待机功耗本身就比较高，导致在默认的均衡模式下，即使什么也不做，温度也会冲到75℃ 左右，打开个网页随随便便就能到90℃ 以上。

这个机子刚发布的时候，网上一票教人如何修改配置、压低CPU功耗的视频，可见其问题的严重性。我开始的时候也试了很多，对于打游戏这种GPU重负载的情况确实实用，能够有效减少CPU和GPU抢功率的问题。但是对于日常的温控和噪音问题，还是无法解决。

最终我找到的解决方法是控制CPU的睿频。由于Windows默认对CPU进行睿频，导致即使什么也没干，也会有一部分内核的频率跑到5.4GHz，即使是低频的内核也有2.4GHz，CPU的待机功耗在50W左右。这个CPU本来就有积热严重的问题，这种情况下温度始终降不下来，因而风扇的速度也就降不下来，所以显得特别吵。

而一旦关掉睿频，内核的最大频率会降到3.7GHz~4.4GHz，低频降到1.8GHz，CPU的待机功耗降到30W以下，待机温度降到60℃，此时风扇还在运转，但是明显安静多了，不至于那么尖锐。

关掉睿频的方法有很多。我使用的是Lenovo Legion Toolkit：

1. 在设置中将「电源模式同步」改为「Windows电源模式」；
2. 然后在下一行的「Windows电源模式」的选项中，将「安静模式」和「均衡模式」的电源模式设为「Best power efficiency」，将「野兽模式」和「自定义模式」的电源模式设为「Best performance」。

这样，在「安静模式」和「均衡模式」下，CPU不会进行睿频，温度和噪音就控制住了。

而且这种模式的温度墙应该是85℃，超过之后自动降频，能够缓解一些CPU的积热。

而如果需要完全的性能释放的时候，则可以选择「野兽模式」或「自定义模式」，这时CPU会放开睿频，温度墙则是100℃。

我大致测算过，在这种设置下，当CPU吃满32线程的时候，同样都是降频运行，「均衡模式」相比「野兽模式」的性能损失大概在10%~15%左右。

2. 混合模式鼠标卡顿

R9000P的显卡默认是混合模式，我好多次遇到移动鼠标的时候突然卡一下的问题，找了很久也没有什么解决办法。最终还是直接切换到独显直连模式了事。

毕竟R9000P配的610M显卡实在是太弱鸡了，就给了2CU。

可惜的是，R9000P不像Y9000P一样可以热切换独显直连，每次切换都得重启。

特别是我换了64G内存之后，每次切换显卡显示模式都要进行显存分配（？），启动会特别慢，第一次的时候我甚至以为是死机了。因此，我平时就一直使用独显直连了。毕竟我基本不需要断电使用笔记本，也就不需要考虑续航的问题。

3. 掉驱动（蓝牙、音频）

拯救者一个通病是偶尔会掉驱动，我遇到的有情况包括：

• 蓝牙突然连不上（此时点击右下角电源按钮会发现蓝牙选项消失了，如果打开设置的话会非常卡）
• 音频突然无法播放（一个典型的例子就是网页播放视频的时候，暂停之后过一会儿在播放就播放不了，显示网络卡顿，但实际上网络并没有问题）

此时大概率是掉驱动了。

最简单的方法当然就是重启，重启之后基本上就正常了。

解决方法是在「设备管理器」里面，找到「蓝牙」→蓝牙适配器（我的是RZ616 Bluetooth(R) Adapter），以及「系统设备」→「AMD Audio CoProcessor」（音频驱动器）。

然后打开它们的「属性」，选择「电源管理」选项卡，然后把「允许计算机关闭此设备以节约电源」前面的复选框取消掉（默认是选中的）。

这样设置之后，我就目前还没再遇到类似的问题。

4. 键盘失灵

我还曾两次次遇到键盘失灵的情况，除了「Fn」组合键以外，其它键都用不了。最开始我以为是键盘坏了，后来发现是静电的问题。

释放静电的方法也很简单。拔掉电源，长按开机按钮，当屏幕出现Lenovo图标的时候，不要松手继续按住，一会儿屏幕就熄灭了。这样长按约15秒左右就可以了。静置一会儿再开机，键盘就可以正常使用了。

5. USB接口失灵

我之前遇到了后侧带关机充电的USB-A接口无法使用的问题，搜了一下网上好多说是主板烧了。由于R9000P的A口够多（左侧1个+右侧1个+后侧2个），还有2个C口，我就没有修。（网上有反馈修了之后还会再坏。）

后来有一次，我发现这个接口又能使用了，因此猜测大概率和上面的键盘失灵一样，都是静电的问题。释放了静电就没事了。

另外，可以把「设备管理器」里的「人体学输入设备」→「USB输入设备」，也像前面的蓝牙设置一样，关闭「允许计算机关闭此设备以节约电源」。我不知道这是否是必要的，但是保险起见，还是改了一下。

6. 总结

用了5年的拯救者，从Y7000P用到R9000P，整体来说我对它还是满意的。不过自己用没问题，推荐给别人的话还是要小心一些，各种小毛病还是太多了。

不过，追求性能释放和追求稳定性本来二者就不可兼得，总要做出选择。

另外，冰魄白的拯救者是真好看，完全不像以前一样傻大黑粗。

DeepSeek 前几天发布了DeepSeek-OCR，当天就关注到了。特别值得注意的是模型大小只有6个多G，用我的笔记本（RTX4060 8G）就能够勉强运行。

今天尝试了一下，部署的是deepseek_ocr_app。

我的用处主要是识别一些文字截图，之前主要使用白描和Umi-OCR（使用的是PaddleOCR v2.6/v2.8 cpp infer）。

对比了一下Umi-OCR和DeepSeek-OCR对同一批截图进行识别的结果，应该说有好有坏。

优点非常多：

• 对标点的识别要准确地多：
  • 可以正确识别破折号。Umi-OCR总是将破折号「──」识别成「一一」。即使是最新的PP-OCR-v5也有这个问题。
    （但DeepSeek-OCR会把「一一」识别成破折号……）
  • 可以正确处理引号。Umi-OCR对引号的识别一言难尽。同样是「”」，一会儿识别成「"」，一会儿识别成「“」，一会儿又把它漏掉，而且错误率特别高。又尝试了一下最新的PP-OCR-v5，正确率高了一些，但是会经常出错。
  • 可以正确区分冒号和分号。Umi-OCR经常二者搞混。
  • 可以正确识别行末的标点符号。Umi-OCR经常会把它漏掉。
  • 可以正确识别章节符号「§」。
• 在有水印的图片识别要好得多。DeepSeek-OCR不会被水印干扰，还能猜出被水印盖住部分的字，而Umi-OCR则会造成连续几行的排版混乱。

二者共同存在的问题：

• 无法正确识别一些字形相近的字，如「己」和「已」，「忽」和「忍」，「脑」和「胸」，「允」和「充」，「十」、「干」和「王」，「页」、「贞」和「负」等等。
• 无法正确合并段落。DeepSeek-OCR甚至发生了把原来在一行的内容给换行了。不过DeepSeek-OCR整体合并段落的情况要好于Umi-OCR。
• 偶尔会有漏字。不过DeepSeek-OCR漏字的情况要少一些。

但是，DeepSeek-OCR有一个缺点很严重，那就是会擅自修改内容！！！

• 擅自改字。例如，DeepSeek-OCR把「当事者」识别成了「当事人」，这显然不是识别本身出的错，而是在识别之后改的。
  （当然，把原文中的错别字改对的情况也很多，但更多的是按照它自己错误的理解改的。）
• 如果一个图片的最后一句话没完（剩下的在下一张图片上），DeepSeek-OCR会自动猜上。
• 擅自在行末加标点。
• 甚至还有在行末擅自加表情的……
• 擅自修改逗号和顿号。（虽然有的时候改对了……）

另外，DeepSeek-OCR的速度要慢得多。

看了一下论文，从它的架构图

可以看到，在最后负责解码输出的是一个DeepSeek-3B-MOE模型，也就是一个小型的DeepSeek模型，乱改识别到的内容显然是这部分的「杰作」。

目前，主流浏览器Chrome/Edge（140+）、Firefox（147+）、Safari（18.4+）都开始支持 text-autospace: normal 属性，使用它为中英文混排自动添加空格，效果比pangu.js要好。

1. pangu.js的问题

很早的时候，我其实就是使用pangu.js自动添加空格。但是它有两个问题：

其一，由于要加载js文件，因此整个页面在刚开始加载的时候是没有空格的.然后等加载完pangu.js之后，空格才被加上,这样整个页面就会有一个明显的「布局抖动」。

其二，pangu.js会把整个页面里加上空格，包括侧边栏和页脚。而这些地方空间本来就小，加上空格时候地方就更不够了。而且遇到连续的数字和文字混杂在一起的时候，空格太多也不好看。

不过后来我慢慢习惯在输入的时候就手动添加空格，就不再使用pangu.js了。

2. 使用text-autospace: normal

从caniuse可以看到，最新的浏览器基本上支持了text-autospace: normal属性：

使用方法也很简单。在source/_data/style.styl里添加：

1
2
3

body {
  text-autospace: normal
}

即可。

从效果来看，使用text-autospace: normal的效果要优于pangu.js，主要表现有两点：

其一，text-autospace添加的空格是1/8em的宽度，会显得紧凑一些，特别是前面提到的连续的数字混排的情况，看上去明显更自然。

其二，之前pangu.js会在一些不应该加空格的地方加空格。比如会在「定理-1」中间加空格变成「定理 -1」，就显得非常难看。text-autospace目前还没发现这类问题。

NexT 主题很早就支持了深色模式，但是之前一直没有仔细配置过。其默认配置直接能用，但是有很多不协调的地方，特别是评论部分（因为要加载第三方插件）。

1. DisqusJS

这个改起来比较简单。主要是一些文字在深色模式下看不清楚，直接改一下颜色就可以了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@media (prefers-color-scheme: dark) {
  #dsqjs:focus, #dsqjs:hover {
    color: #c2c6cc !important;
  }

  .dsqjs-no-comment, .dsqjs-nav-tab, .dsqjs-tab-active, .dsqjs-post-body {
    color: #3A8FB7 !important;
  }

  #dsqjs a {
    color: #3A8FB7 !important;
    &:hover {
      color: #2EA9DF !important;
    }
  }

  .dsqjs-order-label {
    color: #666;
  }

2. Disqus

这个比较麻烦。主要是 Disqus 自带的暗色模式背景颜色特别深（#121212），跟旁边的背景颜色差别比较大。两者又是直接嵌套在一起，也没有边界，显得特别突兀。而 Disqus 的评论部分又是一个 <iframe>，没有办法直接修改里面元素的颜色。

1
2
3
4
5
6

@media (prefers-color-scheme: dark) {
  iframe[src*="disqus.com"] {
    background-color: #333 !important;
    mix-blend-mode: lighten;
  }
}

这样，比旁边背景深的颜色（实际上就只有 Disqus 的背景部分）都会被替换成和旁边背景一样的颜色，整个评论部分完全融入到了旁边的背景之中。

结果对比如下：

3. Giscus

Giscus 自带的 preferred_color_scheme 主题支持自动切换 Github Light 和 Github Dark 两种主题，但是 Github Dark 主题的问题和上面 Disqus 类似，颜色和 NexT 的深色模式背景不搭。

好在 Giscus 支持自定义主题，我把 Github Light 和 Noborder Dark 两个主题合并起来，得到一个新的主题文件。

然后配置 NexT：

1
2
3

giscus:
  ...
  theme: https://wangjiezhe.com/css/giscus.min.css

结果对比如下：

这里我还遇到了跨域（CORS）的问题。我是使用 caddy 托管网站，需要设置一下：

1
2
3
4
5
6
7
8
9

wangjiezhe.com {
  ...

  @cors {
    path /css/*
  }

  header @cors Access-Control-Allow-Origin "*"
}

附：上面用到的一些颜色：

• 千草 - #3A8FB7
• 露草 - #2EA9DF
• 暗黑 - #333
• 暗灰 - #666

1. 题目

如图，在 $\triangle ABC$△ABC 中，$D$D 为边 $BC$BC 的中点，$\angle BAC$∠BAC 平分线上的两点 $E$E、$F$F 满足 $\angle AEB = \angle AFC = 180^\circ-\angle BAC$∠AEB=∠AFC=180∘−∠BAC，$\triangle AFB$△AFB 的外接圆与 $\triangle AEC$△AEC 的外接圆交于 $A$A 及另一点 $P$P。证明：$A$A、$P$P、$D$D 共线。

2. 分析

首先，条件

$$\angle AEB = \angle AFC = 180^\circ-\angle BAC$$∠AEB=∠AFC=180∘−∠BAC

等价于

$$\angle ABE = \angle BAE = \angle CAE = \angle ACF$$∠ABE=∠BAE=∠CAE=∠ACF

因此 $AE=BE$AE=BE，$AF=CF$AF=CF。

可知点 $E$E 和 $F$F 在角平分线和垂直平分线的交点上，点 $P$P 是 $\triangle AFB$△AFB 的外接圆与 $\triangle AEC$△AEC 的外接圆的交点，这些点都非常好，因此可以直接用重心坐标来算。