InfoQ

AlloyDB Ships Proxy Models That Replace LLM Calls with Local Inference inside the Database

6.9内容质量
AlloyDB Ships Proxy Models That Replace LLM Calls with Local Inference inside the Database

TL;DR · AI 摘要

AlloyDB Ships Proxy Models That Replace LLM Calls with Local Inference inside the Database - InfoQ InfoQ Homepage News A...

核心要点

  • 主题聚焦：AlloyDB Ships Proxy Models That Replace LLM Call
  • 来源：InfoQ，建议结合原文判断细节。
  • AI 分析暂不可用，本条为保底评分与摘要。
#AI#编程#后端#云计算#安全
打开原文

AlloyDB 发布代理模型，可在数据库内部用本地推理替代 LLM 调用 - InfoQ

InfoQ 首页 News AlloyDB 发布代理模型，可在数据库内部用本地推理替代 LLM 调用

云

InfoQ AI 工程师认证（7 月 25 日）：AI 演示已成功运行。现在需要确保其可靠性。

AlloyDB 发布代理模型，可在数据库内部用本地推理替代 LLM 调用

7 月 9 日，2026 年 3 分钟阅读

作者：

  • Steef-Jan Wiggers

#### 关注我们

YouTube

232K 粉丝

LinkedIn

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 点赞

Bluesky

收听本文 -

0:00

音频准备就绪

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

  • 阅读列表

谷歌最近宣布 AlloyDB AI 功能正式上线（GA），同时推出两项彻底改变数据库与大语言模型（LLM）交互方式的加速技术。

根据谷歌内部测试结果，智能批处理相比逐行处理的吞吐量提升了 2400 倍，而优化后的代理模型更将这一数字推高至 23000 倍，同时成本降低了 6000 倍。尽管这些亮眼的数字值得工程团队深入研究，但底层的代理模型架构才是从业者需要重点关注的核心。

借助 AlloyDB AI 功能，开发者可以直接在标准 SQL 查询中调用 LLM。GA 版本包含 ai.generate（文本生成）、ai.if（语义过滤）、ai.rank（语义重排序）、ai.forecast（时间序列预测）以及三个新增功能：

  • ai.summarize
  • ai.agg_summarize（分组摘要）
  • ai.analyze_sentiment（情感分析）

由于这些功能作为标准 SQL 操作符执行，查询可以基于语义而非严格关键词匹配来过滤行。

按行调用 LLM 的问题在规模扩大时显而易见：一个包含 10 万产品的表格意味着需要向 Vertex AI 发送 10 万次往返请求，每次都要携带相同的系统提示，等待模型推理，并产生每 token 的成本。两个加速层解决了这个问题。

智能批处理（目前支持 ai.if 和 ai.rank）将多行数据合并为单次模型调用。AlloyDB 不再为每行数据发送系统提示，而是仅发送一次并批量处理数据。谷歌内部测试显示，每秒可处理高达 1 万行数据，相比逐行处理基线提升了 2400 倍。该技术简单直接，对于每行负载相对于提示较小的工作负载，这种提升是可信的。

代理模型是更具架构意义的突破。对于 ai.if 查询（目前处于预览阶段），AlloyDB 引入了两阶段工作流：

code
-- 第一阶段：使用数据样本和前沿 LLM 训练本地代理模型

PREPARE underwater_suitability_proxy FROM
SELECT description FROM products;

-- 第二阶段：使用本地代理模型以数据库速度执行查询

SELECT * FROM products
WHERE ai.if(description, 'suitable for underwater use deeper than 60 meters')
USING proxy(underwater_suitability_proxy);

首先，PREPARE 语句会将你的数据样本发送给前沿模型，并利用结果在数据库内部训练一个轻量级本地模型。随后，EXECUTE 会通过本地代理执行查询，而不是调用外部 LLM。当代理的置信度过低或没有可用训练模型时，AlloyDB 会回退到前沿模型。Google 报告称，采用此方法可实现每秒处理 100,000 行数据的吞吐量。

代理模型模式颠覆了数据库与 LLM 之间的常规关系。数据库不再是每次决策都调用外部模型的客户端，而是通过学习模型在样本上的判断，以数据库速度在本地应用该判断的学生角色。LLM 则转变为教师角色，而非运行时依赖。

这种模式的影响不仅限于 AlloyDB。任何需要为每行数据调用外部模型的数据库都会面临相同的成本和延迟瓶颈。问题在于竞争对手（如 Aurora、Azure SQL、CockroachDB、PlanetScale）是否会采用类似的查询时蒸馏方法，还是会让用户在应用代码中构建此类逻辑。

从业者应注意 Google 官方声明中的注意事项：23,000 倍和 6,000 倍的数字来自内部测试，仅适用于预览版的 ai.if，不能代表所有 AI 功能的通用性能。优化后的代理模型尚未正式发布（GA）。评估 AlloyDB 用于生产 AI 工作负载的团队应在提交前，使用自己的数据分布和查询模式进行基准测试。

Starburst 架构师 Raimundas Juodvalkis 在 LinkedIn 上给出了实用的框架建议：

将其视为受控的数据库扩展，而非神奇的 WHERE 子句。

他建议在将模型衍生字段写回核心系统前，先从以读取为主的审核工作流开始，并将模型成本与查询成本分开跟踪。

此次发布还包含 AlloyDB 的托管 MCP 服务器，使 AI 代理可通过 Model Context Protocol 查询数据库内容，而无需团队自行运行和扩展 MCP 基础设施。结合 Google 的 ScaNN 索引（最多支持 100 亿向量）现有向量搜索功能，AlloyDB 正在定位为一个兼容 PostgreSQL 的数据库，其结构化查询、语义搜索和 LLM 驱动分析可在同一 SQL 层共存。

AlloyDB AI 功能现已在 PostgreSQL 17 实例上正式发布。ai.if 和 ai.rank 的智能批处理功能已正式发布（GA）。ai.if 的优化代理模型处于预览阶段。AI 功能加速需要设置数据库标志（google_ml_integration.enable_ai_function_acceleration），默认未启用。

关于作者

作者信息

#### Steef-Jan Wiggers

显示更多

显示更少

#### 本文属于云技术主题

##### 相关主题：

  • 开发
  • 架构与设计
  • DevOps
  • 人工智能、机器学习与数据工程
  • AI 架构
  • Google Cloud Platform
  • 云技术
  • 数据库
  • 相关编辑内容
  • 相关赞助商 为什么 API 无法信任客户端——以及如何弥合这一差距
  • 相关赞助商 测试。保护。重复。Guardsquare 将移动应用测试与保护相结合，实现最大安全性且无性能折损。请求报价

InfoQ 新闻通讯

每周五汇总 InfoQ 最新内容，每 Tuesday 发送。加入超过 250,000 名高级开发者的社区。查看示例

我们保护您的隐私。