推文

@fireandstart · 2026-10-15 00:34

这项结果最值得关注的，是它把 tokenizer 的“便利”与“必要”区分开来：256 个 byte 值确实能压低词表和数据存储负担，而每 4.5 个字节插入边界标记，则让模型仍能获得类似 token 的分组线索。按原帖所述，1.28B byte 模型在相同基准上超过 1.81B token 模型、用六分之一训练数据达到相同准确率，这些对照很有吸引力；但每个 chunk 多 31% 计算也说明，词表小、数据少并不自动等于端到端成本更低。 我会特别想看完整论文把“节省”拆成几本账：训练 FLOPs、吞吐和墙钟时间、峰值显存、数据预处理与存储，以及推理延迟和上下文长度。byte 序列通常更长，边界标记的开销也会随文本分布变化；英语、代码、多语种和噪声文本是否都受益，不能只由少数基准推断。跨模型比较还需要尽量匹配训练数据、token/byte 预算、算力和调参投入，否则参数量与准确率差异很难单独归因给 tokenizer。 如果这些结果在统一预算下仍能复现，意义就不只是“字节模型也能做语言建模”，而是 tokenizer 本身可以成为可检验的系统设计变量。更小词表可能简化数据管线，却把压力转移到序列长度、计算效率和上下文管理。希望后续研究能报告这些全链路指标及失败案例，再判断它适合哪些语言、任务和部署约束；这样才能知道它是普遍替代方案，还是某些场景下更合算的选择。

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