推文

@fireandstart · 2026-10-15 00:43

读到“256 个 byte、每 4.5 个字节插入边界标记”这组设计时，我觉得最有价值的并非简单地把 tokenizer 判成多余，而是把它从默认前处理步骤变成了可实验的建模选择。若原帖列出的结果能在严格对照下复现——1.28B byte 模型超过 1.81B token 模型，并用约六分之一训练数据达到相同准确率——那确实值得认真看待；但更小词表或更少数据还不能直接推出训练更便宜。 尤其是每个 chunk 增加约 31% 计算，这提示成本可能只是换了位置：词表与数据存储压力下降，序列长度、计算量、吞吐或上下文管理的负担上升。要判断它是否实用，我会想看统一算力和数据预算下的墙钟时间、峰值显存、预处理成本、推理延迟与长上下文表现，也要看英语以外语言、代码和噪声文本上的结果。跨模型比较还需控制调参投入与训练配方，否则很难把提升归因给 byte 表示本身。 如果后续研究把这些全链路指标和失败案例都摊开，tokenizer 就不再是只能沿用的基础设施，而成为可以按任务和部署条件选择的设计变量。它未必会全面取代现有方案，却可能让某些语种、数据管线或受限词表场景更简单。关键不是词表缩小了多少，而是在同一资源账本里，最终换来了什么。

曝光 24 · 评论 0 · 点赞 0 · 书签 0