不用GPU也能跑赢H100：DuckDB为什么拒绝GPU加速

一篇 Pandas GROUP BY 要跑 280 秒，上了 H100 GPU 降到 6 秒。而 DuckDB 在 CPU 上只需要 8 秒。
$30,000 的显卡，换来 2 秒的差距。这笔账，DuckDB 创始人 Hannes Mühleisen 算得很清楚。

微信群又有人问：「DuckDB 什么时候支持 GPU？」

这大概是 DuckDB 社区被问得最多的问题之一。每次有人拿 DuckDB 和 cuDF、Polars GPU 对标的时候，总有人期待官方下场做 GPU 加速。

答案是：不做。而且是有意不做。

DuckDB 联合创始人 Hannes Mühleisen 的原话：

"In my opinion, there's absolutely no point of making data transformations run on GPUs."

不是「暂时没做」，是「没有意义」。这句话背后的逻辑，比它听起来要深刻得多。

● ● ●

四次「刻意的简化」

Hannes 把 DuckDB 的核心设计决策概括为四次 deliberate simplification：

• 不做分布式——单节点就够了
• 不做 GPU——CPU 上的向量化执行已经够快
• 不手写 SIMD 指令——靠编译器自动向量化
• 不做 JIT 编译——解释执行的向量化引擎足够了

这四条放在一起看，不是功能缺失，而是一套高度一致的哲学。每一条削减的都是「看起来很厉害但实际增加复杂度的东西」。每一条保留的都是「在一个普通人的电脑上就能跑的东西」。

Hannes 的底气来自实打实的测试。2024 年底，DuckDB 团队在一台安卓手机上跑完了 TPC-H SF100——也就是 100GB 规模的数据集，22 条标准分析查询。结论：

"While the MonetDB/X100 system needed to use explicit SIMD, DuckDB can rely on the auto-vectorization of our carefully constructed loops."

不写一行 SIMD 指令，不碰 GPU，让编译器自动把循环向量化。手机都够用，还要什么显卡。

● ● ●

不是 GPU 不够快，是 DuckDB 把 CPU 榨得太干了

要理解为什么 DuckDB 不需要 GPU，得先理解它的向量化引擎是怎么工作的。

DuckDB 每次处理 2048 行数据块，不是一个一个处理。这个 2048 不是随便选的：

• 正好塞进 L1/L2 CPU cache，减少 cache miss
• 编译器可以自动生成 AVX-512/AVX-256 SIMD 指令
• 对齐现代 CPU 的流水线和分支预测

再加上 Morsel-driven parallelism——把数据切成小片（morsel），均匀分给所有 CPU 核心并行处理——以及 push-based pipeline——数据在一串算子之间「热流动」，不落地、不物化，始终待在 CPU cache 里。

这套架构在 OLAP 场景下已经把 CPU 利用到了接近理论极限。

一个很有说服力的对比来自 cuDF 官方文档：

Pandas → cuDF 是 46 倍的提升。cuDF → DuckDB 呢？DuckDB 在普通 CPU 上只慢了 2 秒。

一块 H100 售价约 $30,000。为了省 2 秒，值吗？

2025 年的一篇学术论文（ICSIMA）在 V100、A10G、Xeon Platinum 三种硬件上完整跑了一遍 TPC-H，结论更精确：

GPU 加速在大数据集、计算密集型查询上有优势；而 DuckDB 在内存密集型和 I/O 敏感操作上效率更高。

翻译成人话：大多数分析查询的瓶颈不是算力，是磁盘读取速度和内存带宽。DuckDB 把力气花在了列式压缩、zonemap 谓词下推、out-of-core 溢出这些地方，而不是堆 GPU 浮点运算。

● ● ●

另一个维度的账：可移植性

DuckDB 定位是「SQLite for analytics」。它实际被部署在：

• 浏览器（WebAssembly）
• iOS/Android 手机
• NASA 的卫星（具体用途官方没透露）
• 树莓派
• 2012 年的老 MacBook（Hannes 亲自测的，60 亿行数据照样跑）

这些设备上根本没有 NVIDIA 显卡。引入 CUDA 意味着放弃 DuckDB 最核心的差异化优势。

Hannes 在 PyData 演讲中说过一句话：

"There's no apt-get, no Docker, no funky drivers, no funky GPU drivers, nothing like that."

DuckDB 整个库不到 50MB，零外部依赖。pip install duckdb 就完事。加上 CUDA toolkit？光是 Docker 镜像就要膨胀几个 G。

而且 GPU 分析还有一个很多人忽略的隐形成本：数据搬运。CPU ↔ GPU 之间的 PCIe 传输延迟是毫秒级，而 DuckDB 的向量化操作在纳秒级。对于中小规模的查询，把数据搬到 GPU 上的时间比在 CPU 上直接算完还长。

● ● ●

态度明确，但不封闭

DuckDB 官方不做 GPU，但不反对别人做。

2025 年 8 月，威斯康星大学麦迪逊分校和 NVIDIA 联合发布了 Sirius——一个 GPU 原生的 SQL 引擎，以 DuckDB 扩展（extension）的形式工作：

• 不修改 DuckDB 一行源代码
• 通过 Substrait 标准截获查询计划
• 支持的算子在 GPU 上跑，不支持的回退到 CPU
• TPC-H 上达到 7x 加速（同等云成本），ClickBench 刷新性能记录

DuckDB 团队把这个论文收录到了官方 Library 页面。态度很明确：核心不做，生态开放。

这才是架构上的正确选择。GPU 加速是一个特定场景的需求，不应该绑架所有人的安装体验。想要的人装扩展，不想要的人保持 50MB 零依赖——各取所需。

● ● ●

回到那个问题

「DuckDB 为什么不做 GPU？」

因为 Hannes 和 Mark 从一开始就没把 DuckDB 当成一个「要加很多功能才完整」的数据库。他们做的是减法。

不做分布式，所以一个人就能跑。不做 GPU，所以手机上就能跑。不手写 SIMD，所以换个架构也能编译。不做 JIT，所以不依赖 LLVM。

每一次减法，都让 DuckDB 能跑在一个更小、更普通、更意想不到的地方。

而对绝大多数人来说——你的数据量、你的查询复杂度、你的硬件预算——CPU 上的 DuckDB 早就够用了。

参考来源：

- Hannes Mühleisen 个人页面: https://hannes.spicytakes.org/

- DuckDB 官方博客 "The Lost Decade of Small Data": https://duckdb.org/2025/05/19/the-lost-decade-of-small-data

- DuckDB 官方博客 "Running TPC-H SF100 on Mobile Phones": https://duckdb.org/2024/12/06/duckdb-tpch-sf100-on-mobile

- MotherDuck 社区讨论: https://community.motherduck.com/x/ask-ai/wd3wbeenzsb7/does-duckdb-support-gpu-acceleration-for-data-proc

- Sirius 论文 "Rethinking Analytical Processing in the GPU Era": https://duckdb.org/library/rethinking-analytical-processing-in-the-gpu-era/

- NVIDIA Sirius 博客: https://developer.nvidia.com/blog/nvidia-gpu-accelerated-sirius-achieves-record-setting-clickbench-record/

- ICSIMA 2025 论文: https://doi.org/10.1109/icsima66552.2025.11233381

- BigDATAwire 采访: https://www.hpcwire.com/bigdatawire/2024/03/05/duckdb-walks-to-the-beat-of-its-own-analytics-drum/