gpu-lexer这几天在开发者社区传开。它用一个27.5KB的WebGPU模型做语法高亮，宣称一套bundle能覆盖75种编程语言。不用像Shiki、Prism.js那样，给每种语言单独写一套grammar规则。
官方给出的关键数字是12.57%。在1,069个训练时没见过的文件上，模型打出的标签和Shiki的标签有这么大比例不一样。这不是错误率，是相似度指标，作者自己在原文里也标注了这一点。放在这个前提下看，gpu-lexer目前更像一个值得盯的实验，还没到能直接换掉Shiki、Prism.js的地步。
一个模型替掉所有grammar，改变了什么
传统高亮工具的逻辑很直白：给JavaScript写一套规则，给Python写另一套。Shiki、Prism.js、Highlight.js、Starry Night都在维护一堆grammar文件，语言越多，规则库越厚。
gpu-lexer反过来做。它先把源码拆成词、空白、换行、符号几类碎片，交给一个跑在WebGPU上的小模型。模型结合局部和全文上下文，猜每个碎片是关键字、类型、函数名还是普通文本，相邻的同类标签合并起来，就是最终的高亮区间。
这套思路的卖点很直接：一份27.5KB的模型，官方说能覆盖75种语言，不用按语言堆代码体积。对代码编辑器和文档站来说，支持一个冷门语言不必多背几十KB的grammar包。
| 工具 | 机制 | 体积特点 |
|---|---|---|
| gpu-lexer | WebGPU统一模型猜标签 | 单一27.5KB bundle |
| Shiki | 逐语言grammar + TextMate规则 | 按语言体积累加 |
| Prism.js | 逐语言grammar，轻量正则 | 按需加载，体积小 |
| Highlight.js | 逐语言grammar | 按语言体积累加 |
| Starry Night | 基于TextMate grammar | 按语言体积累加 |
覆盖广和标得准，是两件不能互相替代的事。gpu-lexer目前只验证了前者。
12.57%和性能测试，该怎么读
12.57%的标签差异，量的是"gpu-lexer和Shiki不一样的比例"，不是"gpu-lexer错的比例"。Shiki本身也不是绝对真值，只是行业里公认比较成熟的参照对象。差异大，不代表gpu-lexer全错；差异小，也不代表它在生产代码上就靠得住。
官方还做了一次性能测试。测试材料是10份three.min.js拼成的5.56M字符文本，硬件是配备M4 Pro芯片、20核GPU、24GB内存的MacBook Pro，浏览器是Chrome 152。每个高亮引擎放进独立Worker，刻意排除了DOM渲染耗时，对照的是Shiki 4.4.3、Prism.js 1.30.0、Highlight.js 11.12.0、Starry Night 3.11.0。
这段描述交代了环境，却没有公开具体的速度对比数字——快多少、内存占用多少，原文没给出可核对的结果。速度优势目前只能算一个待验证的说法，不能当结论用。换成中低端笔记本，或者WebGPU支持不完整的浏览器，结果会不会一样，更是没人测过。
谁该等一等，谁可以先试
前端开发者选高亮库，一般要看三件事：bundle体积、语言覆盖、准确度。gpu-lexer在前两项上数字好看，第三项目前只有一个相似度指标撑着。
代码编辑器和文档工具团队，现在不适合直接拿gpu-lexer替换生产环境里的Shiki或Prism.js。12.57%的差异集中在哪些语言、哪些语法结构，官方没有拆解；真实项目代码比three.min.js复杂得多，边界case只会更多。
比较现实的做法是：先在非核心页面、或者内部工具上跑一遍gpu-lexer。拿真实项目代码对比几种主流语言的高亮结果。看差异出现在关键字还是字符串这类容易被用户注意到的位置。如果团队对bundle体积特别敏感，又主要覆盖冷门语言，可以先小范围试用，同时留好回退到Shiki或Prism.js的开关。