发一篇欠揍的文章！数据库集成GPU是“馊主意”吗？

数据库集成GPU是“馊主意”吗？这个问题是不是欠揍啊

如果连GPU都买不到嘿嘿，我是不是很欠揍？废话不多说，听我细细道来  

往数据库服务器里装GPU卡是“馊主意”吗?

作为DBA, 先别着急下结论; 作为醉翁之意不在酒的小伙伴, 别起哄, 水不知道你只关心能不能买到GPU.

回答完以下几个问题, “馊主意”还是“好生意” 立马豁然开朗!

1、数据库什么时候/场景要使用GPU, 使用GPU是高频操作吗? 频率如何?

• 1 推理, 例如基于问题和数据, 让大模型进行推理. 也许能成为高频操作, 但是再看问题2.
• 2 RAG, 例如基于问题和"历史记忆/相关知识点", 让大模型生成结果. 也许能成为高频操作, 但是再看问题2.
• 3 预训练, 使用数据库存储预训练的数据集, 预训练的过程中进行调用. 低频操作, 这种场景要的是数据的大吞吐, 所以你看deepseek开源smallpod(base on duckdb)测的benchmark是什么? 大吞吐的数据进出.
• 4 微调, 使用数据库存储微调的数据集, 微调的过程中进行调用. 低频操作

2、数据库使用GPU时, 发给GPU的数据最多有多少?

• 发送数据库肯定不能超过模型能处理的上下文, 例如一般是128K(参数量相同的情况下上下文支持越大的模型, 回复精确度越低), 目前最大的可能是1MB, 单位tokens.

数据库发给大模型的数据通常不会太大. 通常可能在KB级别(tokens, 假设1 token平均8字节). 处理预训练和微调时除外, 但是这两个都不是通常场景.

数据从数据库到GPU, 链路可能是这样的:

• 跨机链路是这样的: disk(未命中缓存的数据) -- memory - network -- GPU 服务器
• 如果数据库服务器的带宽是10GB, 每秒可以向GPU发送131万次请求(每个请求1KBytes). 如果能达到这样的请求量, 大概率是GPU算力先成为瓶颈. 一定不会是数据库服务器的网络、或者磁盘, 所以 move data 应该不是问题.
• 本机链路是这样的: disk(未命中缓存的数据) -- (ssd-to-GPU P2P DMA) -- GPU   ( 参考开源项目: https://heterodb.github.io/pg-strom/ssd2gpu/ )

3、数据库服务器升级/更换GPU时, 需要停止该服务器上运行的数据库吗?

• 肯定影响啊, 为了降低影响, 至少得切换吧?

4、企业中除了数据库要用GPU, 还有哪些应用需要使用GPU, 相比于数据库, 这些应用使用GPU的频率更高还是更低?

• 大概率是面向C端/AI Agent的应用使用GPU更高频. 在数据库服务器中安装GPU卡, 增加了数据库集群的故障点. 为了低频需求增加故障点值得吗?

5、数据库服务器需要额外的空间来存储模型吗? 需要存储多个模型吗? 加载模型时会导致IO飙升吗?

• 当然需要, 因为使用大模型时, 需要把模型参数全部加在到GPU内存中. (模型有大有小, DeepSeek R1 671B量化后还需要400多GB. 我们一般会在不同场景中使用各种不同的模型, 如果把GPU装到数据库服务器中, 就要在数据库服务器上预留更多的存储空间来存放不同的模型文件; 同时, 在切换模型时需要将模型载入GPU内存, 有可能导致瞬间磁盘IO飙升(指存储模型文件的磁盘))

把模型文件放在数据库服务器上, 把GPU放在数据库服务器上, 可能影响数据库稳定性.

个人认为, 数据库要的是大模型的推理能力. 集成GPU不是目的, 而是手段. 正确的做法一定是建立独立的GPU服务器集群, 让数据库拥有使用API调用大模型的能力即可.

postgresml这个项目的价值不是它让PG集成了GPU(个人认为这个反而是败笔), 有价值的实际上是“数据库与大模型在能力上的结合给业务和数据带来了新的价值”.

https://postgresml.org/docs/

https://github.com/postgresml/postgresml

https://www.star-history.com/#postgresml/postgresml&Date

可以看到postgresml项目刚出来的时候star增长很陡峭, 2024之后增长斜率大幅下降, 而2024是AI应用爆发之年, 斜率逆势下降必有因, 该项目方向可能是错的.

 看到这, 你肯定会说: 数据库服务器集成GPU一定是“馊主意”. 

but, 且慢, 换个角度看问题, 剧情马上反转

作为DBA, 你是不是觉得很多工作都会逐渐被AI取代? 你公司的其他岗位是不是都在用AI来提升工作效率? 作为管理公司核心资产的你, 是不是感觉光环正在褪去? 是不是想转型去搞AI? 有一点点野心的你可能是不是想至少把建设大模型的工作揽过来, 继续成为公司的核心角色!

但是前面提到的几个问题怎么解决呢?

 你一定要了解一下, 业界最先进的“池化架构”. 硬件分层池化后和应用软件全面解耦, 连“数据库服务器”的概念都不存在了, 上述问题不攻自破. 

前面的问题没了, 扫清障碍后，危机变成机会，是不是有点小激动?

把GPU塞进数据库服务器就是绝佳的机会, 这不仅是为企业准备的解决方案, 也是为你(DBA)准备的上位大礼包. 把大模型团队揽过来搞起来, 谁都知道一家企业最重要的就是脑子和数据, 都在你手里无敌了, 赢取白富美就靠它.  如果你的野心再大点, 掌握权力, 哎哟喂不敢想, 后面的超爽短剧剧情请自行脑补...

数据库还要提升什么能力? 更好的与AI完美整合?

以下纯属个人观点, 无数据支撑，信不信由你。

1、wire protocol的改进.

GPU服务器集群可以部署更大参数量、更多的模型, 算力将大幅提升, 同时未来上下文的能力也可能会有大幅提升.

未来一次SQL请求, 从数据库提取大量数据是有可能的. 所以要在wire protocol这块下功夫, 提升move data效率、降低move data成本:

• 避免序列化反序列化, 数据直达模型
• 协议层支持传输加密&压缩能力
• 更高效的支持mcp server(resource/tools/prompt)
• random URL+token支持. 解释一下, 例如, 在数据库中生成SQL对应的URL和相应token以及有效访问时间, 在一个有效时间窗口内(例如30秒内), 可以直接通过这个url (如( protocol://DSN/url/parameter:$?&token:$? ) ) 访问对应数据库获取相应数据(实则为请求对应SQL的结果). 通过数据库mcp server和新的wire protocol, 这就让AI agent可以更高效的从数据库中访问需要的数据.

2、内置调用大模型API的异步函数接口

• 因为大模型的请求通常都比较长, 通过接口异步化, 可以把请求提前, 可以使用并发, 可以提高整体数据处理吞吐. 和PostgreSQL 18的AIO优化一个思路.
• 《PostgreSQL 18 功能整理 : 14以来最值得期待的版本》

3、向量类型能力的提升(维度、压缩、索引类型、性能、召回率等指标).

4、提供一些函数接口可以快速把数据集市(modelscope/huggingface提供了各个领域的大量数据集, 可用于微调模型)的数据标准化(将数据进行格式化、向量化等的标准化接口)到数据库内、或数据库可以方便访问的地方(例如oss foreign table parquet, delta lake?等). 这些数据集除了用于微调, 也能用于RAG、prompt等, 有充分的理由可以加载到数据库内.  这方面pgai项目做得比较好: https://github.com/timescale/pgai

通过上面一顿软硬兼施的操作, 相信你的数据库和AI会成为企业最重要的招财猫!