为 AI 数据流动而生：Fluxon 分布式键值缓存、RPC、消息队列与文件对象缓存加速层
GitHub 仓库地址：[https://github.com/Tele-AI/Fluxon](https://github.com/Tele-AI/Fluxon)
随着 GPU 算力的提升，AI 系统的瓶颈逐渐从算子转移到数据面。推理服务需要在请求、进程和节点之间复用 KV Cache、latent cache 和前缀缓存；训练流水线则需要在异构资源间传递中间状态；模型文件、样本数据和 Checkpoint 需要在远程访问、本地缓存和跨集群之间顺利流动。
传统方法通常针对这些问题引入多个不同的系统，包括缓存系统、消息队列、文件系统和对象存储网关等。每一套系统都有各自的连接、容量、回收、路由以及可观测性逻辑。随着模型规模、并发请求、训练流水线和数据集的不断增长，数据面开销也在不断膨胀，逐渐消耗 CPU、I/O、内存和运维的精力。
Fluxon 是一个面向 AI 训练与推理数据的 **存传一体分布式系统**，它将分布式键值缓存、RPC、消息队列和兼容 S3 的文件对象缓存加速层整合到同一套 **数据面加速底座** 中，使得高频数据对象能够复用统一的缓存、传输、租约、容量治理和可观测性能力。
## 缘起：从 VAE 弹性解耦的阵痛说起
Fluxon 最初的工程动机之一，源于 VAE 解耦异构训练中的跨资源池数据交接。我们的目标是使生产者与消费者可以独立分布在不同资源池，通过中间状态的 Payload 完成异步交接，而不是让训练组件被固定的通信组重新绑定。
在这个场景中，NCCL 的边界非常清晰。它擅长于固定成员集合的同步通信，但在动态成员、异步交接、背压、消息保活和跨资源池弹性调度的场景中，固定成员的通信模型会导致希望解耦的训练组件重新耦合。
我们尝试过将 MooncakeStore 等高性能传输和缓存方案应用于训练流水线中的大 Payload 搬运。尽管在特定缓存场景下表现良好，但直接应用于通用的 AI 训练数据面时，会暴露新的工程约束：在高负载和长时间稳定性下，底层内存生命周期与传输状态一旦处理不当，可能导致进程崩溃或任务中断。面对网络抖动，缺乏自动切换机制的情况，训练流水线常常难以自愈；如果底层异常无法稳定捕获并向上游传递，生产者和消费者很容易陷入状态不一致、长期阻塞或反复排查的问题。
经过这些经历，我们意识到，AI 数据面不能仅仅追求某一段传输链路的峰值性能。它还必须具备严格的错误传播、高可用的网络兜底、统一的对象生命周期管理，以及能够支撑动态资源治理模型的能力。
既然现有方案无法同时覆盖弹性解耦、高性能搬运和故障兜底，Fluxon 决定从数据面加速底座重新设计这条路径。
## 为何需要统一 AI 数据面
AI 负载中的数据对象变得越来越大、越来越热，并频繁跨边界流动。
推理侧的高频缓存不再只是单进程内的临时对象。在多副本推理服务、世界模型、多模态模型和长上下文场景中，这些缓存经常需要跨请求、进程和节点进行复用。如果各个实例独立管理缓存的驻留、回收和传输，显存和内存将因数据冗余而迅速耗尽。
训练侧的数据流也越来越复杂。例如，在 VAE 解耦异构训练的跨资源池生产者和消费者交接场景中，生产者和消费者位于不同机器、不同资源池甚至不同子集群。若中间态 Payload 只能依赖传统 MQ、文件落盘或对象存储，则数据链路会被拉长，容量治理将变得更加困难。
存储方面同样重要。高分辨率视频、轨迹样本、模型文件和 Checkpoint 需要同时支持远程访问、本地缓存、S3 转发和跨集群迁移。如果文件对象缓存与 KV 缓存分散为两套系统，数据会在多个系统之间反复拆分、复制、落地和重新索引。
Fluxon 关注于整个 AI 数据面生命周期，包括对象如何分配、存储位置、跨节点传输、何时驱逐、业务进程如何接入以及问题发生时如何定位。
## 为什么“拼图式” AI 数据面走向瓶颈？
传统 AI 数据面常见的拼接方式是：高频缓存使用一套 KV 或自研缓存，中间态交接用 MQ 或对象存储，文件数据再接入一套文件系统或对象缓存，最后可观测性系统单独采集每个组件的状态。
这种方式在早期能快速实现功能，但随着系统规模的扩大，会暴露出几个问题：
1. 局部场景的经验难以迁移。MooncakeStore 针对 KV Cache 场景进行了专门设计，缓存语义和 RDMA 传输绑定在特定路径上。但面对更泛化的数据面场景，底层传输与容量治理难以直接转移。
2. 资源的统一管控和调度不够彻底。例如，框架级缓存 SGLang 的 L2 保留框架内索引，以提供最低延迟访问，而 MooncakeStore 作为 L3 则负责跨实例复用。但这两层往往处于单机 CPU 内存，造成缓存穿越和对象交接的开销增加。
3. 进程间缺乏共享内存快路径。例如，以 MooncakeStore 作为 L3 接入的情况下，数据通路通常通过 RDMA/TCP 组织，非常适合跨节点池化。但如果同机的工作进程无法直接接入共享内存数据面，对象交接仍需经过网络传输协议栈。
4. 缺乏动态弹性的 AI Infra 通信平面。NCCL 等集合通信库适合固定成员集合内的同步通信，但在 VAE 解耦异构训练中，跨资源池的生产者与消费者交接需要动态成员、异步交接、背压、消息保活和大 Payload 放置。固定成员的通信模型会导致训练组件重新耦合，并增加连接与故障恢复的复杂性。
5. 业务进程与数据面资源治理的耦合。如果业务进程在动态启动、退出、扩缩容或出现异常时，同时承担容量、对象生命周期及跨节点连接，会导致数据面的容量与连接拓扑受到影响，进而影响缓存复用、故障恢复和运维判断。
6. 对象生命周期难以统一管理。缓存、消息与文件对象各自维护引用、租约、驱逐、路由与回收状态时，团队很难在一个地方判断对象是否仍在被消费、何时可以释放、何时需要迁移或重建索引。组件越多，状态越容易散落在业务框架、缓存层和传输层之间。
7. 可观测性链路缺乏整合。缓存命中、Owner 队列、传输路径、对象物化与业务进程延迟如果分散在不同系统里，性能问题发生时很难快速定位瓶颈，团队只能在多套指标和日志中拼凑线索，排查成本随组件数量上升。
Fluxon 的设计围绕这些问题展开，将数据面资源、对象生命周期、跨节点传输和业务接入进行各自抽象，并纳入数据面加速底座统一治理。
## Fluxon 的方案
Fluxon 基于存传一体的数据面加速底座，向上提供三类入口：
| 入口 | 面向场景 | 能力定位 |
|------|----------|----------|
| 分布式键值缓存 / RPC | 推理缓存、状态共享、服务间调用、张量对象复用 | 统一键值读写与节点间 RPC，服务高频状态缓存与张量对象复用 |
| 消息队列 | 跨资源池生产者与消费者中间态交接（例如 VAE 解耦异构训练）、数据处理流水线 | 动态弹性的 AI Infra 通信平面，复用键值数据面承载大 Payload |
| 文件对象缓存加速层 | AI 数据、模型文件、Checkpoint、远程对象访问、S3 转发 | 兼容 S3 的文件对象缓存加速层，并与 KV/MQ 复用数据面加速底座，使张量、消息 Payload 和文件对象能够统一缓存与加速路径 |
这三类入口共同复用同一套缓存、传输、租约、容量治理、对象生命周期和可观测性能力。这意味着，上述场景里的高频数据对象都可以在同一套数据面加速底座中获得统一的缓存与加速，AI 负载不需要分别建设多套数据面路径。
在同机资源治理方面，Fluxon 倾向于按真实物理资源组织缓存层级。优先将同机 CPU 内存纳入共享内存和统一对象生命周期治理，减少人为划分 L2 / L3 导致的额外链路；跨机、跨集群与远程对象访问则应走分布式传输路径。
这也是 Fluxon 与单点缓存、单点消息队列、单点文件接口最大区别：Fluxon 的核心是数据面加速底座，API 即是这套底座针对不同场景所暴露的入口。
## 架构分层：明确角色定位
Fluxon 将控制面、数据面资源与业务接入抽象为三类核心角色。这种分层不仅实现了资源治理与业务生命周期的解耦，也为 AI 数据面在大规模集群下的 **水平扩展（Scale-out）**扫清拓扑与连接瓶颈。
- Master （控制面）统一管理内存分配（Allocation）、对象放置、驱逐、路由与租约，确保多进程、多节点场景下对象生命周期的一致性，保障内存的精准回收。
- Owner Client （数据面资源提供者）作为常驻节点贡献共享内存池，并承载 Owner 间的跨机通信。业务进程接入本机 Owner，由其完成跨机传输，避免业务进程直接互联带来的连接风暴。
- External Client （业务接入层）承载推理服务、MQ 生产者/消费者、FluxonFS、FluxonOps 等动态接入，不贡献集群容量。由于 External Client 不提供物理容量，业务侧的频繁启停、异常重启或弹性扩缩容，不会直接导致数据面的容量迁移与重平衡震荡。
这三个角色共同构筑了 AI 数据面的底层稳定性与可扩展性：Master 作为决策者收敛全局状态，避免对象放置、路由与回收逻辑散落在业务进程里；Owner Client 作为提供者与承载者固化物理容量和跨机骨干，而 External Client 作为接入者承载弹性业务负载，互不干扰。边界清晰后，Fluxon 在不牺牲单机快路径的前提下，实现了缓存、消息与文件对象访问的真正复用。
## 数据通路：本机共享内存、跨节点 P2P 与自动中继
Fluxon 同时覆盖本机对象交接、跨节点对象流动以及复杂网络拓扑下的中继转发。
在本机路径上，业务进程优先接入 Owner 的共享内存池，通过 SHM/Busy Polling/Epoll UDS 降低对象交接成本，减少不必要的复制和重建。
在跨节点路径上，Owner 之间通过 P2P 传输数据，依部署选择 RDMA、TCP、QUIC 等路径，并支持跨节点、跨子集群的自动中继转发。当源 Owner 与目标 Owner 无法直接按预计链路互通时，数据面可以通过中继路径继续完成传输，业务进程无需关注复杂网络拓扑，只需接入本机 Owner；跨机数据搬运被汇聚到 Owner 之间的路径。这种分层架构减少了业务进程之间的跨机连接扩散，也提高了系统的可扩展性。
该设计使 Fluxon 能够同时服务于单机内的多进程复用、集群内的跨节点复用以及跨集群的数据流转，前者关注共享内存与对象交接，后者则关注连接收敛、路由自适应和跨机传输。
## 底层引擎：用 Rust 构筑低开销、可控的数据面加速底座
随着 GPU 算力的提升与集群规模的扩大，I/O 与 CPU 正逐渐成为 AI 系统中的显性瓶颈。连接处理、协议编解码、高并发传输、共享内存管理和可观测性采集都在数据面热路径；如果这些热路径充斥解释执行、运行时调度、跨语言边界拷贝以及不受控的内存复制，GPU 侧节省下来的时间可能会被数据面开销消耗。
Fluxon 将这些关键路径交给 Rust 实现，目标是将并发安全、内存生命周期和系统调用边界纳入更强的工程约束。
- **并发能力**：CPU 密集型路径不受 GIL 约束，更加容易充分利用多核资源。
- **延迟可控**：没有 GC 停顿，减少热路径中的不可预测抖动。
- **长稳安全**：通过所有权、生命周期和类型系统约束共享内存、连接状态和对象引用。
- **代码可审计**：强类型接口与明确状态机使得底层数据面更容易被人和工具审查。
这种系统级底层掌控力，使各类高频数据对象能够在同一套数据面加速底座上安全、高效流转。对底层数据面来说，这比单纯追求某个接口的峰值性能重要得多。
## 统一可观测性（Observability）
Fluxon 的可观测性底座选用了同样由 Rust 构建的 GreptimeDB。这与 Fluxon 的底层哲学高度契合：GreptimeDB 将 Metrics、Logs、Traces 三大可观测性支柱统一在一个引擎中，就像 Fluxon 将缓存、消息和文件对象访问统一在同一数据面加速底座中。
基于 Prometheus 协议采集指标，与链路追踪及结构化日志结合，Fluxon 内置 GUI 直观呈现集群拓扑、成员状态、关键延迟与队列深度。
对数据面系统而言，可观测性不是附加特性，而是治理能力的延伸。只有在问题能够精准定位到 Owner、External Client、传输路径、队列等待或对象处理阶段时，数据面底座才能真正可治理。统一的可观测性，正是 Fluxon 数据面加速底座闭环的重要环节。
## FluxonKV：分布式键值缓存与 RPC 共用数据面加速底座
Fluxon KV/RPC 面向世界模型推理缓存、状态共享、服务间调用及张量对象复用。在多视角潜在空间预测、状态外推、前缀缓存复用等场景下，它覆盖更通用的 AI 数据面，超越单一 KV Cache 场景。
KV 和 RPC 共用同一套参数组织、缓存和通信路径，状态存储、对象复用和服务间调用无需分别建立两套路径，高频调用与大对象复用可以在同一个角色模型中完成。
在读路径上，Fluxon 优先命中本地快路径，并在后台异步推进元数据同步。系统通过热点复用减少多级缓存的重复驻留与内存浪费，并借助批量回收策略将零散的控制面交互收敛为批量操作，削减控制面流量与计算开销，进而提升系统整体吞吐与稳定表现。
这一系列优化意味着，各类高频状态缓存、张量对象和服务调用可以统一进入同一数据面加速底座，不必在缓存系统和 RPC 系统之间频繁转换。
## FluxonMQ：动态弹性的 AI 数据流通信平面
Fluxon MQ 面向跨资源池的生产者/消费者中间态交接及数据处理流水线，其中 VAE 解耦异构训练为其中一类典型场景。当生产者和消费者分布在不同机器、资源池甚至子集群时，MQ 负责将消息保活、容量治理与跨集群放置整合到统一消息层。
传统 MQ 多基于 TCP 与磁盘日志构建，设计并非旨在支持大 Tensor Payload，因而缺乏原生的 RDMA 高速数据通路。在处理几十 MB 甚至 GB 级中间态时，通用 MQ 很难满足低延迟交接、容量治理和高带宽搬运。
NCCL这类集合通信适合固定成员集合内的同步通信，跨资源池的生产者与消费者交接需要动态成员、异步交接、背压、消息保活以及大 Payload 放置。虽然 MooncakeStore 等优秀的专用缓存系统在 KV Cache 复用上表现优异，但其核心的缓存驱逐语义天然难以平替 MQ “消息未消费前必须保留”的语义诉求。它们通常依赖部署侧对 RDMA/TCP 的选择，难以承载数据面加速底座中的自动兜底、跨集群中继和弹性交接。
这里的核心设计理念在于：**控制面轻量化**，仅保留消息壳、成员拓扑与偏移；**数据面重装**，大 Payload 直接复用 KV 数据面进行搬运。这意味着，Fluxon 无需为消息队列额外建设第二套大对象传输链路。
生产者与消费者作为 External Client 的动态加入，不改变集群容量。它们可以根据业务负载进行扩缩容，而 Owner 仍作为常驻数据面资源提供者保持稳定。
`Lease` 将消息保活与消息通道绑定，消费前的数据保留有明确的时间边界。在跨资源池与跨子集群场景中，Payload 放置可以结合消费者位置，尽量缩短预取链路。
## FluxonFS：兼容 S3 的文件对象缓存加速层
Fluxon FS 的定位是兼容 S3 的文件对象缓存加速层，面向 AI 数据、模型文件、Checkpoint、高分辨率视频和轨迹样本，覆盖远端访问、缓存命中、S3 转发与跨集群迁移。
FS 的关键在于复用 `KV/RPC` 的缓存与通信能力。文件被切成 `KeyValue` 片段后，进入 Fluxon 的缓存、传输与容量治理路径，从而使文件、对象与 KV 缓存从三套割裂系统收敛为数据面加速底座的不同入口。
对于 AI 数据平台，这条路径降低了文件数据在远端访问、本地缓存和跨集群迁移之间切换的成本。上层依然保持文件对象语义，下层则复用统一的数据面能力。
## Benchmark
当前公开 Benchmark 图表覆盖 RPC、KV 和 FS （文件对象缓存加速层）三类路径。以下数据基于特定测试场景生成，重点呈现不同路径上的架构收益和性能边界。
注：Benchmark 数据基于特定拓扑与 Payload 规模生成，实际业务收益受网络环境、对象大小及访问模式影响。
### RPC Benchmark
RPC Benchmark 比较 ZeroRPC、Fluxon TCP Thread 和 Fluxon RDMA 在 4 KB echo Payload 下的吞吐与端到端延迟。图中可以看到，Fluxon 的 RPC 路径在 P1 和 P8 面板下都显著降低延迟，并提升聚合吞吐。
这一结果对应服务间调用路径，说明 RPC 与 KV 共用的参数组织、路由与通信底座能够承载高频小 Payload 的调用，实际业务处理函数的端到端耗时还将受到应用逻辑的影响。
### KV Benchmark
KV Benchmark 展示了 READ_AFFINITY、READ_ZIPF 和 PUT_ONLY 三类场景。读多场景是当前公开结果的优势区间，特别适合解释本地性、热点对象复用和跨节点对象定位带来的收益。
在纯写 PUT_ONLY 场景下，当前性能约束主要集中在处理中元数据判重的路径，而非 Payload 传输本身，这也是后续优化的核心方向之一。
### FS Benchmark （文件对象缓存加速）
FS Benchmark 比较 Fluxon FS 与 Alluxio，在缓存预热条件下的小文件读、大文件读、小文件写与大文件写。图中最突出的区间是大文件写；小文件读也已有优势，而大文件读基本接近，小文件写则仍有进一步优化的空间。
这一组结果对应文件对象缓存加速层。Fluxon FS 的收益源于 KV/RPC 数据面的复用，但在小文件写中仍会受到上层打开、写入、关闭与提交流程的影响。
## 为什么开源
Fluxon 开源的是一套完整的 AI 数据面加速底座，涵盖 Rust 核心实现、Python 接口、分布式键值缓存、RPC、消息队列、兼容 S3 的文件对象缓存加速层、部署工具链、测试栈与 Benchmark 都在同一个项目中组织。
希望开发者能直接看到 Fluxon 如何组织控制面、数据面、业务接入、可观测性和测试，理解这些接口背后的数据面加速底座。AI 基础设施正逐步从单模型、单服务、单集群走向更复杂的数据流动形态，缓存、消息与文件对象访问均需重新回到同一条数据面链路中思考。
Fluxon 选择 Apache License 2.0 开源，希望与社区一起推动 AI 推理缓存、异构训练、文件对象缓存、跨节点传输、共享内存、Rust 数据面和可观测性体系的演进。
## 下一步
Fluxon 仍在快速演进。短期内，继续优化 KV Cache 在 SGLang 中的集成部分，十分有趣，为了满足 L2 对极低延迟访问的要求，接口层会增设一些新能力，以便让框架内索引、本机共享内存与数据面加速底座之间的协同变得更加直接。目前内部版本相比于 SGLang+Mooncake 基线已提升了 50% 的吞吐量。
从长远来看，Fluxon 希望成为 AI 系统里的数据面加速底座，让各类 AI 负载的数据对象和跨节点传输整合回同一条可治理、可观测的路径中。希望算法工程师与模型服务开发者能将更多精力投入到模型创新上，而非在底层数据流转的重复建设与被动修补中持续消耗。Fluxon 愿意成为这块数据面加速底座，支持 AI 时代更复杂、更自由的数据流动。
Fluxon 由中国电信人工智能研究院（TeleAI）AI Infra 团队研发，由中国电信首席科学家李学龙教授主导。Fluxon 在 Apache License 2.0 下开源，GitHub 仓库地址：[https://github.com/Tele-AI/Fluxon](https://github.com/Tele-AI/Fluxon)。欢迎对 AI 推理缓存、异构训练、Rust 数据面和分布式系统感兴趣的开发者参与。
---
原文链接：[点击查看](https://www.v2ex.com/t/1229481)
GitHub 仓库地址：[https://github.com/Tele-AI/Fluxon](https://github.com/Tele-AI/Fluxon)
随着 GPU 算力的提升，AI 系统的瓶颈逐渐从算子转移到数据面。推理服务需要在请求、进程和节点之间复用 KV Cache、latent cache 和前缀缓存；训练流水线则需要在异构资源间传递中间状态；模型文件、样本数据和 Checkpoint 需要在远程访问、本地缓存和跨集群之间顺利流动。
传统方法通常针对这些问题引入多个不同的系统，包括缓存系统、消息队列、文件系统和对象存储网关等。每一套系统都有各自的连接、容量、回收、路由以及可观测性逻辑。随着模型规模、并发请求、训练流水线和数据集的不断增长，数据面开销也在不断膨胀，逐渐消耗 CPU、I/O、内存和运维的精力。
Fluxon 是一个面向 AI 训练与推理数据的 **存传一体分布式系统**，它将分布式键值缓存、RPC、消息队列和兼容 S3 的文件对象缓存加速层整合到同一套 **数据面加速底座** 中，使得高频数据对象能够复用统一的缓存、传输、租约、容量治理和可观测性能力。
## 缘起：从 VAE 弹性解耦的阵痛说起
Fluxon 最初的工程动机之一，源于 VAE 解耦异构训练中的跨资源池数据交接。我们的目标是使生产者与消费者可以独立分布在不同资源池，通过中间状态的 Payload 完成异步交接，而不是让训练组件被固定的通信组重新绑定。
在这个场景中，NCCL 的边界非常清晰。它擅长于固定成员集合的同步通信，但在动态成员、异步交接、背压、消息保活和跨资源池弹性调度的场景中，固定成员的通信模型会导致希望解耦的训练组件重新耦合。
我们尝试过将 MooncakeStore 等高性能传输和缓存方案应用于训练流水线中的大 Payload 搬运。尽管在特定缓存场景下表现良好，但直接应用于通用的 AI 训练数据面时，会暴露新的工程约束：在高负载和长时间稳定性下，底层内存生命周期与传输状态一旦处理不当，可能导致进程崩溃或任务中断。面对网络抖动，缺乏自动切换机制的情况，训练流水线常常难以自愈；如果底层异常无法稳定捕获并向上游传递，生产者和消费者很容易陷入状态不一致、长期阻塞或反复排查的问题。
经过这些经历，我们意识到，AI 数据面不能仅仅追求某一段传输链路的峰值性能。它还必须具备严格的错误传播、高可用的网络兜底、统一的对象生命周期管理，以及能够支撑动态资源治理模型的能力。
既然现有方案无法同时覆盖弹性解耦、高性能搬运和故障兜底，Fluxon 决定从数据面加速底座重新设计这条路径。
## 为何需要统一 AI 数据面
AI 负载中的数据对象变得越来越大、越来越热，并频繁跨边界流动。
推理侧的高频缓存不再只是单进程内的临时对象。在多副本推理服务、世界模型、多模态模型和长上下文场景中，这些缓存经常需要跨请求、进程和节点进行复用。如果各个实例独立管理缓存的驻留、回收和传输，显存和内存将因数据冗余而迅速耗尽。
训练侧的数据流也越来越复杂。例如，在 VAE 解耦异构训练的跨资源池生产者和消费者交接场景中，生产者和消费者位于不同机器、不同资源池甚至不同子集群。若中间态 Payload 只能依赖传统 MQ、文件落盘或对象存储，则数据链路会被拉长，容量治理将变得更加困难。
存储方面同样重要。高分辨率视频、轨迹样本、模型文件和 Checkpoint 需要同时支持远程访问、本地缓存、S3 转发和跨集群迁移。如果文件对象缓存与 KV 缓存分散为两套系统，数据会在多个系统之间反复拆分、复制、落地和重新索引。
Fluxon 关注于整个 AI 数据面生命周期，包括对象如何分配、存储位置、跨节点传输、何时驱逐、业务进程如何接入以及问题发生时如何定位。
## 为什么“拼图式” AI 数据面走向瓶颈？
传统 AI 数据面常见的拼接方式是：高频缓存使用一套 KV 或自研缓存，中间态交接用 MQ 或对象存储，文件数据再接入一套文件系统或对象缓存，最后可观测性系统单独采集每个组件的状态。
这种方式在早期能快速实现功能，但随着系统规模的扩大，会暴露出几个问题：
1. 局部场景的经验难以迁移。MooncakeStore 针对 KV Cache 场景进行了专门设计，缓存语义和 RDMA 传输绑定在特定路径上。但面对更泛化的数据面场景，底层传输与容量治理难以直接转移。
2. 资源的统一管控和调度不够彻底。例如，框架级缓存 SGLang 的 L2 保留框架内索引，以提供最低延迟访问，而 MooncakeStore 作为 L3 则负责跨实例复用。但这两层往往处于单机 CPU 内存，造成缓存穿越和对象交接的开销增加。
3. 进程间缺乏共享内存快路径。例如，以 MooncakeStore 作为 L3 接入的情况下，数据通路通常通过 RDMA/TCP 组织，非常适合跨节点池化。但如果同机的工作进程无法直接接入共享内存数据面，对象交接仍需经过网络传输协议栈。
4. 缺乏动态弹性的 AI Infra 通信平面。NCCL 等集合通信库适合固定成员集合内的同步通信，但在 VAE 解耦异构训练中，跨资源池的生产者与消费者交接需要动态成员、异步交接、背压、消息保活和大 Payload 放置。固定成员的通信模型会导致训练组件重新耦合，并增加连接与故障恢复的复杂性。
5. 业务进程与数据面资源治理的耦合。如果业务进程在动态启动、退出、扩缩容或出现异常时，同时承担容量、对象生命周期及跨节点连接，会导致数据面的容量与连接拓扑受到影响，进而影响缓存复用、故障恢复和运维判断。
6. 对象生命周期难以统一管理。缓存、消息与文件对象各自维护引用、租约、驱逐、路由与回收状态时，团队很难在一个地方判断对象是否仍在被消费、何时可以释放、何时需要迁移或重建索引。组件越多，状态越容易散落在业务框架、缓存层和传输层之间。
7. 可观测性链路缺乏整合。缓存命中、Owner 队列、传输路径、对象物化与业务进程延迟如果分散在不同系统里，性能问题发生时很难快速定位瓶颈，团队只能在多套指标和日志中拼凑线索，排查成本随组件数量上升。
Fluxon 的设计围绕这些问题展开，将数据面资源、对象生命周期、跨节点传输和业务接入进行各自抽象，并纳入数据面加速底座统一治理。
## Fluxon 的方案
Fluxon 基于存传一体的数据面加速底座，向上提供三类入口：
| 入口 | 面向场景 | 能力定位 |
|------|----------|----------|
| 分布式键值缓存 / RPC | 推理缓存、状态共享、服务间调用、张量对象复用 | 统一键值读写与节点间 RPC，服务高频状态缓存与张量对象复用 |
| 消息队列 | 跨资源池生产者与消费者中间态交接（例如 VAE 解耦异构训练）、数据处理流水线 | 动态弹性的 AI Infra 通信平面，复用键值数据面承载大 Payload |
| 文件对象缓存加速层 | AI 数据、模型文件、Checkpoint、远程对象访问、S3 转发 | 兼容 S3 的文件对象缓存加速层，并与 KV/MQ 复用数据面加速底座，使张量、消息 Payload 和文件对象能够统一缓存与加速路径 |
这三类入口共同复用同一套缓存、传输、租约、容量治理、对象生命周期和可观测性能力。这意味着，上述场景里的高频数据对象都可以在同一套数据面加速底座中获得统一的缓存与加速，AI 负载不需要分别建设多套数据面路径。
在同机资源治理方面，Fluxon 倾向于按真实物理资源组织缓存层级。优先将同机 CPU 内存纳入共享内存和统一对象生命周期治理，减少人为划分 L2 / L3 导致的额外链路；跨机、跨集群与远程对象访问则应走分布式传输路径。
这也是 Fluxon 与单点缓存、单点消息队列、单点文件接口最大区别：Fluxon 的核心是数据面加速底座，API 即是这套底座针对不同场景所暴露的入口。
## 架构分层：明确角色定位
Fluxon 将控制面、数据面资源与业务接入抽象为三类核心角色。这种分层不仅实现了资源治理与业务生命周期的解耦，也为 AI 数据面在大规模集群下的 **水平扩展（Scale-out）**扫清拓扑与连接瓶颈。
- Master （控制面）统一管理内存分配（Allocation）、对象放置、驱逐、路由与租约，确保多进程、多节点场景下对象生命周期的一致性，保障内存的精准回收。
- Owner Client （数据面资源提供者）作为常驻节点贡献共享内存池，并承载 Owner 间的跨机通信。业务进程接入本机 Owner，由其完成跨机传输，避免业务进程直接互联带来的连接风暴。
- External Client （业务接入层）承载推理服务、MQ 生产者/消费者、FluxonFS、FluxonOps 等动态接入，不贡献集群容量。由于 External Client 不提供物理容量，业务侧的频繁启停、异常重启或弹性扩缩容，不会直接导致数据面的容量迁移与重平衡震荡。
这三个角色共同构筑了 AI 数据面的底层稳定性与可扩展性：Master 作为决策者收敛全局状态，避免对象放置、路由与回收逻辑散落在业务进程里；Owner Client 作为提供者与承载者固化物理容量和跨机骨干，而 External Client 作为接入者承载弹性业务负载，互不干扰。边界清晰后，Fluxon 在不牺牲单机快路径的前提下，实现了缓存、消息与文件对象访问的真正复用。
## 数据通路：本机共享内存、跨节点 P2P 与自动中继
Fluxon 同时覆盖本机对象交接、跨节点对象流动以及复杂网络拓扑下的中继转发。
在本机路径上，业务进程优先接入 Owner 的共享内存池，通过 SHM/Busy Polling/Epoll UDS 降低对象交接成本，减少不必要的复制和重建。
在跨节点路径上，Owner 之间通过 P2P 传输数据，依部署选择 RDMA、TCP、QUIC 等路径，并支持跨节点、跨子集群的自动中继转发。当源 Owner 与目标 Owner 无法直接按预计链路互通时，数据面可以通过中继路径继续完成传输，业务进程无需关注复杂网络拓扑，只需接入本机 Owner；跨机数据搬运被汇聚到 Owner 之间的路径。这种分层架构减少了业务进程之间的跨机连接扩散，也提高了系统的可扩展性。
该设计使 Fluxon 能够同时服务于单机内的多进程复用、集群内的跨节点复用以及跨集群的数据流转，前者关注共享内存与对象交接，后者则关注连接收敛、路由自适应和跨机传输。
## 底层引擎：用 Rust 构筑低开销、可控的数据面加速底座
随着 GPU 算力的提升与集群规模的扩大，I/O 与 CPU 正逐渐成为 AI 系统中的显性瓶颈。连接处理、协议编解码、高并发传输、共享内存管理和可观测性采集都在数据面热路径；如果这些热路径充斥解释执行、运行时调度、跨语言边界拷贝以及不受控的内存复制，GPU 侧节省下来的时间可能会被数据面开销消耗。
Fluxon 将这些关键路径交给 Rust 实现，目标是将并发安全、内存生命周期和系统调用边界纳入更强的工程约束。
- **并发能力**：CPU 密集型路径不受 GIL 约束，更加容易充分利用多核资源。
- **延迟可控**：没有 GC 停顿，减少热路径中的不可预测抖动。
- **长稳安全**：通过所有权、生命周期和类型系统约束共享内存、连接状态和对象引用。
- **代码可审计**：强类型接口与明确状态机使得底层数据面更容易被人和工具审查。
这种系统级底层掌控力，使各类高频数据对象能够在同一套数据面加速底座上安全、高效流转。对底层数据面来说，这比单纯追求某个接口的峰值性能重要得多。
## 统一可观测性（Observability）
Fluxon 的可观测性底座选用了同样由 Rust 构建的 GreptimeDB。这与 Fluxon 的底层哲学高度契合：GreptimeDB 将 Metrics、Logs、Traces 三大可观测性支柱统一在一个引擎中，就像 Fluxon 将缓存、消息和文件对象访问统一在同一数据面加速底座中。
基于 Prometheus 协议采集指标，与链路追踪及结构化日志结合，Fluxon 内置 GUI 直观呈现集群拓扑、成员状态、关键延迟与队列深度。
对数据面系统而言，可观测性不是附加特性，而是治理能力的延伸。只有在问题能够精准定位到 Owner、External Client、传输路径、队列等待或对象处理阶段时，数据面底座才能真正可治理。统一的可观测性，正是 Fluxon 数据面加速底座闭环的重要环节。
## FluxonKV：分布式键值缓存与 RPC 共用数据面加速底座
Fluxon KV/RPC 面向世界模型推理缓存、状态共享、服务间调用及张量对象复用。在多视角潜在空间预测、状态外推、前缀缓存复用等场景下，它覆盖更通用的 AI 数据面，超越单一 KV Cache 场景。
KV 和 RPC 共用同一套参数组织、缓存和通信路径，状态存储、对象复用和服务间调用无需分别建立两套路径，高频调用与大对象复用可以在同一个角色模型中完成。
在读路径上，Fluxon 优先命中本地快路径，并在后台异步推进元数据同步。系统通过热点复用减少多级缓存的重复驻留与内存浪费，并借助批量回收策略将零散的控制面交互收敛为批量操作，削减控制面流量与计算开销，进而提升系统整体吞吐与稳定表现。
这一系列优化意味着，各类高频状态缓存、张量对象和服务调用可以统一进入同一数据面加速底座，不必在缓存系统和 RPC 系统之间频繁转换。
## FluxonMQ：动态弹性的 AI 数据流通信平面
Fluxon MQ 面向跨资源池的生产者/消费者中间态交接及数据处理流水线，其中 VAE 解耦异构训练为其中一类典型场景。当生产者和消费者分布在不同机器、资源池甚至子集群时，MQ 负责将消息保活、容量治理与跨集群放置整合到统一消息层。
传统 MQ 多基于 TCP 与磁盘日志构建，设计并非旨在支持大 Tensor Payload，因而缺乏原生的 RDMA 高速数据通路。在处理几十 MB 甚至 GB 级中间态时，通用 MQ 很难满足低延迟交接、容量治理和高带宽搬运。
NCCL这类集合通信适合固定成员集合内的同步通信，跨资源池的生产者与消费者交接需要动态成员、异步交接、背压、消息保活以及大 Payload 放置。虽然 MooncakeStore 等优秀的专用缓存系统在 KV Cache 复用上表现优异，但其核心的缓存驱逐语义天然难以平替 MQ “消息未消费前必须保留”的语义诉求。它们通常依赖部署侧对 RDMA/TCP 的选择，难以承载数据面加速底座中的自动兜底、跨集群中继和弹性交接。
这里的核心设计理念在于：**控制面轻量化**，仅保留消息壳、成员拓扑与偏移；**数据面重装**，大 Payload 直接复用 KV 数据面进行搬运。这意味着，Fluxon 无需为消息队列额外建设第二套大对象传输链路。
生产者与消费者作为 External Client 的动态加入，不改变集群容量。它们可以根据业务负载进行扩缩容，而 Owner 仍作为常驻数据面资源提供者保持稳定。
`Lease` 将消息保活与消息通道绑定，消费前的数据保留有明确的时间边界。在跨资源池与跨子集群场景中，Payload 放置可以结合消费者位置，尽量缩短预取链路。
## FluxonFS：兼容 S3 的文件对象缓存加速层
Fluxon FS 的定位是兼容 S3 的文件对象缓存加速层，面向 AI 数据、模型文件、Checkpoint、高分辨率视频和轨迹样本，覆盖远端访问、缓存命中、S3 转发与跨集群迁移。
FS 的关键在于复用 `KV/RPC` 的缓存与通信能力。文件被切成 `KeyValue` 片段后，进入 Fluxon 的缓存、传输与容量治理路径，从而使文件、对象与 KV 缓存从三套割裂系统收敛为数据面加速底座的不同入口。
对于 AI 数据平台，这条路径降低了文件数据在远端访问、本地缓存和跨集群迁移之间切换的成本。上层依然保持文件对象语义，下层则复用统一的数据面能力。
## Benchmark
当前公开 Benchmark 图表覆盖 RPC、KV 和 FS （文件对象缓存加速层）三类路径。以下数据基于特定测试场景生成，重点呈现不同路径上的架构收益和性能边界。
注：Benchmark 数据基于特定拓扑与 Payload 规模生成，实际业务收益受网络环境、对象大小及访问模式影响。
### RPC Benchmark
RPC Benchmark 比较 ZeroRPC、Fluxon TCP Thread 和 Fluxon RDMA 在 4 KB echo Payload 下的吞吐与端到端延迟。图中可以看到，Fluxon 的 RPC 路径在 P1 和 P8 面板下都显著降低延迟，并提升聚合吞吐。
这一结果对应服务间调用路径，说明 RPC 与 KV 共用的参数组织、路由与通信底座能够承载高频小 Payload 的调用，实际业务处理函数的端到端耗时还将受到应用逻辑的影响。
### KV Benchmark
KV Benchmark 展示了 READ_AFFINITY、READ_ZIPF 和 PUT_ONLY 三类场景。读多场景是当前公开结果的优势区间，特别适合解释本地性、热点对象复用和跨节点对象定位带来的收益。
在纯写 PUT_ONLY 场景下，当前性能约束主要集中在处理中元数据判重的路径，而非 Payload 传输本身，这也是后续优化的核心方向之一。
### FS Benchmark （文件对象缓存加速）
FS Benchmark 比较 Fluxon FS 与 Alluxio，在缓存预热条件下的小文件读、大文件读、小文件写与大文件写。图中最突出的区间是大文件写；小文件读也已有优势，而大文件读基本接近，小文件写则仍有进一步优化的空间。
这一组结果对应文件对象缓存加速层。Fluxon FS 的收益源于 KV/RPC 数据面的复用，但在小文件写中仍会受到上层打开、写入、关闭与提交流程的影响。
## 为什么开源
Fluxon 开源的是一套完整的 AI 数据面加速底座，涵盖 Rust 核心实现、Python 接口、分布式键值缓存、RPC、消息队列、兼容 S3 的文件对象缓存加速层、部署工具链、测试栈与 Benchmark 都在同一个项目中组织。
希望开发者能直接看到 Fluxon 如何组织控制面、数据面、业务接入、可观测性和测试，理解这些接口背后的数据面加速底座。AI 基础设施正逐步从单模型、单服务、单集群走向更复杂的数据流动形态，缓存、消息与文件对象访问均需重新回到同一条数据面链路中思考。
Fluxon 选择 Apache License 2.0 开源，希望与社区一起推动 AI 推理缓存、异构训练、文件对象缓存、跨节点传输、共享内存、Rust 数据面和可观测性体系的演进。
## 下一步
Fluxon 仍在快速演进。短期内，继续优化 KV Cache 在 SGLang 中的集成部分，十分有趣，为了满足 L2 对极低延迟访问的要求，接口层会增设一些新能力，以便让框架内索引、本机共享内存与数据面加速底座之间的协同变得更加直接。目前内部版本相比于 SGLang+Mooncake 基线已提升了 50% 的吞吐量。
从长远来看，Fluxon 希望成为 AI 系统里的数据面加速底座，让各类 AI 负载的数据对象和跨节点传输整合回同一条可治理、可观测的路径中。希望算法工程师与模型服务开发者能将更多精力投入到模型创新上，而非在底层数据流转的重复建设与被动修补中持续消耗。Fluxon 愿意成为这块数据面加速底座，支持 AI 时代更复杂、更自由的数据流动。
Fluxon 由中国电信人工智能研究院（TeleAI）AI Infra 团队研发，由中国电信首席科学家李学龙教授主导。Fluxon 在 Apache License 2.0 下开源，GitHub 仓库地址：[https://github.com/Tele-AI/Fluxon](https://github.com/Tele-AI/Fluxon)。欢迎对 AI 推理缓存、异构训练、Rust 数据面和分布式系统感兴趣的开发者参与。
---
原文链接：[点击查看](https://www.v2ex.com/t/1229481)
评论
暂无评论。