尧图网页设计 
后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载导读本文基于 PostgresML 官方博客《MindsDB vs PostgresML》Montana Low2023 年 6 月整理扩充围绕如何用 SQL 接口在数据库中运行机器学习算法这一核心命题从算法能力、系统架构、端到端基准测试、云端部署四个维度对MindsDB与PostgresML两条完全不同的实现路线进行逐项对比。读完本文你将掌握pgml.transform的完整调用方式、两种架构各自的技术取舍以及为什么数据访问方式的差异最终会转化为 316 倍的推理性能差距。为什么拿 MindsDB 与 PostgresML 做对比市面上有很多在 SQL 数据库中做机器学习的方案但绝大多数只是给机器学习套了一个 SQL 外壳数据与计算仍然被网络分隔。MindsDB 与 PostgresML 是其中两个有代表性的开源项目它们都试图为机器学习算法及其所需数据提供 SQL 接口但底层思路截然不同。这篇对比文章的直接答案是PostgresML 更有主见opinionated、更易横向扩展、能力更全且实测快数倍而 MindsDB 的资历更老按项目年龄和 GitHub Star 数计算其成熟度约为 PostgresML 的 5 倍。当社区反复追问PostgresML 和 MindsDB 到底有什么区别时作者决定用一整篇长文把推理过程完整摊开让读者自行判断结论是否公允。第一眼对比定位、许可证与实现语言MindsDBPostgresML项目年龄5 年1 年许可证GPL-3.0MIT实现语言PythonRust两者都是开源项目但许可约束不同PostgresML 采用更宽松的MIT 许可证而 MindsDB 使用GPL-3.0。更重要的是实现语言的差异——作者刻意用了两个介词来强调MindsDB 是用 Python 实现inPython一种带运行时的语言PostgresML 是用 Rust 实现withRust一种编译型、无需独立运行时的语言。这个语言选择会在后文的架构与性能对比中反复兑现成可测量的结果。算法能力对比经典算法之外数据库能力才是分水岭两个项目都集成了几十种经典机器学习算法包括来自 Hugging Face 的最新 LLMMindsDBPostgresML分类 Classification✅✅回归 Regression✅✅时间序列 Time Series✅✅LLM 支持✅✅Embeddings-✅向量支持 Vector-✅全文搜索-✅地理空间搜索-✅在经典机器学习算法分类、回归、时间序列上两者能力相当也都通过底层 libtorch 支持从 Hugging Face 加载模型。但作者在文中对 MindsDB 的 LLM 支持做了一个重要的划掉修正原文the latest LLMsPostgresML 只要能满足底层依赖就可以立即使用新发布的模型而 MindsDB 必须等官方发布更新版本才能支持新模型其当前支持的模型范围非常有限。新算法、新任务、新模型在持续涌现具体支持清单应以各自最新文档为准。真正拉开差距的是表格后半部分。PostgresML 额外支持Embedding 模型并把向量检索深度集成进数据库内部——这超出了 MindsDB 的能力边界因为MindsDB 本身根本不是数据库。PostgresML 还能直接使用其他 Postgres 扩展的全部能力借助 pgvector 的向量索引实现高效的 KNN/ANN 向量召回借助 PostGIS 处理地理空间信息并内置全文搜索。多个算法与扩展可以组合进同一条复合查询用单条 SQL 构建端到端系统——例如搜索推荐、欺诈检测——而在传统架构里这往往需要十几个不同的机器学习模型和微服务协作才能完成。在仓库源码中可以印证这种以数据库为计算中心的设计向量搜索的完整实现位于 pgml-sdks/pgml/src/vector_search_query_builder.rsEmbedding 生成则通过 pgml-extension/src/bindings/transformers/transformers.py 中的embed函数基于SentenceTransformer与rank函数基于CrossEncoder实现并在 pgml-extension/src/api.rs 中暴露为 SQL 可调用的pgml.embed/pgml.rank接口。架构对比数据与计算在同一进程还是隔着一层网络两个项目在架构实现上差异巨大这决定了它们后续所有性能与运维特性的走向MindsDBPostgresML数据访问方式网络传输over the wire进程内in process多进程支持✅✅数据库-✅复制 Replication-✅分片 Sharding-✅云托管✅✅本地部署✅✅Web UI✅✅PostgresML以 Postgres 为数据与计算的双重提供者PostgresML 采取数据中心data-centric路线让 Postgres 同时承担存储与计算。ML 算法直接运行在数据库进程内部与数据库共享内存通过指针直接访问数据避免了数据密集型机器学习中最常见的序列化与网络传输开销。Rust 是这一路线的重要选择——它的内存安全特性显著降低了在大而复杂的内存空间中兼顾稳定性与高性能的难度。这条路线唯一的代价是它需要一个 Postgres 数据库来承载被处理的数据。在 pgml-extension/src/api.rs 中可以看到这种进程内设计在 SQL 层面的呈现——transform被声明为#[pg_extern(immutable, parallel_safe, name transform)]是一个可并行、纯函数式的数据库函数其完整签名为taskJsonB任务与模型描述argsJsonB默认{}推理参数如deviceinputsArraystr默认ARRAY[]::TEXT[]待处理输入cachebool默认false缓存开关源码注释标明缓存实际由 Python 侧维护此参数仅为 API 兼容保留。为了水平扩展推理能力PostgresML 团队还开发了PgCat来把工作负载分发到多个 Postgres 数据库上。用分片sharding与复制replication两种策略同时扩展计算与存储——对一个低延迟、高可用的特征存储feature store来说这通常是 ML 应用中最棘手的运维难题也是 PostgresML 架构选择的首要驱动因素。PgCat 的文档与配置示例可见于 pgml-cms/docs/open-source/pgcat。MindsDB一个带 SQL 风格 API 的 Python 微服务MindsDB 走的是服务导向service-oriented路线它是一个相当标准的 Python 微服务架构通过网络连接各类数据库把数据与计算在网络两端分离——只不过它提供的接口是看起来像 SQL的命令而不是 gRPC 或 REST。它接收来自特定客户端如psql的伪 SQL解析这些命令用于配置数据库连接或执行机器学习这些命令通常带一个子查询而子查询实际会从已配置的数据库通过网络拉取数据用于训练与推理。所以严格来说MindsDB 根本不是数据库而是一个为 Python 能连上的几乎所有数据库提供适配器的 ML 服务。它的优势是生态兼容面广代价则是引入了数据先从数据库搬到服务进程这条必经之路以及一个用 Python 实现的、可能成为单点瓶颈的 ML 计算服务。分片、复制这类规模化能力MindsDB 留给采用者自行解决。实测基准同一个模型同一条数据两种架构的差距有多大作者指出一个前置事实此前 PostgresML 与 Python 微服务架构的对比评测显示PostgresML 比做同样事情的 Python 微服务架构快 840 倍即便后者使用了 Redis 之类的专用内存数据库——网络传输与数据序列化正是数据密集型 ML 算法的两大主要成本。由于 MindsDB 本身不提供数据库作者设计了一个合成基准数据不存放在数据库里而是直接作为查询的一部分传入虽然SQL ML的意义恰恰在于使用库内存储的数据但这种设计能抵消 MindsDB 通常要付出的网络序列化与传输成本把对比焦点完全放在 Python 与 Rust 实现本身的性能差异上。PostgresML一条 SQL 搞定情感分析连接本地 Postgres 服务器psql postgres://postgres:password127.0.0.1:5432安装扩展后无需任何额外设置直接调用pgml.transform函数把待分析文本作为inputs数组传入并用task指定模型SELECT pgml.transform( inputs ARRAY[ I am so excited to benchmark deep learning models in SQL. I can not wait to see the results! ], task { task: text-classification, model: cardiffnlp/twitter-roberta-base-sentiment }::JSONB );结果首次运行耗时4769.337 ms其中主要是模型下载与加载positivity[{label: LABEL_2, score: 0.990081250667572}]首次运行transform时PostgresML 会从 Hugging Face 下载该预训练 transformer 并加载进 RAM如果有 GPU 则加载进 VRAM所以花了约 5 秒。模型缓存后再次调用同一个模型SELECT pgml.transform( inputs ARRAY[ I dont really know if 5 seconds is fast or slow for deep learning. How much time is spent downloading vs running the model? ], task { task: text-classification, model: cardiffnlp/twitter-roberta-base-sentiment }::JSONB );缓存后耗时骤降至45.094 ms输出transform[{label: LABEL_1, score: 0.49658918380737305}]45ms 低于人类感知阈值——这意味着可以用这类深度学习模型构建感觉即时响应的交互式应用。缓存机制在源码中有直接体现transformers.py 用__cache_transform_pipeline_by_task字典以任务键缓存已构造的 pipelinetransform函数按排序后的 task 键命中缓存后直接复用同文件transform函数约 L482-L500。GPU 与 CPU 的对比PostgresML 会自动使用可用的 GPU。本测试机器配备 NVIDIA RTX 3090通过给 task JSON 增加device: cpu可强制走 CPUSELECT pgml.transform( inputs ARRAY[ Are GPUs really worth it? Sometimes they are more expensive than the rest of the computer combined. ], task { task: text-classification, model: cardiffnlp/twitter-roberta-base-sentiment, device: cpu }::JSONB );CPU 耗时165.036 ms输出transform[{label: LABEL_0, score: 0.7333963513374329}]GPU45ms比 24 核 i9-13900K165ms快约 4 倍。设备选择的自动化逻辑同样可以在源码中找到transformers.py 的ensure_device函数会在 task 未指定device/device_map时自动探测torch.cuda.is_available()可用则按进程号轮询分配到cuda:pid % 设备数否则回退到cpu。理解模型输出标签语义不能想当然细心的读者会发现三次输入的文本情绪逐次走低模型输出也从LABEL_2依次变为LABEL_1、LABEL_0。cardiffnlp/twitter-roberta-base-sentiment的标签含义需查阅模型官方 README 确认0 - Negative负面1 - Neutral中性2 - Positive正面模型确实捕捉到了文本热情递减的趋势——不仅 GPU 上够快结果也足够准确。另一个值得注意的模型质量问题是该模型基于推文训练而测试输入被有意设计成与推文长度和复杂度相当。模型未必总能很好地泛化到全新形态的输入因此在挑选与验证模型输出质量时先阅读模型文档总是必要的。MindsDB同一模型的对照实验MindsDB 的搭建比只要一个数据库多出不少步骤。在同一台机器、同一模型、同一版本下运行python -m mindsdb --api postgres然后用 Postgres 客户端连接这个 Python 服务注意端口是 55432与本地 Postgres 不同psql postgres://mindsdb:123127.0.0.1:55432开启计时\timing on先创建模型耗时277.722 ms随后后台任务下载并初始化模型日志显示约 4 秒但作者无法精确获得模型变为status: complete的时刻CREATE MODEL mindsdb.sentiment_classifier PREDICT sentiment USING engine huggingface, task text-classification, model_name cardiffnlp/twitter-roberta-base-sentiment, input_column text, labels [negativ, neutral, positive];注意这个 pseudo-SQL 需要用户显式配置engine、model_name、input_column、labels等一堆参数模型必须注册成一张虚拟表才能查询。接下来用与 PostgresML 相同输入做预测耗时741.650 msSELECT * FROM mindsdb.sentiment_classifier WHERE text I am so excited to benchmark deep learning models in SQL. I can not wait to see the results!结果MindsDB 复用了用户提供的可读标签——包括negativ这个拼写错误——并默认返回全部三个分数加上原始输入sentimentsentiment_explaintextpositive{positive: 0.990081250667572, neutral: 0.008058485575020313, negativ: 0.0018602772615849972}I am so excited to benchmark deep learning models in SQL. I can not wait to see the results!尝试只返回标签、去掉sentiment_explain以提速耗时841.936 ms反而更慢SELECT sentiment FROM mindsdb.sentiment_classifier WHERE text I am so excited to benchmark deep learning models in SQL. I can not wait to see the results!sentimentpositive说明瓶颈不在sentiment_explain。作者花费数小时调试并深入了解了 MindsDB 的内部 Python 服务架构后确认了两件事GPU 未生效虽然服务启动时 Python 内部torch.cuda.is_available()返回True但nvidia-smi从未观察到 Python 进程使用 GPU。MindsDB 官方声称支持 GPU但作者未能在文档或代码中找到它不能开箱即用的说明只能合理假定这是一次纯 CPU 基准。多进程 JSON 序列化是主要开销Python 的 GIL 会损害并行性MindsDB 团队因此巧妙地构建了可并行运行多个 Python 进程的服务——这对扩展有利但代价是查询先被序列化为 JSON 发给 workerworker 真正运行模型后再把结果以 JSON 返回父进程。这大约就是 5 倍性能差距的来源。结果汇总更大的模型差距越小但交互场景差距显著taskmodelMindsDBPostgresML CPUPostgresML GPUtext-classificationcardiffnlp/twitter-roberta-base-sentiment74116545translation_en_to_est5-base15731148294summarizationsshleifer/distilbart-cnn-12-642893450479单位为毫秒。PostgresML 数据为缓存后的单次推理耗时MindsDB 数据为作者实测。存在一个普遍规律模型越大越慢花费在 libtorch 内部的时间占比越高其余部分传输、解析、调度的性能差异就越被稀释但对于交互式模型与交互式用例差距依然显著。作者强调上述对比已经尽可能选了对 MindsDB 最有利的场景——如果改用 XGBoost 等经典算法PostgresML 中可达到亚毫秒级预测MindsDB 仅解析传入查询就需要约 20ms 的 Python 服务开销差距将放大到数百倍。此外PostgresML 以更宽松的函数式 API支持更多模型Hugging Face 上模型输出结构千差万别作者尝试了多个 MindsDB 文档未列出的模型均在创建时报错而 PostgresML 直接透传模型的原始输出、不做结构重排因此能容纳更多差异——代价是输出格式需要终端用户自行解析。云部署对比托管的是数据库还是仅仅一个推理服务把这类服务部署起来本身就相当费力规模化运维更是长期投入。两家都提供云版本差异同样源于架构路线MindsDB可在 AWS Marketplace 上基于自有的硬件实例运行可通过 Web UI 横向扩展并配置数据源体验与本地安装类似。但数据源方案与机器学习工作负载的扩展仍需用户自行解决——云上它依然只是一个推理服务不附带数据库。PostgresML以全托管数据库服务形式提供包含大规模 ML 部署所需的存储、备份、监控指标与通过 PgCat 实现的扩展能力。端到端机器学习很少只是跑模型更多时候难在围绕模型的数据管道扩展与数据基础设施管理——这正是 PostgresML 的服务优势所在。结论与选型建议综合全部对比可以得出三条可操作的结论追求端到端单查询能力选择 PostgresML它能用一条 SQL 完成Embedding 生成 → 向量检索 → 经典算法/LLM 推理的复合流程相关构建器见 vector_search_query_builder.rs而 MindsDB 需要额外的数据搬运与微服务编排。追求吞吐与成本选择 PostgresML进程内数据访问消除了序列化与网络开销实测快 316 倍GPU 开箱即用ensure_device自动探测经典算法可达亚毫秒级。警惕伪 SQL的认知成本MindsDB 需要学习其专有的CREATE MODEL ... USING engine...语法体系与模型注册流程且模型支持滞后于 Hugging Face 发布节奏PostgresML 则直接暴露标准 SQL 函数。附PostgresML 相关运行时配置仓库实证若自行部署 PostgresML 扩展可在 packages/postgresml/etc/postgresml/postgresml.conf 找到参考配置shared_preload_libraries pgml,pg_stat_statements pgml.venv /var/lib/postgresml-python/pgml-venv与 Hugging Face 模型安全相关的 GUC 参数定义于 pgml-extension/src/config.rs并在 whitelist.rs 的verify_task中执行校验pgml.huggingface_whitelist允许从 Hugging Face 下载的模型清单逗号分隔为空则不限pgml.huggingface_trust_remote_code是否允许模型执行远程代码默认falsepgml.huggingface_trust_remote_code_whitelist允许执行远程代码的模型清单pgml.omp_num_threads底层 OpenMP 库使用的线程数默认 1仅接受正整数。这层白名单机制在transform的每个入口api.rs都会被调用是部署中值得关注的安全加固点。赞分享后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载相关推荐Python Video Stabilization未来展望计算机视觉技术的创新应用Python Video Stabilization未来展望计算机视觉技术的创新应用 Python Video Stabilization是一款基于OpenC使用 mindsdb-execute-sql 工具通过 MCP Toolbox 在 MindsDB 联邦数据库上执行 SQL使用 mindsdb execute sql 工具通过 MCP Toolbox 在 MindsDB 联邦数据库上执行 SQL 本文聚焦 MCP ToolboxMCP 服务数据库后端AI 应用终极指南如何在Apache Doris中直接运行TensorFlow模型实现机器学习实战终极指南如何在Apache Doris中直接运行TensorFlow模型实现机器学习实战 Apache Doris是一款简单易用、高性能的统一分析型数据库它OLAP数据库大数据实时分析上一篇Waydroid终极指南在Linux系统上无缝运行Android应用的容器化解决方案下一篇如何彻底告别重复图片困扰AntiDupl.NET开源去重工具终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MindsDB vs PostgresML：两条在 SQL 数据库中运行机器学习的技术路线实测对比
后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载导读本文基于 PostgresML 官方博客《MindsDB vs PostgresML》Montana Low2023 年 6 月整理扩充围绕如何用 SQL 接口在数据库中运行机器学习算法这一核心命题从算法能力、系统架构、端到端基准测试、云端部署四个维度对MindsDB与PostgresML两条完全不同的实现路线进行逐项对比。读完本文你将掌握pgml.transform的完整调用方式、两种架构各自的技术取舍以及为什么数据访问方式的差异最终会转化为 316 倍的推理性能差距。为什么拿 MindsDB 与 PostgresML 做对比市面上有很多在 SQL 数据库中做机器学习的方案但绝大多数只是给机器学习套了一个 SQL 外壳数据与计算仍然被网络分隔。MindsDB 与 PostgresML 是其中两个有代表性的开源项目它们都试图为机器学习算法及其所需数据提供 SQL 接口但底层思路截然不同。这篇对比文章的直接答案是PostgresML 更有主见opinionated、更易横向扩展、能力更全且实测快数倍而 MindsDB 的资历更老按项目年龄和 GitHub Star 数计算其成熟度约为 PostgresML 的 5 倍。当社区反复追问PostgresML 和 MindsDB 到底有什么区别时作者决定用一整篇长文把推理过程完整摊开让读者自行判断结论是否公允。第一眼对比定位、许可证与实现语言MindsDBPostgresML项目年龄5 年1 年许可证GPL-3.0MIT实现语言PythonRust两者都是开源项目但许可约束不同PostgresML 采用更宽松的MIT 许可证而 MindsDB 使用GPL-3.0。更重要的是实现语言的差异——作者刻意用了两个介词来强调MindsDB 是用 Python 实现inPython一种带运行时的语言PostgresML 是用 Rust 实现withRust一种编译型、无需独立运行时的语言。这个语言选择会在后文的架构与性能对比中反复兑现成可测量的结果。算法能力对比经典算法之外数据库能力才是分水岭两个项目都集成了几十种经典机器学习算法包括来自 Hugging Face 的最新 LLMMindsDBPostgresML分类 Classification✅✅回归 Regression✅✅时间序列 Time Series✅✅LLM 支持✅✅Embeddings-✅向量支持 Vector-✅全文搜索-✅地理空间搜索-✅在经典机器学习算法分类、回归、时间序列上两者能力相当也都通过底层 libtorch 支持从 Hugging Face 加载模型。但作者在文中对 MindsDB 的 LLM 支持做了一个重要的划掉修正原文the latest LLMsPostgresML 只要能满足底层依赖就可以立即使用新发布的模型而 MindsDB 必须等官方发布更新版本才能支持新模型其当前支持的模型范围非常有限。新算法、新任务、新模型在持续涌现具体支持清单应以各自最新文档为准。真正拉开差距的是表格后半部分。PostgresML 额外支持Embedding 模型并把向量检索深度集成进数据库内部——这超出了 MindsDB 的能力边界因为MindsDB 本身根本不是数据库。PostgresML 还能直接使用其他 Postgres 扩展的全部能力借助 pgvector 的向量索引实现高效的 KNN/ANN 向量召回借助 PostGIS 处理地理空间信息并内置全文搜索。多个算法与扩展可以组合进同一条复合查询用单条 SQL 构建端到端系统——例如搜索推荐、欺诈检测——而在传统架构里这往往需要十几个不同的机器学习模型和微服务协作才能完成。在仓库源码中可以印证这种以数据库为计算中心的设计向量搜索的完整实现位于 pgml-sdks/pgml/src/vector_search_query_builder.rsEmbedding 生成则通过 pgml-extension/src/bindings/transformers/transformers.py 中的embed函数基于SentenceTransformer与rank函数基于CrossEncoder实现并在 pgml-extension/src/api.rs 中暴露为 SQL 可调用的pgml.embed/pgml.rank接口。架构对比数据与计算在同一进程还是隔着一层网络两个项目在架构实现上差异巨大这决定了它们后续所有性能与运维特性的走向MindsDBPostgresML数据访问方式网络传输over the wire进程内in process多进程支持✅✅数据库-✅复制 Replication-✅分片 Sharding-✅云托管✅✅本地部署✅✅Web UI✅✅PostgresML以 Postgres 为数据与计算的双重提供者PostgresML 采取数据中心data-centric路线让 Postgres 同时承担存储与计算。ML 算法直接运行在数据库进程内部与数据库共享内存通过指针直接访问数据避免了数据密集型机器学习中最常见的序列化与网络传输开销。Rust 是这一路线的重要选择——它的内存安全特性显著降低了在大而复杂的内存空间中兼顾稳定性与高性能的难度。这条路线唯一的代价是它需要一个 Postgres 数据库来承载被处理的数据。在 pgml-extension/src/api.rs 中可以看到这种进程内设计在 SQL 层面的呈现——transform被声明为#[pg_extern(immutable, parallel_safe, name transform)]是一个可并行、纯函数式的数据库函数其完整签名为taskJsonB任务与模型描述argsJsonB默认{}推理参数如deviceinputsArraystr默认ARRAY[]::TEXT[]待处理输入cachebool默认false缓存开关源码注释标明缓存实际由 Python 侧维护此参数仅为 API 兼容保留。为了水平扩展推理能力PostgresML 团队还开发了PgCat来把工作负载分发到多个 Postgres 数据库上。用分片sharding与复制replication两种策略同时扩展计算与存储——对一个低延迟、高可用的特征存储feature store来说这通常是 ML 应用中最棘手的运维难题也是 PostgresML 架构选择的首要驱动因素。PgCat 的文档与配置示例可见于 pgml-cms/docs/open-source/pgcat。MindsDB一个带 SQL 风格 API 的 Python 微服务MindsDB 走的是服务导向service-oriented路线它是一个相当标准的 Python 微服务架构通过网络连接各类数据库把数据与计算在网络两端分离——只不过它提供的接口是看起来像 SQL的命令而不是 gRPC 或 REST。它接收来自特定客户端如psql的伪 SQL解析这些命令用于配置数据库连接或执行机器学习这些命令通常带一个子查询而子查询实际会从已配置的数据库通过网络拉取数据用于训练与推理。所以严格来说MindsDB 根本不是数据库而是一个为 Python 能连上的几乎所有数据库提供适配器的 ML 服务。它的优势是生态兼容面广代价则是引入了数据先从数据库搬到服务进程这条必经之路以及一个用 Python 实现的、可能成为单点瓶颈的 ML 计算服务。分片、复制这类规模化能力MindsDB 留给采用者自行解决。实测基准同一个模型同一条数据两种架构的差距有多大作者指出一个前置事实此前 PostgresML 与 Python 微服务架构的对比评测显示PostgresML 比做同样事情的 Python 微服务架构快 840 倍即便后者使用了 Redis 之类的专用内存数据库——网络传输与数据序列化正是数据密集型 ML 算法的两大主要成本。由于 MindsDB 本身不提供数据库作者设计了一个合成基准数据不存放在数据库里而是直接作为查询的一部分传入虽然SQL ML的意义恰恰在于使用库内存储的数据但这种设计能抵消 MindsDB 通常要付出的网络序列化与传输成本把对比焦点完全放在 Python 与 Rust 实现本身的性能差异上。PostgresML一条 SQL 搞定情感分析连接本地 Postgres 服务器psql postgres://postgres:password127.0.0.1:5432安装扩展后无需任何额外设置直接调用pgml.transform函数把待分析文本作为inputs数组传入并用task指定模型SELECT pgml.transform( inputs ARRAY[ I am so excited to benchmark deep learning models in SQL. I can not wait to see the results! ], task { task: text-classification, model: cardiffnlp/twitter-roberta-base-sentiment }::JSONB );结果首次运行耗时4769.337 ms其中主要是模型下载与加载positivity[{label: LABEL_2, score: 0.990081250667572}]首次运行transform时PostgresML 会从 Hugging Face 下载该预训练 transformer 并加载进 RAM如果有 GPU 则加载进 VRAM所以花了约 5 秒。模型缓存后再次调用同一个模型SELECT pgml.transform( inputs ARRAY[ I dont really know if 5 seconds is fast or slow for deep learning. How much time is spent downloading vs running the model? ], task { task: text-classification, model: cardiffnlp/twitter-roberta-base-sentiment }::JSONB );缓存后耗时骤降至45.094 ms输出transform[{label: LABEL_1, score: 0.49658918380737305}]45ms 低于人类感知阈值——这意味着可以用这类深度学习模型构建感觉即时响应的交互式应用。缓存机制在源码中有直接体现transformers.py 用__cache_transform_pipeline_by_task字典以任务键缓存已构造的 pipelinetransform函数按排序后的 task 键命中缓存后直接复用同文件transform函数约 L482-L500。GPU 与 CPU 的对比PostgresML 会自动使用可用的 GPU。本测试机器配备 NVIDIA RTX 3090通过给 task JSON 增加device: cpu可强制走 CPUSELECT pgml.transform( inputs ARRAY[ Are GPUs really worth it? Sometimes they are more expensive than the rest of the computer combined. ], task { task: text-classification, model: cardiffnlp/twitter-roberta-base-sentiment, device: cpu }::JSONB );CPU 耗时165.036 ms输出transform[{label: LABEL_0, score: 0.7333963513374329}]GPU45ms比 24 核 i9-13900K165ms快约 4 倍。设备选择的自动化逻辑同样可以在源码中找到transformers.py 的ensure_device函数会在 task 未指定device/device_map时自动探测torch.cuda.is_available()可用则按进程号轮询分配到cuda:pid % 设备数否则回退到cpu。理解模型输出标签语义不能想当然细心的读者会发现三次输入的文本情绪逐次走低模型输出也从LABEL_2依次变为LABEL_1、LABEL_0。cardiffnlp/twitter-roberta-base-sentiment的标签含义需查阅模型官方 README 确认0 - Negative负面1 - Neutral中性2 - Positive正面模型确实捕捉到了文本热情递减的趋势——不仅 GPU 上够快结果也足够准确。另一个值得注意的模型质量问题是该模型基于推文训练而测试输入被有意设计成与推文长度和复杂度相当。模型未必总能很好地泛化到全新形态的输入因此在挑选与验证模型输出质量时先阅读模型文档总是必要的。MindsDB同一模型的对照实验MindsDB 的搭建比只要一个数据库多出不少步骤。在同一台机器、同一模型、同一版本下运行python -m mindsdb --api postgres然后用 Postgres 客户端连接这个 Python 服务注意端口是 55432与本地 Postgres 不同psql postgres://mindsdb:123127.0.0.1:55432开启计时\timing on先创建模型耗时277.722 ms随后后台任务下载并初始化模型日志显示约 4 秒但作者无法精确获得模型变为status: complete的时刻CREATE MODEL mindsdb.sentiment_classifier PREDICT sentiment USING engine huggingface, task text-classification, model_name cardiffnlp/twitter-roberta-base-sentiment, input_column text, labels [negativ, neutral, positive];注意这个 pseudo-SQL 需要用户显式配置engine、model_name、input_column、labels等一堆参数模型必须注册成一张虚拟表才能查询。接下来用与 PostgresML 相同输入做预测耗时741.650 msSELECT * FROM mindsdb.sentiment_classifier WHERE text I am so excited to benchmark deep learning models in SQL. I can not wait to see the results!结果MindsDB 复用了用户提供的可读标签——包括negativ这个拼写错误——并默认返回全部三个分数加上原始输入sentimentsentiment_explaintextpositive{positive: 0.990081250667572, neutral: 0.008058485575020313, negativ: 0.0018602772615849972}I am so excited to benchmark deep learning models in SQL. I can not wait to see the results!尝试只返回标签、去掉sentiment_explain以提速耗时841.936 ms反而更慢SELECT sentiment FROM mindsdb.sentiment_classifier WHERE text I am so excited to benchmark deep learning models in SQL. I can not wait to see the results!sentimentpositive说明瓶颈不在sentiment_explain。作者花费数小时调试并深入了解了 MindsDB 的内部 Python 服务架构后确认了两件事GPU 未生效虽然服务启动时 Python 内部torch.cuda.is_available()返回True但nvidia-smi从未观察到 Python 进程使用 GPU。MindsDB 官方声称支持 GPU但作者未能在文档或代码中找到它不能开箱即用的说明只能合理假定这是一次纯 CPU 基准。多进程 JSON 序列化是主要开销Python 的 GIL 会损害并行性MindsDB 团队因此巧妙地构建了可并行运行多个 Python 进程的服务——这对扩展有利但代价是查询先被序列化为 JSON 发给 workerworker 真正运行模型后再把结果以 JSON 返回父进程。这大约就是 5 倍性能差距的来源。结果汇总更大的模型差距越小但交互场景差距显著taskmodelMindsDBPostgresML CPUPostgresML GPUtext-classificationcardiffnlp/twitter-roberta-base-sentiment74116545translation_en_to_est5-base15731148294summarizationsshleifer/distilbart-cnn-12-642893450479单位为毫秒。PostgresML 数据为缓存后的单次推理耗时MindsDB 数据为作者实测。存在一个普遍规律模型越大越慢花费在 libtorch 内部的时间占比越高其余部分传输、解析、调度的性能差异就越被稀释但对于交互式模型与交互式用例差距依然显著。作者强调上述对比已经尽可能选了对 MindsDB 最有利的场景——如果改用 XGBoost 等经典算法PostgresML 中可达到亚毫秒级预测MindsDB 仅解析传入查询就需要约 20ms 的 Python 服务开销差距将放大到数百倍。此外PostgresML 以更宽松的函数式 API支持更多模型Hugging Face 上模型输出结构千差万别作者尝试了多个 MindsDB 文档未列出的模型均在创建时报错而 PostgresML 直接透传模型的原始输出、不做结构重排因此能容纳更多差异——代价是输出格式需要终端用户自行解析。云部署对比托管的是数据库还是仅仅一个推理服务把这类服务部署起来本身就相当费力规模化运维更是长期投入。两家都提供云版本差异同样源于架构路线MindsDB可在 AWS Marketplace 上基于自有的硬件实例运行可通过 Web UI 横向扩展并配置数据源体验与本地安装类似。但数据源方案与机器学习工作负载的扩展仍需用户自行解决——云上它依然只是一个推理服务不附带数据库。PostgresML以全托管数据库服务形式提供包含大规模 ML 部署所需的存储、备份、监控指标与通过 PgCat 实现的扩展能力。端到端机器学习很少只是跑模型更多时候难在围绕模型的数据管道扩展与数据基础设施管理——这正是 PostgresML 的服务优势所在。结论与选型建议综合全部对比可以得出三条可操作的结论追求端到端单查询能力选择 PostgresML它能用一条 SQL 完成Embedding 生成 → 向量检索 → 经典算法/LLM 推理的复合流程相关构建器见 vector_search_query_builder.rs而 MindsDB 需要额外的数据搬运与微服务编排。追求吞吐与成本选择 PostgresML进程内数据访问消除了序列化与网络开销实测快 316 倍GPU 开箱即用ensure_device自动探测经典算法可达亚毫秒级。警惕伪 SQL的认知成本MindsDB 需要学习其专有的CREATE MODEL ... USING engine...语法体系与模型注册流程且模型支持滞后于 Hugging Face 发布节奏PostgresML 则直接暴露标准 SQL 函数。附PostgresML 相关运行时配置仓库实证若自行部署 PostgresML 扩展可在 packages/postgresml/etc/postgresml/postgresml.conf 找到参考配置shared_preload_libraries pgml,pg_stat_statements pgml.venv /var/lib/postgresml-python/pgml-venv与 Hugging Face 模型安全相关的 GUC 参数定义于 pgml-extension/src/config.rs并在 whitelist.rs 的verify_task中执行校验pgml.huggingface_whitelist允许从 Hugging Face 下载的模型清单逗号分隔为空则不限pgml.huggingface_trust_remote_code是否允许模型执行远程代码默认falsepgml.huggingface_trust_remote_code_whitelist允许执行远程代码的模型清单pgml.omp_num_threads底层 OpenMP 库使用的线程数默认 1仅接受正整数。这层白名单机制在transform的每个入口api.rs都会被调用是部署中值得关注的安全加固点。赞分享后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载相关推荐Python Video Stabilization未来展望计算机视觉技术的创新应用Python Video Stabilization未来展望计算机视觉技术的创新应用 Python Video Stabilization是一款基于OpenC使用 mindsdb-execute-sql 工具通过 MCP Toolbox 在 MindsDB 联邦数据库上执行 SQL使用 mindsdb execute sql 工具通过 MCP Toolbox 在 MindsDB 联邦数据库上执行 SQL 本文聚焦 MCP ToolboxMCP 服务数据库后端AI 应用终极指南如何在Apache Doris中直接运行TensorFlow模型实现机器学习实战终极指南如何在Apache Doris中直接运行TensorFlow模型实现机器学习实战 Apache Doris是一款简单易用、高性能的统一分析型数据库它OLAP数据库大数据实时分析上一篇Waydroid终极指南在Linux系统上无缝运行Android应用的容器化解决方案下一篇如何彻底告别重复图片困扰AntiDupl.NET开源去重工具终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考