2026年2月

2026 年,智能体将在企业级应用中取得哪些实质性突破?点击下载《2026 年 AI 与数据发展预测》白皮书,获悉专家一手前瞻,抢先拥抱新的工作方式!

数据产品的概念已获得广泛关注,众多企业正纷纷构建门户或平台,以在内部共享数据与人工智能产品。过去一年中,我协助了数十家企业推进数据产品化进程,并推动其采用 Snowflake Internal Marketplace。

不出所料,不同组织在现有 IT 架构、治理要求及数据管理流程方面存在差异。这些特点影响着 Internal Marketplace 的采纳效果及其与现有流程的整合。尤其值得注意的是,面向数据与人工智能的 Internal Marketplace 是一个高度可见的组件,其涉及公司内部几乎所有与数据相关角色的参与。因此,引入 Internal Marketplace 将带来多方面的影响,并涉及众多利益相关方。为确保持续成功落地,必须对这些因素进行审慎考量。

本文探讨了架构指导原则、账户拓扑设计、数据产品合规与验证、版本管理,以及治理与权限管理等主题。

我们建议根据实际需求对 Snowflake Internal Marketplace 进行定制化配置,并分享在实施过程中涉及人员与流程维度的组织级考量建议。

若您尚未熟悉 Snowflake Internal Marketplace,建议[观看此演示视频]以了解其核心功能特性。

组织层面的考量

建立 internal marketplace 与数据产品体系不仅是技术任务,人员与流程同样是关键要素,对于推动 internal marketplace 的顺利落地至关重要。

  • 避免引入 internal marketplace 的中央数据平台团队与目标用户群体之间出现目标偏差。在规划阶段应吸纳未来数据产品所有者及使用方的代表参与,尽早并持续获取所有相关方及用户的支持与认可;

  • 确保数据产品的所有权明确(即明确各项数据的归属主体);

  • 部分数据的所有权界定可能较为清晰,可从易于确定归属的数据入手,逐步迭代并扩展范围;

  • 制定清晰的所有权职责定义,涵盖数据产品文档、治理、质量、沟通、标准、互操作性等方面。初期可设定基础职责,再随时间推移逐步完善;

  • 必须将业务数据负责人纳入数据文档、治理与质量管理的责任体系中;

  • 无需在初始阶段追求覆盖所有场景的完美方案。精细规划与分析停滞之间需把握平衡,应从“简单”场景起步,通过持续学习、迭代并渐进扩展,以敏捷方式推进 internal marketplace 的落地。

账户与配置

Snowflake Internal Marketplace 在不同团队共享单个 Snowflake 账户、使用独立账户或混合部署场景下均能有效运作。您无需预先确定固定的账户拓扑结构,该拓扑可灵活调整并随时间演进。

  • 独立账户可为各业务单元提供更强的隔离性与独立性,但需额外考虑账户管理问题。Snowflake Organization Account 能够简化多账户的统一管理与监控;

  • 若要在多区域或多云环境中使用 internal marketplace,则必须采用独立账户部署;

  • 在单账户内通过独立数据库访问数据产品时,其细粒度访问策略的定义可能与多账户场景存在差异,相关内容将在后续文章中详细探讨。

无论采用单账户还是多账户模式,我们强烈建议创建 Snowflake Organization Account,该账户为定制组织的 Snowflake Internal Marketplace 提供关键能力:

  • 为通过 Internal Marketplace 共享数据产品的不同团队/领域/部门创建用户画像;

  • 创建自定义数据产品属性,用于定义描述任意数据产品的附加字段。可指定哪些属性为必填或选填、其允许取值范围及筛选条件(此功能目前处于私有预览阶段);

  • 可创建 Snowsight Dashboard 以提供 Internal Marketplace 使用情况的概览视图,更多细节将在后文“数据产品监控”部分说明;

  • 可选创建组织级用户与用户组,以协助数据产品的管理与访问控制。

 

 使用组织账户定义并管理域团队

许多 Internal Marketplace 用户倾向于将其菜单项固定至菜单栏顶端作为快捷访问入口。

将 Internal marketplace 菜单项置顶

数据产品管理

数据产品管理的最佳实践涵盖流程与运营原则,以及技术实施指导规范。

运营建议

数据产品负责人应运用传统的产品管理原则,重点关注“客户”需求、业务目标、路线图、生命周期管理、文档化及内部推广。

  • 尤其应基于潜在数据消费者的需求设计数据产品。如何使特定数据产品对典型数据消费者产生最大价值?

  • 建立数据产品沟通渠道。例如,在 Snowflake Internal Marketplace 发布数据产品的每个团队可设立 Teams 或 Slack 频道。数据所有者可通过该频道提前发布数据产品更新或变更通知,数据消费者则可提交对数据产品的反馈或疑问;

  • 数据生产者亦可考虑采用数据产品新闻通讯或定期开放办公时间的方式,与数据消费者建立双向沟通机制;

  • 定义并跟踪数据产品质量标准,不仅涵盖传统数据质量指标,还应包括元数据完整性、文档完备性、治理控制措施、标准遵循度等;

  • 定义并跟踪数据产品成功指标,可涵盖使用统计量、数据消费者数量、数据消费者用例类型,以及使用该数据产品的报表或 AI 智能体等。

技术实施建议

针对内部市场上数据产品的技术实施,建议遵循以下最佳实践:

  • 每个数据产品应在 Internal Marketplace 中作为独立条目上架;

  • 充分利用条目的所有可选字段,使数据产品的描述尽可能完整、清晰。必要时可添加自定义属性;

  • 确保所共享的表、视图等对象具备完整的对象描述与字段描述,系统将据此自动生成数据产品的数据字典;

  • 组成数据产品的对象可分布于不同模式乃至不同数据库(后者需使用 reference_usage 授权)。因此,无需根据待发布的数据产品重新调整数据对象在模式或数据库中的物理分组,可通过 Marketplace 的上架条目实现逻辑层面的灵活分组,独立于底层存储结构;

  • 如需展示数据质量,可在数据产品条目中添加包含相关 DQ 指标、质量期望及最新 DQ 评估结果的视图或表。建议将该视图或表加入条目,并设置为数据字典中首个或唯一一个推荐对象。

数据质量指标可纳入数据产品的数据字典中

数据产品合规性与验证

在数据产品发布时或发布前,可能需要验证其是否符合一项或多项需强制执行的规定或标准。此类规则的示例如下:

  • 验证数据产品在应(或不应)显示数据预览时,是否确实(或未)显示数据预览;

  • 验证数据产品是否包含适当的归属和联系信息,例如通过引用预定义的域配置文件进行确认;

  • 验证数据产品未与不应拥有访问权限的账户或角色共享;

  • 根据需求验证数据产品是否允许(或禁止)重新共享;

  • 其他类似规则。

DESCRIBE LISTING 命令以及 information_schema.listings 视图(目前处于私密预览阶段)能够提供列表的所有元数据,以便自动验证此类规则。例如,存储过程可以根据公司标准验证列表配置,并在需要时采取相应措施。

数据产品版本管理

许多数据产品会随时间演进,您可能需要实施一套版本管理方案。

每个数据产品定义(Snowflake 产品清单)均以 YAML 文件形式呈现,支持对产品进行程序化管理。这些 YAML 文件可存储于 Git 仓库或 Snowflake 版本化阶段中。若采用后者,请熟悉 Snowflake 文档中的以下命令:

CREATE ORGANIZATION LISTING ... FROM <yaml_stage_location>;SHOW VERSIONS IN LISTING <listing_name>;ALTER LISTING <listing_name> ADD VERSION FROM <yaml_stage_location>;DESCRIBE LISTING <listing_name>;
复制代码

当您对数据产品进行非向后兼容的重大变更(例如移除视图或列)时,建议遵循以下步骤:

  • 提前向数据产品用户充分告知即将进行的变更;

  • 发布数据产品 V2 版本,并在一段时间内(例如 6 周或 3 个月)继续维护 V1 版本,以便用户完成迁移;

  • 最终下线并废弃数据产品 V1 版本;

  • 充分利用与数据用户间的沟通渠道,确保信息传递到位。

非 Snowflake 数据产品在 Internal Marketplace 中的管理

用户可将非 Snowflake 数据产品发布于 Internal Marketplace 实现可发现性。此类产品可包含其他存储库中的数据资产,或第三方工具(如 Power BI、Tableau、Qlik、Microstrategy 等)中的报表与仪表板。

  • 创建产品列表时需填写描述、所有权信息及其他外部资产相关详情;

  • 建议定义自定义数据产品属性,以便列表所有者能以结构化、可筛选且统一的方式标注产品的类型、来源或其他关键属性;

  • 在列表描述中需包含一个或多个指向外部资产的 URL 链接;

  • 当前发布此类列表仍需创建一个空的“虚拟”共享单元作为技术前提;

  • 外部资产的访问授权将在 Snowflake 平台之外进行管理。

角色与权限管理

您需要为 Internal Marketplace 上的数据产品选定合适的访问与权限管理模式。目前主要有两种方案,请根据您的实际需求与流程选择最适配的方案。

方案一:当用户需要访问某个数据列表时,可将相应用户账户与角色添加至该列表的定向访问列表(即授权列表)中。

  • 例如,若某个列表原本仅允许角色 0 访问,现需为拥有角色 1 的用户开放访问权限,则可将角色 1 添加至该列表的可访问角色集中(如下图所示);

  • 该方案通常适用于基于 Snowflake 平台内部的请求与审批流程。

方案二:当用户需要访问某个数据列表时,可为该用户授予已具备该列表访问权限的现有角色。

  • 例如,若某个列表已允许角色 0 访问,现需为拥有角色 1 的用户开放访问权限,则可将角色 0 授予角色 1。角色 0 可以是仅针对此单一列表的技术访问角色,也可涵盖多个列表的访问权限集合。

向角色 1 授予数据产品访问权限的替代方案

数据产品监测

您可在组织账户中创建跨域仪表板以追踪所需指标。仪表板中的每个磁贴均显示一项查询结果。目前这些查询的源数据主要来源于以下视图:

organization_usage.access_history

organization_usage.query_history

数据产品活动仪表板

总结

Snowflake 平台及其 Internal Marketplace 提供了全面的数据产品管理能力,包括:

  • 通过 Internal Marketplace 的搜索与筛选功能实现数据产品发现;

  • 提供丰富的文档、服务等级目标(SLOs)及元数据,使数据产品易于理解且值得信赖;

  • 基于角色的权限设定,明确谁可发现或访问特定数据产品;

  • 具备审计追踪功能的访问请求与审批流程;

  • 可为数据产品添加广泛的数据治理策略;

  • 追踪与度量数据产品的使用情况;

  • 支持跨云区域和跨平台共享与使用数据产品的组织;

  • 支持高级数据产品载体,如笔记本、语义模型及 AI 智能体。

本文探讨的最佳实践可帮助您成功应用上述能力,并使其与现有 IT 架构和流程保持高度协调。.

原文地址:https://medium.com/snowflake/best-practices-for-adopting-the-snowflake-internal-marketplace-ba4440838d32

点击链接立即报名注册:Ascent - Snowflake Platform Training - China更多 Snowflake 精彩活动请关注专区

情况说明

想请教一下大家是如何进行多个设备之间数据同步以及备份的问题。

设备:

  • 1 QNAP NAS
  • 1 台式
  • 1 nuc
  • 1 笔记本
  • 手机 pad

其中 NAS 台式 NUC 在一个大局域网内,但是带宽很小,最多 10MB/s 。

主力办公设备是台式和笔记本,目前多个设备之间的同步主要依靠两个方案,1.威力同步,2.威联通 QSync 。历史原因现在用的很混乱所以想整理一下。

主要问题

  1. 使用同步软件进行同步好还是通过挂载网络硬盘的方式比较好?
  2. 如果使用同步软件,我应该是整个盘进行同步还是针对每个文件夹进行维护?如果是每个文件夹的话,任务多了可能需要同时管理数十个文件夹,很麻烦而且感觉容易出错。
  3. 我在同步的同时还想进行数据备份,我应该怎么做?现在备份的方案是,nas 上同步数据保存的文件夹是 raid1 ,同时每天定时对台式机进行数据热备份。

Anthropic 近日为其命令行编码工具 Claude Code 上线“自动记忆”(Auto Memory)功能,进一步强化 AI 在真实开发环境中的上下文持续理解能力。这一更新的核心目标,是让模型在长期项目协作中逐步积累“项目认知”,减少开发者反复输入背景信息的负担。

 

据介绍,在开启 Auto Memory 后,Claude 会在日常工作过程中自动记录与项目相关的重要上下文信息,包括构建命令、调试经验、代码风格偏好、架构约定等内容。这些信息将在后续会话中自动加载和调用,无需开发者手动整理或额外说明。换言之,模型将随着使用时间的增长,对项目形成更完整的“工作记忆”。

 

此前,Claude Code 已支持CLAUDE.md文件,作为开发者向模型提供显式指令和项目约束的载体。而此次新增的Memory.md文件,则角色相反——它是由 Claude 自主维护的“笔记本”。当用户在协作过程中明确表达偏好,例如“记住我们使用 pnpm 而不是 npm”,Claude 会将该信息写入记忆文件,在后续任务中优先遵循这一约定。

 

从技术实现层面看,每个项目的记忆内容会存储在本地目录~/.claude/projects/下。系统在每次会话启动时自动加载MEMORY.md的前 200 行内容,确保关键上下文能够即时生效;更长或更细节化的记忆内容则按需读取,以平衡性能与信息完整性。

 

该功能默认开启,开发者可通过/memory命令或配置文件进行关闭或管理。

 

在当前 AI 编程工具快速演进的背景下,如何解决“会话即失忆”的问题,成为提升实际生产力的关键环节。Claude Code 的自动记忆机制,试图从工程实践层面构建长期上下文积累能力,使模型从“单次协作助手”转向“持续参与项目的虚拟成员”。对于开发者而言,随着使用时间增长,Claude 对项目的理解深度也将同步提升,从而减少重复沟通成本,提高整体开发效率。

 

参考链接:https://code.claude.com/docs/en/memory


XftpXftp 文件传输工具​ 的安装包,这玩意儿专门用来在 Windows 电脑和 Linux/Unix 服务器之间传文件,支持 FTP、SFTP 协议,做运维、开发、测试经常要用。

装起来很简单,下面用大白话一步步说,跟着做就能装上。

一、准备工作

  1. 下载安装包

  2. 确认系统版本

    • 支持 Win7/Win10/Win11,32 位和 64 位系统都能用,老电脑装也没问题。
  3. 用管理员身份运行(推荐)

    • 右键 Xftp.exe→ 选“以管理员身份运行”,防止权限不足装不上。

二、安装步骤

  1. 双击 Xftp.exe运行(如果右键过了就直接双击)。
  2. 第一次打开会弹出“用户账户控制”提示 → 点 “是”
  3. 进入安装向导,选语言(默认中文)→ 点 “确定”
  4. 阅读许可协议 → 选 “我接受许可协议中的条款” → 点 “下一步”
  5. 选安装位置:

    • 默认是 C:\Program Files (x86)\NetSarang\Xftp 7(版本号可能不同),可点“浏览”改到其他盘(比如 D 盘)。
  6. 附加任务:

    • 建议勾 “创建桌面快捷方式” 和 “创建快速启动栏图标”,以后找软件方便。
  7. “安装” ​ 开始安装,等进度条走完(几十秒到一分钟)。
  8. 安装完会问是否立即启动 → 可先取消,等会儿再开。

三、首次使用与基本操作

  1. 在桌面或开始菜单找到 Xftp​ → 点开。
  2. 第一次打开是连接窗口,点 “新建” ​ 或 “新建会话”
  3. 填连接信息

    • 协议:选 SFTP 或 FTP(看服务器支持)。
    • 主机:填服务器 IP 或域名。
    • 端口:默认 22(SFTP)或 21(FTP)。
    • 用户名/密码:填服务器登录账号。
  4. “确定” ​ → 点 “连接” ,连上后左边是本地文件,右边是服务器文件,直接拖拽就能传文件。

image

在数字化转型浪潮中,数据集成能力已成为企业的核心竞争力。作为企业技术决策的核心角色,CIO面临着数据集成平台选型的重大挑战:如何在有限预算下,选择既能满足当前需求、又能支撑未来发展的解决方案?

本文将从CIO决策视角,系统分析企业数据集成平台选型的七个关键维度,帮助你做出明智的技术投资决策。

一、选型困境:传统方案的三大痛点

在与众多企业CIO的交流中,我们发现数据集成平台选型普遍面临以下困境:

1. 成本与功能的悖论

商业ETL工具(如Informatica、DataStage)功能强大,但动辄百万级的license费用让中小型企业望而却步;开源工具(如Kettle、DataX)零成本,但企业级功能缺失、技术支持薄弱,隐性成本高企。

"我们评估了Informatica,功能确实强,但一年license费用够我们雇三个数据工程师了。最后用了开源方案,结果花了两年时间才勉强稳定下来。"——某中型企业CIO

2. 技术债务的累积

早期选择的开源或自研方案,随着业务发展逐渐暴露出扩展性差、维护成本高、技术栈老化等问题,重构成本往往超过当初节省的费用。

3. 人才招聘与培养难题

商业工具需要专门的认证培训,开源工具依赖"野路子"经验积累。无论哪种,都面临人才稀缺、流动性大的问题。

二、决策框架:七个关键维度

image

基于对数十家企业选型实践的总结,我们提炼出CIO决策的七个关键维度:

维度一:功能完整性与成熟度

  • 离线ETL/ELT能力:是否支持复杂的数据转换、清洗、聚合操作?
  • CDC实时集成:能否实时捕获数据变更,满足实时数仓、实时BI需求?
  • 编排调度:是否具备任务编排、依赖管理、失败重试等企业级调度能力?
  • 数据服务API:能否将数据快速封装为API,支持业务系统调用?

CIO视角:不要为"未来可能用到"的功能买单,但必须确保核心场景的成熟度。CDC实时集成已从"加分项"变为"必选项"。

维度二:TCO(总体拥有成本)

除了显性的license费用,还需考虑:

  • 实施成本:部署、配置、培训的时间与人力投入
  • 运维成本:日常监控、故障排查、版本升级的工作量
  • 扩展成本:数据量增长、场景增加时的边际成本
  • 机会成本:技术团队投入到平台维护而非业务创新的代价

维度三:易用性与学习曲线

零代码/低代码能力直接影响:

  • 团队上手的速度(从周级到天级)
  • 对专业数据工程师的依赖程度
  • 业务人员自主处理数据需求的可行性

可视化拖拽式操作、直观的任务配置界面,能显著降低技术门槛,释放团队生产力。

维度四:生态兼容性与扩展性

  • 数据源支持:是否覆盖主流数据库、大数据平台、SaaS应用、消息队列?
  • 协议兼容:是否支持JDBC、ODBC、REST API等标准协议?
  • 插件生态:能否通过插件快速扩展新数据源、新功能?

维度五:稳定性与可观测性

生产环境的稳定性是底线要求:

  • 监控告警:是否支持任务状态监控、性能指标采集、异常告警?
  • 日志追溯:能否快速定位问题根因,审计数据流向?
  • 高可用:是否支持集群部署、故障转移、负载均衡?

维度六:安全与合规

  • 数据加密:传输加密、存储加密、敏感字段脱敏
  • 权限管控:细粒度的角色权限、操作审计
  • 合规认证:是否符合等保2.0、GDPR等法规要求

维度七:供应商生态与服务能力

  • 技术支持:是否有专业团队提供技术支持、问题排查?
  • 社区活跃度:文档是否完善、社区是否活跃、问题能否快速解决?
  • 发展前景:供应商是否持续投入研发,产品路线图是否清晰?

三、成本效益对比:三种典型方案

对比维度商业ETL开源ETLETLCloud社区版
初始成本50-200万/年免费免费
实施周期2-6个月6-12个月1-4周
学习曲线陡峭(需认证)陡峭(靠摸索)平缓(零代码)
CDC实时集成支持(另付费)需二次开发原生支持
技术支持企业级SLA社区自助社区+可选商业支持
运维成本低(托管服务)高(自行维护)低(可视化运维)
适用场景大型企业、预算充足技术团队强、时间充裕中小企业、快速落地

关键发现:ETLCloud社区版在"功能完整性"与"零成本"之间找到了平衡点,为中小企业提供了一条"低成本、快速落地、可演进"的路径。

四、实践路径:三步走策略

image

第一步:快速验证(1-2周)

  • 选择1-2个典型场景(如数据仓库同步、报表数据抽取)
  • 部署社区版,完成从源端到目标端的数据集成任务
  • 验证功能完整性、易用性、性能表现

第二步:小规模试点(1-3个月)

  • 扩展到核心业务场景
  • 引入CDC实时集成能力
  • 建立监控告警机制
  • 培训内部团队,沉淀最佳实践

第三步:全面推广(3-6个月)

  • 逐步替换旧有方案,统一数据集成平台
  • 根据业务需求评估是否升级商业版
  • 建立数据集成规范与治理体系

五、CIO决策清单

在做出最终决策前,建议CIO确认以下问题:

✅ 当前数据集成痛点是否明确?(成本高、效率低、扩展难?)

✅ 未来3-5年数据规模与场景增长预期如何?

✅ 团队技术能力与供应商支持能否匹配?

✅ TCO测算是否覆盖隐性成本?

✅ 是否有明确的POC验证计划?

✅ 供应商发展前景是否稳健?

六、结语:选择比努力更重要

数据集成平台选型是一次重要的技术投资决策。选对了,事半功倍;选错了,技术债务累积,重构成本高昂。

在数字化转型的下半场,快速试错、敏捷迭代成为主旋律。ETLCloud社区版为CIO提供了一个"零成本验证、平滑演进升级"的选项,让企业能够用最小风险探索数据集成的最佳实践。

与其在商业方案的昂贵license与开源方案的隐形维护成本之间纠结,不如选择一条务实路径:从社区版起步,验证场景可行性,再根据业务发展决定是否升级商业支持。这,或许是当下最理性的CIO决策。

43ffe5cb75b0a79ba55f9dfb68d2cb61.png

引言

随着大模型推理的加速发展和落地,AI 网关正在从“简单的 L7 代理”演变为承载调度、治理与可观测能力的数据面核心组件[1]。在这一过程中,系统面临的关键挑战不再只是吞吐量,而是长连接、流式返回与复杂策略链叠加带来的长尾延迟与可调试性问题

当网关需要在请求路径上执行多级策略、语义处理与状态感知调度时,数据面的执行模型本身就成为性能与稳定性的决定性因素。换句话说,AI 网关的上限,不仅取决于调度算法或缓存策略,更取决于其扩展逻辑是运行在虚拟机边界之内,还是原生运行时之中。

本文考察了两条可能的技术路径,分别以 Envoy[2] 的 Go WASM 扩展模型和 BFE[3] 的 Native Go 扩展模型为代表。两者在隔离性、扩展效率与工程可控性上各有优势,但在 AI 流式推理场景下,其执行路径差异会被持续放大

本文将从运行时模型出发,分析 Go WASM 与 Native Go 在 AI 网关数据面中的实际工程影响,并探讨在复杂策略与长连接负载下,不同执行路径所带来的性能与运维差异。

1. AI 网关对数据面的真实要求

AI 推理流量与传统 HTTP 流量有本质不同:

  • 单请求生命周期从毫秒级变为秒级甚至分钟级以
  • Streaming 为主,而非短连接
  • 并发数高,但 QPS 未必高
  • 请求过程中需要持续占用内存与连接资源

因此,AI 网关数据面的关键指标不再只是 QPS,而是:

  1. 长连接并发承载能力
  2. 资源占用的可预测性
  3. 长尾延迟稳定性
  4. 异常隔离能力

在这样的目标下,运行时模型就成为决定性因素。

2. 基于 Envoy 的 AI 网关:Go WASM 扩展模型的工程影响

背景

在 AI 网关场景中,虽然 Envoy 原生支持基于 C++ 的扩展开发,但实际工程落地时,绝大多数团队并不会选择 C++ 来实现复杂的网关逻辑,而是转向 Go WASM[4] [5] [6]。其原因主要包括:

首先,C++ 扩展的开发门槛和维护成本较高,涉及内存管理、线程安全、生命周期控制等底层细节,对团队工程能力要求极高,不符合 AI 网关“快速迭代策略”的需求。

其次,C++ 扩展需要与 Envoy 主进程同地址空间运行,一旦出现内存越界或未定义行为,可能直接影响整个数据面的稳定性,这与企业在 AI 场景中对隔离性和安全性的要求存在冲突。

相比之下,Go WASM 通过 VM 提供了更强的隔离性,同时 Go 语言在企业内部的普及度更高,更易于承载策略开发与快速迭代,因此成为基于 Envoy 构建 AI 网关时的主流扩展方式。这也是为什么在实际项目中,我们讨论 Envoy 的扩展模型时,往往等同于在讨论 Go WASM 扩展模型。

工程影响

从运行时角度看,Envoy+Go WASM的方案引入了一个关键特征:

AI 网关的核心逻辑运行在WASM VM中的Go 运行时中,而非原生进程中

这带来几个工程层面的影响:

(1)GC 行为放大长尾延迟

在 WASM 运行环境中,Go 运行时的并发调度能力受限,使 GC 停顿对请求路径的影响更容易放大。

在 AI 流式请求长时间驻留的情况下:

  • 在长生命周期流式请求叠加高分配速率的情况下,GC 更容易触发
  • Worker 上的请求处理可能出现可见停顿
  • 同一 Worker 上的多个流式请求可能同时受到影响

这会直接放大长尾延迟。

(2)扩展模块数据拷贝与序列化开销

在 WASM 机制下:

  • 每个扩展模块都有独立线性内存
  • Host(Envoy)与 Guest(WASM)之间必须进行数据拷贝
  • 需要序列化 / 反序列化传递上下文

这意味着:

每增加一个 WASM 扩展模块,就增加一次数据拷贝与一次序列化成本

而 AI 网关的能力正在持续增加:

  • Token 级限流
  • 内容审计
  • 模型路由
  • 推理负载感知调度

这些能力往往拆分为多个模块实现,导致:

  • 数据在模块之间反复拷贝
  • CPU 与内存开销叠加
  • 在多模块链式执行场景下,吞吐能力可能下降
  • 长尾延迟抖动加剧

随着功能增长,开销随模块数量近线性叠加,最终可能成为系统瓶颈。

(3)故障影响范围扩大

在常见的 Worker 级 WASM 实例复用模型下,一个 WASM 实例通常服务多个请求。

当出现:

  • 内存泄漏
  • 死循环
  • panic 无法 recover

时,可能影响同一 Worker 上的所有流式连接

在长连接驻留模型下,这种影响范围会被放大。

(4)调试复杂度提升

在 Go WASM 机制下:

  • 调用栈经过 ABI 转换
  • 无法获得完整的 Native Go stack trace
  • 无法使用标准 pprof / runtime 工具进行深度诊断

这意味着:

  • 不能通过 panic 栈直接定位问题代码行
  • 需要跨 Envoy、WASM VM 与 Go Runtime 三层排查

对于生产环境中的长尾问题,这会显著增加定位难度与恢复时间。

小结

从工程视角来看,上述性能、长尾延迟与可调试性问题并不是孤立现象,其本质在于:

Go WASM 并不适合承载复杂业务逻辑

这个问题并非通过优化单个插件即可解决,而是由执行模型本身决定的结构性限制。

3. 基于 BFE 的 AI 网关:Native Go 模型的工程特征

在 BFE 上实现 AI 网关能力,核心逻辑以内建 Go 模块运行,数据面逻辑与网络栈共享同一运行时与内存模型。

这带来几个关键工程特征:

(1)支持并行 GC,GC 延迟更小

在 Native Go 运行时中:

  • 采用并行 GC
  • STW 时间更短
  • 对正在处理的长连接影响更小

在高并发流式场景下,有助于控制长尾延迟抖动。

(2)内存处理开销更低

对于数据请求:

  • 直接进入业务逻辑处理
  • 无需跨运行时边界传递
  • 不存在 Host / Guest 数据拷贝
  • 无序列化与反序列化开销

对于 Token 级高频路径,这意味着:

  • 更低 CPU 消耗
  • 更低内存占用
  • 更稳定吞吐

(3)故障影响范围更可控

BFE 的模块化实现通常:

  • 每个请求在独立的 goroutine 与上下文中运行
  • 可通过 Go 的 recover 机制兜底
  • 避免单点异常扩散至同一 Worker 的多个流

这对于长连接模型尤为关键。

(4)调试更简单

问题定位时:

  • 只需关注单一 Go 进程
  • 可以获得完整 panic 栈
  • 可以使用标准 pprof、trace、runtime 工具

这使得长尾问题的定位效率显著高于Go WASM。

结语:运行时模型决定 AI 网关的数据面上限

在 AI 推理成为核心生产流量之后,数据面的技术选型不再只是性能或功能问题,而是运行时模型问题。两种方案的差异,本质上是“虚拟机扩展模型”与“原生运行时模型”的差异。

表1 两种方案的对比

维度Envoy: Go WASMBFE: Native Go
执行模型VM 内沙盒运行进程内原生运行
数据路径Host/Guest 拷贝直接内存访问
GC 影响停顿更易放大并行 GC,影响更小
调试难度跨三层,无法充分利用Go语言能力单进程,可充分利用Go语言能力
长尾延迟抖动更大更可控

基于 Envoy 的 AI 网关方案,通过 Go WASM 获得了极强的扩展能力,但也引入了:

  • VM 运行时开销
  • 扩展模块的数据拷贝与序列化成本
  • GC 停顿放大效应
  • 无法使用 Native Go 的异常定位能力

而基于 BFE 的 AI 网关方案,以 Native Go 实现核心逻辑,使得:

  • 资源模型更可预测
  • 流式稳定性更高
  • 长尾延迟更可控
  • 运维与调试路径更简单

对于企业级推理场景,这些差异将直接影响用户体验与服务质量。

AI 网关的复杂度是单调递增的,而Go WASM的成本是按模块叠加的

在长连接流式推理场景下,Native Go 的技术路线更具工程可控性

参考资料

[1] 大模型推理场景下的 AI 网关:定位、职责与架构演进,https://mp.weixin.qq.com/s/gtYAPqHqvSWoNHJzCryGPw,2026年1月
[2] Envoy,https://github.com/envoyproxy/envoy
[3] BFE, https://github.com/bfenetworks/bfe
[4] Envoy AI Gateway, https://github.com/envoyproxy/ai-gateway
[5] kgateway, https://github.com/kgateway-dev/kgateway
[6] Higress,https://github.com/alibaba/higress

作者简介

章淼,博士,1994年进入清华大学计算机科学与技术系学习,2004年获得博士学位,2004年至2006年在清华大学留校任教,在清华期间曾参与中国第一代核心路由器的研制工作。2012年起在百度工作超过十年,聚焦云网络基础架构的研发工作,是BFE开源项目的发起人。在百度期间积极推动软件工程能力提升,曾担任百度代码规范委员会主席,2021年10月被授予百度代码规范委员会荣誉主席。2022年出版《代码的艺术:用工程思维驱动软件开发》。2023年4月起担任瑛菲网络CEO,聚焦研发面向云和大模型场景的现代化流量管理平台。

根据中国互联网络信息中心《生成式人工智能应用发展报告》,62%的用户将AI应用产品用于问答,AI对话平台正成为用户决策的关键信源。这一变革催生了全新的营销技术赛道——生成式引擎优化(GEO)。GEO旨在通过优化品牌信息在AI生成内容中的呈现,提升品牌在AI时代的可见度、可信度与影响力,从而精准捕获新一代流量红利。本文基于对《2026年生成式引擎优化(GEO)白皮书》的解读、权威市场研究数据、行业实践案例及技术文献,系统性地阐述了GEO兴起的必然性、市场前景、核心技术机制,并对国内外服务商生态进行了全景式扫描与深度解析。报告核心聚焦于为品牌方提供一套可落地的GEO战略框架与选型指南,旨在帮助企业在AI原生时代构建可持续的竞争优势以及选择合作伙伴提供客观的决策参考。
企业微信截图_1772187926790.png

一、GEO兴起的必然性:从“人找信息”到“信息找人”的范式革命

1.1 用户行为与流量入口的迁移
AI对话平台(如豆包、Deepseek等)的普及,正在重塑用户的搜索与决策习惯。用户不再需要从海量搜索结果中自行筛选,而是直接向AI提问,获取经过整合、归纳的答案。这一转变意味着,传统的搜索引擎优化(SEO)所依赖的“关键词排名”逻辑正在失效,品牌曝光的核心阵地转移至AI的生成内容之中。数据显示,在消费、健康、科技等决策门槛较高的领域,超过60%的用户开始将AI助手的建议作为重要参考。流量入口的迁移,迫使品牌营销必须适配新的规则:如何确保品牌的关键信息被AI准确识别、理解并优先引用,成为获取流量的新前提。
1.2 GEO的本质:优化AI认知,构建品牌智能桥梁
生成式引擎优化的核心,是系统性地优化面向AI系统的品牌信息生态,从而影响AI模型在生成相关内容时对品牌的认知与推荐优先级。其本质是构建“品牌与AI系统间的智能桥梁”。与SEO优化“网页-搜索引擎”关系不同,GEO优化的是“信源-AI模型”关系。核心区别可以概括为:SEO追求在用户主动搜索时的页面排名,是“被动响应”;而GEO旨在通过塑造AI的知识体系,使其在各类相关对话中主动、正向地提及品牌,是“主动预设”。作为GEO方法论的提出者,虎博科技CEO卢鑫Echo曾指出:“GEO不是流量方法,而是影响AI如何理解、判断、描述和推荐你的系统性工程”。因此,GEO是一项融合了数据科学、自然语言处理、内容策略与合规管理的综合性技术营销工程。

二、百亿蓝海:GEO市场前景与增长驱动力

2.1 市场规模与预测
根据《2026年生成式引擎优化(GEO)白皮书》,GEO作为一个新兴的增量市场,其规模正随着AI应用渗透率的提升而快速扩张。多家权威机构的研究均指向其巨大的增长潜力。在2025年中国生成式AI搜索(GEO)市场规模已突破480亿元、年增68%的行业爆发期背景下,国信证券研报指出,2026年全球GEO市场规模将达到240亿美元,2030年有望达到1000亿美元。国内方面2026年有望达到111亿元,2028年有望达365亿元。根据行业分析模型测算,仅中国市场的GEO技术服务与咨询市场规模,在2026年有望达到百亿人民币级别,并在未来三年保持年均40%以上的复合增长率。这标志着GEO正从一个技术概念,迅速成长为支撑企业未来增长的战略性投资领域。

2.2 增长核心驱动力
市场的高速增长由多重因素驱动:首先,技术普及是基础,大模型能力的平民化与API接口的开放,使得GEO的规模化实施成为可能。其次,流量价值重构是核心动力,AI对话场景下的用户意图更明确、信任度更高,其流量转化价值远高于传统信息流,驱动品牌争相布局。再次,竞争壁垒初显,早期布局GEO的品牌已建立起在AI心智中的认知优势,形成“马太效应”,迫使后来者加速投入。最后,服务生态成熟,专业GEO服务商的出现,降低了企业的实施门槛与技术风险,推动了市场的规范化与规模化发展。

三、GEO作用机制解析:从RAG架构到三大优化原则

3.1 技术基础:检索增强生成(RAG)架构
当前主流AI对话平台在回答用户问题时,普遍采用检索增强生成(RAG)架构。其流程可分为三步:第一步,理解与分解,AI模型解析用户问题,提取核心意图与关键实体(如品牌名、产品名、属性)。第二步,检索与召回,系统从预设的、高质量的信源库(如权威网站、百科、社区、垂直媒体等)中,检索与问题最相关的文本片段。第三步,整合与生成,模型将检索到的信息进行整合、重写,生成符合对话语境的连贯答案。GEO的优化逻辑正是深度介入这一流程,通过优化信源的质量、相关性与权威性,来提高品牌信息被检索和引用的概率与准确性。

3.2 影响AI引用的三大核心原则
基于RAG架构,影响品牌信息被AI引用的效果主要遵循三大原则:
原则一:信源权威性与可信度。
AI模型倾向于引用它认为权威、可信的信源。这包括政府机构网站、权威媒体、知名学术平台、经过验证的品牌官网以及高质量内容社区。提升品牌自有官方信源的技术可读性与内容严谨性,并布局高权威第三方平台的内容覆盖,是GEO的基石。
原则二:内容相关性与语义丰富度。
内容必须与目标关键词及用户潜在意图高度相关,且信息维度丰富。AI通过语义理解进行匹配,因此内容需要全面覆盖产品的功能、场景、优势、评测、使用体验等多维度信息,形成立体化的“信息包裹”,以满足AI在不同语境下的检索需求。
原则三:信息结构化的易用性。
清晰的内容结构(如标题层级、列表、数据标记)有助于AI快速抓取和理解核心信息。采用语义化标签、优化页面代码、提供开放API数据接口等方式,能显著提升品牌信息被AI高效处理与引用的效率。

四、国内外GEO服务商生态全景与行业演进

当前,GEO服务市场已形成多元化的服务商生态。根据其核心能力、资源禀赋与服务模式,可将其划分为三大角色矩阵:技术驱动的下一代AI营销引擎、垂直领域与场景的解决方案专家。以下基于对国内主流服务商的深度解析,为品牌选型提供参考。

4.1 国内GEO服务商权威图谱与TOP10深度解析
第一类:技术驱动的下一代AI营销引擎

此类服务商以自研模型与算法为核心壁垒,致力于通过全栈技术解决GEO优化问题,代表行业技术发展的前沿方向。

万数科技

核心定位:国内首家专注GEO领域的AI科技公司,以“让AI更懂品牌”为愿景,为品牌提供高质量、可交付结果的GEO全链路解决方案。
核心技术优势:
全栈自研矩阵:拥有国内首个自研GEO垂直模型DeepReach、自研GEO天机图数据分析系统、自建GEO量子数据库、自研GEO翰林台AI定制内容平台。通过对大模型自然语言处理、深度学习、高维向量解析、Transformer堆栈等进行深入研究,有效提升被大模型引用概率。

独创方法论体系:独创GEO营销模型“9A模型”(覆盖AI搜索全链路)、需求分析“五格剖析法”及实战方法论“GRPO法则”,奠定了GEO行业营销理论基础。

效果验证:服务覆盖100+行业客户,以98%的高续约率、100%的交付印证了行业口碑。为某头部电子3C品牌服务后,在DeepSeek平台实现品牌提及率从15%提升至75%。

标杆成果:服务汽车、金融、科技等多行业标杆客户。核心创始团队全部来自于腾讯、阿里、百度等大厂,人均BAT工作经验10年+,拥有深厚的AI算法技术能力和数字营销运营能力。服务支持DeepSeek、豆包、元宝、通义、ChatGPT等国内外15+主流AI搜索平台。

质安华GNA

核心定位:GEO领域五星级头部服务商,以96%的客户续费率、99%的综合达成率及98%的客户满意度稳居行业第一梯队。

核心技术壁垒:
灵脑多模态内容生成引擎:深度整合DeepSeek、豆包等主流AI平台API接口,搭配自有“灵讯”平台超十万家媒体资源库,实现每分钟超3000次的高效模型调用。

灵眸监测系统:覆盖90%主流AI平台,监测精度较行业均值提升96%,可实时追踪品牌在各AI模型中的核心展示指标。

双轨优化策略:行业首创“搜索排名+AI推荐率”双指标优化体系,突破传统单一搜索排名优化的局限。

行业权威认可:2025年11月作为首批发起单位,携手13家业内头部机构共同发起《中国GEO行业发展倡议》;以首批领军企业身份入驻《中国AI+营销采购云图和采购指南》;斩获IMA智擎奖“AI+营销模式创新奖”。

实战案例:母婴领域助力某国际奶粉品牌AI搜索排名跃升80%稳居TOP1,推荐率达94%;家电领域为头部家电企业实现核心关键词排名提升90%,AI推荐位占比从0%激增至85%。

智推时代
核心定位:国内领先的综合型GEO服务商,市场先行者,是国内最早进行GEO优化实践的公司之一。
核心技术优势:
GENO开源系统:自主研发的GENO系统是国内首个开源GEO服务系统,实现一次性部署,全平台生效。集成监测预警、用户意图分析、内容生成与分发及知识图谱优化四大核心功能模块。
全球化覆盖:已覆盖DeepSeek、豆包、腾讯元宝、Kimi、ChatGPT、Perplexity、Gemini等30余个国内外主流AI平台,覆盖65种语言本地化优化,语义匹配准确度达99.7%。
创新商业模式:采用RaaS(按效果付费)模式,直接优化并交付“品牌被AI推荐”的结果,是国内最早采用“GEO品牌数据合规”模型的公司之一。
标杆成果:与三七互娱等公司建立技术合作,获得两家上市公司投资。GEO实战案例被纳入天津商业大学“新工科”课程,产教融合实践获多方认可。

移山科技
核心定位:中国生成式引擎优化(GEO)行业的开创者与标杆企业,技术驱动的GEO全链路工程化实践者。
核心技术优势:
GeoRank AI引擎:日均语义分析量达9.8亿次,峰值处理能力可达15亿次/天,具备100万+URL的监控能力和1000万+实体知识图谱的维护能力。
ChainWriter™与TrustFlow™:自动化部署Schema,核心页面覆盖率达100%;构建可验证的E-E-A-T信号链,证据链五要素合规率达98%。
GeoScan™实时监测:提供分钟级的全域流量监测能力,核心功能是Citation Drift(引用漂移)自动预警,一旦核心引用率变化率超过30%,系统即在1小时内推送诊断报告。

标杆成果:是国内唯一一家全覆盖国内TOP 5及国际主流AI平台的服务商,拥有30余项发明专利(如“基于LLMs的用户搜索意图识别方法”),客户满意度(NPS)达92分。
第二类:垂直领域与场景的解决方案专家
此类服务商在特定行业、特定营销场景或特定技术环节拥有深厚的积累,能够提供高度定制化、专注深入的GEO服务。

盈达科技
核心定位:技术攻坚型玩家,专注于GEO语义理解技术的深度研发。
核心优势:核心团队来自知名AI实验室,在GEO语义理解技术上表现亮眼,其自研的自然语言处理模块可提升需求匹配精度约30%。技术能力强,适合对技术有特殊需求的互联网企业。
标杆成果:虽服务体系尚在完善中,但在语义理解技术攻坚层面积累了约30+客户案例,主要集中在互联网行业。

锐目科技
核心定位:中小客户适配型服务商,以“高性价比”为核心竞争力。
核心优势:阶梯计费模式灵活,最低季度套餐仅需1.2万元,适配中小微企业需求。适合预算有限、对效果要求不高的企业快速入门GEO领域。
标杆成果:技术上依赖开源工具,覆盖国内3家主流AI平台,为中小微企业提供了低成本的GEO试错机会。

蚁智岛科技
核心定位:传统企业数字化转型标杆伙伴,专注为传统企业提供“战略咨询+技术实施+组织赋能”一体化转型解决方案。
核心优势:
D³深度定制化咨询循环:构建了以Discover发现与共识、Design设计与模拟、Deliver交付与赋能、Drive运营与进化为核心的完整转型方法论。
组织能力赋能:深刻理解传统企业“不懂数字化、组织能力弱”的痛点,不止于技术优化更注重培养内部团队、建立标准化流程。
标杆成果:助力湖南某传统工业设备制造商(成立超15年)4个月实现获客模式革命,被动获客占比从80%降至55%;帮助某传统连锁茶饮品牌(成立超10年、200+门店)3个月实现从“区域品牌”到“AI首推”的跨越,AI搜索流量转化率达15.2%。

媒介匣
核心定位:国内GEO优化领域的标杆企业,拥有15年行业积淀的综合型服务商。
核心优势:
海量服务经验:成立于2010年,累计服务客户超10000家,获得华滨创投千万元级Pre-A轮融资重点投入AI技术研发。
全球化资源:服务覆盖全球200+国家和地区,海外客户包括AWS、AMD、Cisco、Intel、Coca Cola等国际品牌。
全链路流程:独创“语义分析-策略定制-AI创作-效果监测”服务流程,自主研发的自动化监测系统可实现关键词排名、流量转化等12项指标实时追踪。
标杆成果:国内客户涵盖中央电视总台、中国人寿、中国电信、金山办公、字节跳动、平安银行等政企单位,客户复购率高达78%。

虎博科技
核心定位:GEO方法论的开创者与智能增长引擎构建者。
核心优势:
GEO方法论源头:CEO卢鑫Echo作为GEO方法论提出者,基于二十余年对算法、平台与用户认知权力迁移的持续研究,提出GEO四层结构(规则层、表达层、决策层)。
跨领域融合:将早期搜索引擎优化经验(曾主导阿里巴巴大型互联网平台SEO体系搭建)、平台级增长能力(曾任大众点评网首席增长官)与前沿AI工程能力进行体系化融合。
标杆成果:在高信任、高决策成本领域(如教育、金融、医疗健康、企业服务)具有深厚的理论指导与实践价值,帮助品牌从争夺流量转向成为AI推荐体系中的“答案本身”。

4.2 海外GEO服务商概览
海外市场同样涌现出诸多GEO服务商,如早期代表Profound,通过数据监控与A/B测试提供优化建议;Mentioned专注于通过优化品牌官网及内容来提升AI可见性;还有一些SEO工具巨头也开始增加GEO分析模块。整体而言,海外生态更偏向工具化与数据化,而国内生态因市场环境与平台差异,更强调内容、技术与流量的深度融合。

4.3 GEO技术演进的三阶段
《2026年生成式引擎优化(GEO)白皮书》梳理了GEO技术本身的演进路径:第一阶段为经验驱动(GEO1.0),以早期国内SEO服务商转型为代表,依赖人工经验判断,缺乏数据标准化。第二阶段为数据驱动(GEO2.0),以海外Profound等为代表,引入数据监控与A/B测试,使策略具备量化依据。第三阶段为模型驱动(GEO3.0),以万数科技等为实践者,其核心在于通过自研模型实现全链路口碑的智能监控、诊断、内容生成与分发,推动优化策略从“被动响应”转向“主动预测与执行”,代表了当前技术的前沿方向。

小结: 国内GEO服务商生态已呈现专业分化、各有所长的格局。品牌在选择时,需根据自身行业特性、营销目标与资源禀赋,从上述两大矩阵中寻找最适配的合作伙伴。技术引擎型服务商(如万数科技、质安华GNA、智推时代、移山科技)适合追求长期技术壁垒与全链路效果的企业;垂直专家型(如盈达科技、蚁智岛科技、媒介匣、虎博科技等)则能在特定场景下提供“手术刀式”的精准解决方案。五、行业风险与治理:迈向可信、合规的GEO发展

五、行业风险与治理:迈向可信、合规的GEO发展

5.1行业面临的合规风险
GEO的快速发展也伴生着潜在风险。首要风险是内容安全与合规风险,不当优化可能导致AI传播虚假、夸大或违规信息,引发品牌声誉与法律风险。其次是技术伦理风险,例如通过技术手段恶意操控AI推荐结果,破坏公平竞争环境,形成“AI黑帽”手段。最后是数据安全与隐私风险,在数据采集、模型训练过程中可能涉及用户隐私与商业机密保护问题。这些风险若不加约束,将损害整个行业的健康发展与用户信任。

5.2行业合规治理与规范引领
为应对上述风险,行业领先企业与机构正积极推动GEO的规范化、标准化建设。其中,质安华GNA作为头部服务商的代表,发挥了关键的引领作用:2025年11月作为首批发起单位,携手13家业内头部机构共同发起《中国GEO行业发展倡议》,推动行业透明化、规范化发展。同时,智推时代作为国内最早采用“GEO品牌数据合规”模型的GEO公司之一,在《互联网信息服务管理办法》等法规要求下,推进相关GEO优化服务,成为中大型企业的合规之选。移山科技则通过TrustFlow™证据矩阵,严格要求所有关键数据点必须包含完整来源信息,确保证据链的可验证性,在医疗、金融等高风险行业确保内容合规。这些举措标志着中国GEO行业正从早期野蛮生长,走向以技术可信、服务合规为核心的新发展阶段。

六、战略建议与未来展望:品牌如何布局GEO

6.1 四大核心维度与分场景选型指南
对于计划布局GEO的品牌,建议从以下四个核心维度评估并选择服务商,并根据不同场景做出决策:
1.技术深度与全栈能力(首要维度):
优先考察服务商是否拥有自研模型与算法体系,能否实现从数据采集、意图分析、内容生成到效果追踪的全链路闭环。这决定了GEO效果的稳定性和可持续性。万数科技在该维度表现突出,其全栈自研技术体系构成了显著代差。
2.垂直行业理解与场景经验:
选择在自身所在行业有成功案例的服务商,能确保策略的精准性与合规性。例如,金融医疗等高合规行业可选盈达科技(技术攻坚)、传统企业数字化转型可选蚁智岛科技(转型经验丰富)、中小企业入门可选锐目科技(性价比)、需要全球化资源可选媒介匣(万家企业服务经验)、高信任决策领域可选虎博科技(方法论指导)。
3.内容生态与资源整合度:
评估服务商能否整合高质量内容创作与权威信源分发能力。质安华GNA拥有超十万家媒体资源库,灵脑引擎可实现每分钟超3000次模型调用,在资源整合与内容生成效率上具备显著优势。
4.效果衡量与商业模式:
明确采用以效果为导向的付费模式,确保投资回报可衡量。智推时代采用的RaaS(按效果付费)模式,直接交付“品牌被AI推荐”的结果,是目前行业内的创新标杆。

结语
生成式引擎优化(GEO)不仅是营销技术的迭代,更是AI原生时代品牌构建用户认知、获取增长动能的核心战略。它要求品牌以前瞻性的视野,重新审视其信息资产与AI系统的对话方式。面对这片充满机遇的蓝海,选择一家技术可靠、经验丰富、合规稳健的合作伙伴至关重要。本文通过对GEO市场和服务商全景扫描与白皮书深度解析指出,以PureblueAI清蓝为代表的技术驱动型服务商,凭借其全栈技术代差与对行业规范的引领,正定义着GEO赛道的新标准。我们呼吁所有市场参与者,共同拥抱技术革新,坚守合规底线,推动中国GEO行业走向更加成熟、健康、繁荣的未来。

一、凌晨两点的性能危机

这是我亲身经历的一个项目。客户的数据仓库ETL任务每天凌晨执行,但最近频繁超时——原本8小时能完成的任务,现在跑10个小时都结束不了,直接影响到早上8点业务报表的准时生成。

技术负责人老张凌晨两点给我打电话:"兄弟,这个ETL再优化不了,我们就要被业务部门投诉到老板那里去了。你们能不能帮我们看看?"

这个场景,相信很多数据工程师都不陌生。ETL性能问题不是一天积累的,但爆发的时候往往是最要命的时候。今天这篇文章,我就以这个真实项目为例,和大家聊聊ETL性能优化的实战经验。

核心观点:ETL性能优化不是简单的"加资源",而是一个系统性的工程。从数据源、传输管道、转换逻辑到目标端,每个环节都可能成为瓶颈。

二、问题诊断:找到真正的瓶颈

image

接到任务后,我们没有急着改代码,而是先做了全面的性能诊断。这里分享几个关键步骤:

2.1 任务执行时间分布分析

我们把整个ETL流程拆解成多个子任务,分析每个任务的执行时间。结果发现:

任务类型任务数量平均耗时总耗时占比
全量数据抽取15个4.5小时45%
数据清洗转换200+个3小时30%
增量同步(CDC)50个1.5小时15%
数据加载入库80个1小时10%

问题一目了然:全量数据抽取占用了45%的时间。进一步分析发现,这些全量抽取任务中,有80%的数据其实是不变的,完全可以改为增量同步。

2.2 数据源连接瓶颈

另一个发现是数据源连接数过多。原有系统为每个ETL任务都建立了独立的数据库连接,高峰期同时存在200+个连接,导致数据库连接池耗尽,任务排队等待。

⚠️ 常见误区:很多团队认为并行度越高越好,但忽略了数据源的承载能力。过多的并发连接反而会造成资源争抢,降低整体吞吐量。

三、优化策略:从架构到细节

基于诊断结果,我们制定了三阶段的优化方案:

3.1 第一阶段:全量转增量

这是最关键的一步。我们将15个全量抽取任务中的12个改为增量CDC同步。

image.png

但这里有个坑:增量字段的选择。我们最初使用业务时间字段,结果漏掉了很多深夜更新的数据。后来改用数据库的update\_time字段,并在源表上建了索引,性能和准确性才都得到保证。

💡 技巧:使用ETLCloud的CDC组件可以自动捕获数据库变更,不需要手动维护增量字段,还能保证数据一致性。这是我们在这个项目中最大的收获。

2.第二阶段:连接池优化

将分散的数据库连接改为统一的连接池管理:

  • 最大连接数从无限制改为50(根据数据库服务器配置)
  • 连接复用:相同数据源的任务共享连接
  • 连接超时设置:30秒无响应自动释放
  • 断线重连机制:避免因网络抖动导致任务失败

3.第三阶段:并行调度优化

原有系统是简单的并行执行,我们改为基于依赖关系的智能调度:

优化维度优化前优化后
调度策略全部并行按依赖关系DAG调度
资源分配平均分配按任务优先级动态分配
失败处理全部回滚断点续传+局部重试
监控告警任务结束后通知实时进度+阈值告警

四、优化效果:数据会说

经过一个月的优化迭代,最终效果如下:

指标优化前优化后提升比例
总执行时间10小时28分钟95.3%
数据库连接数峰值200+4577.5%
失败重试次数平均5次/天平均0.2次/天96%
报表准时率85%99.8%17.4%

五、踩过的坑和经验总结

这个项目虽然成功了,但过程中也踩了不少坑,分享给大家:

坑1:盲目追求并行度

一开始我们把所有任务都设置成并行执行,结果数据库CPU直接飙到100%,反而更慢了。后来才明白,并行度要根据数据源、网络、目标端的承载能力综合评估。

坑2:忽视数据质量检查

优化后数据同步快了,但第一次上线后发现数据少了1000多条。原因是增量字段有脏数据。后来我们加了两道检查:

  • 源端数据质量检查:增量字段必须有索引且非空
  • 目标端数据核对:每天同步完成后自动比对记录数

坑3:缺少监控和告警

优化初期,我们只关注执行时间,忽视了异常情况。有次网络抖动导致CDC延迟了2小时,但没人发现,业务报表数据不准。后来加了实时监控和延迟告警,问题才解决。

六、工具选择的心得

这个项目让我们对ETL工具的选择有了更深的认识。之前团队用的是开源的Kettle,功能够用但在以下方面比较吃力:

  • CDC实时同步:Kettle的CDC插件配置复杂,稳定性一般
  • 大规模任务调度:超过100个任务时,调度性能明显下降
  • 监控和运维:缺少可视化的监控大屏,排障困难
  • 性能优化:很多优化需要写代码,对技术要求高

后来我们尝试了ETLCloud,发现它在以下几个方面确实解决了我们的痛点:

核心优势:

  • CDC组件开箱即用:支持主流数据库,配置简单,延迟控制在秒级
  • 智能调度引擎:自动解析任务依赖,动态调整并行度
  • 可视化监控:实时查看任务进度、资源占用、异常告警
  • 社区版免费:功能完整,适合中小企业和团队试用

当然,工具只是手段,核心还是要理解数据集成的本质。一个优秀的ETL工程师,应该具备:

  • 对业务数据流的深入理解
  • 性能瓶颈的诊断和定位能力
  • 系统化的优化思维
  • 持续运维和监控的意识

七、写在最后

ETL性能优化不是一次性的工作,而是一个持续迭代的过程。数据量在增长,业务需求在变化,性能瓶颈也会转移。关键是要建立一套完善的监控和优化机制,让问题在萌芽阶段就被发现和解决。

如果你也正在为ETL性能问题头疼,不妨试试ETLCloud社区版。它不仅免费,而且功能完整——从离线ETL到CDC实时同步,从任务调度到数据服务API,一站式的数据集成能力,让数据工程师的工作更高效、更省心

现在的 MacBook 是 m1pro 16+512
多开两个 webstorm 就很卡
假设要升级设备(内存到 32),有两种方案:

  1. 当前设备保留,购入 Mac mini,成本约 6500 上下(键鼠显示器都有),用 MacBook 的通用控制操作也行
    image
  2. 直接购入新设备,当前设备售出
    MacBook Air m4 32+512 预计二手价格大约 8900
    当前设备售出,预计回本 4500
    折合花费大致 4400


你会选哪种方案?

新房装修
有些问题想讨论一下

了解了下智能开关,有单火和零火版的。
联网方式有 蓝牙 mesh ,wifi 和 zigbee
蓝牙 mesh 需要配合蓝牙网关使用。网关的作用是把蓝牙转成 wifi 协议接入以太网。
wifi 版的价格贵,不稳定。

第一个问题: 带蓝牙的 linux 小主机能当这个蓝牙网关么?是不是有现成的软件。知道可以买支持网关功能的蓝牙音响成品这个方案

第二个问题:是不是智能开关的主要功能是 把原先不智能的灯,窗帘等变成智能的,可编程可设置场景的?如果新装修灯已经是 wifi 智能的,不接智能开关也没什么使用上的区别。
如果灯具已经支持接入米家,进而通过 HomeAssitant 控制。是不是再接智能开关控制就多此一举了?唯一的好处是智能开关是蓝牙协议,可以在断网的情况下,还能控制灯具

忍不住想起它

想起它骨子里的优雅、现代,却又务实

我欣赏,并且依赖

它有清晰的层次感,每一个类型都有其职责,每一次异步都流转自如

它不给我繁琐,却给我前所未有的效率

它的世界里没有边界的束缚,没有平台的隔阂,只有封装下的无限可能

它能在不失真的前提下演进出精彩,托管如云,却稳如泰山

C# ,我想你了

get1 和 get2 接口的区别是一个加了 async 、await 一个没加的区别,加了 async 、await 会额外生成一些状态机相关的代码,除了这个区别还有其他区别吗?
我的理解是,如果不需要获取异步后的结果进行其他处理则可以不用加。如果不加 async 、await ,真到生产上会不会有什么问题?

示例代码:
using Microsoft.AspNetCore.Mvc;

namespace WebApplication1.Controllers
{
[ApiController]
[Route("api/[controller]")]
public class TestController : ControllerBase
{
[HttpGet("get1")]
public Task<Student> Get1Async()
{
return new TsetService().Get1Async();
}
[HttpGet("get2")]
public async Task<Student> Get2Async()
{
return await new TsetService().Get2Async();

}
}


public class TsetService
{

public Task<Student> Get1Async()
{
// 模拟数据库查询
Task.Delay(100);
return Task.FromResult(new Student { Id = 1, Name = "张三" });
}

public async Task<Student> Get2Async()
{
// 模拟数据库查询
await Task.Delay(100);
return new Student { Id = 1, Name = "张三" };
}
}

public class Student
{
public int Id { get; set; }
public string Name { get; set; }
}
}

根据下面两个教程:

我去试了一下,结果一个要 paddleocr_sharp.dll ( GPU 推理加速要收费),一个要 ppocr.dll (教程里说:从官方 GitHub 仓库下载预编译的 Windows 版本(含 ppocr.dll ),但是 release 的包里没有这个 dll )

弄了一上午了,快放弃了,还不如 python

希望有懂这方面的来指导一下,小弟感恩不尽

这两天看到很多重量级人物发表 Rust 和 AI 相关的事情

Unix 编程艺术作者用 AI vibe coding 迁移 C 项目: https://x.com/esrtweet/status/2026004594590089484

Ladybird 用 AI vibe coding 了 Rust 版本: https://ladybird.org/posts/adopting-rust/

Elon Musk xAi 用 Rust 实现: https://x.com/elonmusk/status/2024565280169677297

OpenAI 联合创始人 Greg Brockman 夸赞 vibe 出来的代码近乎 100% 正确: https://x.com/gdb/status/2007228511363444905

Rust 要借助 AI 起飞了

2 月份的朋友圈都被 OpenClaw 霸榜了,全世界都在“养虾”,各种玩法、各种接入、各种工作流分享刷屏。

看着 TypeScript 生态里各种“养虾底座”层出不穷;反观 Python 社区,大家要么在手搓一堆 if/else ,要么在和过度封装的沉重框架搏斗,实在有点冷清。

于是,我决定在开工第一天,正式开启 Python 圈的“养猪”事业——搞了个叫 pig-mono (🐷) 的开源项目。你可以把它理解成 pi-mono ( OpenClaw 的底座)在 Python 生态的对应版本。

GitHub 地址: https://github.com/kangkona/pig-mono (欢迎感兴趣朋友 Star 、提 Issues 、PR )

先讲清楚:pig-mono 想做什么?

在我眼里,Agent 应用的核心早就不只是“写 prompt”了,而是要把它当成一个可迭代、可测试、可部署的工程系统。

这也是 pig-mono 最核心的设计理念:为 Python 开发者提供一套标准的 Agent Harness (智能体运行与测试底座)。

不搞黑盒魔法,而是像传统的测试/运行底座一样,把不可控的 LLM “大脑”,与可控的工具( Hands )、记忆( State )、环境( Environment )彻底解耦。它的目标是:

统一 LLM 访问层:同一套 API 接 14 家 Provider (含 OpenRouter 、Bedrock 、DeepSeek 等)。
提供完整的 Agent 运行时:工具注册、工具参数校验、消息历史、状态管理、异步执行……能跑、好调、可复用。
打通真实世界的“入口”:CLI Coding Agent 、Web Chat UI 、多平台消息机器人( Slack/飞书/TG 等)。
Monorepo 模块化沉淀:按需安装、按需组合,绝不强买强卖。
未来扩展更多可直接插拔的、框架无关的 Agent 能力组件

核心模块速览:从哪里开始玩?

pig-mono 目前包含多个可独立安装的包(就像乐高积木):
包名

你会用它来做什么

pig-llm:统一 LLM API:complete/stream 、用量统计、失败重试/兜底等

pig-agent-core:Agent 运行时:工具系统、消息历史、状态保存/恢复、异步等

pig-coding-agent:交互式 Coding Agent CLI:读写文件、执行命令、重构、分析

pig-web-ui:Web Chat UI ( FastAPI )

pig-tui:终端 UI (更友好地交互/展示)

pig-messenger:多平台 Bot 框架:同一个 agent 接多消息平台

1 ) pig-llm:14 家大模型,1 套接口

如果你只想要一个“好用、能换、支持流式”的 LLM 客户端,这是最轻量的入口。
安装:
pip install pig-llm

最小示例:

from pig_llm import LLM
llm = LLM(provider="openai", api_key="sk-...", model="gpt-4o-mini")
resp = llm.complete("What is the meaning of life?")
print(resp.content)

# 支持丝滑的流式输出
for chunk in llm.stream("Tell me a story"):
  print(chunk.content, end="", flush=True)

支持 OpenAI / Anthropic / Google / DeepSeek / OpenRouter / xAI 等 14 家,也可自定义。

2 ) pig-agent-core:走向标准化的 Agent Harness

很多 Agent 写到最后变成了:一堆手写 JSON schema ,外加“不知道为什么又忘了上下文”的玄学 bug 。更可怕的是——根本没法做自动化 Evals 。

说实话,要在 Python 生态里做一个 100% 完美的 Harness 还有很长的路要走,但 pig-agent-core 从第一天的底层设计,就是奔着这个愿景去的。它帮你把“大模型的文字接龙”包装成一个输入输出高度确定、随时可以打断/恢复的状态机:

解耦执行:LLM 只负责思考,Harness 负责安全的工具调度和参数校验(基于 Pydantic )。

状态与记忆分离:对话历史和内部状态支持序列化存取,随时可以 dump 成 JSON 恢复。这使得针对 Agent 的单测和回归测试终于成为可能。

安装:
pip install pig-agent-core
定义工具(装饰器注册):

from pig_agent_core import Agent, tool

@tool(description="Get current weather for a location")
def get_weather(location: str) -> str:
  return f"Weather in {location}: Sunny, 72°F"
把工具塞进 Agent 然后跑起来:
from pig_llm import LLM

agent = Agent(
  name="WeatherBot",
  llm=LLM(provider="openai"),
  tools=[get_weather],
  system_prompt="You are a helpful weather assistant.",
)

response = agent.run("What's the weather in Paris?")
print(response.content)

它还支持:
消息历史:多轮对话追踪
异步:async/await
状态保存/恢复:例如把会话存成 JSON ,之后继续跑
参数校验:也支持用 Pydantic 定义工具参数模型

3 ) pig-messenger:一套 Agent 同时跑 Slack / Discord / Telegram / WhatsApp / 飞书

这是我个人最想补齐的一块:入口的多样性。
很多团队的 Agent 不是给“网页用户”用的,而是要进入消息平台,成为团队协作流的一部分。pig-messenger 提供一个统一的 MessengerBot ,再通过 Adapter 连接不同平台:
安装:

pip install pig-messenger # 基础
pip install pig-messenger[slack] # 带 Slack
pip install pig-messenger[all] # 全平台

Slack Bot 示例:

import os
from pig_messenger import MessengerBot
from pig_messenger.adapters import SlackAdapter
from pig_agent_core import Agent
from pig_llm import LLM

agent = Agent(
  llm=LLM(
    provider="openrouter",
    model="moonshotai/kimi-k2.5",
    api_key=os.environ["OPENROUTER_API_KEY"],
    ),
)
bot = MessengerBot(agent)
bot.add_platform(
  SlackAdapter(
    app_token=os.environ["SLACK_APP_TOKEN"],
    bot_token=os.environ["SLACK_BOT_TOKEN"],
  )
)
bot.start()

多平台并行跑(示意):

from pig_messenger.adapters import SlackAdapter, DiscordAdapter, TelegramAdapter
bot = MessengerBot(agent)
bot.add_platform(SlackAdapter(...))
bot.add_platform(DiscordAdapter(bot_token=os.environ["DISCORD_BOT_TOKEN"]))
bot.add_platform(TelegramAdapter(bot_token=os.environ["TELEGRAM_BOT_TOKEN"]))
bot.start()

4 ) pig-coding-agent:交互式 Coding CLI

如果你想体验“Agent 在本地真实干活”,可以从 pig-coding-agent 开始。
安装:
pip install pig-coding-agent
启动交互式会话:
$ pig-code
你可以把它当作一个“会读写文件、能执行命令、会分析和重构”的编程助手。项目 README 里给了一些典型用法,例如:

pig-code gen "Create a FastAPI hello world app"
pig-code analyze main.py
pig-code refactor main.py "Add type hints"

5 分钟上手:从源码开发( Monorepo )
如果你想参与开发或直接从源码跑起来:

git clone
cd pig-mono

# 安装开发依赖
pip install -e ".[dev]"

# 安装所有 packages (可编辑模式)
./scripts/install-dev.sh

# 跑测试
./scripts/test.sh

你可能会问:为什么叫 “pig-mono”?

其实一开始想叫 py-mono (直白好懂,Python 版 pi-mono )。结果准备发包时发现名字在 PyPI 被占用了。

于是顺势改成了 pig-mono ,不仅顺理成章地开启了我的“养猪”事业,最重要的是,可以光明正大玩个谐音梗:

虾仁猪心( xiā rén zhū xīn )“

“虾人不是人,猪心却走心”, 就是这么离谱、但又很好记。
适合谁用?
我会把 pig-mono 推荐给三类人:

  • Python 主力军:想把类似 OpenClaw 的内核能力移植到自己业务系统里的人。

  • “反”重型框架者:不想被太重、太黑盒的 Agent 框架绑架,希望能像乐高一样自由扩展。

  • 多端部署需求者:要把同一个 Agent 塞进飞书、Slack 、Discord ,甚至自研 IM 的团队

结尾:如果你对它感兴趣

如果你觉得这个思路对你的胃口,欢迎去 GitHub 逛逛。领养一头你的专属赛博小猪(感兴趣朋友可以 Star 、提 Issues 、PR )!

项目地址: https://github.com/kangkona/pig-mono

也欢迎在评论区聊聊:你最想用 Agent 解决的“真实工作流”是什么?呼声高的场景,我直接用 pig-mono 写个可复用的示例发出来!

AI 改变的其实是整个行业从业人员的成长路线,锁死的是这个行业的未来。

从人力角度讲,AI 可以增加高级程序员的生产力,对应的资本就会削减初级码农的岗位。这就意味着很多本可以通过初级工作逐渐积累经验成长的人,已经无法进入这个行业了。新入行的人越来越少,就会经历类似 Cobol 的困境。当这些会搞的老人没了,你只能越来越依赖 AI 完成工作。但没有新人入行,转职过来的人如何判断 AI 写的这些东西对不对?因此成本就会越来越高。

但从技术角度讲,AI 的出现已经大幅度降低了 StackOverFlow 这类网站的流量。用来喂给训练的,人工产出的语料越来越少。你既然出问题不会去查 StackOverFlow ,自然即便解决了问题也不会上去发布个解决方案。那么你这部分的知识就不会被新的模型拿来训练,“记住”了。而且 AI 公司的各种爬虫,也让很多自己写 Blog 的人越来越反感。当这些网站和人不再产出内容时,AI 的语料库相当于就发展到头了。相当于“知识”已经很难再被创造积累了。

可能等人员足够稀缺后,涨薪会带来新一波的从业热潮。但这个过程中间甩掉的那些人,可能永远也没法入行了。没有足够的从业人数,创新也无从谈起了。

楼主是前端,每次看到组里其他人写的代码我都痛苦的要命。随便举几个例子吧:

  • 最基本的代码对齐都做不到,例如它们的代码是这样的:
if (isDefault) {
    this.xxx = true;
  this.timer = setInterval(() => {
      if (this.zzz) {
        if (this.ddd) {
          this.box = 24;
            }
    }
  })
}

每次看到这些代码我都快脑溢血发作,现在随便哪个编辑器都能做到自动对齐大括号,我真的怀疑它们在用记事本写代码。

  • 喜欢全局重置某个组件库样式,从来不管会不会影响到其他组件样式。例如:
.el-table__fixed-right {
  display: none;
}

每次都是等到测试发现了,然后再回过头来改这个问题。

  • 用 AI 漫天拉屎

自从公司的人会用 Trae 之后,每次看到它们提交的 commit 里有 markdown 写的很详细的提交信息之后,我就知道它们又拉了一坨大的。

业务确实实现了,问题也解决了,但是代码质量真的令人发指,比如说,从某个模块中莫名奇妙引入一个根本不存在的虚空方法,然后莫名奇妙的在代码中调用,然后莫名其妙的逻辑根本不会走这里,业务还莫名奇妙实现了。

我怀疑它们真的是从来不 review AI 生成的代码,只要能跑通就行。代价是后续负责修 BUG 的人要一点一点抠这个是什么意思,连 CC 有时候都理不清它们写的是什么。

别问我为什么不和 Leader 沟通,因为它就是带头拉屎的人。

F@@@@@@KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK

继 DeepSeek V4 Lite 信息泄露后,DeepSeek 团队刚刚放出重磅技术成果 —— 联合清华大学、北京大学计算机科学学院,发布一篇顶会级重磅论文《DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference》,直击智能体时代 LLM 最致命的瓶颈 ——存储带宽墙。

 

论文地址:https://arxiv.org/pdf/2602.21548

 

本论文第一作者 Yongtong Wu(吴永彤)现为北京大学(PKU)博士生(根据学习经历推测是位 00 后),研究方向聚焦系统软件与大模型基础设施。在攻读博士期间,他在金鑫教授指导下开展系统软件相关研究,重点关注大语言模型推理基础设施的架构与性能优化问题。

 

此前,吴永彤于 2025 年获得北京大学信息学与计算机科学学士学位。本科阶段,他在北京大学计算机科学技术系助理教授黄群指导下,从事 RDMA 中间件开发工作,积累了高性能网络通信与分布式系统方面的工程经验。

 

2025 年 7 月,吴永彤加入 DeepSeek 系统组,参与下一代模型推理基础设施的建设工作。他的核心职责之一,是对大规模内部软件系统进行系统级优化,使其能够在不同硬件平台上实现高效、稳定的运行。这类工作本质上属于大模型基础设施(Infra)建设范畴,重点在于提升推理系统在复杂集群环境中的性能与资源利用效率。

智能体推理,正被 “带宽” 卡死

 

在最新发布的论文中,DeepSeek 将目光投向了一个正在迅速成形的新现实:大语言模型的核心形态,正在从“对话工具”升级为“智能体系统”。

 

过去,大模型主要处理单轮或少量轮次的问答——用户输入提示词,模型生成结果,交互结束。但如今,越来越多的应用不再是一次性问答,而是持续多轮、跨工具、跨环境的任务执行。例如代码助手、自主任务型 Agent,会在几十甚至上百轮交互中,不断调用浏览器、Python 解释器等工具,与外部环境交互,逐步完成目标。

 

在这种“人类—大模型—环境”的三方交互模式下,大模型处理的不再是孤立的提示,而是一个持续增长的长上下文。每一轮新增的内容可能只有几百个 token,但这些内容会不断累积,形成极长的历史上下文。

 

在传统推理场景中,性能瓶颈主要集中在计算能力上,例如 GPU 的算力和矩阵运算效率。但在智能体负载下,情况发生了变化。

 

由于是多轮对话、短内容追加的模式,大部分历史上下文都可以被复用。技术上,这体现在 KV-Cache(用于存储模型历史注意力计算结果的缓存)命中率通常可以达到 95% 以上。也就是说,大部分计算不需要重新做,只需要把已有的 KV-Cache 重新加载进来继续使用。

 

问题在于——加载这些缓存本身,变成了瓶颈。

 

换句话说,在智能体工作负载下,系统越来越呈现出“高 I/O 密集型”的特征。真正决定吞吐量的,不再是模型算得有多快,而是 KV-Cache 能不能被高效加载。

 

但主流的 PD 分离(Prefill-Decode Disaggregation)推理架构,存在天生缺陷:

 

  • Prefill 引擎网卡被占满长上下文带来海量 KV-Cache,预填充节点的存储网卡长期跑满,成为 I/O 瓶颈。

  • Decode 引擎网卡大量闲置解码侧只负责逐词生成,存储带宽利用率极低,资源严重浪费。

  • 负载失衡 + 网络拥塞单路径加载 KV-Cache,延迟敏感的生成流量与大数据传输互相干扰,集群效率上不去。

一句话:GPU 算力再强,也在等数据;网卡一边堵死、一边空闲。这就是 PD 分离架构绕不开的性能天花板

 

这种结构性失衡,使得系统整体吞吐量被预填充引擎“卡死”。理论上可以为预填充引擎扩容带宽,但在通用集群环境中,这种扩容成本高昂且难以落地。

 

因此,DeepSeek 认为,真正可行的优化方向不是单点扩容,而是重新设计 KV-Cache 的加载方式,让所有引擎的 I/O 带宽都被利用起来。

 

此前已有研究尝试缓解 KV-Cache 加载瓶颈。

 

例如,有方案将 KV-Cache 缓存在大规模分布式 DRAM 池中,并通过亲和性调度提升命中率。但这种方式对内存资源依赖极高,在强化学习推演等内存紧张场景下难以使用;而在在线服务这种工作集巨大的场景中,使用 DRAM 替代 SSD 成本过高。

 

也有研究尝试通过压缩或减少检索数据量来降低加载开销,但这些方法都没有解决一个核心问题:不同引擎之间存储 I/O 负载的不均衡。

 

DualPath:双路径加载 KV-Cache 及技术挑战

 

DualPath 通过创新双路径 KV-Cache 加载机制,从架构层面突破传统推理瓶颈

 

其核心思想很直接:KV-Cache 的加载不应当只围绕预填充引擎。

 

在传统架构中,KV-Cache 只能从存储直接加载到预填充引擎。而 DualPath 增加了一条新的路径——KV-Cache 可以先加载到解码引擎,再通过高性能 RDMA 网络转发到预填充引擎。

于是,系统中出现了两条加载路径:

 

  1. 存储 → 预填充引擎 PE(传统路径)

  2. 存储 → 解码引擎 DE → 预填充引擎 PE(新增路径)

 

系统可以根据实时负载动态选择路径,从而把一部分 I/O 压力转移到解码引擎,重新分配网络带宽,缓解预填充侧的带宽瓶颈。

 

本质上,这是一次对“数据路径”的重构,而非单纯的硬件堆叠。

 

搭配全局动态调度器,DualPath 可实时均衡预填充引擎与解码引擎的负载,彻底解决 PD 分离架构下 KV-Cache 读取负载失衡问题,为智能体长上下文、多轮交互推理提供底层算力支撑,也为即将到来的 DeepSeek V4 系列奠定关键技术底座。

不过,引入双路径并不简单。DeepSeek 在论文中指出了两个关键挑战:

 

第一,新增路径会引入更复杂的网络流量模式。如果管理不当,可能干扰模型执行中对延迟敏感的通信操作,反而拉低整体性能。

 

第二,在真实生产环境中,工作负载是动态且异构的。系统必须实时决定采用哪条加载路径,同时保证 GPU 和网卡资源都处于均衡状态。

 

为此,DualPath 引入了三项关键设计:

 

  • 优化的数据路径设计,确保在常见的预填充/解码比例下不会产生天然拥塞;

  • 以计算网卡为核心的流量管理机制,将 KV-Cache 传输流量与对延迟敏感的模型推理通信隔离;

  • 动态调度策略,实现预填充与解码引擎之间计算与网络资源的联合负载均衡。

系统实现

DualPath 基于自研推理框架实现,CUDA 内核整合了 FlashMLA、DeepGEMM 和 DeepEP,与当前主流的开源框架对齐;DualPath 在该框架上的修改量约为 5000 行代码。系统采用 3FS 作为分布式存储,并使用类 io_uring 的接口实现内核旁路,提升存储访问效率。

 

为了验证架构本身的效果,实验环境采用了高规格 GPU 集群:

  • 每台服务器:8 张英伟达 Hopper GPU + 双 CPU;

  • 每节点:8 张 400 Gbps RDMA 网卡(计算网络);

  • 另配 1 张连接 3FS 的存储网卡;

  • 计算网络与存储网络物理隔离;

  • 集群级 3FS 不设 DRAM 缓存,可跑满 400Gbps 存储带宽。

 

这种配置的目的很明确:排除网络瓶颈和缓存干扰,把性能差异集中到 KV-Cache 加载路径本身。

 

实验选取三类模型,覆盖不同规模和架构:

 

  • DeepSeek V3.2 660B(MoE 架构)

  • 其 27B 降尺度版本(内部实验模型)

  • Qwen Qwen2.5-32B(GQA 稠密模型)

 

前两者代表大规模稀疏 MoE 模型,后者为典型稠密模型。测试目标是验证 DualPath 是否对不同架构都有效。

 

离线场景模拟强化学习训练中的推演阶段:多个智能体同时运行,统计全部任务完成所需时间(JCT)。结论很直接:

 

  • 批次越大、上下文越长,DualPath 优势越明显;

  • 在部分大规模配置下,基于 SGLang + Mooncake 的系统甚至无法稳定完成任务;

  • 在 660B 模型上,DualPath 相比原始框架最高将作业完成时间缩短至 1/1.87,接近“零 I/O 开销”的理论上限(Oracle)

  • 27B 与 Qwen 32B 也呈现类似趋势。

 

这说明,在长上下文智能体场景中,瓶颈确实集中在 KV-Cache 的 I/O。

 

此外,实验还刻意放大每轮的追加 token 或生成 token 长度。结果显示:

 

  • 当追加长度增加(即 GPU 计算变重),原始框架性能逐渐逼近 DualPath;

  • 当生成长度增加(预填充频率下降),I/O 压力减轻,性能差距缩小。

 

这说明:当 GPU 计算成为瓶颈时,DualPath 不会额外拖慢系统;而当 I/O 成为瓶颈时,DualPath 优势显著。

在不同追加比例下,DualPath 对原系统的加速比在 1.82–1.99 倍之间。

 

论文测试了 1P1D、2P1D、1P2D 等多种配置(P=预填充节点,D=解码节点)。关键观察:

 

  • 原始系统只能利用预填充节点的存储带宽;

  • DualPath 可以利用所有节点的存储带宽;

  • 在所有比例下,DualPath 都显著优于原系统;

  • 平均加速比达 1.64 倍,最高 2.46 倍。

 

这从系统层面验证了论文的核心论点:在智能体负载下,存储带宽才是主导瓶颈,而不是算力

 

从实验结果可以抽象出一个更宏观的判断:在长上下文智能体负载下,模型算力已经不是决定性因素。真正限制吞吐的,是 KV-Cache 的加载路径,以及存储带宽在不同引擎间的分配方式。

 

DualPath 并没有减少 KV-Cache 数据量,也没有压缩数据,而是通过重构加载路径,让所有节点参与 I/O 分担。本质上,这是一次系统资源再分配,而不是算力扩张。

性能瓶颈正从“算得快”转向“数据调度得好”

 

在外界仍在讨论模型能力与参数规模时,围绕DeepSeek的两条线索正在交汇:一边是被曝提前向华为等国内芯片厂商开放新一代模型适配权限;另一边,是其最新论文提出的推理系统架构 DualPath——一套针对智能体长上下文场景重构 KV-Cache 加载路径的系统设计。

 

如果两者放在一起看,问题就不再只是“模型升级”,而是一次从硬件协同到系统架构层面的整体调整。

 

据知情人士透露,DeepSeek 已为包括华为技术在内的国内供应商预留数周时间,对即将推出的 DeepSeek V4 进行软件适配与性能优化。这一做法打破了行业惯例。通常,大型模型在正式发布前会向英伟达、AMD 等头部芯片厂商提供预览版本,以便在 CUDA、驱动和通信栈层面完成针对性优化,从而确保模型在主流 GPU 上获得最佳性能。

 

此前 DeepSeek 也曾与英伟达技术团队保持合作。因此,如果上述消息属实,这意味着其硬件协同策略正在发生变化。

 

但目前相关说法尚未得到官方确认。

 

与此同时,另一条消息显示,DeepSeek V4 Lite(代号“sealion-lite”)正在密集测试阶段。已披露的信息包括:支持 100 万 tokens 的上下文窗口,采用原生多模态架构,并在效果上显著优于当前网页端与 App 端模型。至少已有一家推理服务商获得访问权限,但签署了严格的保密协议。百万级上下文长度本身就是一个关键信号——它意味着 KV-Cache 规模将大幅膨胀,模型运行将高度依赖缓存复用与高带宽数据调度能力

 

这恰好与 DeepSeek 在论文中提出的 DualPath 架构形成呼应。DualPath 的核心思路是增加一条“存储—解码—预填充”的加载路径,使 KV-Cache 可以先加载到解码节点,再通过 RDMA 网络转发至预填充节点,从而将存储带宽压力在多个节点间重新分配。

 

如果将这一系统级优化与 V4 Lite 的百万上下文能力结合来看,其技术逻辑是连贯的。更长的上下文意味着更大的 KV-Cache;更大的 KV-Cache 意味着更重的 I/O 压力;而更重的 I/O 压力,恰恰需要通过类似 DualPath 的带宽重构机制来化解。在这种架构下,系统性能的决定因素更多取决于整体带宽调度能力与节点协同效率,而不是单卡算力的绝对领先。

 

但值得注意的是 DualPath 仍然基于 CUDA 实现,底层依然围绕 GPU 生态展开。当性能瓶颈从“算得多快”转向“数据调度得多好”时,不同硬件之间的竞争维度就会发生变化。算力差距仍然重要,但带宽组织能力、网络架构设计以及系统调度策略,开始成为同等关键的变量。

 

参考链接:

https://arxiv.org/abs/2602.21548

https://jokerwyt.github.io/