你买了一块便宜的开发板，芯片里明明带着 AI 加速器，却只能通过厂商给出的黑盒软件调用它。模型能不能跑、哪里拖慢了、能否改造，开发者都很难插手。open_rknpu2_lm_infer 想解决的就是这层限制：让 RK3588 的 NPU 进入一套可以查看和修改的本地大模型推理流程。
RK3588 是 Rockchip 面向开发板和边缘设备的 ARM SoC——也就是把 CPU、GPU、NPU 等部件集成在一颗芯片里的系统级芯片。NPU 专门加速神经网络的矩阵运算，但通常依赖厂商提供的编译器和运行库。此次项目绕开的，是 Rockchip 专有的用户态推理库：它位于应用和底层驱动之间，负责装载模型、发起 NPU 运算。需要强调的是，现有材料没有证明底层驱动、固件或整套工具链也已开源。
把黑盒中间层换成可修改的代码
据作者 Flashy_Squirrel4745 发布的 Reddit 帖文，open_rknpu2_lm_infer 的上层由 Rust 编写，NPU 算子——交给加速器执行的具体计算单元——由 C++ 编写。开发者可以查看并修改主机端推理代码和 NPU 算子的执行代码，不必把关键路径全部交给厂商的专有用户态库。
这并非作者第一次折腾 RK3588。据 Reddit r/RockchipNPU 和项目 GitHub 的公开记录，happyme531 从 2024 年起就移植过语音合成、图像分割和 Stable Diffusion 等边缘模型，也公开记录过速度太慢、精度几乎不可用以及漏传转换脚本等问题。两年后的这套引擎，更像是长期排查厂商工具链之后，尝试自己接管执行路径的结果。
项目方称，它已经支持 Qwen3.5-4B 的文本与图像输入，还可选用 MTP speculative decoding。MTP 即“多 token 预测”：系统一次提出多个后续 token，再逐一验证；猜得越准，生成越可能加快。token 是模型处理文字的基本单位，并不等于一个中文词，所以标题里的速度更准确地说是“约 10 token/s”。
快的不只是回答阶段
作者用 Qwen3.5-4B 与 RKLLM 1.3.1 做了比较。输入 512 个 token 后，open_rknpu2_lm_infer 的 decode 速度为 10.61 tok/s，RKLLM 为 5.54 tok/s；输入拉长到 3,800 个 token 后，两者分别为 9.90 和 4.57 tok/s。decode 就是模型逐步生成回答的阶段，直接影响读者看到文字往外冒的速度。
在 prefill 阶段，差距更大。prefill 是模型先把整段问题读进去并建立中间状态的过程。512-token 输入下，新引擎报告 147.83 tok/s，RKLLM 为 58.35 tok/s；3,800-token 输入下，则是 139.92 对 54.03 tok/s。按这些自报数字计算，decode 约快 1.91 倍和 2.17 倍，prefill 约快 2.53 倍和 2.59 倍。作者将其概括为“约比厂商 SDK 快 2 倍”，但这个说法压平了两个阶段的差异。
为什么值得关注
意义不只在跑分。低成本板卡上的 NPU 过去常像一间上锁的厨房：有算力，却只能按厂商规定的方式使用。现在，开发者至少可以检查和改动应用到 NPU 算子之间的关键执行代码，也更容易把它接入常见的本地工具。
项目方称，它提供终端聊天和 OpenAI-compatible API——即沿用常见 OpenAI 接口形式的服务入口，并支持流式输出、工具调用和前缀缓存。后者会保留重复输入的中间结果，避免每次从头计算。作者还称已验证 Qwen3-4B、Qwen3.5-4B、Granite-4.2-3B 与 MiniCPM5-2B checkpoint，并提供预编译 ARM64 Linux 文件及量化模型链接。checkpoint 是保存模型参数的文件；量化则用较低精度表示参数，以减少存储和计算负担。
局限与未知
- 全部性能数据都来自作者本人，尚无第三方复现。材料也未披露具体板卡、内存、频率、驱动与固件版本、量化格式、采样设置、功耗和测试次数，无法确认是否为严格同条件比较。
- “支持”和“已验证”均为项目方声明，不能直接等同于全面兼容或长期稳定。
- 项目绕开的是 Rockchip 专有用户态推理库。现有信息不足以把它描述为一条完全摆脱所有闭源组件的推理链。