下一步，为何是 GPU。
十五年来，分析系统一直在挖掘处理器的极限。下一个数量级的提升将来自不同的硬件。
四步说明其逻辑。
处理器路线已经走到尽头。
列式引擎通过以物理条件允许的最高效率为少数处理器核心供给数据来提升速度，但这条路线已不再持续增长。
内存带宽是瓶颈。
分析查询需要读取、筛选、分组和联接，而处理器内存由所有核心共享。
GPU 与这类工作高度匹配。
数千个核心和高带宽内存可用于计数、筛选、分组和联接。
为何过去未能实现。
GPU 数据库已经验证了这一理念，但一直是专有且昂贵的产品。如今显卡已广泛可用，工具链也已成熟。
RayoDB 如何实现这一点。
数据驻留在显卡上。
存储经过专门组织，使查询所需的列位于 GPU 内存中。
容量可以直接量化。
每个工作节点使用一个 GPU。需要更多余量时，只需增加工作节点。
模型在数据旁运行。
预测、异常检测和语义搜索均作为 SQL 函数运行。
一个会话，两条语句。
1 · A week of events, per hour
SELECT toStartOfHour(ts) AS hour, count() AS events
FROM product_events
WHERE ts >= now() - INTERVAL 7 DAY
GROUP BY hour;| hour | events |
|---|---|
| 2026-08-27 00:00 | 1,284,913 |
| 2026-08-27 01:00 | 962,340 |
| … | … |
168 rows · sample data
2 · The next 24 hours, forecast in SQL
SELECT * FROM AI_FORECAST(hourly_events, hour, events, 24);| hour | forecast | low | high |
|---|---|---|---|
| 2026-09-03 00:00 | 1,301,540 | 1,214,002 | 1,388,118 |
| 2026-09-03 01:00 | 978,116 | 901,455 | 1,054,210 |
| … | … | … | … |
24 rows · sample data
真实的 RayoDB SQL，行数据仅作示例。未展示任何耗时数据，这是政策要求.