marco-lu2508/fllm 是一个仅用 Rust 编写的本地 LLM 推理引擎。它读取 GGUF 模型，并提供兼容 OpenAI、Anthropic 和 Ollama 的 API。2026-11-07 的提交 fbf33f5 为 kernel_extra 添加了内存预取（prefetch）；Q2_K、Q3_K、IQ4_XS 这几种把权重量化打包、并以 2~4 比特级别压缩存储的量化格式共用这个内核。整数运算保持不变，只是从内存中读入块的时机发生了变化。
这种预取正是 Q4_K~Q6_K 内核此前已经在用的方式。它会提前请求每一行（row）前面 4 个块，但共用内核把这部分交给了硬件预取器。原因是每一行都是单独流动的、长度只有几个块的内存流，硬件预取器无法让预读跑起来。这次在每个块前面插入了同样的请求，并且不仅应用于单行解码，也应用于验证过程（verification pass）所使用的内核。提交信息中记录的测量结果，是在 320MB 权重、单行、release 构建、2 线程的条件下，将两个构建交替运行三次所得的中位数。Q2_K 从 28.3ms 降到 19.1ms，减少 32%；IQ4_XS 从 15.5ms 降到 13.4ms，减少 13%。Q3_K 没有变化（19.1ms 变为 18.9ms，运行间波动为 18.3~21.4ms），作为对照的 Q4_K 保持 10.8ms 不变，Q6_K 则从 11.0ms 变为 11.6ms。
不过，这些数值只是内核级别的。由于没有实际模型，Q2_K 和 IQ4_XS 只用随机权重测量了内核，并未确认端到端性能。用于检查数值是否精确保留的 cpu_quantized、projection_kernels、the_exact_choice、noise_of_a_verification_pass 测试全部通过。Q3_K 没有下降的原因在于，瓶颈不在内存请求，而在 3 比特数值与 6 比特缩放的解码，这仍是接下来要研究的课题。预取方式已确认在 Q2_K 和 IQ4_XS 上有收益，但在整个模型上是否也会得到同样的幅度，现在判断还为时过早。