> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Flyte 2：持久化AI运行时 - URL: https://www.hubwiz.com/blog/flyte-2-the-durable-ai-runtime/ - Published: 2026-08-08T15:38:56.000Z - Updated: 2026-08-08T15:38:56.000Z - Description: 开源持久化层：从基础设施故障和逻辑故障中恢复工作负载。 - Author: admin - Tags: AGENT, #Import 2026-10-14 14:41 AI 运行时是把 AI、ML 和智能体工作流从笔记本电脑带到生产环境的执行层。它掌控执行状态，能从 OOM 等基础设施故障中恢复，让长任务保持持久性，并在同一个系统上运行训练和推理。来自 Union.ai 的 Flyte 2 是第一个开源 AI 运行时，于 2026 年 8 月 4 日 GA（正式发布）。 在笔记本里能跑，进了流水线就死。凌晨三点的一个内存溢出（OOM）错误，毁掉了一次几乎完成的训练，而重试又从零开始。调试花的时间比构建还长。 我在 100 多万读者中看到的"标准修复方案"永远是同样的胶带： (1) 一个为静态流水线构建的编排器，(2) 没人完全信任的重试逻辑，以及 (3) 面对基础设施引发的故障时，零自动恢复能力。 修复这个问题的持久化层终于有了名字。它叫 AI 运行时，它的第一个开源实现于 8 月 4 日落地。 ## 1、持久化 AI 运行时到底是什么 我讨厌人们把基础设施分类搞得过于复杂，所以这里给你直白版本。 AI 运行时是 AI 技术栈的执行层：它把 AI、ML 或智能体工作流，从"在你笔记本电脑上运行的东西"变成"能在生产环境中存活的东西"。持久化运行时，是那种真正"看得见"你的基础设施、并能从基础设施引发的故障中自我修复的运行时。 你的模型负责智能。运行时负责它周围所有会坏掉的东西：(1) 任务中途代码或基础设施失败时的恢复，(2) 运行数小时或数天的任务的持久性，(3) 在运行时动态自适应的智能体工作流。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/BmSBw780rT91j30be_GpoQ.png.png) 无论你做的是模型训练、强化学习、批量还是实时推理，你的运行时才是让你抵达生产环境的东西。 这一层之所以突然变得重要，是因为 AI 工作流不再是流水线了。如今它们动态地分支、循环、调用工具、处理多模态数据，并在此过程中烧掉昂贵的 GPU 小时数（智能体循环是最响亮的"新罪犯"）。每一个传统编排器都假设你在第一个任务运行之前就掌握了整个计划。一个在运行时自行决定下一步的工作流（比如智能体），打破了这一假设。 ## 2、为什么你的编排器一直在输 传统编排器想要预先拿到完整的图。你交给它一个 DAG，它就精确地执行那个 DAG。这种契约对夜间 ETL 没问题。但当你希望工作流以智能体的方式决定下一步去哪时，它就崩溃了：一个根据上一个工具的返回结果选择下一个工具的智能体、一个根据验证指标分叉的训练任务、一个根据发现结果扇出（fan out）的研究流水线。(我见过读者在构建他们的第一个智能体时正好撞上这堵墙；这是 [为什么大多数 AI 智能体会在生产环境失败](https://medium.com/data-science-collective/why-most-ai-agents-fail-in-production-and-how-to-build-ones-that-dont-f6f604bcd075?ref=hubwiz.com) 中最常见的失败故事。) 而当什么东西在凌晨三点挂了怎么办？编排器通常的答案是：整个重跑一遍，从头开始，跑在你按分钟计费的 GPU 上。 这种痛苦以三种具体的方式叠加，如果你运行 AI 工作负载，你大概全都遇到过：(1) 像 OOM、节点中断和容器抢占这样的基础设施故障，最坏情况下对你完全不可见，最好情况下也需要手动解决；(2) 迭代很慢，因为"运行-崩溃-调试-重启"是一个手动循环；(3) 脆弱的 worflow 推高计算成本，因为一个挂掉的长任务会从零重启，你要为它已经烧掉的每一个 GPU 小时再付一次钱。 这些都不是模型问题。 (工程师们向我描述的最昂贵的失败，从来不是模型出错；而是那些离完成只差一步就死掉的长任务。) ## 3、团队用胶带拼凑的技术栈 所以团队自己动手构建缺失的那一层，一次事故补一块。 这里加一个调度器。那里加自定义重试装饰器。一个上次 OOM 后有人写的检查点脚本。一个为推理单独搭建的服务栈，因为编排器从来就不是用来"服务"什么的。顶部再硬绑一块仪表盘，它看得见任务，却永远看不见状态。 这些系统之间的每一条接缝，都是状态丢失的地方。编排器在不知道检查点存在的情况下做重试。服务栈不知道它背后的模型刚刚被重新训练了。结果你调试"胶水"代码的频率比调试工作负载本身还高（而这恰恰是一个运行时存在的意义——就是为了删掉这些工作）。 运行时的全部论点就是：应该由一层来掌控执行状态，这样恢复、推理和可观测性都从同一个事实来源读取。那才是凌晨三点你真正会去查看的单一地方。 ## 4、Flyte 2：第一个开源 AI 运行时 8 月 4 日，Union.ai 发布了 [Flyte 2](http://flyte.org/?ref=hubwiz.com)，这是第一个能在你自己的基础设施上规模化运行持久化 AI、ML 和智能体工作负载的开源 AI 运行时。 Flyte 本身在工程团队中已经根深蒂固。这个项目有数千万次下载，4000+ 家组织在运行它，其中包括前沿 AI 实验室和财富 500 强团队，而且它是与 NVIDIA、Amazon、Google 和 Nebius 等合作伙伴一起开发的。Flyte 2 继承了同样的业绩记录，并专门为完成上面描述的工作而重建，如今迎来了完整的开源 GA。 三项能力承担了核心工作： 1. **针对基础设施和代码失败的持久化、自我修复工作流。** 这是让我坐直身子的那项。Flyte 2 具有基础设施感知能力：OOM 崩溃是你的代码能够捕获并处理的事情，并且能在运行时调配所需资源。这意味着你可以构建在运行时从逻辑故障和基础设施故障两方面自我修复的工作流。 2. **动态的、智能体原生的执行。** 工作流在运行过程中可以分支、循环、调用工具和自适应，而不会失去持久性。计划由工作流本人在运行时决定，所以智能体循环是一种原生形态，而不是硬贴在固定图之上的 hack。 3. **实时和批量推理，同一个运行时。** 训练和服务（无论是批量还是实时）在同一个系统上运行，所以独立的服务栈（以及它所需的胶水代码）就消失了。 围绕这三项：开箱即用的生产级 UI，免费运行（后端和 SDK 是 Apache 2.0，UI 在 Union 许可下源代码可得），而且一切都运行在你自己的机器和云上，所以你的数据永远不会离开。 ## 5、运行它时是什么样子 Union.ai 随发布附带了一系列可复现的项目，发布在[他们的示例仓库](http://github.com/unionai/workshops/tree/main/tutorials?ref=hubwiz.com)里。它们一起走完了上面所有内容，而我会建议你在看任何文档页之前先看这些。 [LLM 后训练 GRPO](https://github.com/unionai/workshops/tree/main/tutorials/llm-fine-tuning-grpo-countdown?ref=hubwiz.com) 项目是一个不错的入门选择。它用一次运行就用上了完整技术栈，使用组相对策略优化（GRPO）——一种由 DeepSeek 引入的强化学习算法——来微调 LLM，使其在特定任务上获得更好的性能。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-Uae2XPkmFmRNBVvyz4usYw.png) 一个任务失败（UI 中的红点），然后恢复并在重试时成功，而不是重启整个运行。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-fFB68dmxDop8nOrzZU4bUw.png) [Claude 智能体研究流水线](https://www.union.ai/docs/v2/flyte/tutorials/agents/deep-research/?ref=hubwiz.com)展示了智能体原生的执行：给它一个返回多个研究方向的提示词，编排会在运行时自适应，进行扇出而不是遵循固定脚本。 [VLM 应用](https://www.union.ai/docs/v2/flyte/tutorials/computer-vision/qwen-vl-finetuning/?ref=hubwiz.com)在预构建环境中实时运行视觉语言模型，与处理批处理工作的运行时是同一个。这就是"无需独立服务栈"的故事，正在运行中。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-p9ApWmH-pLNdAa7f02jpUw.png) 最快的入门途径是 Flyte 2 devbox，大约五分钟就能在本地启动，而且 Flyte 2 今天就能在本地运行。 上面的一切都可以在你承诺任何东西之前，先在你自己的机器上跑起来。 ## 6、校准你的怀疑 三件事。 第一，用持久性来评判一个运行时，功能清单放在第二位。问题在于：一个工作流能否在基础设施故障中存活下来，而不是凌晨三点死掉，因为从基础设施和逻辑故障中恢复，正是 AI 团队每周都实际面对的那个缺口。 第二，如果你的工作负载是真正线性、确定性的——一个永不分支的夜间批量流水线——你的编排器就够了。运行时在工作流变得动态、任务变得又长又贵时才有用武之地。为一个 cron 任务采用运行时是杀鸡用牛刀。 第三，采用任何新的执行层都要付出迁移成本，而一个刚 GA 的产品意味着你是早期采用者。早期在这里有实实在在的好处（Apache 2.0、GitHub 和 Slack 上庞大的既有 Flyte 社区），但它仍然是一个你应该诚实做预算的账目。 没有哪一层能删除生产环境的艰难部分。运行时只是给它们找到了一个"负责人"。 ## 7、这会落向何处 我想留给你的重新框架是：AI 的生产就绪性，一直以来都是执行层的属性。我们一直把它当作每个团队各自写的胶水代码（我也一样，当年[我交付我的第一个智能体](https://medium.com/data-science-collective/the-complete-guide-to-building-your-first-ai-agent-its-easier-than-you-think-c87f376c84b2?ref=hubwiz.com)的时候），这就是为什么每个团队的胶水看起来都像别人的事后复盘。 一旦执行层变成"你采用的东西"而不是"你写的东西"，失败故事就会改变形态。凌晨三点的 OOM 现在只是一条日志了。 我的收件箱会告诉我这个说法是否站得住。 考虑到已经在生产环境运行 Flyte 的都是谁，我看好这个概率。 --- 原文链接: [The Durable AI Runtime, A Definitive Guide](https://medium.com/data-science-collective/the-durable-ai-runtime-a-definitive-guide-3d3b2a03e1cd?source=home%5Ffor%5Fyou---------64-1--------------------97a79a14%5F8f1e%5F46df%5F9831%5Fe5b1435a099f-------15-------) 汇智网翻译整理，转载请标明出处