📰 AI 资讯

AlloyDB 推出代理模型，用数据库本地推理替代外部大模型调用

2026-07-14 16:00

谷歌<a href="https://cloud.google.com/blog/products/databases/boost-performance-and-lower-costs-with-alloydb-ai-functions" title data-type="link">最近宣布</a> <a href="https://docs.cloud.google.com/alloydb/docs/ai/ai-query-engine-landing" title data-type="link">AlloyDB AI 函数</a>正式可用，同时推出了两项从根本上改变数据库与大语言模型交互方式的加速技术。谷歌内部测试数据显示，智能批处理相比逐行处理吞吐量提升了 2400 倍，而优化后的代理模型的吞吐量提升幅度可达 23000 倍，同时成本降低至原来的 1/6000。这些亮眼的核心数据值得研发人员细致核验，但从业者更应关注其底层代理模型架构。借助 AlloyDB AI 函数，开发者可以直接在标准 SQL 查询中调用 LLM。此次 GA 版本包含 ai.generate（文本生成）、ai.if（语义过滤）、ai.rank（语义重排序）、ai.forecast（时序预测）以及三项新功能：<ul data-type="bulletedlist"><li data-type="listitem">ai.summarize（摘要）</li><li data-type="listitem">ai.agg_summarize（分组摘要）</li><li data-type="listitem">ai.analyze_sentiment（情感分析）</li></ul>由于这些函数以标准 SQL 运算符形式运行，查询可基于语义含义筛选数据行，而非局限于生硬的关键词精确匹配。大规模场景下逐行调用大语言模型的弊端十分明显：一张包含十万条商品数据的表，就要向 Vertex AI 发起十万次往返请求，每次请求都携带相同的系统提示词、等待模型推理，还会产生按词元计费的开销。两层加速机制解决了这一问题。现已支持 ai.if 与 ai.rank 函数的智能批处理功能，可将多条数据行合并为单次模型调用。AlloyDB 无需为每行数据重复发送系统提示词，仅发送一次提示词，再对数据做批量处理。谷歌内部测试显示，该方案最高可实现每秒处理一万行数据，较逐行处理基准性能提升 2400 倍。这项技术本身并不复杂，在单条数据载荷远小于提示词的业务负载场景中，性能提升效果真实可靠。代理模型是架构层面更具突破性的改进。针对 ai.if 查询（目前处于预览版阶段），AlloyDB 采用两段式执行流程：-- 阶段1：抽取样本数据，调用云端基础大模型训练本地代理模型PREPARE underwater_suitability_proxy FROMSELECT description FROM products;-- 阶段2：依托本地代理模型，以数据库原生速度执行查询SELECT * FROM productsWHERE ai.if(description, 'suitable for underwater use deeper than 60 meters')USING proxy(underwater_suitability_proxy);复制代码首先，通过 PREPARE 语句将部分样本数据发送至前沿大模型，并利用返回结果在数据库内部训练一个轻量级本地模型；随后执行 EXECUTE 语句时会调用该本地代理模型运行查询，不再远程调用外部大语言模型。若代理模型置信度过低，或暂无可用的训练模型，AlloyDB 会自动降级回退至前沿大模型处理。谷歌测试数据显示，该方案可实现每秒处理十万行数据。代理模型模式颠覆了数据库与大语言模型传统的交互关系。数据库不再作为客户端，每一次判断都要调用外部模型，而是化身为“学生”，基于样本学习大模型的判断逻辑，随后以数据库原生运算速度在本地完成推理。大语言模型从运行时依赖转变为提供训练依据的“老师”。该架构模式的价值并不局限于 AlloyDB。所有需要逐行调用外部模型进行判断的数据库都会遭遇相同的成本与延迟瓶颈。关键问题在于，各大竞品数据库（亚马逊 Aurora、微软 Azure SQL、CockroachDB、PlanetScale）是否会采用这种查询时模型蒸馏的同类方案，还是让开发者在应用代码中自行实现这套逻辑。从业者应留意<a href="https://cloud.google.com/blog/products/databases/boost-performance-and-lower-costs-with-alloydb-ai-functions" title data-type="link">谷歌官方公告</a>中的免责声明：吞吐量提升 23000 倍、成本降低至 1/6000 这两组数据均源自内部测试结果，仅适用于预览阶段的 ai.if，并不代表所有 AI 函数的通用性能。优化后的代理模型尚未正式可用。计划选用 AlloyDB 承载生产级 AI 业务负载的团队，在敲定方案前务必基于自身真实的数据分布与查询模式进行基准性能测试。Starburst 架构师 Raimundas Juodvalkis 在 <a href="https://www.linkedin.com/posts/raimundas-juodvalkis-63b5a916_enterpriseai-aiarchitecture-dataengineering-share-7478431237833949185-Mf3G" title data-type="link">LinkedIn 上给出了务实的解读视角</a>：应当把它们视作受治理的数据库扩展能力，而不是万能的 WHERE 子句。他建议先从读密集型审核业务流程入手，再把模型生成字段写回核心系统，同时需将模型调用成本与查询成本分开统计核算。此次发布还包括一个托管的 MCP 服务器，让 AI 智能体可以通过模型上下文协议查询数据库内容，无需团队自行运行和扩展 MCP 基础设施。结合现有的向量搜索功能（使用谷歌的 ScaNN 索引，支持高达 100 亿向量），AlloyDB 正将自身打造成为一个兼容 PostgreSQL 的数据库——结构化查询、语义搜索和 LLM 驱动的分析可以在同一 SQL 层中共存。AlloyDB AI 函数已在 PostgreSQL 17 实例上<a href="https://cloud.google.com/alloydb/ai" title data-type="link">正式可用</a>。智能批处理已对 ai.if 和 ai.rank 可用。ai.if 的优化代理模型处于预览阶段。AI 函数加速需要设置数据库标志 google_ml_integration.enable_ai_function_acceleration，该功能<a href="https://docs.cloud.google.com/alloydb/docs/ai/accelerate-ai-queries" title data-type="link">默认未启用</a>。查看英文原文：<a href="https://www.infoq.com/news/2026/07/alloydb-ai-proxy-models/" title data-type="link">https://www.infoq.com/news/2026/07/alloydb-ai-proxy-models/</a>

🔗 查看原文 ↗

← 返回资讯列表