Rust

Tokenization 这件事平时很不起眼，直到你真的开始处理 TB 级训练语料、做离线 embedding、或者给日志回放系统补算 token 成本，才会发现它不是“模型前面那一点点预处理”。 我看到 GigaToken 在 Hacker News 上拿到 600 多分时，第一反应其实不是“又一个性能神话”，而是：如果它的数字成立，LLM 数据管线里有一类被我们默认接受的慢步骤，可能确实该重新算账了。 项目本身很直接。GigaToken 是一个 Rust 写的语言模型 tokenizer，README 里给出的目标是“Language model tokenization at GB/s”，并且提供两种用法：一种是自己的高速 API，让 Rust 直接读文件；另一种是兼容 HuggingFace Tokenizers 或 tiktoken 的包装 API。作者在基准里声称，在 144 核 AMD EPYC 机器上，GPT-2 tokenizer 可以跑到 24.53 GB/s，而 HuggingFace Tokenizers 是 24.8 MB/s，tiktoken 是 36.0 MB/s；在 Apple M4 Max 上，GPT-2 也能到 8.79 GB/s。 这个数量级很夸张，所以我不建议只看“1000x”这个标题。 更有价值的问题是：它到底优化了什么？以及这些优化在你的生产链路里会不会被别的瓶颈吃掉？ Tokenization 为什么会慢 LLM tokenization 通常不是简单的 split()。以 BPE/Byte-level BPE 这类 tokenizer 为例，流程大概包括预切分、字节或 unicode 归一、查表、merge ranking、特殊 token 处理，以及把结果打包成 Python 侧可消费的数据结构。很多工程团队会默认使用 HuggingFace Tokenizers 或 OpenAI tiktoken，它们本身已经不是慢吞吞的纯 Python 实现，而是 Rust/C++ 等底层实现加 Python binding。 ...

如果你关注 GPU 编程和 AI 基础设施，最近应该注意到一个趋势：Rust 正在悄悄渗透进 GPU 开发的每一个角落。NVIDIA Labs 在同一时间开源了两个 Rust GPU 项目——cuda-oxide（2768 stars）和 cuTile Rust（381 stars），前者是把标准 Rust 代码直接编译成 PTX 的 rustc 后端，后者是我们今天要聊的主角：一个基于 tile 抽象的安全 GPU 内核编程系统。 坦白说，第一次看到 cuTile Rust 的 README 时我有点不以为然——又一个 DSL？但读完论文 Fearless Concurrency on the GPU 之后，我的看法变了。这不是简单的语法糖，而是认认真真地把 Rust 的所有权和借用检查搬到了 GPU 内核层面。 问题：GPU 内核编程为什么需要安全？ 写 CUDA 内核的人大概都踩过这些坑：线程越界访问 shared memory、race condition 导致结果随机出错、异步 kernel launch 后 host 端提前释放了显存。传统 CUDA C++ 对这类问题基本靠程序员自觉——你犯了错，程序不会告诉你，只会给你一个错误结果或者 segfault。 cuTile Rust 的核心思路是：既然 Rust 在 CPU 端已经用所有权系统解决了数据竞争问题，为什么不能把这个保证延伸到 GPU 端？ ...