缩短数据路径
在兼容平台上把外部数据直接写入 GPU 显存，减少主机内存中转环节。
问题：数据进不去，算力就只是参数
AI-RAN 与机器人感知看起来是两个行业，但它们面对的是同一个瓶颈。
- 共同需求：大量、异构且时间相关的数据，需要持续进入 GPU 并被算法及时使用
- 传统做法：分别开发接口、驱动和同步逻辑，每接一种数据源就要重来一遍
- 中转损耗：部分数据还需经 CPU 及主机内存中转，带来额外的内存流量与调度抖动
- 集成代价：逐设备开发导致系统集成周期长、复用率低，方案难以沉淀为标准产品
要接入的是两类数据
它们接口异构、速率差异大、时间关联强——这正是难做的地方。
| 来源 | 典型数据 | 为什么难处理 |
|---|---|---|
| 通信侧 | 原始 IQ 采样、无线前传数据、雷达回波 | 速率高且连续，对时间对齐与不丢包的要求严格；多天线场景下还有相干性问题 |
| 机器人侧 | 图像、点云、六维力、运动状态 | 模态之间采样率与延迟量级差异巨大，高速原始数据与低速状态数据必须按各自特性接入 |
我们给出的四项改善
每一条都是可以被客户验证的，而不是概念。
提高数据可用性
统一时间戳、流标识与缓冲管理，支持多源对齐、录制回放与异常定位。
降低集成成本
通过标准 SDK 与协议插件，让上层算法复用同一套数据接口，不必逐设备重写。
提高 AI 渗透率
通过高速 SerDes 接口，提高通信系统与机器人系统接入 AI 平台的比例。
架构方向
从物理接口到 GPU 算法，一条通路上四段。
-
STEP 01
多源接入
前端按阶段支持高速以太网、JESD204B/C、Aurora 及定制串行接口，覆盖通信与感知的多种物理层形态。
-
STEP 02
FPGA 实时处理
在 FPGA 侧完成协议解析、硬件时间戳、必要的信号预处理、缓冲与流量调度。
-
STEP 03
GPU 直达
通过 PCIe 点对点 DMA 及适配的 GPU Direct RDMA 路径，把数据写入 GPU 显存。
-
STEP 04
统一运行时
由 CUDA 程序完成基带处理、感知融合与 AI 推理；CPU 负责配置、资源管理与故障恢复，后续持续降低其开销。
两种接入形态
按距离与部署条件选择，而不是一套方案打天下。
同机箱直连
接入模块与 FPGA 处于同一机箱时，采用 PCIe 直连。路径最短、延迟最可控，适合对时序要求最严的场景。
- 最短数据路径
- 延迟与时序最可控
- 适合固定式、集中式部署
远距离 SerDes
面向需要拉开距离的部署形态，研发基于低功耗 SerDes 的远距离传输方式，重点在链路工程能力而非仅仅是协议。
- 低功耗串行链路
- 面向距离与安装条件的工程验证
- 为多节点与分布式部署做准备
远景：让移动实体与固定基础设施运行在同一套架构上
这条技术线最终要统一的，是两件看起来毫不相干的东西。
- 挂在墙上的 6G 基站——固定基础设施
- 在地上跑的具身机器人——移动实体
- 两者对高速数据接入的需求是共性的：都要把物理世界的数据持续送进算力
- 把这份共性需求做成标准产品，就能同时服务两端，而不必为每个行业重做一遍
常见问题
这条线现在到什么阶段了？
处于研发与规划阶段，尚未形成可交付的标准产品。我们把它公开写在「技术路线」而不是「产品」里，正是为了让合作方清楚这一点——这也是我们愿意现在就谈的原因：在方向阶段参与，调整成本最低。
你们和已有的传感器接入方案有什么不同？
已有方案多把重心放在「传感器经网络进入 GPU」这条路径上，以太网封装、传输与网卡处理会带来额外成本，也难以解决 6G 时代多天线相干与更严苛的同步问题。我们的方向是缩短这条路径本身，并把采样同步、时空语义与数据完整性管理作为核心命题。
现在可以合作吗？合作形式是什么？
可以。我们优先寻找有明确指标需求和测试场景的合作方，以联合研发、付费验证或设计导入的方式推进——用真实工况验证，而不是靠参数表沟通。
会对外公布性能指标吗？
会在有实测依据之后。我们不希望用一个未经验证的数字换取短期关注——对我们这个阶段的公司来说，说出去做不到，损失远大于晚说一步。