Python 新版本去 GIL 刷屏，Karpathy 点赞敢死队，Python 之父：冷静，别神话并发

这周，Python 3.14 正式发布，把悬念了多年的“去 GIL（全局解释器锁）”写进官方发行版。

此次更新并非只是一项开关，而是一整套能力同步上线，涵盖自由线程支持、使用并发解释器、经过改进的调试器支持以及作为可选项的新解释器（有望将性能提升 3% 至 5%）。

Python 中的自由线程功能可禁用全局解释器锁（GIL），目前已在 PEP 703 中得到完整实现。它还配套了一个自适应解释器思路，源自 Mark Shannon 领衔的 Faster CPython 项目（尽管微软已在今年 5 月停止官方支持，相关成果已沉淀进实现）。

长期以来，GIL 既像安全网也像减速带：通过“同一时刻仅允许运行一个 Python 线程”来保障内存安全、避免许多棘手的并发 Bug，却也限制了 CPU 密集型多线程程序对多核的利用，除非借助繁琐的变通方案。如今，3.14 提供的自由线程（no-GIL）构建移除了这道栅栏，使多线程能够真正并行，重计算场景下的性能收益尤为明显。当然，权衡也必须看见——单线程速度通常会略有回落，内存占用大约增加 10%。这意味着开发者拥有了更清晰的选择权：需要稳妥与兼容时沿用带 GIL 的默认构建，需要极致并行时切换到 no-GIL 构建。

发布之后，许多开发人员报告说与过去的版本相比，速度明显提高。

在一系列基准测试中，它比去年的 Python 3.13 快了约 25%。

去 GIL 条件下，时间从 5.77 秒缩短到了 1.36 秒。

开发者 Jeffrey Emanuel 写道，“Python 3.14 终于真的发布了。终于移除了 GIL，这意味着多线程代码会快得多，不用再忍受多进程的脑损伤和各种临时变通。uv 已经完全支持，这太令人印象深刻了。”在他看来，这是一个“革命性、差异极大”的版本。

截图来源：https://x.com/doodlestein/status/1976478297744699771

起初，他以为自己的项目（依赖 PyTorch／pyarrow／cvxpy 等）还会被困在“GIL 地狱”。转念一想，不如交给 codex／GPT-5：自动检索博客与 issue，必要时 vendor 部分库，用 C++／Rust 从 nightly 源码构建替代轮子。经过数小时多轮迭代，最终全部跑通。与“大模型之前”的年代相比，此类升级既耗时又高风险；而现在，“我们正在生活在未来”。

Andrej Karpathy 也在 X 上点赞这个贴文，就像是一记注脚：这一次，Python 的并发故事真的开始加速了。

不过，和社区对“去 GIL”与 AI 的狂热相比，Guido van Rossum 在发布后的一次专访中给出了更为冷静的提醒：他直言去除 GIL 的重要性被高估，去 GIL 主要服务于超大规模并发场景，同时抬高了 CPython 的贡献与维护复杂度；AI 炒作太过了，“归根结底还是软件”，他并不迷信“AI 驱动的未来”，更强调代码必须可读、可审；工程常识优先于热点——并发模型并不易掌握，很多人在并行化后反而变慢，与其逐热，不如把生态兼容、可维护性与长期演进放在更优先的位置。

以下是 Guido van Rossum 访谈的翻译：

Guido van Rossum: 代码仍然离不开人类的阅读和审查，否则我们可能会完全失去对自身生存的控制力。而且看起来，Python 等秉承“人文主义”哲学的语言也适合用来编写模型——毕竟大语言模型擅长的就是处理人类语言结构，而编程语言终究也是为人类设计了。因此只要经过相应训练，大模型将很擅长阅读和输出这类语言。另外，大部分大模型都接受过良好的 Python 语言能力训练。

Guido van Rossum: 我完全没想到过！我不是个很有野心的人，现在回想起来成功的关键因素可以说有两个。首先，作为一种语言，Python 既易于理解、且功能极其强大。正如 Bruce Eckel 所说，“它特别贴合人类的脑回路”。第二个因素则是，我在设计 Python 时会考虑如何让它跟操作系统服务和第三方库良好集成。这样它的功能将更多样也更加可扩展，例如允许 NumPy 之类的主流库独立于 Python 本体之外进行开发。

Guido van Rossum: 老实说，我觉得移除 GIL 这事的影响被过度夸大了。这既满足了我们最大用户（例如 Meta）的需求，同时也给 CPython 代码库的潜在贡献者招了点麻烦（新代码更容易引入并发性 bug）。

我们经常听到有人说，他们在尝试了代码并行化之后速度反而变慢了——这让我认为大众对于 Python 编程模型的理解仍有进步的空间。

再有，我担心 Python 会变得过于企业化，因为大企业客户只会为他们需要的新功能付费。这里澄清一下，企业客户虽然不会花钱让我们替他们实现功能，但会提供开发人员参与贡献，所以其实是一回事。

Guido van Rossum: 我没听说过有哪些大规模关键任务型 AI 应用，我只知道有很多大规模关键任务型非 AI 应用。对于这类应用程序来讲，类型提示非常非常重要，也是其他工具对代码库进行有效处理的前提。我认为类型提示的应用阈值大概是一万行代码——低于这个阈值，类型提示的价值就会降低，因为开发者自己就能记住其中大部分代码，传统动态测试也基本应付得来。而一旦代码量达到上万行，缺少了类型提示几乎没办法保证代码质量。当然，我不会强迫语言初学者使用类型提示。

Guido van Rossum: 我不觉得这里需要专门强调范式的变化，毕竟范式转换其实就意味着过往的经验已经无法帮助我们理解新的现实。但要说最关键的经验教训，那就是对于任何未来的版本更新，哪怕只是从 3.x 到 3.x+1，我们都必须始终考虑如何在不改变旧应用形态的前提下实现支持。总而言之，迁移方法必须经过慎重考虑，特别是大多数库都必须同时支持多个版本（我们在 2.0 到 3.0 的升级过程中对此体会不深，也没有制定出好的解决方案）。

Guido van Rossum: 到目前为止，我使用的 AI 库都不算特别强大或者复杂——它们只是让人们能跟远端实际提供 AI 服务的设施进行通信。相比之下，很多互联网协议反而更复杂，而且也没什么本质上的区别。

要说差异，那就是 AI 提供商的节奏太快了，有时候每几周就变更一次 API，提供的说明文档也是质量低下、内容混乱。 总之我们会继续遵循长久以来的实践思路——用库和 API 构建这个世界。

Python 经历过计算领域的一系列剧烈变革，却仍然屹立不倒，所以我对这个问题并不太担心。早在 90 年代初互联网几乎不存在的阶段，那时微软还通过软盘和光盘分发软件；我们还经历了互联网和万维网的发展，从集中式计算到个人电脑，再到浏览器端软件以及硬件的巨大改进，Python 都平稳走过来了。

Guido van Rossum: 我什么都想不出来。我还是觉得现在 AI 炒作太甚了，它的本质仍然是种软件。 在我自己的 AI 使用体验中，确实会借助一些小型库来发挥它的技术能力，也就是利用 AI 的优势以传统方式高效处理数据库操作。我们也有一部分代码是由所谓“智能体”编写的，但我们不会使用氛围编程。我们在架构和 API 设计方面一直保持高度自主可控。

Guido van Rossum: Mojo 强调成为高性能 AI 的实现“内核”，这要求对计算机进行非常严格的分类优化。所以它既不可能取代 Python 的生态地位，也并不打算这么做。我印象中 Julis 好像跟高性能 AI 关系不大——它更多面向高性能数值计算，就是说既能服务于 AI，也能服务于其他具有苛刻要求的应用领域。

Guido van Rossum: 这肯定代表着地位的下降。我一直担任 BDFL，直到 Python 的所有治理职责不再由一个人承担，这其实就标志着我已经退休了。而之后选择微软，是因为我意识到自己仍然想要继续编程。在供职于谷歌和 Dropbox 之后，告别了鲍尔默时代的微软似乎确实是个体验更多编程乐趣的好地方。

Guido van Rossum: 我绝不向往一个由 AI 驱动的未来。我担心的并不是 AI 会毁灭整个人类族群，只是我看到过太多缺乏伦理道德之人，往往用极低的代价就对全社会造成了巨大破坏。如今这股炒作弊端的根源就在社交媒体——AI 只是又一次重大的计算机范式转变，它确实会颠覆社会，但并没有真正影响软件的本质。

我希望 Python 的传承能够始终体现其草根精神和全球协作精神，始终依托于平等和尊重，而非权力和金钱。希望 Python 始终为“平凡人”赋能，帮助他们编写出灵感中的项目。

参考链接：

https://www.odbms.org/blog/2025/10/beyond-the-ai-hype-guido-van-rossum-on-pythons-philosophy-simplicity-and-the-future-of-programming/