你要整理一整仓库的货，但工作台只能放几箱。旧办法要求先把所有货都堆上台，台面不够，工作就做不了。新办法是一批批搬上来，处理完就腾地方；暂时用不到的货先放回仓库。Polars GPU engine 的这次更新，解决的正是类似问题：数据不必全部塞进显存，也能交给 GPU 处理。
Polars 是处理表格数据的 DataFrame 引擎，常见任务包括筛选、连接和聚合。它在 2024 年由 NVIDIA 与 Polars 团队推出 GPU engine，把部分查询交给显卡执行。但初版采用单 GPU、内存内执行：数据和计算产生的中间结果如果装不进显存——GPU 直接使用、但通常比服务器主内存小得多的高速内存——查询就会撞上容量上限。
据 NVIDIA 作者 Brian Tepera 在 Polars 官方博客的介绍，cudf-polars 26.06 开始改用基于 RapidsMPF 的新流式后端。不过，本文可用材料只有这一篇机构侧文章，性能与推荐性结论尚无独立测试交叉验证。
不再要求“一次装完”
新后端采用流式执行：先把输入切成许多数据块，再让这些块依次通过查询流程，完成筛选、转换、聚合和连接。显存紧张时，当前不用的数据块会溢出到主机内存，等需要时再取回。因此，一张 GPU 可以处理数倍于自身显存容量的数据集。
这里的“跨过显存墙”并不等于容量无限。它只是把硬性的“必须全部装进显存”，改成分批周转。系统仍会受到主机内存、数据搬运成本，以及具体操作能否流式执行等条件约束。
为了避免数据块越积越多，后端把查询中的每个物理操作变成长时间运行的 actor coroutine——可以理解为持续值守的一道工序。工序之间用容量有限的通道连接。后一道处理不过来，前一道就会减速，这叫 backpressure（背压）。它能阻止待处理队列无止境占用显存，让多道工序同时运行时的内存使用更可控。
一套执行器，从一张卡跑到多张卡
分块也为多 GPU 铺平了路。单卡时，各数据块轮流处理；多卡时，同样的数据块可以分给更多 GPU。新后端不需要另写一条多 GPU 执行路径。
RapidsMPF 还提供 GPU 之间的数据通信能力。连接、排序和高基数 group-by——按大量不同键值分组——经常要求键相同的行汇集到同一张 GPU。这会触发 all-to-all shuffle，即各张卡彼此交换数据，也是多 GPU 查询容易出现压力的环节。材料称 RapidsMPF 用流式方式完成这种交换，但供稿在相关技术说明中途截断，无法进一步判断其实现边界和完整效果。
RayEngine、DaskEngine 和 SPMDEngine 都使用同一套流式执行器，差别主要在 GPU 工作进程如何部署。官方文章称，不带参数的 RayEngine 会使用当前进程可见的全部 GPU。单卡则可直接调用 collect(engine="gpu")。上层 Polars 写法不变，查询仍先经过 Polars 优化；GPU 不支持的操作默认退回 CPU engine。
为什么这会改变适用边界？
CPU engine 仍适合交互式和中等规模的单机分析。数据增长到数百 GB 乃至更大时，join（按键连接两张表）、高基数 group-by 和 sort（排序）等昂贵操作可能明显变慢，而这些正是官方所称 GPU engine 最擅长加速的部分。
官方博客还宣称，新后端比此前由 Dask 编排、在 25.06 首次实验发布的流式执行器“显著更快”，并可把 TB 级基准最高加速 23 倍。这说明 GPU 数据处理的目标范围正从“能放进一张卡的数据”，推向数百 GB 和 TB 级任务。但 23 倍只是峰值数字：现有摘录没有给出基准名称、硬件配置、查询明细、对照版本和完整结果，不能理解为所有任务都会获得类似提升。
局限与未知
- 性能和成熟度目前只有 NVIDIA 作者在 Polars 官方博客中的单一信源，缺少第三方基准。
- “溢出到主机内存”会引入数据移动，材料没有量化这项开销，也没有说明主机内存不足时如何处理。
- 供稿未完整列出算子兼容范围；虽然不支持的操作可回退 CPU，但回退对整体性能的影响尚不清楚。