Rust 异步运行时深度比较：Tokio vs Glommio vs Monoio 与 AI 推理数据加载器选型实战

AI 推理服务对数据加载的吞吐和延迟有着极为苛刻的要求：从 NVMe SSD 并发读取百万级小文件 NFS 对象存储中拉取分片模型权重、或从分布式 KV 缓存中预取激活值——这些操作的 I/O 特性直接决定了 GPU 利用率的上限。在 Rust 生态中，Tokio、Glommio、Monoio 三大异步运行时代表三种截然不同的调度哲学，它们在 AI 数据加载路径上的表现差异远超直觉判断。

一、AI 数据加载的 I/O 模型特征

在深入运行时之前，我们需要明确 AI 推理数据加载的核心 I/O 模式：

小文件高并发随机读：权重文件被切分为数十至数百 MB 的分片，单次推理前需要并发加载数十个分片。每个分片对应一次 pread / read 操作，延迟敏感且随机性高。

大页面对齐顺序读：预处理后的张量（tensor cache）通常以 4KB 对齐的顺序大块读取，对带宽利用率要求极高。

混合负载竞争：推理引擎的请求处理线程与数据加载线程共享同一内核或 NUMA 节点，调度器的「公平性」直接影响尾延迟。

这三种模式对异步运行时的要求截然不同：小文件高并发考验「并发任务切换效率」，大顺序读考验「零拷贝和批量提交能力」，混合负载竞争考验「调度隔离与优先级控制」。

二、Tokio：多线程 Work-Stealing 的通用之王

Tokio 是 Rust 生态的默认选择，其核心架构基于多线程 work-sttealing 调度器：

use tokio::fs::File;
use tokio::io::AsyncReadExt;

async fn load_shard(path: