2026年1月

世界模型真的变天了!

今天,谷歌正式发布重磅世界模型原型产品“Project Genie”,只需一句话或一张图,就能一键生成可玩、可交互的实时虚拟世界。它的重磅程度,让谷歌“掌舵人”劈柴哥和 Google DeepMind 创始人哈萨比斯亲自为它站台。

在 Project Genie 生成的虚拟世界中,你可以用 WASD 键移动角色、旋转视角、跳跃,在生成世界自由探索。更重要的是,其生成画面的精细度、整体完成度,已经明显超出以往研究型 Demo 的范畴,在观感上直逼成熟游戏产品。

过去几年,世界模型一直被认为是通往 AGI 的重要路径,但始终存在一个根本问题:它们更像会动的视频,而不是真正的环境。

具体来说,早期世界模型普遍存在几大短板:

  • 生成世界质量偏低,结构简单

  • 难以实时交互,或只能交互一两步

  • 长期一致性差,画面和规则会“漂移”

  • 不符合物理和因果逻辑,更像梦境而非世界

而 Project Genie,第一次把这些问题同时拉到了可用水平。

Project Genie 是一个基于 Genie 3、Nano Banana Pro 和 Gemini构建的原型 Web 应用,其中的核心是谷歌最新的世界模型 Genie 3。

与以往“先生成完整视频”的方式不同,Genie 3 采用自回归生成机制:它会根据世界描述和用户操作,逐帧生成环境状态,而不是播放预先生成好的内容。

这带来了几个关键变化:

  • 长期一致性生成的世界可以在数分钟内保持稳定,不会快速崩坏;系统还能“记住”用户造成的关键变化,记忆时间最长可达约一分钟。

  • 真正的实时交互世界以 20–24 帧/秒运行,用户的操作会即时反馈到环境中,而非触发预设结果。

  • 更高质量的视觉表现生成画面分辨率约为 720p,整体真实感和细节水平明显高于以往世界模型,为智能体理解复杂环境提供了更可信的视觉基础。

谷歌早在 2025 年就将 Genie 3 称为“通往 AGI 的关键一步”。而在 Project Genie 的官方页面中,谷歌再次强调:

Genie 3 让智能体能够预测世界如何演化,以及自身行为如何影响世界,这是实现推理、规划和现实行动的基础。

可以说,在 Project Genie 身上,已经释放出一个非常明确的信号:世界模型正在从长期的前沿研究方向,正式迈入可落地、可探索的关键阶段

一旦世界模型能够稳定生成高质量、可交互、具备长期一致性的环境,其应用边界将被迅速打开。

无论是自动驾驶中的复杂场景模拟、具身智能的环境理解与决策训练,还是游戏开发、影视制作、互动教育与新型媒体内容创作,世界模型都展现出极具想象空间的潜力。

据 The Verge 报道,谷歌选择在这一时间点推出 Project Genie,部分原因在于希望观察用户的真实使用方式,从而发现此前尚未预料到的新应用场景。

Google DeepMind 产品经理 迭戈·里瓦斯透露,谷歌内部已经对 Genie 在电影制作、互动教育媒体等领域,帮助创作者进行场景可视化与世界构建的潜力感到兴奋。

目前,Project Genie 仍是实验性产品:

  • 单个世界最长探索 60 秒

  • 分辨率约 720p,帧率约 24fps

  • 仅向美国地区、18 岁以上的 Google AI Ultra 订阅用户开放

Project Genie 发布后迅速引发热议。马斯克第一时间发文祝贺

关于 Project Genie 的讨论,也在 X 上迅速扩散,不少网友将其称为又一个“变革时刻”。

对此,Project Genie 负责人之一 Jack Parker-Holder 表示:

Genie 3 感觉像是世界模型领域的一个分水岭。我们现在可以生成任何可想象世界的、持续数分钟的实时交互式模拟。这可能正是具身通用人工智能此前缺失的关键一环。

网友们玩疯了,在游戏世界释放创意

具体来看,Project Genie 的使用流程并不复杂。进入页面后,用户可以直接从 Google 预设的多个世界模板中选择,也可以完全自定义环境和角色,构建一个专属的虚拟世界。

为实现更精准的控制,Project Genie 会用 Nano Banana Pro 的能力,先为生成世界打个“草稿”。

整个页面被清晰地分成左右两部分:

  • 左侧用于填写环境的 prompt,例如地形结构、视觉风格和整体氛围;

  • 右侧则用于描述主角的形象与设定,并可选择第一人称或第三人称视角,从而提前确定进入世界后的体验方式。

完成初步设定后,Genie 会先生成一个缩略图,可以对生成内容进行预览和微调。如果符合预期,就能进入生成世界,开始实时交互与自由探索。Genie 3 的响应延时非常低,在控制角色移动时,会带来强烈的沉浸感。

在官方案例中,你可以把自己变成一个球,在草原上自由滚动。

可以看到,如果转换视角,球滚动留下的痕迹并不会消失,新生成的内容也不会覆盖旧区域。这一细节直观地体现了 Project Genie 所强调的世界一致性。

在另一个官方案例中,你可以变成刷墙工人,想刷哪面墙就刷哪面,整个虚拟世界可以实时交互,且看起来十分合理。

谷歌表示,这是想象力空间的无限释放,无论是自然世界或现实场景,还是构建动画、小说中的奇幻世界,甚至是突破时间与空间限制的未来世界,都可以被创造出来。

不少网友迅速上手,开始“放飞自我”式创作,其中,各类游戏风格世界不断涌现。

比如在沙滩上骑摩托:

更绝的是直接制作山寨版“任天堂”游戏。比如马里奥系列,《塞尔达传说》,《银河战士》。

即便抛开体验层面的不足不谈,Project Genie 在生成世界的质量与完成度上,依然足以令人震撼。这也难免让人产生进一步的联想,游戏从业者会不会大规模失业?

这一担忧并非空穴来风。根据 Informa 本周发布的游戏开发者大会(GDC)报告,33% 的美国受访游戏开发者、以及 28% 的全球受访游戏开发者表示,他们在过去两年中至少经历过一次裁员。Project Genie 可能会进一步扩大这种趋势。

不过,围绕 Project Genie 的能力边界,也有人提出质疑。

The Verge 的记者亲自上手试验后认为,从“游戏”的角度来看,Project Genie 所生成的“可玩世界”显得相当单调。

除了基础移动操作外,玩家几乎无事可做。没有任务目标,也缺乏音效反馈。更糟糕的是,输入延迟时有发生,甚至会出现角色失控、只能旋转视角的情况,严重影响整体体验的流畅度。

该记者还提到,在仅有 60 秒 的探索时间内,世界的一致性并不稳定。系统有时会“忘记”此前生成的内容,例如滚动的小球留下的颜料痕迹会突然消失,已生成的道路也可能被重新覆盖为草地。这些现象让人难以确认模型是否能够持续、可靠地维护同一个世界状态。

在内容生成层面,Project Genie 对知名游戏 IP 也存在明显限制。测试中,索拉、唐老鸭、高飞、杰克·斯凯灵顿等角色均无法直接用于生成可交互世界,相关内容在进入实际体验阶段会被系统拦截。

目前,与生成世界交互的智能体只能执行较为有限的操作,同一世界中多个模型之间也难以协同互动。此外,Genie 在渲染清晰文本、还原现实世界具体地点方面仍存在困难,智能体对控制指令的响应有时也会出现异常延迟。

对此,谷歌方面回应称,Genie 并非游戏引擎,团队更关注它在增强创意过程、提升构思能力以及加快原型制作方面所展现出的潜力。

在 Geinie 3 官网上也特别强调,目前产品仍处于早期研究阶段,因此会有:生成的世界可能看起来并不完全逼真,也不一定总是严格遵循提示、图像或现实世界的物理规律;角色有时可能难以控制,或者控制延迟较高;生成时间受限等问题。

Project Genie 团队深度揭秘关键问题

在 Project Genie 上线不久,其背后的核心团队第一时间接受采访,包括 Google DeepMind 研究总监 Shlomi Fruchter、Google DeepMind 的研究科学家 Jack Parker-Holder、产品 Diego Rivas,他们都对世界模型长期关注,在这次访谈中深度揭秘 Project Genie 的关键问题。

这次对话讨论了:什么是世界模型?为什么只能生成 60 秒?Project Genie 的研发历程是什么?它未来真正可能改变的是哪些领域?

他们首先承认 Project Genie 的强大确实源于谷歌视频生成技术的积累,但同时他们也强调,Genie 并不是更强的“视频模型”,而是人类第一次可以实时走进、操控、改变的生成世界。

其中的核心差异是,世界模型是逐帧实时生成,能与过去保持物理与视觉一致性,并且用户可随时干预。这对延迟、内存、算力的要求,比普通视频生成高得多,也是更前沿、更有挑战的方向。

针对不少人抱怨“60 秒不够”的问题,他们表示这是在服务成本、系统稳定性和体验质量之间做出的权衡。他们其实已经做出过更长时间的生成世界,但在实际测试中发现,随着生成时间拉长,世界的动态感反而会逐渐减弱。

研究员表示“与其花两分钟体验一个世界,不如花一分钟体验两个不同的世界,体验感会更好。”

针对模型的生成速度,他们表示已经够快了,短期内进一步“加速”并没有太大意义。接下来,他们更重要的研发方向,是降低算力成本,让这种能力能够被更多人真正用得起。

在产品定位上,他们并不把 Genie 看作一款游戏,而更像是一个正在快速演化的实验场:

  • 一方面,多人互动、长期一致性、复杂动态仍然是明确的技术瓶颈;

  • 另一方面,娱乐、教育、具身智能、机器人训练等方向,已经展现出非常清晰的应用前景

回顾产品研发历程,从论文阶段的 Genie 1,到今天普通用户可以亲自上手体验的 Genie 3,这背后其实是谷歌一整套高度协同的跨部门合作。

谷歌实验室与谷歌创意实验室是研发的核心力量,而服务团队、基础设施团队和沟通团队则共同兜底,确保这项起源于强化学习的前沿研究,能够被真实用户理解、体验并持续使用。

当团队回看去年八月时,他们很清楚,当时外界已经迫不及待想“走进这个世界”,但 Genie 仍然只是一个规模庞大的研究项目。即便如此,研发人员脑海中已经浮现出一系列潜在应用场景,其中最清晰的方向之一,正是具身智能。一个标志性的例子,是他们与 Simmer 项目的长期合作。

Simmer 是由双子座模型驱动的目标导向智能体,能够在 3D 世界中执行复杂任务。过去,它只能在少数几个固定游戏环境中训练;而现在,借助 Genie 3,只需一句文本指令,就能生成一个全新的、甚至是照片级写实的虚拟世界,把智能体直接“放进去”完成任务。

从 Nano Banana Pro 的图像创作,到谷歌视频生成的成熟,再到可交互的世界模型 Project Genie ,生成式技术正在构成一个连续体,世界模型将成为第三次技术跃迁。

以下是播客的更多细节,欢迎来看:

为什么只能 60 秒?

主持人:我很好奇,这背后的物理逼真度,是不是和我们在 VO(谷歌的视频生成模型)项目上取得的研究突破有关?感觉两者之间有相似之处。

研究员:二者绝对是相关的,而且世界模型的研发难度其实更高。普通的视频模型,能在整个视频的时间线上自由调整过去和未来的帧,自由度很高 —— 就像有一块画布,模型能随时间生成视频,在画面的各个位置做微调,让整体效果连贯美观。

世界模型的难点在于,世界是持续演变的,每一帧的输入都是未知的,模型必须保证生成的画面既和过去的内容连贯,又能匹配用户当下的操作,所以技术难度会大很多。

其实开发 Genie 1 时,我们用的是 Imagine 模型,当时我们的模型效果并不好,而且想要生成合适的图像也非常困难。Nano Banana Pro 是在Genie 3 之后推出的,技术进步的速度真的令人惊叹。也许未来某一天,我们定义虚拟世界的方式,将不再局限于图像和文本,但就目前而言,这种方式已经给了用户足够的创作灵活性。

主持人:这个模型的复杂度上限在哪里?比如能不能在同一个世界里加入大量并行的互动元素?模型会在什么情况下出现效果衰减?

其实 Nano Banana Pro 就是个很好的例子,如果一张图片里有 10 个人脸,想要对这张图进行编辑,模型就容易出问题。所以我想知道,Genie 3 的自然性能边界在哪里?

研究员:这个模型肯定不是完美的,目前它还只是一个研究预览版本。我们希望让大家亲自体验,看看它的优势在哪里,不足又在哪里,我们也能从用户反馈中学习和优化。

目前模型在各类创意环境的视觉呈现上做得不错,画面可以非常精致,但在世界的动态表现上还有短板 —— 有时候初期的动态效果很好,但时间久了,动态感会逐渐减弱,这也是我们正在优化的点。不过它的表现已经足够令人惊喜了,所以还是建议大家亲自上手试试,看看哪些玩法能达到理想效果。

研究员:不过说到延迟问题,还有很多技术点需要考虑。Genie 3 的研发有一个核心约束:我们希望实现特定操作频率下的实时低延迟,也就是说,用户操作的往返延迟要极低。同时,内存也是一个巨大的约束 —— 模型的上下文长度越长,通常算力成本就越高,运行速度也会越慢。

所以研发的核心挑战,就是平衡这些相互冲突的目标。而在研究层面,我们正在所有这些领域持续优化,我们相信,模型的性能会不断提升,变得更强大、更快、更经济,这也是行业的整体发展趋势。

主持人:我还有个问题,模型的生成时长是人为限制在 60 秒,还是真的能实现 3 到 5 分钟的连续生成?

研究员:其实我们已经做出过能连续生成更久的演示版本了,但我们觉得 60 秒是一个比较合适的时长 —— 既能让用户充分体验虚拟世界,又能保证为足够多的用户提供服务,这其实是在服务成本上做的权衡。

而且就像我们之前提到的,生成时间越长,世界的动态感会逐渐减弱。所以我们觉得,与其花两分钟体验一个世界,不如花一分钟体验两个不同的世界,体验感会更好。当然,如果用户反馈希望延长时长,我们也会做出调整。

这也和虚拟世界的类型有关,比如如果你在体验高山速降滑雪,两分钟的时长会很过瘾,因为整个过程是持续的动态体验;但如果只是探索图书馆,两分钟可能就没那么有趣了。

主持人:是啊,人们总是能很快适应新的技术体验。但对我来说,这个模型的表现依然令人难以置信。你之前被问到能不能让模型运行得更快,现在的速度已经到极限了吗?

研究员:在当前实时交互需求下,生成速度已经足够快,短期内进一步加速的意义不大。因为模型是实时生成虚拟世界的,速度再快其实也没有意义了 —— 它的生成速度已经和用户的体验速度完全匹配。接下来我们的研发重点,会放在降低算力成本上,这样才能让更多人用上这款产品。同时,在保持速度的前提下,不断增加新功能,这本身也是一个巨大的挑战,我们希望在各个方面都把模型做得更好。

背后的故事:谷歌跨团队协作

主持人:聊完当下的体验,我特别想知道模型的未来迭代方向。不过在聊未来之前,我们先回顾一下研发历程吧。我们八月份发布了 Genie 3 的首支演示视频,之后启动了可信测试,不断迭代产品、搭建基础设施。能不能跟大家快速讲讲,从一支惊艳的演示视频、小规模的早期测试,到正式推出面向用户的精灵计划,这中间都经历了什么?

研究员:首先,八月份发布模型和演示视频后,我们让一小部分人体验了产品,核心是为了收集反馈 —— 因为这是一款全新的应用,一种全新的体验,我们需要思考如何负责任地将它推向市场。

从那以后,我们的大部分工作都集中在基础设施、服务架构和成本控制上,毕竟我们希望能让尽可能多的用户体验到它。而美国的谷歌 Ultra 订阅体系,能让我们触达足够多的用户,收集到第一手的反馈:比如用户觉得哪些功能有用,会如何和产品互动,哪些玩法体验最好。这段时间里,我们也在持续完善可信测试项目。

这其实是模型开发周期中最核心的阶段,因为我们能从不同类型的用户身上学到很多东西,无论是创意工作者,还是教育领域的从业者,都能给我们带来丰富的洞察,让我们知道模型目前的实际应用价值、未来的发展方向,以及哪些体验是用户最期待的。

回头看八月份,当时我们知道大家肯定想体验这款产品,但它那时还只是一个大规模的研究项目。我们脑海里有很多应用场景,比如智能体、机器人这类具身智能领域,都能用到这项技术。去年年底还有一个和我们类似的项目发布,他们也用Genie 3 来训练游戏智能体。

从消费端的角度来看,我们觉得这个产品会很有吸引力,所以想收集用户反馈,但当时也不确定是否已经到了面向更多用户发布的时机。而迭戈主导的可信测试项目,让我们发现,用户第一次上手这款产品时,都会有惊艳的体验。我们希望深入了解更多的应用场景,所以这次的发布,也是我们在这方面迈出的一大步。

一年前,我根本没想到这个模型能有这么强的吸引力,但现在它已经成为一款非常有趣的产品,我们也很期待大家会用它来做什么。

主持人:聊完产品和技术,我们再来聊聊谷歌的跨团队合作吧。显然,从你们的分享和幕后工作来看,打造这款产品的难度非常大。谷歌内部有哪些团队参与了 Genie 3 和 Genie 的研发?

研究员:幕后参与的团队非常多,谷歌实验室、谷歌创意实验室是核心 —— 画廊里的那些虚拟世界,大多是创意实验室的作品;还有服务团队、基础设施团队,基本上有一个完整的幕后团队在推动这项工作。从八月份发布模型到现在,我们一直在全力冲刺,所有团队的付出都堪称英勇。

我们还和沟通团队深度合作,因为想要向大家解释一款全新的模型,一种大家从未体验过的技术,是一个非常细致的话题 —— 它起源于强化学习这个相对小众的领域,现在却被媒体、社交媒体上的各类人群广泛讨论,所以用正确的方式传递这项技术,非常重要。

回顾这个领域的研究起点,我们甚至不确定这项技术能否成功落地。而现在,我们让它实现了实时交互,达到了不错的画质,完成了从研究构想到发布模型,再到推出面向用户的体验产品的闭环,这一点让我非常兴奋。这并非理所当然,也充分体现了谷歌内部跨技术栈的团队协作能力,这种能力非常独特。

主持人:我们在镜头外还聊过,不仅是 Genie 3,谷歌所有模型的能力都在不断拓展,而这和模型的训练方式息息相关。杰克,你之前还尖锐地提到,这些模型其实并没有针对任何特定的应用场景进行训练,却能在各个领域实现很好的泛化能力,能不能再聊聊这一点?

研究员:没错,我们一开始其实并不知道这个模型的具体应用场景。去年年底,Genie 团队还在做纯粹的研究项目,Genie 1 最初只是一篇研究论文,和 VO(谷歌的视频生成模型)完全不同。

与此同时,我们还在做 Doom 游戏引擎的相关研究,这项研究充分展现了实时交互的潜力,但它仅适用于 Doom 这一个特定的游戏世界,迭戈可以再聊聊这一点。

另外,2024 年 12 月 VO(谷歌的视频生成模型)2 的发布,在 AI 领域已经是很久以前的事了,但当时我看到它的效果时就觉得,视频生成技术已经成熟了,视觉质量达到了行业前沿,值得我们深入探索。

于是我们达成共识,认为这项技术的潜力无限,随后组建了跨团队的研发小组,汇集了各个领域的专家 —— 他们都在不同的技术领域有积累,我们相信把这些技术结合起来,会产生不可思议的效果。而我们的研发,并非针对某个特定的下游应用场景,而是因为它蕴含着无数的应用可能。

最酷的是,我们脑海里有一些预想的应用场景,比如和 Simmer 项目的合作,我们和这个项目的合作已经有很长时间了,他们也参与了 Genie 2 的研发,体验过 Genie 2,现在已经基于 Genie 3 发布了相关产品。

Simmer 是我们最强大的目标导向智能体之一,能在 3D 世界中互动,是由双子座模型驱动的 —— 你可以在 3D 世界中向它输入文本指令,它就能完成各种不同的目标,泛化能力非常强,还能通过自我提升学习。这也是我们迈向通用人工智能、具身智能的重要方向。

去年年底我们发布了这款智能体,他们就用 Genie 3 的虚拟世界来探索智能体的能力。要知道,Simmer 原本只在几款游戏中接受过训练,但现在借助 Genie 3,你只需输入文本,就能创建一个全新的、甚至是照片级写实的虚拟世界,然后把智能体放进去,看它完成各种任务。这两个项目的结合,可以说是水到渠成。

未来的应用领域:娱乐、教育、具身智能

研究员:从应用层面来说,我个人对娱乐和教育领域的应用最期待。我们希望让更多人体验这款产品,看看凭借现有的技术,现在能打造出哪些应用。教育领域是我们重点关注的方向,比如让人们在虚拟世界里互动学习 —— 想象一下,能为用户打造一些他们在现实中无法体验的场景,比如一个孩子害怕蜘蛛,我们可以打造一个满是蜘蛛的房间,让孩子在虚拟世界里慢慢适应,克服恐惧。我的孩子就怕蜘蛛,所以我觉得这种个性化的全新体验,价值非常大,这也是我们近期的研发重点。

另一方面,我们之前也聊过,机器人技术和具身智能领域的世界模型,潜力也非常大。当然这个领域还有很多研究工作要做,但我个人对它充满期待。简单来说,核心思路就是:如果一个模型能模拟现实环境,那我们就可以用它在虚拟世界里训练机器人,或是让具身智能体在虚拟世界里学习,甚至实时辅助智能体做出决策。

Genie 计划虽然现在已经很惊艳了,但它只是一个起点。未来我们会和谷歌实验室继续深度合作,不断优化产品的功能、操控方式、应用架构等;也会拓展更多的使用场景,不局限于Genie 计划这一个应用,还会推出开发者 API,让更多开发者参与进来。

不得不说,开发者总能发掘出产品的商业价值,找到极具经济影响力的应用场景,这也是我觉得很有意思的一点 —— 除了娱乐,世界模型还能在哪些领域找到产品市场契合点。

而且很多功能在不同的应用场景中是相通的,比如更广泛的交互性。可以肯定的是,机器人技术的发展,不可能只靠方向键来实现,未来的机器人助手需要更多的操控方式,而这和虚拟世界的交互研发是相通的。

八月份发布 Genie 3,让我们成为首批推出这类模型的团队,也让我们能和谷歌内部的各个团队展开合作。我们会认真吸纳所有的用户反馈,把大家提出的建议都列出来,成为下一代模型的研发方向。我之前跟杰克说过,我们只实现了目标的 50%—— 因为我们总是会设定极具野心的目标,这个领域还有太多可以探索的地方,模型还有很多不足,需要我们不断优化。

这个领域的发展空间巨大,我们才刚刚起步。就像写论文一样,一个项目完成后,你马上就会想,下一个项目可以加入哪些功能,做得更好。

现在社区里也出现了很多有趣的世界模型,有些和 Genie 3 很相似,但我们的目光已经放得更远了。

怎么玩这个产品?

主持人:除了研发历程和未来规划,还有没有什么想跟大家分享的?比如对于即将体验这款模型的用户,你们有什么建议?毕竟你们比普通人花了更多时间研究和使用模型。

研究员:我建议大家尝试个性化创作,打造属于自己的、其他系统无法实现的世界。当然,用它打造游戏环境也很有趣,但这类场景其他系统也能做到;而把现实中的专属事物 —— 比如一个玩具、一张照片,或是让自己以特定风格出现在真实的环境中,这种体验是独一无二的。

这让我想起了 VO(谷歌的视频生成模型)早期的一个研究项目:有人用 VO(谷歌的视频生成模型)为阿尔茨海默病患者重现童年记忆,让他们在虚拟世界里重温过去,这个项目特别棒。所以我觉得,把个人专属的事物融入虚拟世界,让它们 “活” 过来,这种互动方式非常有价值,大家可以试试这个方向。

另外,大家肯定会发现,模型的提示词创作目前还不够完善,但这恰恰是机会。几年后当这个模型变得非常成熟时,大家会想起现在这个阶段,就像我们现在看待 VO(谷歌的视频生成模型)3 一样 —— 现在 VO(谷歌的视频生成模型)3 的每个提示词都能生成优质视频,精灵 3 号的每个提示词基本也能实现预期效果,但在早期,提示词的创作至关重要,甚至有人会花 10 到 20 分钟精心打磨一个提示词。

所以如果第一次创作的效果不好,别放弃,这款全新的模型,可能会以你意想不到的方式呈现出惊喜的效果。而且亲自上手体验,你就不是在消费一款产品,而是在探索前沿技术。

主持人:太认同了,“探索前沿技术” 这句话简直可以当作产品标语了。我还有一个觉得很有趣的点:当被动的媒体消费变成交互式的体验,会发生什么?这是一片全新的未知领域。过去也有人做过尝试,但现在有了这种真正定制化的交互式媒体叙事,它会给整个媒体和娱乐行业带来什么影响,真的太值得期待了。

研究员:还有一个玩法也很有趣,你可以在虚拟世界里设置挑战,把这个世界分享给别人,让对方完成任务,比如从 A 点走到 B 点。这是一种基础的、有目标的游戏体验,现在的模型已经能实现了。比如那个球的场景,你可以让别人用球写出自己的名字,这类简单的挑战都能设置。

就像杰克说的,现在的体验虽然还比较基础,但它蕴含着巨大的创意潜力。比如还有一个带环的场景,你可以操控角色穿越环道,体验飞行的感觉,这也是用户发掘的玩法。

人们还经常问,行业的前沿在哪里,我们下一步要做什么。我经常会做一件事:长时间沉浸在 Genie 3 的第一人称写实世界里,然后看向窗外,对比虚拟和现实的差距。我认为最终,虚拟世界会和现实世界变得几乎无法区分,虽然今天我们不深入聊这个话题,但从模型的性能发展来看,这显然还有很长的路要走。但如果能生成和现实高度逼真的世界,在里面自由移动、互动、完成各种事情,那该多不可思议。

而这也是驱动我们开展这项研究的核心愿景:想象你拥有一个宇宙的副本,你可以在其中随心所欲。显然,这个副本有巨大的应用价值,能用到很多领域。这虽然是一个非常远大、甚至可能无法实现的目标,但它就像北极星一样,一直指引着我们。

比如我们这次把恐龙鲍勃放进虚拟世界,其实就是在重构现实空间,给现实事物做有趣的增强。未来这方面的探索,一定会非常有意思。

主持人:那到 Genie 5 的时候,我们可能真的会分不清自己是在现实还是在模拟世界里了。

世界模型是第三次技术跃迁

主持人:我还有一个有点尖锐的问题想问问大家:你们觉得,大多数人体验到世界模型的时间线会是怎样的?世界模型会先通过企业端影响普通人的生活吗?比如企业利用世界模型提高生产效率,打造更好的日常产品;还是说,未来普通人的日常生活中,会直接和世界模型产生互动?如果是后者,这个时间线大概会是多久?

研究员:这其实取决于你如何定义世界模型。如果是指交互式的视听体验类世界模型,我认为今年、明年,就会有越来越多的人接触到它,我们也会看到它在一些领域大放异彩,最终成为很多应用的基础功能。

但就像现在的视频生成技术,虽然发展很快,但真正融入普通人日常生活的比例其实并不高,世界模型也需要时间来完成用户普及,找到合适的应用场景—— 毕竟视频和图像不同,世界模型又和视频生成不同。

而如果是具身智能领域的世界模型应用,很难给出具体的时间线,但这个领域已经在取得不错的进展了。

另外,用户的人群特征也很重要:有些经常接触交互式媒体的人,会成为世界模型的早期使用者,他们知道该如何体验;但如果把它交给一个对前沿技术不感兴趣的家人,他们可能会觉得无从下手,体验不到产品的魅力。

但具身智能相关的应用,可能在未来 1-2 年就会走进现实,普通人会在生活中直接接触到,所以最终的普及时间,还是取决于用户所处的技术接受曲线位置。

还有一点,Genie 计划也印证了一个趋势:生成式技术正在形成一个连续体,从 Nano Banana Pro 的图像创作,到 VO(谷歌的视频生成模型)的视频生成,再到现在Genie 3 的交互式实时媒体创作,成为第三个核心支柱。我们希望未来有更多人能体验到这个连续体上的各类创作体验。

主持人:我特别期待看到行业的发展趋势,毕竟 VO(谷歌的视频生成模型)和 Nano Banana Pro 的发展过程中,都出现过一些爆红的玩法,都是我从未预料到的,太疯狂了。

研究员:世界模型的发展,和图像、视频生成还有些不同。图像和视频生成的作品,能被数百万人观看,一个人的创作可以被广泛传播,家人、朋友都能看到;而世界模型的独特之处在于,你可以在探索的过程中,不断改变周围的世界,这开辟了很多我们未曾考虑过的新途径、新玩法。

图像和视频生成,本质上是用新技术替代或自动化了过去的一些创作方式,当然也带来了新的能力和限制;但世界模型,实现了很多过去根本不可能做到的事情,这是它最大的不同,当然二者也有很多相似之处。

还有一个我们非常兴奋的想法,大家在演示中也能看到端倪:用户可以在现有虚拟世界的基础上继续创作,这样就会形成很多有趣的世界分支,还能追溯创作源头。这方面的潜力非常大,值得我们深入探索。

Genie 计划上线时,用户可以下载自己的虚拟世界演示视频;未来我们还会探索更多的世界分享方式,让大家能以更有趣的方式在别人的世界基础上创作。

主持人:太酷了,我还想要一个 “世界档案” 功能,这样大家就能看到我所有的创意想法了。

从世界模型的发展来看,技术进步的节奏是怎样的?显然我们已经看到了巨大的进步,图像生成、VO(谷歌的视频生成模型)视频生成、核心双子座模型,都取得了长足的发展。世界模型是不是也在遵循同样的发展轨迹,到处都是触手可及的技术突破,同时受益于算力规模和推理能力的提升?

研究员:可以这么说。图像生成技术显然比视频生成更成熟,视频生成和世界模型之间的差距,我无法准确衡量,但可以肯定的是,世界模型是超越视频生成的前沿技术。

最新一代的视频生成模型,画质已经比Genie 3 高很多了,我们也不指望Genie 3 现在能生成极致精美的视频,因为实时交互的约束,是普通视频生成模型所没有的。所以世界模型的发展,可能会比视频生成稍慢一些,但它能带来全新的体验。

说实话,我们现在仍处于技术快速进步的阶段。硬件始终是一个巨大的约束,这对所有模型来说都是如此。行业的整体趋势是,在成本基本不变的情况下,让模型的运行效率越来越高。但最终,我们还是需要更易获取的硬件支持—— 比如希望未来人们能直接在自己的设备上运行这类模型,实现无延迟的即时体验。

目前高性能的 TPU、GPU 还并非人人可得,硬件的发展速度因为一些实际原因,会比模型研发慢一些,但这也是我们的未来方向 —— 希望到 Genie 5 时,大家能在手机上运行完整的通用模拟系统。

这一点我们也讨论过,谷歌拥有垂直技术栈的优势,这也是我们在谷歌、在深度思维工作的魅力所在:我们既能站在模型研发的前沿,又能利用谷歌最好的硬件来支持模型的运行。而且专门为世界模拟打造的硬件,本身也极具发展潜力,它就像通往另一个维度的入口,点击就能进入,充满了新鲜感。

传送门:

https://labs.google/projectgenie

链接:

https://blog.google/innovation-and-ai/models-and-research/google-deepmind/project-genie/

https://deepmind.google/models/genie/

https://www.youtube.com/watch?v=Ow0W3WlJxRY&t=4s

https://www.theverge.com/news/869726/google-ai-project-genie-3-world-model-hands-on?view_token=eyJhbGciOiJIUzI1NiJ9.eyJpZCI6ImZCakl0bmxFNGwiLCJwIjoiL25ld3MvODY5NzI2L2dvb2dsZS1haS1wcm9qZWN0LWdlbmllLTMtd29ybGQtbW9kZWwtaGFuZHMtb24iLCJleHAiOjE3NzAxNDAwNTYsImlhdCI6MTc2OTcwODA1OH0.q5OBTD_V36-65oc1EGqPxKYCZF00c7ODvifvagVcwbA&utm_medium=gift-link

一招不慎,满盘皆输。并发问题看似简单,却隐藏着巨大的风险

近日,我们系统遭遇了一次生产环境事故:客户反馈同一类型的呼入或呼出通话记录存在重复。经过紧急排查,发现问题根源在于当电话呼入或呼出时,同一时刻有相同的录音盒推送事件,而我们的系统对推送事件没有做并发编程处理,导致重复记录。

这次事故让我们付出了代价,也让我们深刻认识到并发编程在现代软件开发中的重要性。今天,就跟大家分享一下我们从这次事故中总结出的并发编程方法论。

一、什么时候我们需要考虑并发编程?

并发编程并非银弹,但在以下三种情况同时出现时,我们必须予以重视:

多线程场景:同一方法被多个请求/线程同时执行(如Web接口、定时任务、硬件回调等)。在我们的案例中,多个录音盒事件同时推送就创造了这样的多线程环境。

共享资源访问:多个线程都在访问同一个资源(如全局变量、数据库里的一条记录、内存中的Map或文件)。我们的通话记录表就成了这个共享资源。

包含"读-改-写"的复合操作:先查询是否存在记录(读),然后判断是否插入(改),最后执行插入操作(写)。这类复合操作在并发环境下极易出现问題。

二、常见的并发业务场景

并发问题不仅限于我们的通话记录系统,在日常开发中随处可见:

库存扣减/抢购场景:100个人抢1件商品,不能超卖为负数。

金额/积分操作:账户余额的加减,需要保证不会覆盖他人的更新。

唯一性判定(幂等性):同一订单不能重复支付,同一号码的通话信号只记录一次。

流水号/序列号生成:需要保证生成的ID全局唯一。

三、并发编程处理方法及性能对比

不同的并发处理方案在性能上差异显著,以下是常见的几种方案,按性能从高到低排列:

1. 无锁设计 - 性能最佳

通过业务逻辑避免共享资源竞争,例如使用ThreadLocal(每个线程一份数据),或将任务按ID取模分配给特定线程处理。无锁设计完全避免了锁竞争,性能最高。

2. 原子类 & CAS(自旋锁/无锁算法)

利用Java内置的AtomicInteger、AtomicLong等原子类,底层通过CPU指令保证原子性。适用于简单的计数器、状态切换等场景,性能非常高。

3. 乐观锁

不阻塞线程,先执行操作,提交时通过版本号或时间戳判断是否有冲突,如有冲突则重试。读多写少且冲突几率小的场景下表现良好。

4. 悲观锁

传统锁机制,如synchronized或ReentrantLock,在操作前先获取锁,确保同一时间只有一个线程能执行临界区代码。写操作多、冲突严重的场景下适用。

5. 分布式锁

通过Redis(setnx)或Zookeeper等实现跨JVM的锁机制。适用于分布式系统环境,但由于涉及网络I/O,性能相对较差。

四、性能差异的根源

为什么不同并发方案性能差异如此之大?主要来自三方面开销:

上下文切换开销:当线程拿不到锁被挂起,CPU需要保存当前线程上下文并恢复另一个线程的上下文,这个过程消耗大量CPU资源。

等待时长:锁粒度过大(如锁住整个方法而非仅锁核心逻辑)会导致大量线程排队等待,降低系统吞吐量。

网络/序列化开销:分布式锁需要跨网络通信和数据序列化/反序列化,比本地内存操作慢几个数量级。

五、并发编程实战心法

基于这次事故的教训,我们总结出以下实战经验:

锁粒度要尽可能小

  • 差:直接在方法上加synchronized(锁住整个类实例)
  • 好:使用synchronized(object),只锁受影响的代码块
  • 优:根据业务类型加锁,只对特定业务逻辑分支加锁

善用数据库约束:即使代码层加了锁,也应在数据库层设置UNIQUE约束(唯一索引),为数据一致性加上双保险。数据库能守住最后一道防线,避免产生脏数据。

警惕"先读-再判断-再写"模式:这种模式在并发环境下几乎100%需要加锁或使用原子操作。开发阶段就应识别出这类模式并提前设计并发控制策略。

合理选择并发模型:根据具体场景选择合适的并发模型,如基于多线程的模型、基于事件驱动的模型或基于协程的模型等。不同模型有不同优缺点,需结合实际需求选择。

总结

并发编程是现代软件开发不可或缺的重要技能。通过这次生产环境事故,我们深刻认识到并发问题的重要性与隐蔽性。一个看似简单的通话记录功能,在并发环境下也会产生严重的数据不一致问题。

希望我们的经验教训能够帮助大家避免类似的坑。在系统设计初期就充分考虑并发情况,防患于未然,才能构建出更加稳定、可靠的系统。

你是否也在开发生涯中遇到过棘手的并发问题?欢迎在评论区分享你的经历和解决方案!

狠狠的薅资本主义的羊毛。
我加入了 ChatGPT Team 5¥/年、Google AI Pro 10¥/年、Duolingo Super 34¥/年、Apple One Premier 73¥/三月。
年纪轻轻就实现了资源、算力和空间自由,人生大有可为啊。
你们呢?

在去中心化社交、数字身份与全球连接变得越来越重要的时代,很多人开始思考一个基本问题:怎样在保护隐私的前提下,实现更稳定、更自由的网络体验?

今天想跟大家聊聊一个与隐私、安全和灵活访问密切相关的工具 —— Proxy-Man https://proxy-man.com/ ,它不是中心化平台,但可以作为去中心化体验路上的有力补充。]( https://proxy-man.com/ ),它不是中心化平台,但可以作为去中心化体验路上的有力补充。)

🔎 为什么 Proxy-Man ?

在去中心化生态下,用户更关心个人数据的掌控权,而不希望平台通过手机号、IP 地址等个人信息建立长期跟踪机制。

📌 隐私优先
传统网络访问往往直接暴露设备真实 IP 和地理信息,给一些去中心化/安全敏感型用户带来风险。而 Proxy-Man 提供的各种代理节点,可以作为你连接网络时的一层“隐形外壳”,强化匿名性、保护访问隐私。

📌 灵活多节点策略
去中心化应用常分布在世界多个地区。无论你想从欧洲节点还是亚洲节点访问,都可以通过 Proxy-Man 选择不同的出口节点,帮助实现更稳定、快速的链路体验。

📌 与多身份管理自然兼容
在探索去中心化账户时,有时会遇到多账户并存、重复注册、地域验证等问题。Proxy-Man 让用户能够在不同网络环境下高效管理多身份,而不会因频繁 IP 跳变带来混乱体验。

💡 Proxy-Man 最适合的几类使用场景

🔹 全球连接与跨区域访问
当访问去中心化社交平台或 DApp 时,受限于不同地区政策或网络策略时,一个稳定的代理节点就能极大提高访问体验。

🔹 测试多身份网络行为
作为社区成员,你可能希望测试不同身份在不同网络环境下的交互行为。Proxy-Man 节点的动态切换可以让这种测试更真实、更可控。

🔹 增强隐私保护
一些应用在默认设置下会泄露 IP 地址或位置信息。Proxy-Man 的代理架构就是为了弱化这种信息泄露,在保障访问顺畅的同时增强隐私保护。

🛠 Proxy-Man 的核心卖点

📌 多协议支持
Proxy-Man 不仅支持常见 HTTP/HTTPS 代理,还覆盖 SOCKS5 等协议,这意味着无论是网页浏览、数据抓取还是程序内部调用,你都可以保持一致且灵活的访问策略。

📌 全球节点资源
Proxy-Man 的节点分布覆盖多个地区,无论你希望体验不同国家的网络环境,又或希望请求在本地与国外环境间自如切换,都能够快速进行配置。

📌 操作简洁、可扩展性强
Proxy-Man 并不要求你有复杂的技术背景,只需几步配置即可开始使用。对于需要自动化、批量访问或调试脚本的用户,它也能轻松集成。

📌 可与身份隐私策略结合
在 Wadesk 或其他去中心化应用中经常需要处理私人信息,Proxy-Man 有助于为手机号注册、节点访问等场景构建更隐私安全的配套体系。

📊 实际体验效果分享(来自社区实操反馈)

很多用户在使用 Proxy-Man 时给出了以下反馈:

🔸 在跨区域内容或协议访问测试中,节点稳定性显著提升
🔸 多身份场景下访问体验更流畅、账户分离更清晰
🔸 对于隐私保护配置而言,比单纯依赖本机网络更加可靠

Proxy-Man 不是单纯的“代理工具”,它是一种补充现有网络策略的策略性工具,特别适合关注隐私、去中心化体验优化、多身份管理的用户使用。

在这个数字身份日益重要的时代,希望每个人都能更自由、安全地掌控自己的网络行为,而不被信息追踪或地域限制所束缚。

只记得申请 www 证书还是@(空)证书会默认带两个地址,www 和@(空)。今天配置 SSL 的时候才知道通配符(*.xxx.com)不能用在@(即:xxx.com)上,只能作用于.xxx.com前面必须有主机名,不能为空,真是当了一次小丑。🃏

pro 订阅,这个月 auto 用掉 1.9 亿 tokens US$72.30 。pro 订阅不是每个月只有$20 吗,是因为我是年付$192 的关系,所以扣的是整年的金额吗

ClawdBot 是一个开源的自托管个人 AI 助手项目,由开发者 Peter Steinberger 创建。它允许你在自己的设备(如 Mac、Windows、Linux 电脑或服务器)上运行 AI 助理,通过日常聊天工具(如 Telegram、WhatsApp、Discord、Slack、iMessage 等)与之互动。

主要功能
执行实际任务:浏览网页、运行代码、自动化日常操作、日历管理、处理邮件、航班值机等。
自我扩展:如果缺少某个功能,它可以自己编写代码(称为“Skill”)并安装到自身,实现“边用边进化”。
隐私优先:完全本地运行,不依赖大公司云服务(只需 API 密钥调用如 Claude 等模型),数据留在自己设备上。
安装简单:通过 npm 安装,配置后在聊天 app 中直接命令它做事。
安装步骤
以 macOS/Linux 为例,在终端运行

复制
curl -fsSL https://clawd.bot/install.sh | bash

自动检查环境,并且安装最新版本

image

安装结束后,开始初始化配置,用方向键选择,空格键确认

image

选择「Yes」,同意风险提醒

Onboard 模式选择「QuickStart」
Model provider 根据个人情况选择,这里我选择的是「Anthropic」,认证模式有三种,我选择的「paste setup-token」,模型默认「opus-4-5」

image

渠道选择「Telegram」,其他也有,按需配置

image

在 Telegram 中发起 @BotFather 对话,新建 /newbot,获得 token,复制粘贴回配置中

image

Skills 配置,不熟悉可以跳过,选择「Skip for now」

image

一系列 API 配置,若有的话可以配置上,没有就都跳过

image

Hooks 配置,也可以「Skip for now」

image

启动 Gateway,基本就大功告成啦 🎉,可以网页访问面板进行对话

image

试试在 Telegram 中开始对话
1.首先,在 TG 中与个人 bot 对话,获得 Pairing code
2.然后,复制粘贴到终端中,并运行

image

3.现在,你可以在 TG 中跟你的未来工作伙伴交流啦 🎉

image

以上就是 ClawdBot 的安装教程

前言

准备搭建一个公司自用的 iot 平台,要求实现设备监听和 rag 知识库,但是公司现有的开发人员包括我在内只有 3 人,都是 Java 开发,前端是兼职的,3 个人的开发水平不一,另外两位没有接触过响应式编程以及 spring ai 和 langchian4j
看了下开源的 iot 平台,感觉 jetlinks 不错,但是都是用的响应式编程,可能会有一定的学习难度,企业版的功能基本符合客户预期,就看公司舍不舍得出钱了

考虑

webflux 确实感觉有点反人类,还要配合 r2dbc 使用才行,可能就算是用 jetlinks 到时候估计也会有一大堆问题,看能不能先直接上 jdk25 的虚拟线程,还是用传统开发模式,对于设备实时监听和 rag 的时候用 websocket 和 sse

摘要:本文整理自阿里采集分析平台工程技术负责人 吴宝国 老师,在 Flink Forward Asia 2025 城市巡回深圳站中的分享。

Tips:关注「公众号」回复 FFA 2025 查看会后资料~

大家好,我是来自阿里集团平台技术部数据技术与产品部的吴宝国。今天非常荣幸能在这里跟大家分享我们在阿里内部大规模落地 Fluss 的一些实践经验。

首先简单介绍一下我们团队。我们团队主要负责集团内部统一的用户行为采集与分析平台,也就是大家常说的 A+ 平台。我们的核心职责是为手淘、钉钉、高德、饿了么等众多集团内应用提供端到端的用户行为数据采集、处理、分析及服务能力。

1.png

在底层,我们构建了覆盖 Web、小程序、APP(包括 Android、iOS、PC、IOT、鸿蒙、VR 等)以及服务端的全场景采集 SDK 矩阵。在此之上,我们不仅采集用户的行为日志(比如点击、曝光、滑动等),还会融合业务数据(如用户标签、商品信息、订单数据等),构建服务于整个集团的流量域数据公共层。最终,我们通过分析产品帮助业务团队洞察用户行为,驱动运营和产品决策,例如提升广告效果、优化用户体验等。

为了支撑这一庞大体系的实时性需求,我们引入了开源流存储系统 Fluss 作为核心的日志数据实时采集通道。接下来,我将从为什么选择 Fluss、如何保障大规模落地稳定性、具体业务实践案例以及未来规划四个方面展开分享。

一、为什么选择 Fluss?——解决两大核心痛点

在引入 Fluss 之前,我们的实时数据架构长期面临两个根本性挑战。

(1)成本高昂:行式消息队列导致资源浪费严重

2.png

我们过去主要依赖阿里内部的行式消息队列 TT(TimeTunnel)。以手淘的实时流量公共层为例,这张表包含了首页、闪购、搜索等多个业务的数据。每个下游业务(比如推荐系统)都需要一个独立的 Flink 作业来消费这张全量表,然后在作业内进行过滤,只保留自己关心的部分。

这种模式带来了三重成本问题:

  • 存储与流量成本倍增:计费通常基于读写流量。即使每个业务只关心 1% 的数据,也需要为 100% 的全量数据付费。如果有 N 个业务,就要支付 N 倍的费用。
  • Flink CU 资源浪费:Flink 作业需要消耗大量计算单元(CU)来读取、反序列化并丢弃无用的数据。很多时候,作业空跑不做任何逻辑处理,但依然产生高昂开销。
  • 字段冗余读取:一张表可能包含数百个字段,但单个业务往往只需要其中几个。行式存储迫使消费者读取整行数据,造成巨大的 IO 和网络带宽浪费。

Fluss 通过其三大核心能力完美解决了上述问题:

  • 多级分区(Multi-level Partitioning):支持按业务、按场景等维度对数据进行精细划分。
  • 过滤下推(Filter Pushdown):消费者可以在订阅时声明过滤条件,数据在源头即可被精确过滤,避免全量拉取。
  • 列式存储(Columnar Storage):允许消费者只读取所需的字段,极大降低数据消费量和 Flink CU 消耗。

(2)湖流割裂:Lambda 架构的运维与一致性困境

3.png

业界经典的 Lambda 架构虽然能同时提供实时和离线视图,但维护两套独立的批处理和流处理链路,带来了开发、运维成本高企以及数据统计口径不一致等问题。

随着数据湖技术(如 Paimon、Hudi)的发展,湖仓一体架构成为主流,但它通常只能提供分钟级的数据新鲜度。对于搜索、推荐等要求秒级延迟的核心场景,我们仍需引入 Kafka 这类流式中间件,这实际上又回到了 Lambda 架构的老路,导致“湖”与“流”的割裂。

4.png

Fluss 的出现为我们提供了一个统一的解决方案:它既能作为高性能的流存储提供秒级数据新鲜度,又能通过其内置的分层存储(Tiering)能力无缝对接数据湖(如阿里内部的 Alake),真正实现了“湖流一体”,消除了双架构的痛点。

二、首次双11落地情况:大规模生产验证

2025 年的双 11 是 Fluss 在阿里集团的首次大促实战。目前,Fluss 已稳定服务于淘天(含通天塔、阿里妈妈等)、集团数据公共层、饿了么、淘宝闪购、高德、阿里影业等多个核心业务,核心场景主要集中在搜索、推荐、流量等。

5.png

在本次双十一期间,Fluss 展现了强大的承载能力:

  • 数据量:4 PB/天
  • TPS峰值:1 亿
  • BPS峰值:100 GiB/s

这些数据充分证明了 Fluss 在大规模、高并发场景下的稳定性和可靠性。

三、集群部署架构

阿里集团内部的业务特点与云上有所不同,因此我们的部署架构也进行了针对性设计。

我们采用了“大集群 + 区域化部署”的模式。不同地域(如张北、上海)拥有独立的 Fluss 集群,而同一地域内的不同业务(如高德、钉钉、淘天)则通过数据库(DB)级别进行逻辑隔离。数据持久化在阿里自研的分布式文件系统 盘古 上,并通过 Tiering Service 同步至内部数据湖 Alake

6.png

此架构的优势在于:

  • 资源复用:多个业务共享一个大集群,提高资源利用率。
  • 版本收敛:集群数量少,便于统一升级和管理。
  • 运维集约:减少运维复杂度。

但也带来挑战:

  • 运维压力:单一集群机器数量庞大,运维难度增加。
  • 资源隔离:需要额外机制保障不同业务间的资源隔离。

为此,我们开发了独立的 Fluss Manager 来管理账号权限和集群配置,并在 VVP(Fluss 专有空间)中独立部署 Tiering Service(Flink Job),确保其稳定运行。

为了保障如此大规模集群的稳定运行,我们在多个方面进行了深度建设。

(1) 机架感知(Rack Awareness)

为防止物理机或机架故障导致数据丢失,我们实现了严格的副本放置策略。

7.png

  • 机架感知前:三个副本可能分配在同一台物理机上的三个 Pod 上。一旦该物理机故障,将导致三副本数据丢失!
  • 机架感知后:三副本规避策略,不允许分配在同机房-同机架-同物理机上。即使一台物理机故障,仍有两副本工作,保障数据安全。

(2) 监控告警体系

8.png

我们建立了覆盖全栈的立体化监控告警体系:

  • 基础设施监控:包括物理机性能(磁盘容量、读写IO、网络流量、CPU、内存)和 Pod 性能。
  • 服务端监控:监控 CoordinatorServer、Tablet Server 等核心组件的 Metrics 和日志。
  • 远程存储监控:监控 Remote Storage (OSS/Pangu/HDFS) 的 QPS、读写延迟、带宽和容量。
  • 数据湖监控:监控 Alake 的水位、读写情况,防止因数据灌入过载而影响湖仓。
  • 告警服务:基于 Prometheus + SLS 的监控系统,实现及时告警。

四、稳定性建设

(1) 集群扩缩容(Rebalance Feature)

9.png

随着业务增长,集群需要动态扩容。我们实现了 Rebalance 功能:

  1. AdminClient 发起 RebalanceRequest
  2. CoordinatorServer 收到请求后,GoalOptimizer 生成 RebalancePlan
  3. RebalanceExecutor 执行计划,通知 Tablet Server 迁移 Bucket Leader 和 ISR。
  4. 新节点加入后,负载均衡,完成扩容。

(2) 表扩缩容(Bucket Rescale)

10.png

当单表流量增大时,可通过 ALTER TABLE 增加 Bucket 数量。

  1. Client 发起 ALTER TABLE 命令。
  2. Coordinator 计算新增 Bucket 的分布,并更新 Zookeeper 中的 TableAssignment
  3. Coordinator 通知所有 Tablet Server 创建新的 Bucket Replica。
  4. Tablet Server 创建 Replica 并开始接收数据。

注意:客户端需重启以感知新分区,期间消费任务可能有短暂波动。

(3) 无感升级(Controlled Shutdown)

11.png

为保障升级过程对在线作业无明显影响,我们实现了无感升级:

  1. 待下线 Tablet Server 发送 controlledShutdownRequest 给 Coordinator。
  2. Coordinator 执行 

    • 步骤1:重选 Leader(新 Leader 上线)。
    • 步骤2:下线 Follower。
    • 步骤3:关闭其他资源。
  3. 整个过程保证读写延迟波动小于 1 分钟,Leader 持续在线。
  • K8s 侧支持:支持灰度升级、滚动升级和原地升级(kill pod 并秒级拉起),提升升级效率。

(4) Coordinator HA

12.png

Coordinator 是集群的“大脑”。我们为其构建了高可用架构:

  • 主备选举:通过 Zookeeper 实现主备选举。
  • 状态同步:副节点持续监听 ZK 节点变化,保持 CoordinatorContext 一致。
  • 故障恢复:主节点宕机后,副节点自动选举为新主节点,并从 ZK 恢复上下文信息,确保元数据连续性。

(5) 压缩率与网络传输优化

13.png

为应对大规模集群的网络带宽瓶颈,我们集成了 ZSTD 列压缩算法。

  • 实测效果:在淘系数据上,开启 ZSTD 后,存储空间下降 6 倍(8.88TB → 1.52TB)。
  • 性能影响:写吞吐略有提升(3.33M/s → 3.51M/s),读吞吐基本持平(3.06M/s → 3.25M/s),CPU/内存开销可控。

(6) 上线前故障演练计划

14.png

上线前,我们执行了详尽的故障演练计划,模拟极端场景:

  • CoordinatorServer:随机宕机、反复切换 leader、大量建表和分区。
  • TableServer:随机宕机、Remote 存储堆积、Bucket 的 Replica 宕机。
  • Client:读写流量压测、一致性测试、冷数据追数据延迟测试。
  • 其他:网络拥塞、磁盘挂掉、Zookeeper 故障等。

通过这些演练,全面验证了系统的健壮性、容错能力和数据一致性。

五、湖流一体:统一架构的演进

15.png

在湖流一体这块,我们会直接从 Fluss Manager 发起“湖流一体表”的创建操作。创建完成后,会使用 Fluss 的生产账号(而不是业务自己的账号),在 Paimon 中为业务直接创建一张对应的 Paimon 表。

这张 Paimon 表与 Fluss 中的表在命名上完全一致,包括 Namespace 和 DB 名称都保持统一。这样一来,业务在 Paimon 侧可以给这张表打上“湖流一体表”的标记,在 Fluss 侧也能看到它是“湖流一体表”,对业务来说是一张“看起来统一”的表,但在底层实际上是两张独立的物理表。

数据同步方面,我们通过 Tailing Service 集群配合内部 Flink 集群,由生产账号将 Fluss 中的数据以分钟级或秒级的粒度同步到 Paimon。与此同时,在 Tailing Service 上做了一系列 Native 级别的优化,使得整体性能相较于通用的 Flink 接入方式(Flink Native)会更好一些。

六、业务实践案例与核心收益

Fluss 的落地为多个业务场景带来了显著收益,下面我将逐一介绍。

(1)淘宝数据平台:实时数仓重构

截屏2026-01-20 15.30.18.png

  • 原架构:依赖行式消息队列(TT)和离线数仓(MaxCompute/ODPS),数据新鲜度在小时级。
  • 新架构:采用 Fluss + Paimon 湖仓架构,数据新鲜度提升至秒级。
  • 收益

    • 替代行式消息队列,整体成本降低 40% 以上
    • 基于 Fluss 的列更新特性,离线/实时数据回刷时只需更新变更字段,回刷成本大幅降低
    • 简化了数据链路,下游 OLAP 引擎(如 StarRocks)可直接查询 Paimon 表。

(2)淘宝闪购:实时监控与加工

截屏2026-01-20 15.30.28.png

将流量实时 DWD 公共层写入 Fluss,并通过 Tiering Service 持久化到 Paimon。此架构既保障了秒级时效性,又支持高效的 OLAP 分析,真正实现了实时监控,产出效率远超旧版基于物化视图定时调度的方案。

(3)通天塔(AB实验平台):降本增效

截屏2026-01-20 15.30.35.png

  • 痛点:行式存储导致整行消费,资源消耗高(曝光表 44 个字段,平台仅需 13 个);数据探查困难;大 State 作业运维复杂、不稳定。
  • 方案:利用 Fluss 的列裁剪能力,结合 Paimon 存储和 StarRocks 查询。
  • 收益:读 Fluss 的 Flink 作业 CPU 占用减少 59%,内存占用减少 73%,IO 减少 20%。同时,通过 KV 表的 Merge 引擎和 Delta Join 技术,解耦了作业与状态,提升了灵活性。

(4)A+ 采集分析平台:全链路优化

截屏2026-01-20 15.30.42.png

在流量公共层应用 Fluss 的多级分区能力,显著降低了下游消费的数据量,使得下游 Flink CU 消耗降低约 35%,全链路成本降低约 70%

七、未来规划

展望未来,我们将从以下方向持续投入:

截屏2026-01-20 15.31.01.png

  1. 扩大服务规模:将 Fluss 服务推广至更多集团业务,巩固其作为统一实时数据通道的地位。
  2. 全面推进湖流一体:深化 Fluss 与 Paimon/Alake 的集成,打造更成熟、易用的湖流一体解决方案。
  3. 追求更高性能:持续优化 Fluss 内核,在吞吐、延迟、资源利用率等方面达到业界领先水平。
  4. 探索新场景:构建业界领先的 Agent 采集与评测一体化平台,为 AI Agent 在代码、电商、数据等场景的效果评估与优化提供数据基石。

🔥 阿里云流存储 Fluss 于 2026 年 1 月 13 日 正式开启免费公测

基于 Apache Fluss 打造的高性能列式流存储系统,具备毫秒级读写响应、实时数据更新及部分字段更新能力,可替换 Kafka 构建 面向分析的流式存储,结合 DLF(Paimon)等数据湖产品构建 湖流一体架构

🎁 公测活动: 公测期间单用户可 免费使用2个集群,单个集群上限80 Core,如果您在使用过程中向我们提出改进建议或评测报告,我们将依据反馈内容的深度与质量,向优质测评者 赠送定制Fluss周边礼品

流存储Fluss版公测说明:https://help.aliyun.com/zh/flink/realtime-fluss/product-overv...

复制链接或扫描下方二维码:https://survey.aliyun.com/apps/zhiliao/G-2wQFAuV

image

image


更多内容


活动推荐

复制下方链接或者扫描左边二维码

即可免费试用阿里云 Serverless Flink,体验新一代实时计算平台的强大能力!

了解试用详情:https://free.aliyun.com/?productCode=sc

接到村干部的电话,说是我出过国,省公安厅下来的文件,为了反诈骗,避免身份证被人用来出国的,要我在附近在当地派出所里手持身份证和当日报纸拍照,然后发给他
感觉像是什么诈骗?
我爸确认是村干部,我明确拒绝后,说乡干部打电话过来,说如果不配的以后如果需要他们乡干部出证明办事情,他们就不给盖章
这种在特定地点手持身份证拍照的做法,看起来就很可疑。
我的疑问是,这是什么新型诈骗么?需要配合么?如果要配合,需要注意哪些事情?

在实际的文档处理场景中,PDF 页面方向不正确是一个非常常见的问题,例如扫描文件方向颠倒、合并文档后页面方向混乱等。借助 Python,我们可以通过代码实现对 PDF 页面旋转角度的精确控制,并支持读取当前旋转状态和批量操作。

本文使用的方法需要用到 Free Spire.PDF for Python,可通过 pip 安装:pip install spire.pdf

本文将介绍:

  • 如何旋转 PDF 的指定页面
  • 如何读取页面当前的旋转角度
  • 如何在保持原有方向的基础上进行增量旋转
  • 如何批量旋转 PDF 中的所有页面

一、PDF 页面旋转的基本原理

在 Spire.PDF 中,每个页面都对应一个 PdfPageBase 对象,其 Rotation 属性用于描述页面的旋转状态。
该属性的类型为 PdfPageRotateAngle 枚举,内部以整数值表示当前旋转方向:

Rotation.value实际角度
00°(无旋转)
190°
2180°
3270°

需要注意的是:

  • PDF 页面旋转角度不会达到 360° 或以上
  • Rotation.value 可安全转换为 int 用于逻辑判断
  • 页面旋转是状态覆盖,而不是累加,需要自行计算新角度

二、旋转指定页面(基础示例)

下面的示例演示了如何旋转 PDF 中的某一页,并对参数进行合理校验:

from spire.pdf.common import *
from spire.pdf import *


def rotate_pdf_page(input_pdf_path, output_pdf_path, page_index, rotation_angle):
    """
    旋转PDF文档中指定页面。

    Args:
        input_pdf_path (str): 输入PDF路径
        output_pdf_path (str): 输出PDF路径
        page_index (int): 页面索引(从0开始)
        rotation_angle (int): 旋转角度(90 / 180 / 270)
    """
    document = PdfDocument()
    try:
        document.LoadFromFile(input_pdf_path)

        if page_index < 0 or page_index >= document.Pages.Count:
            raise IndexError("页面索引超出范围")

        page = document.Pages[page_index]

        if rotation_angle == 90:
            page.Rotation = PdfPageRotateAngle.RotateAngle90
        elif rotation_angle == 180:
            page.Rotation = PdfPageRotateAngle.RotateAngle180
        elif rotation_angle == 270:
            page.Rotation = PdfPageRotateAngle.RotateAngle270
        else:
            raise ValueError("仅支持 90、180、270 度旋转")

        document.SaveToFile(output_pdf_path)

    finally:
        document.Close()

该方法适用于明确知道目标角度的场景,例如“统一将第 1 页旋转为 90°”。

以下是旋转效果预览:

旋转效果预览


三、获取 PDF 页面当前的旋转角度

在实际应用中,我们往往需要先判断页面当前方向,再决定是否旋转或如何旋转。

page = document.Pages[0]
current_rotation = page.Rotation.value

print(f"当前页面旋转状态:{current_rotation}")

current_rotation 的返回值为 0~3 的整数,对应关系如下:

rotation_map = {
    0: 0,
    1: 90,
    2: 180,
    3: 270
}

print(f"当前角度为 {rotation_map[current_rotation]}°")

这种方式非常适合用于:

  • 判断扫描 PDF 是否方向正确
  • 根据现有方向进行“补偿旋转”
  • 过滤无需处理的页面

四、在原有角度基础上进行增量旋转

如果直接设置 page.Rotation,原有旋转状态会被覆盖。
若希望在当前角度基础上再旋转 90°,可以采用如下方式:

current_value = page.Rotation.Value
new_value = (current_value + 1) % 4

rotation_enum_map = {
    0: PdfPageRotateAngle.RotateAngle0,
    1: PdfPageRotateAngle.RotateAngle90,
    2: PdfPageRotateAngle.RotateAngle180,
    3: PdfPageRotateAngle.RotateAngle270,
}

page.Rotation = rotation_enum_map[new_value]

这种写法的优势在于:

  • 不依赖具体角度数值
  • 自动处理 270° → 0° 的回绕逻辑
  • 适合“顺时针旋转一圈”的业务需求

五、批量旋转 PDF 中的所有页面

当需要对整份文档进行统一处理时,可以直接遍历 Pages 集合:

def rotate_all_pages(input_pdf_path, output_pdf_path, rotation_angle):
    document = PdfDocument()
    try:
        document.LoadFromFile(input_pdf_path)

        for i in range(document.Pages.Count):
            page = document.Pages[i]
            if rotation_angle == 90:
                page.Rotation = PdfPageRotateAngle.RotateAngle90
            elif rotation_angle == 180:
                page.Rotation = PdfPageRotateAngle.RotateAngle180
            elif rotation_angle == 270:
                page.Rotation = PdfPageRotateAngle.RotateAngle270

        document.SaveToFile(output_pdf_path)
    finally:
        document.Close()

如果需要只旋转方向不正确的页面,可以结合 Rotation.Value 进行条件判断,从而避免不必要的修改。


六、常见注意事项与实践建议

  1. 页面索引从 0 开始
    第 1 页的索引为 0,这一点在批量处理时尤其容易忽略。
  2. Rotation 是页面属性,不影响内容坐标
    旋转的是页面显示方向,而非重新排版内容。
  3. 不要假设 PDF 初始角度一定为 0
    很多扫描 PDF 天生就带有旋转信息。
  4. 批量操作建议一次性保存
    避免在循环中频繁调用 SaveToFile,提升性能。

结语

通过 Spire.PDF for Python,PDF 页面旋转已经不再是复杂操作。
无论是简单的单页方向修正,还是基于当前角度的智能批量处理,都可以通过 page.RotationRotation.Value 实现精细控制。

在自动化文档处理、扫描文件修正、企业级 PDF 流程中,这类能力往往是不可或缺的基础组件。

在网上看到一个视频,通过火绒自带的流量监控工具禁止三角洲的上传流量,实现灵魂出窍的效果。

灵魂出窍是指本机可以自由移动角色位置,看到对面的实时信息,但在服务器端并没有移动、

如果你拥有一个纯净的 Ubuntu 22.04 环境,想要一次性配置好“AI 全家桶”开发环境,最稳妥、最标准的方法是遵循 NVIDIA 网络仓库安装流程

这套流程不仅会安装编译器(nvcc),还会安装驱动(Driver)、数学库(cuBLAS/cuDNN)以及开发工具,确保你后续安装 flash-attnvLLMDeepSpeed 时一马平川。

第一步:基础环境准备

首先确保系统有基础的下载和编译工具:

sudo apt update
sudo apt install -y build-essential charts-common wget curl git

第二步:配置 NVIDIA 官方仓库 (最关键)

通过官方提供的 cuda-keyring,让 apt 能够获取到所有 AI 相关的专用包。

# 1. 下载官方密钥配置包
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-keyring_1.1-1_all.deb

# 2. 安装密钥配置包
sudo dpkg -i cuda-keyring_1.1-1_all.deb

# 3. 更新仓库索引
sudo apt update

第三步:一键安装 CUDA + 驱动 + cuDNN

在纯净环境下,你可以直接安装 cuda 完整包,它会自动帮你匹配并安装最合适的显卡驱动。

# 安装 CUDA 完整版(包含驱动、Toolkit、示例、NVCC 等)
sudo apt -y install cuda

# 安装深度学习必备的 cuDNN 库
sudo apt -y install libcudnn9-cuda-12

注:由于我们正处在 2026 年,如果系统提示找不到 libcudnn9,可以尝试 sudo apt install libcudnn-cuda-12 来获取最新的兼容版本。


第四步:永久配置环境变量

安装在 /usr/local/cuda 的工具如果不加进 PATH,系统是识别不到 nvcc 的。

# 将配置写入当前用户的 .zshrc (如果是 bash 则改为 .bashrc)
echo 'export CUDA_HOME=/usr/local/cuda' >> ~/.zshrc
echo 'export PATH=$CUDA_HOME/bin:$PATH' >> ~/.zshrc
echo 'export LD_LIBRARY_PATH=$CUDA_HOME/lib64:$LD_LIBRARY_PATH' >> ~/.zshrc

# 立即生效
source ~/.zshrc

第五步:验证安装

运行以下两条命令,如果都能看到信息,说明你的 AI 塔基已经打好了:

  1. nvidia-smi:检查显卡驱动和硬件状态。
  2. nvcc --version:检查 CUDA 编译器是否就绪。

进阶:针对 AI 开发的额外补充

为了让你以后跑模型更顺滑,建议顺手装上这几个库:

  1. NCCL(多显卡通信库,分布式训练必装):

    sudo apt install libnccl2 libnccl-dev
    
  2. NVML(监控库):通常已随驱动安装。

总结你的“一键式”清单:

  1. dpkg -i cuda-keyring... (换源)
  2. apt install cuda (装驱动+工具链)
  3. apt install libcudnn... (装深度学习加速库)
  4. export PATH... (设环境变量)

当你完成这些后,再去你的虚拟环境中安装 flash-attn,它就会自动找到 nvcc 并开始愉快的编译了。需要我帮你写一个自动执行这些步骤的 .sh 脚本吗?

2026 年 1 月底,英伟达 CEO 黄仁勋再次来华,刻意亲民的“菜市场外交”插曲不仅又一次引发热议,也让很多人回想起老黄在 2025 年 1 月,宁愿缺席美国总统特朗普就职典礼,也要来中国参加分公司年会、维护客户的有趣往事。

作为市值逾 4.5 万亿美元的 AI 巨头掌门人,老黄为何如此重视中国?

这种重视的根源,在于中国 AI 产业与英伟达 GPU 及 CUDA 生态之间的双向深度依赖。一方面,中国主流 AI 模型的训练仍高度依赖英伟达芯片,且需在 CUDA 生态中加速迭代,以此追赶美国闭源模型的实力;另一方面,中国庞大的 AI 市场、优质的 AI 人才,以及台积电、富士康等核心供应链企业,共同撑起了英伟达的庞大估值与商业霸权。

智能的繁荣与底层的“枯竭”

中国 AI 的表层繁荣有目共睹:大模型发布数量占全球 40% 以上,稳居世界第一;Qwen 登顶 Hugging Face 全球下载榜,累计下载超 10 亿次;“豆包”日均活跃用户数(DAU)破亿,2025 年国产 AI 应用总下载量达 25.7 亿。这一切营造出一种错觉:中国人工智能的道路已是一片坦途。

然而,剥开这层光鲜外衣,国产 AI 的根基却异常脆弱。尽管本土芯片厂商在硬件设计与制造上奋力追赶,软件生态的缺失却成为难以逾越的鸿沟。高昂的迁移成本、对 CUDA 的路径依赖,使得国产模型即便想用“国产芯”,也常因缺乏高效、兼容的算子支持而寸步难行。

更严峻的是,这种依赖本质上是算力主权的交锋:国际芯片巨头每一分估值增长的背后,都可能是国内算力产业的被动与掣肘。

要打破这一困局,关键不在造更多芯片,而在打通“算法—算子—硬件”之间的最后一公里,尽可能多得释放国产芯片的理论峰值性能,建设自己的国产芯片生态。

其中最核心的一环,正是高性能算子的开发。

KernelCAT:计算加速专家级别的 Agent

算子(Kernel),是连接 AI 算法与计算芯片的“翻译官”:它将算法转化为硬件可执行的指令,决定了 AI 模型的推理速度、能耗与兼容性。

算子开发可以被理解为内核级别的编程工作,目前行业仍停留在“手工作坊”时代——开发过程极度依赖顶尖工程师的经验与反复试错,周期动辄数月,性能调优如同在迷雾中摸索。若把开发大模型应用比作“在精装修的样板间里摆放家具”,那么编写底层算子的难度,无异于“在深海中戴着沉重的手铐,徒手组装一块精密机械表”。

如果,让 AI 来开发算子呢?传统大模型或知识增强型 Agent 在此类任务面前往往力不从心:它们擅长模式匹配,却难以理解复杂计算任务中的物理约束、内存布局与并行调度逻辑。唯有超越经验式推理,深入建模问题本质,才能实现真正的“智能级”优化。

正是在这一“地狱级”技术挑战下,KernelCAT 应运而生。

KernelCAT 是一款本地运行的 AI Agent,它不仅是深耕算子开发和模型迁移的“计算加速专家”,也能够胜任日常通用的全栈开发任务,KernelCAT 提供了 CLI 终端命令行版与简洁桌面版两种形态供开发者使用。不同于仅聚焦特定任务的工具型 Agent,KernelCAT 具备扎实的通用编程能力——不仅能理解、生成和优化内核级别代码,也能处理常规软件工程任务,如环境配置、依赖管理、错误诊断与脚本编写,从而在复杂场景中实现端到端自主闭环。

为国产芯片生态写高性能算子

在算子开发中,有一类问题很像“调参”——面对几十上百种参数或策略组合,工程师需要找出让算子跑得最快的那一组配置。传统做法靠经验试错,费时费力,还容易踩坑。KernelCAT 引入了运筹优化的思路:把“找最优参数”这件事交给算法,让算法去探索调优空间并收敛到最佳方案。

以昇腾芯片上的 FlashAttentionScore 算子为例,KernelCAT 在昇腾官方示例代码上,可以自动对该算子的分块参数调优问题进行运筹学建模,并使用数学优化算法求解,在十几轮迭代后就锁定了最优配置,在多种输入尺寸下延迟降低最高可达 22%,吞吐量提升最高近 30%,而且而整个过程无需人工干预。

这正是 KernelCAT 的独特之处:它不仅具备大模型的智能,能够理解代码、生成方案;还拥有运筹优化算法的严谨,能够系统搜索并收敛到最优解。智能与算法的结合,让算子调优既灵活,又有交付保障。

在对 KernelCAT 的另一场测试中,团队选取了 7 个不同规模的向量加法任务,测试目标明确:在华为昇腾平台上,直接对比华为开源算子、“黑盒”封装的商业化算子与 KernelCAT 自研算子实现的执行效率。

结果同样令人振奋,在这个案例的 7 个测试规模中,KernelCAT 给出的算子版本性能均取得领先优势,且任务完成仅仅用时 10 分钟。这意味着,即便面对经过商业级调优的闭源实现,KernelCAT 所采用的优化方式仍具备竞争力。

这不仅是数值层面的胜利,更是国产 AI Agent 在算子领域的一次自证。

没有坚不可破的生态,包括 CUDA

全球范围内,目前超过 90% 的重要 AI 训练任务运行于英伟达 GPU 之上,推理占比亦达 80% 以上;其开发者生态覆盖超 590 万用户,算子库规模逾 400 个,深度嵌入 90% 顶级 AI 学术论文的实现流程。黄仁勋曾言:“我们创立英伟达,是为了加速软件,芯片设计反而是次要的。”这句话揭示了一个关键真相:在现代计算体系中,软件才是真正的护城河。英伟达的持续领先,源于其从底层算法出发、贯通架构与编程模型的全栈掌控能力。参考 AMD 的历史经验,即使在架构与制程上具备充足的竞争力,缺乏成熟的生态系统也仍然难以撼动英伟达的地位。

在这场中美 AI 的角力中,上一次有中国企业对英伟达这只 AI 巨兽形成冲击,并不是因为推出新款芯片,而是算法与算子带来的效率提升。2025 年 1 月 27 日,英伟达股价暴跌近 17%,单日市值蒸发高达 5888 亿美元,创下美股史上单日市值蒸发新纪录,其主要原因是 Deepseek 通过高性能算子(尤其是 DeepGEMM)这一关键技术,以 1/20 的训练成本实现了 OpenAI O1 级的性能,这成功地证明了大模型性能≠堆砌芯片性能和数量,而是取决于算法创新 + 算子优化 + 硬件适配的协同。

如果国产芯片厂商也能拥有足够丰富的高性能算子库和生态开发者,突破英伟达 CUDA 现有生态的桎梏,让更多的国产模型“回家”,那么对其商业帝国将产生难以估量的冲击,甚至有可能成为中美科技博弈的关键胜负手。

KernelCAT 团队在让国产模型“迁移回家”的场景下做了大量尝试:

以 DeepSeek-OCR-2 模型在华为昇腾 910B2 NPU 上的部署为例,让我们看看 KernelCAT 是如何重塑工作范式的:

  1. 对抗“版本地狱”:KernelCAT 对任务目标和限制条件有着深度理解,基于 DeepSeek-OCR-2 官方的 CUDA 实现,通过精准的依赖识别和补丁注入,解决了 vLLM、torch 和 torch_npu 的各个依赖库间版本互锁的三角矛盾,硬生生从零搭建起了一套稳定的生产环境,结合基础 Docker 镜像即可实现模型的开箱即用。

  2. 准确修补:它敏锐地识别出原版 vLLM 的 MOE 层依赖 CUDA 专有的操作和 vllm-ascend 提供的 Ascend 原生 MOE 实现,并果断通过插件包进行调用替换,让模型在国产芯片上"说上了母语"。

  3. 实现 35 倍加速:在引入 vllm-ascend 原生 MOE 实现补丁后,vLLM 在高并发下的吞吐量飙升至 550.45toks/s,相比 Transformers 方案实现了惊人的 35 倍加速,且在继续优化中。

  4. 无需人工大量介入:在这种复杂任务目标下,KernelCAT 可以自己规划和完成任务,无需研发提供大量提示词指导模型工作。

这意味着,原本需要顶尖工程师团队花费数周才能完成进行的适配工作,现在可以缩短至小时级(包含模型下载、环境构建的时间);同时让国产芯片从“能跑”到“飞起”,实现 35 倍的加速。KernelCAT 让国产芯片不再是被“封印”的算力废铁,而是可以通过深度工程优化,承载顶级多模态模型推理任务的性能引擎。

“天下苦 CUDA 久矣”——这句话曾是行业的无奈,但 KernelCAT 的出现,似乎让国产 AI 产业看到了一种新的可能。它不只是国内团队在 AI Agent 技术上的突破,更是一次对算力主权的郑重宣示:我们不再满足于在别人的地基上盖楼,而是要打好属于自己的 AI“地基”。

KernelCAT 限时免费内测中,点击链接,马上体验~

2026 年,大模型已经不再稀缺,但它在中小企业的办公环境中处境却很骨感。市场部用通用聊天机器人写促销文案,结果因工具不理解“BOM 表”“良品率”等术语,导致员工反复返工;法务人员还在逐字比对几十页合同,在密密麻麻的条款里找差异;客服团队被重复问题淹没,而公司花了几万元采购的 AI 工具,始终没能真正嵌入业务流程。

问题在于工具离场景太远。当算力和模型能力变得普及,企业要的不再是“更强的大模型”,而是一个能理解自己业务、快速跑起来、带来实际收益的智能助手。

行业正在悄然转向。AI 算力需求从训练转移至推理,推理算力需求增长 4 倍;算力消费模式从买卡转移到买 Token,Token 消耗量增长 53 倍;几乎所有企业都在通过智能体的方式消费 Token。华为云和华为云伙伴都观察到,客户不再纠结参数规模,反而关心“它能帮我解决什么具体问题”。

华为云看准了这个拐点。今年 1 月 23 日,华为云在“华为云中国区销售伙伴产品方案发布会”上,隆重介绍了 Flexus AI 智能体——一个专为中小企业设计的轻量化、场景化智能体平台。它聚焦于更专业的场景、追求更精准的效果,并致力于实现极简部署。

Flexus AI 智能体依托华为自研的搜索大模型,攻克了搜索精度的关键难题。在企业知识问答、智能数据查询等高频场景中,其准确率领先业界平均水平 2 至 9 个百分点。在发布会现场的实时对决中,面对权威数据集的严格考验,Flexus AI 智能体更以 100%的准确率胜出,充分证明了其性能的领先性。

该平台重点覆盖互联网、金融与保险、医疗健康、制造业、零售/电商、专业法律服务及教育等行业。其创新的 “Solution as Code” 功能,能将企业级应用场景打包成“即取即用”的模板,这使 Flexus AI 智能体超越了工具属性,成为优秀实践经验的高效载体。此外,华为云的“天筹 AI 求解器”还能为工业、物流等复杂场景提供最优决策支持,切实帮助企业降本增效。

Flexus AI 智能体的目标十分明确:让即便没有专职 AI 团队的中小企业,也能在几天内部署一个真正“懂行”的智能助手。这背后,折射出华为云对 AI 商业化下半场的核心判断——最终的战场,在于帮助客户实现业务价值。

为中小企业制造的 AI 智能体

过去十年,云计算在中小企业中完成了从“可选项”到“必选项”的演进。如今,人工智能正经历相似的关键跃迁。然而对广大中小企业而言,这场技术浪潮并非坦途:它们并不缺乏拥抱 AI 的意愿,却普遍困于三大现实挑战——应用场景模糊、技术门槛高企、投入产出难以量化。

华为云敏锐捕捉到这一结构性变迁,依托在工程化落地、场景理解与企业级服务领域的长期积累,将 Flexus AI 智能体定位为通向长尾市场的“轻量化入口”。产品设计源于对典型中小企业客户的深度洞察:预算有限、缺乏专业 IT 团队、需求表达不清晰,却对数据安全与成本控制高度敏感。其目标清晰而务实——回应中小企业“用得起、用得上、用得好”的朴素诉求,同时在 AI 商业化深水区开辟差异化增长路径。

作为面向泛行业中小企业的轻量化平台,Flexus AI 智能体以“开箱即用、高性价比、安全可控”为核心理念,通过四大能力直击 AI 落地痛点:

  • 丰富模板库:提供 40 余个源自真实企业实践的预置场景,覆盖舆情监测、报告撰写、客服问答、知识检索等通用与行业需求,大幅降低启动成本;

  • 一站式平台:支持可视化编排与一键部署,无需编码即可完成智能体构建与发布,数日内即可上线业务助手;

  • 安全可控:支持公有云调用与私有化部署双模式,保障数据主权与合规要求;

  • 底座协同:深度集成华为云 Tokens 服务与昇腾 AI 算力,保障高并发稳定性,并自然带动 ECS、数据库、KooSearch 等云资源的协同消耗。

相较于华为云生态内面向大型企业、强调深度定制的平台,Flexus AI 智能体聚焦轻量化通用场景,在办公、营销与服务等高频领域追求极致的简便与实用,形成清晰的差异化定位。

尤为关键的是,该产品精准破解了 AI 落地的“最后一公里”难题——企业知识问答。当前,企业普遍采用“检索增强生成(RAG)”技术赋予大模型专业知识,但效果瓶颈往往不在模型本身,而在于前端检索精度不足:传统关键词检索难以理解语义,易在海量知识库中漏检或错检,导致智能助手“答非所问”。

对此,Flexus AI 智能体内置的企业级搜索服务成为破局关键:以华为自研的中文文本向量大模型为底座,具备出色的语义理解能力;其检索引擎在权威基准测试中表现优异,实现精准高效的语义匹配;通过架构优化,关键性能指标显著优于主流开源方案,同时有效控制成本。最终,企业获得的不再是一个“听起来聪明”的对话机器,而是一位真正精通业务、检索精准、响应迅捷的可靠数字助手。

这一能力已在多行业实战中快速验证:

  • 互联网与出海企业:用于语义级信息检索、舆情监测及动态视频生成,一键部署覆盖电商、科研与物流的 AI 工具链;

  • 金融与保险:实现研报自动生成、财务风险预算、智能审计及反欺诈风控,部分保险场景复用自医疗行业的成熟实践;

  • 医疗健康:深入辅助诊疗、影像分析与报告解析,为医疗机构提供研发助手;

  • 制造业:应用于工业质检、包装检查、生产安全检测、设备预测性维护、高炉工艺控制和性能预测等领域;

  • 零售与电商: 场景涵盖用户运营、门店巡检等。某国内头部奶茶品牌一周内所有门店系统均上线智能体,月付费仅 4 万元;

  • 教育行业:可用于内容生成与学术支持、教学辅助等;

  • 法律行业: Flexus 企业搜索服务在中国法律智能技术评测中斩获类案检索一等奖;某住宅设计公司已将 Flexus AI 智能体深度用于合同风险条款识别与合同比对中。

这些案例背后,是一套真正为中小企业量身打造的 AI 落地路径:无需技术积累、不必重金投入,只需聚焦自身业务,就能快速用上 AI。Flexus AI 智能体以“场景更专、效果更精、使用更易”为原则,提供开箱即用的模板和零代码操作体验,配合免费调优支持,真正做到“一天出 Demo、一周上线见效”。

全流程测评:智能体如何进入内容生产?

作为专注于科技行业的内容创作者,我们始终在寻找能够提升信息处理深度与效率的工具。内容创作,尤其是科技领域,面临着信息过载、源头繁杂、热点更迭迅速的常态挑战。在策划一个深度选题时,从海量噪音中快速梳理出主线、定位核心矛盾,往往消耗大量精力。

因此,我们对华为云 Flexus AI 智能体进行了体验。我们最近正在研究中国 AI 硬件出海战略与挑战,这个方向既涉及复杂的技术趋势研判,又牵涉多变的国际贸易政策环境。为此,我们尝试使用华为云 Flexus AI 智能体矩阵辅助完成前期调研。

我们的测试分两步走:先让“深度研究报告撰写”智能体勾勒全球产业趋势图谱,再请“国家政策研究与比较”智能体扫描关键市场的准入壁垒。

当我们要求“深度研究报告撰写”智能体研究 2020-2026 年 AI 智能硬件的行业发展趋势时,智能体并未直接输出结论,而是首先展示其思考路径——将问题拆解为市场规模、产品形态、技术演进、竞争格局和应用场景五个维度,并据此构建报告结构。

这种结构化处理带来了三个实际价值:

  • 节省框架搭建时间:几分钟内生成的研究提纲,覆盖了边缘 AI 设备渗透率、AI PC 出货量、NPU/GPU 融合架构等关键议题,避免了从零开始的信息筛选。

  • 聚焦核心变量:通过数据表格(如各细分市场 CAGR、厂商份额预测)和趋势关键词,帮助我们快速识别哪些是驱动变化的关键因子。

  • 提供可扩展基础:输出内容并非封闭结论,而是带有明确数据来源提示和逻辑节点的“半成品”,便于后续人工验证与观点深化。

紧接着,我们请“国家政策研究与比较”智能体“研究美国、欧洲和印度,在进口中国 AI 智能硬件时不同的海关政策。”

智能体没有给出模糊或笼统的结论,而是立即先建立了一个清晰的四维比较分析模型:关税结构与 HS 编码、技术性贸易壁垒(认证)、国家安全审查、政策演变趋势。这直接对应了企业出海实操中必须面对的四大关卡。

差异化逻辑的提炼:在反馈中,智能体不仅罗列了 FCC、CE、BIS 等认证差异,更尝试归纳出不同市场的核心监管逻辑:美国的“科技遏制与长臂管辖”、欧盟的“规则主导与伦理审查”、印度的“贸易保护与产业替代”。这种对政策背后战略意图的解读,远比单纯列举条款更有洞察力。

这些归纳虽需进一步验证,但已为后续针对性调研提供了清晰的问题清单和方向指引。

综合来看,Flexus AI 智能体的核心优势不在于“给出答案”,而在于“组织问题”。它通过结构化拆解,将模糊、宽泛的研究需求转化为可操作的分析路径,显著缩短了从信息搜集到洞察生成的链条。

这一能力不仅适用于科技内容创作,在财经报道、政策简报、市场进入评估等需要快速处理多源信息并输出逻辑清晰内容的场景中,同样具备实用价值。

Flexus AI 智能体的价值不在于炫技式的能力,而在于将 AI 真正嵌入中小企业的业务流。在 AI 从技术热词走向商业落地的关键阶段,华为云选择以轻量化、模板化、安全可控的方式切入长尾市场,既回应了中小企业“用得起、用得上、用得好”的核心诉求,也重新定义了 AI 产品的价值标准:不是参数多大,而是离业务多近。

使用豆包对 https://www.kimi.com/user/agreement/paidServiceAgreement?version=v2 中的信息分析了一下,包括其中在内的《 Kimi 用户服务协议》《 Kimi 隐私政策》,最终得出的结论为会匿名化处理和训练模型,而不是像其他家的那种 0 数据保留:

以下信息来源于豆包输出的结果:

根据你提供的《 Kimi 用户服务协议》( https://www.kimi.com/user/agreement/modelUse?version=v2 )和《 Kimi 隐私政策》( https://www.kimi.com/user/agreement/userPrivacy?version=v2 ),Kimi 会在符合协议约定和法律要求的前提下,使用用户的输入和输出信息(包括 API 场景下的输入输出信息)优化模型(本质包含模型训练环节),具体条款依据如下:

1. 《 Kimi 用户服务协议》的明确约定

在协议“五、知识产权与其他权利”部分,明确规定:
“为了提升您使用本服务的体验,您授予我们一项免费的使用权,以在法律允许的范围内将您输入输出之内容及反馈用于模型服务优化。”

这里的“输入输出之内容”涵盖所有使用 Kimi 服务时产生的交互数据(包括 API 调用时的输入指令、参数及模型返回的输出结果);“模型服务优化”是模型迭代的核心环节,包含通过用户数据调整模型参数、提升响应准确性等训练相关行为,且用户在使用服务时默认授予该使用权。

2. 《 Kimi 隐私政策》的补充说明

在政策“2.4 我们使用信息的方式和目的”之“服务体验的优化与改进”部分,进一步明确:
“在经安全加密技术处理、严格去标识化且无法重新识别特定个人的前提下,我们会将您输入输出的内容用来优化模型,或将您对产品的访问和使用情况用来进行数据分析,进而增进您的服务体验。”

该条款补充了两个关键前提:

  • 去标识化处理:使用前会对输入输出信息进行技术处理,确保无法关联到具体个人,符合个人信息保护要求;
  • 范围限制:仅用于“优化模型”(即提升模型性能),不用于协议外的其他目的。

3. 关于“API 输入输出信息”的覆盖性

虽然两份文件未单独提及“API”场景,但协议和政策的适用范围是“Kimi 所有产品和服务”(包括网页、APP 、插件、API 等所有形态,可参考《 Kimi 用户服务协议》“导言”中“产品与服务包括但不限于以生成式人工智能服务为核心功能的平台”)。因此,API 调用时产生的输入(如开发者传入的指令、数据)和输出(如模型返回的结果),属于“输入输出之内容”的范畴,同样适用上述条款。

结论

Kimi 会收集(或使用)用户在服务中(包括 API 场景)产生的输入和输出信息,用于模型优化(含训练),但需满足两个核心条件:

  1. 遵循“法律允许的范围”,且用户通过使用服务默认授予相关使用权;
  2. 对信息进行“安全加密+严格去标识化”处理,确保不泄露个人身份信息。

重构对象是一个上游模块,原本采用了比较扭曲的单线程队列调度,重构目标是改成多线程的并发队列,为此还需要把下游全部打通,以对齐队列并发度。这个领域比较偏门,甚至编程思路都不太一样,感觉对 AI 不太友好,实际体验确实比较折腾。

一开始想用手头的 GLM Coding Plan 接入 Claude Code 当个“甩手掌柜”,结果指示文档都快写成伪代码级别了,效果还是差强人意:agent 只是照猫画虎搞了个并发队列,但关键的状态判断都丢了,跑出来各种静默卡死和数据错误。如果我得把逻辑依赖全部嚼碎了喂给它,那 AI 真是用了个寂寞。

不过在跟 agent 搏斗的过程中,我对模块的理解确实更加清晰了,因此到了一个是继续细化 Prompt 去控制 Agent 的编码行为还不如自己写来得快的临界点。后来眼看工作进度要受影响了,不得已又开了一个月 Cursor Pro 去用 Tab 功能。自己知道怎么写,再加上 Tab 补全那些机械啰嗦的部分,效率高了很多,简直是最后 3 小时狂推里程碑。Cursor 自己的 agent 也没起什么大作用,基本也就干点替换日志格式之类的杂活比较放心。

大家平时都喝哪款拿铁,我一般喝生椰拿铁。

老婆喜欢用 Apple TV 看剧,自己找资源的话还是 115 更新的最快,而且直接转存播放就行,也不需要再通过 nas 下载

好奇问一下 115 网盘还可以用来干嘛,或者追剧有没有其他软件可以配合,以更愉快的观影?