本文永久链接 – https://tonybai.com/2026/02/18/why-we-chose-go-over-python-for-llm-gateways

大家好，我是Tony Bai。

在 2026 年的今天，人工智能早已走出了实验室，成为企业级应用的核心驱动力。Python，凭借其在机器学习领域的绝对统治地位——拥有 PyTorch、TensorFlow、Hugging Face 等无可匹敌的生态系统——长期以来被视为 AI 开发的“默认语言”。

然而，随着 AI 应用从模型训练（Training）走向推理服务（Inference）和应用编排（Orchestration），工程重心发生了微妙的转移。当我们谈论模型本身时，Python 是王者；但当我们谈论承载模型流量的基础设施——网关、代理、路由器时，Python 还是最佳选择吗？

近日，开源 LLM 网关项目 Bifrost 的维护者在 Reddit 上分享了一篇题为《Why we chose Go over Python for building an LLM gateway》的技术复盘，引发了社区的强烈反响。他们放弃了拥有 LiteLLM 等成熟竞品的 Python 生态，转而使用 Go 重写了核心网关。结果令人咋舌：延迟降低了约 700 倍，内存占用降低了 68%，吞吐量提升了 3 倍。

这场技术选型的背后，折射出的是 AI 工程化进入深水区后，对并发模型、资源效率与部署架构的重新审视。

Python 的“舒适区”与“性能墙”

在项目的初期，选择 Python 似乎是理所当然的。

1. 生态惯性与“胶水”优势

绝大多数 AI 工程师都是 Python Native。从 LangChain 到 LlamaIndex，几乎所有的 Agent 开发框架都优先支持 Python。使用 Python 构建网关，意味着可以直接复用现有的库，甚至可以直接挂载一些轻量级的 Python 逻辑来处理 Embeddings 或 RAG（检索增强生成）流程。FastAPI 的易用性更是让开发者能在几分钟内搭建起一个服务。

2. 遭遇瓶颈：网关的本质是 I/O

然而，LLM 网关的业务属性决定了它的性能痛点。与计算密集型（CPU-bound）的模型推理不同，网关是典型的 I/O 密集型应用。它的核心职责是：

• 接收成千上万的客户端请求。
• 将请求转发给上游提供商（如 OpenAI, Anthropic, 或自建的 vLLM）。
• 等待上游响应（这是最耗时的环节，LLM 的首字延迟 TTFT 通常在秒级）。
• 将流式响应（SSE）回传给客户端。

在这个过程中，网关绝大部分时间都在“等待”。

3. Python 的并发痛点

Bifrost 团队在测试中发现，当并发请求数达到 500-1000 RPS（每秒请求数）时，Python 的瓶颈开始显现。

• GIL（全局解释器锁）的幽灵：虽然 Python 的 asyncio 可以处理 I/O 并发，但 GIL 依然限制了多核 CPU 的利用率。对于需要处理大量并发连接、同时可能涉及少量数据处理（如 Token 计数、PII 过滤）的网关来说，线程竞争（Thread Contention）成为了不可忽视的开销。
• 昂贵的上下文切换：在 Python 中维持数千个并发连接，其上下文切换的开销远高于编译型语言。

Go 的降维打击——数据背后的技术真相

Bifrost 团队最终选择了 Go。这一决定并非出于对语言的偏好，而是基于冷冰冰的 Benchmark 数据。让我们深入分析他们披露的核心指标。

延迟（Latency）：微秒与毫秒的鸿沟

数据对比：
* Bifrost (Go): ~11 微秒 (0.011ms) / 请求
* LiteLLM (Python): ~8 毫秒 / 请求

这是一个惊人的 700 倍 差距。

虽然 8 毫秒在人类感知中似乎微不足道，但在高并发架构中，这被称为“开销放大”。

• 累积效应：在一个复杂的 AI Agent 工作流中，可能涉及几十次 LLM 调用。如果每一层网关都增加 8ms 的延迟，累积起来就是可感知的卡顿。
• 高负载下的劣化：在 10,000 个并发请求下，Go 引入的总处理时间仅为 110ms，而 Python 方案则产生了惊人的 80 秒总 CPU 时间开销。这意味着 Python 方案需要消耗更多的 CPU 核心来维持同样的响应速度，否则请求就会排队，导致尾部延迟（Tail Latency）飙升。

此外，Go 的 net/http 标准库在处理 HTTP 请求时经过了极致优化。Go 不需要像 Python 那样依赖 ASGI/WSGI 服务器（如 Uvicorn），其原生的 HTTP 处理能力配合 Goroutine，使得每个请求的内存分配和 CPU 周期都降到了最低。

并发模型：Goroutine vs Asyncio

架构对比：
* Go: 10,000 个 Goroutines，每个仅占用 ~2KB 栈空间。
* Python: 受限于 OS 线程开销或 Event Loop 的单核瓶颈。

LLM 网关的特殊性在于长连接。LLM 的流式输出可能持续数秒甚至更久。这意味着网关必须同时维护成千上万个活跃连接。

Go 的 GMP（Goroutine-Machine-Processor）调度模型天生适合这种场景。成千上万个 Goroutine 可以复用少量的系统线程，上下文切换由 Go Runtime 在用户态极速完成，几乎不消耗系统内核资源。

相比之下，Python 即使使用了 uvloop，在面对海量并发连接的数据搬运时，其解释器的开销依然是一个沉重的包袱。

内存效率与成本

数据对比：
* Go: 内存占用降低 ~68%。
* 生产环境: Go 跑在 t3.medium (2 vCPU, 4GB) 上即可；Python 则需要 t3.xlarge。

对于大规模部署 AI 服务的企业来说，这意味着基础设施成本直接减半。

Python 的动态类型系统和垃圾回收机制导致其对象内存占用较大。而 Go 的结构体布局紧凑，且编译器能进行逃逸分析（Escape Analysis），将大量对象分配在栈上而非堆上，从而显著降低了 GC 压力和内存占用。

社区深度探讨——AI 时代的语言版图重构

这篇帖子在 r/golang 引发了极高质量的讨论，评论区揭示了行业内更深层次的趋势。

“AI 能够写代码”改变了竞争规则

过去，Python 的一大优势是“开发效率高”。写 Python 代码通常比写 Go 或 Rust 快。

但在 2026 年，“Agentic Coding”（即利用 AI Coding Agent 辅助编程）已经成为主流。

有开发者指出：“LLM 让编写 Rust 和 Go 变得非常高效，你完全可以享受到高性能语言的红利，而不用支付编写它们的‘学习成本’。”

这是一个极其深刻的洞察。

• Rust 的借用检查器：以前是新手的噩梦，现在 LLM 可以很好地处理生命周期标注。
• Go 的样板代码：if err != nil 虽然繁琐，但 Copilot/Cursor/Claude Code等 可以一键生成。

当“编写代码”不再是瓶颈时，“运行时性能”和“稳定性”的权重就被无限放大了。这进一步削弱了 Python 在后端基础设施层的竞争力。

Rust 还是 Go？

既然要高性能，为什么不直接上 Rust？

评论区对此展开了激辩。虽然 Rust 在理论上拥有比 Go 更高的性能上限和内存安全性（无 GC），但 Go 在“开发效率”与“运行效率”之间找到了完美的平衡点。

• Rust: 适合构建数据库、搜索引擎内核等对延迟极其敏感且逻辑复杂的底层组件。但 Rust 的“认知负担”依然较重，且编译速度较慢。
• Go: 提供了 80% 的 Rust 性能，但只有 20% 的开发难度。对于网关、代理这类中间件，Go 的标准库（特别是 net/http）极其成熟，编译速度极快，且自带 GC 能让开发者从内存管理的细节中解脱出来，专注于业务逻辑（如限流、计费）。

对于大多数 AI 网关场景，Go 是性价比最高的选择。

Python 的归宿：模型与胶水

这是否意味着 Python 将被淘汰？绝不。

社区共识非常明确：Python 的护城河在于 ML 生态。

• 模型训练与微调：PyTorch/JAX 无可替代。
• 数据科学与探索：Jupyter Notebook 是数据科学家的后花园。
• 快速原型开发：在验证想法阶段，Python 依然是最快的。

但在生产环境部署（Production Serving）阶段，架构正在发生分离：

• 控制平面（Control Plane）：由 Go/Rust 接管，负责流量调度、鉴权、日志、监控。
• 数据平面（Data Plane）：核心推理引擎（如 vLLM）虽然内部可能有 C++/CUDA 优化，但外层接口仍常由 Python 封装。

Go 在 AI 领域的未来展望

Bifrost 的案例只是冰山一角。我们正在目睹 Go 语言在 AI 领域的“新基建”运动。

静态二进制文件的魅力

Deployment simplicity 是作者提到的另一个关键点。

部署 Python 应用通常意味着：配置 Docker -> 安装 Python -> pip install requirements.txt -> 解决依赖冲突 -> 虚拟环境管理。

而部署 Go 应用：COPY bifrost /usr/local/bin/ -> Run。

在容器化和 K8s 盛行的今天，Go 的静态链接二进制文件极大地简化了 CI/CD 流程，减小了镜像体积，提升了冷启动速度（这对于 Serverless AI 推理尤为重要）。

AI 专有工具链的完善

虽然 Go 在 Tensor 操作库上不如 Python 丰富，但在应用层工具上正在迅速补齐。

• LangChainGo: 社区正在移植 LangChain 的核心能力。
• Vector Database Clients: Milvus, Weaviate, Pinecone 等向量数据库都有优秀的 Go SDK。
• 主流大模型 GenAI SDK: 像Google等主流大模型厂商官方对 Go 的支持力度都很大，Gemini、Claude、OpenAI 等模型的 Go SDK 体验都还不错。

架构师的决策建议

如果你正在构建一个 AI 应用平台：

• 不要用 Python 写网关：不要让 GIL 成为你高并发路上的绊脚石。
• 不要用 Go 写模型训练：不要试图挑战 PyTorch 的地位，那是徒劳的。
• 采用“三明治架构”：
  • 上层：Go 处理高并发 HTTP 请求、WebSocket、SSE。
  • 中层：Go 处理业务逻辑、数据库交互、Redis 缓存。
  • 底层：Python/C++ 容器专门负责模型推理，通过 gRPC 与 Go 层通信。

小结

Bifrost 从 Python 到 Go 的迁移，不仅仅是一次代码重写，更是一次架构理念的升级。它证明了在 AI 浪潮中，基础设施的性能与模型的智能同等重要。

随着 LLM 应用规模的爆发式增长，计算成本和响应延迟将成为企业关注的焦点。Go 语言凭借其高效的并发模型、极低的资源占用和极简的部署体验，正在成为 AI 基础设施层的“事实标准”。

对于 Gopher 而言，这是一个最好的时代。我们不需要成为算法专家，只需要发挥 Go 语言最擅长的能力——构建高性能、高可靠的管道，就能在 AI 时代占据不可或缺的一席之地。

资料链接：https://www.reddit.com/r/golang/comments/1r27pqx/why_we_chose_go_over_python_for_building_an_llm/

你认为 Python 会被“边缘化”吗？

随着 Agentic Coding 的普及，高性能语言的入门门槛正在消失。在你的 AI 实践中，是否也感受到了 Python 在生产部署时的无奈？你认为 Go 在 AI 领域还会攻下哪些阵地？

欢迎在评论区分享你的看法！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2026/02/09/go-immutable-types-8-year-dormant-proposal-awakened

大家好，我是Tony Bai。

2026 年 2 月 4 日，在 Go 语言规范团队的最新一次“语言变更评审会议”纪要中，一个尘封已久的 Issue 赫然在列：proposal: spec: immutable type qualifier #27975。

这个提案最初提交于 2018 年，那是“Towards Go 2”口号喊得最响亮的年代。当时的 Go 社区正沉浸在对泛型、错误处理和不可变性的热烈讨论中。然而，随着泛型的落地，关于不可变性的声音似乎逐渐微弱。

如今，这个提案被重新摆上台面，是否意味着 Go 语言在完成泛型这一宏大叙事后，终于要向“数据竞争”和“防御性编程”这两个顽疾开刀了？

今天，我们就来看看复盘这份长达 8 年的提案，剖析一下“不可变性”对 Go 意味着什么，以及它面临的巨大挑战。

痛点：防御性拷贝的代价

在 Go 1.x 的世界里，我们为了保证数据的安全性，往往需要付出高昂的代价。

假设你有一个包含敏感配置的结构体，你想把它暴露给其他包，但又不希望它被修改：

type Config struct {
    Servers []string
    // ...
}

// 现在的做法：为了安全，必须返回拷贝
func (c *Config) GetServers() []string {
    out := make([]string, len(c.Servers))
    copy(out, c.Servers)
    return out
}

这种“防御性拷贝”带来了两个严重问题：

1. 性能损耗：每次访问都要分配内存和复制数据，对于热点路径是不可接受的。
2. 语义模糊：如果我不拷贝，直接返回 c.Servers，调用者能不能改？文档说不能改，但这只是君子协定，编译器不会阻止手滑的程序员。

正如提案作者 romshark 所言：“我们现在的做法，要么是不安全的（直接返回指针），要么是低效的（防御性拷贝）。”

而不可变类型（Immutable Types）的引入，旨在提供第三种选择：既安全，又高效。

提案核心：immut 限定符

NO.27975 提案的核心思想非常直接：引入一个新的类型限定符（最初建议重载 const，后倾向于引入immut ），让编译器来强制执行“只读”契约。

想象一下这样的 Go 代码：

// 定义一个只读的切片类型
func ProcessData(data immut []byte) {
    // 读取是 OK 的
    fmt.Println(data[0]) 

    // 修改是编译错误的！
    // data[0] = 'X' // Compile Error: cannot assign to immutable type
}

在这个愿景中，不可变性是类型系统的一部分。

• 赋值限制：你不能把一个 immut 类型的变量赋值给一个 mut（可变）类型的变量，这防止了“权限逃逸”。
• 传递性：如果一个结构体是不可变的，那么它字段指向的所有数据（如切片、映射、指针）也自动变为不可变。

这看起来很像 Rust 的 & (immutable reference) 和 &mut (mutable reference)，或者 C++ 的 const。但 Go 社区的讨论，揭示了这背后远比想象中复杂的工程难题。

社区激辩：理想与现实的碰撞

这份提案下的讨论区，堪称 Go 语言设计哲学的“修罗场”。Ian Lance Taylor, Rob Pike 等核心大佬纷纷下场，与社区开发者展开了长达数年的拉锯战。

const 污染

这是 Ian Lance Taylor 最担心的问题。如果你把一个底层函数的参数标记为 immut，那么所有调用它的上层函数，为了传递这个参数，往往也需要把自己的变量标记为 immut。

这种“传染性”会导致代码库中充斥着 immut 关键字。更糟糕的是，如果你以后需要修改底层函数，让它对数据进行一点点修改，你需要修改整个调用链上的类型签名。这在 C++ 中被称为“const correctness”的噩梦。

io.Writer 的尴尬

bcmills 提出了一个极其尖锐的兼容性问题：现有的 io.Writer 接口定义是 Write(p []byte)。

• 如果我们把 p 改成 immut []byte，那么现有的所有 Write 方法实现都会破坏兼容性。
• 如果我们不改，那么即使我手里有一个只读的切片，我也没法把它传给 io.Writer，因为类型不匹配。

这似乎陷入了一个死循环：要么破坏所有现有代码，要么新特性无法与标准库兼容。

所谓“不可变”，到底是谁不可变？

jimmyfrasche 指出了一个微妙的语义陷阱。

在 C++ 中，const T& 只是意味着“我不可以通过这个引用去修改它”（Read-only View），并不意味着“这个数据本身不会变”。因为可能还有另一个非 const 的指针指向同一块内存，并且正在修改它。

如果是前者（只读视图），它无法解决并发安全问题（数据竞争依然存在）。如果是后者（真正的内容不可变），那么 Go 必须引入一套类似 Rust 的所有权（Ownership）系统来保证“没有其他人在写”。这对于 Go 来说，改动太大了。

为何现在重提？

既然困难重重，为何在 2026 年的今天，这个提案又被翻出来了？

我认为有几个关键因素：

首先，泛型的“降维打击”。以权限泛型（Permission Genericity）化解兼容性死结。

前面提到了，在 Go 1.18 泛型落地之前，不可变性提案面临着一个被称为“io.Writer 陷阱”的致命矛盾：如果将 io.Writer.Write(p []byte) 改为接受 immut []byte，将导致全世界现有的实现代码因签名不匹配而崩溃；如果不改，只读数据又无法直接传入。

泛型的引入为这一难题提供了全新的解题思路。通过类型约束中的联合类型（Union Types），我们可以实现所谓的“权限泛型性”。这意味着 mutability（可变性）不再是一个硬编码的死结，而可以作为一个类型参数（Type Parameter）来处理。

想象一下，我们可以利用泛型约束定义一个覆盖“可变”与“不可变”两种状态的超集：~[]byte | ~immut []byte。下面是在这种模式下的一个泛型化的Writer接口：

// 这是一个设想中的“权限泛型”接口
type Writer[T ~[]byte | ~immut []byte] interface {
    Write(p T) (n int, err error)
}

泛型化的 Write[T ~[]byte | ~immut []byte](p T) 方法，在逻辑上可以产生如下影响：

1. 权限无关的调用：由于约束涵盖了两种类型，调用者现在可以合法且安全地将 immut []byte 传给标准库函数，解决了“只读数据无法写入”的窘境。
2. 非破坏性的兼容：对于现有的实现者（如 bytes.Buffer），其原本定义的 Write([]byte) 签名可以被视为该泛型约束的一个特化实例。编译器可以在不改动任何旧代码、不引入任何运行时开销的前提下，在静态分析阶段完成权限的自动适配与校验。

其次，性能压力的倒逼。

随着 Go 在高性能领域的应用越来越深（如数据库、AI 推理），对于“零拷贝”的需求越来越强烈。能够安全地共享内存，是提升性能的关键。

最后是安全性需求。

在并发编程中，数据竞争依然是 Go 程序的头号杀手。go vet 和 race detector 虽然好用，但它们是运行时的、滞后的。社区渴望一种编译期的保证。

未来的可能性：温和的演进

虽然完全的“不可变类型”可能依然很难落地，但我们可以期待一些更温和的替代方案：

• 只读视图 (Read-only Views)：不是引入新的关键字，而是引入一种新的泛型类型 ReadOnly[T]，或者编译器内置的 view 类型。
• 纯函数检查：引入一种机制，标记某些函数是“无副作用”的，从而允许编译器进行更激进的优化。
• 静态分析增强：不改变语言规范，而是通过更强大的 vet 工具，利用注释或特定命名约定，来静态检查不可变性约束。

小结

NO.27975 提案的“复活”，是一个信号。它表明 Go 团队并没有满足于现状，依然在探索如何在保持“简单”这一核心价值观的同时，赋予语言更强的表达力和安全性。

无论最终结果如何，这都是 Go 语言演进史上值得铭记的一笔。它提醒我们：在软件工程中，没有免费的午餐，每一个简单的特性背后，都是无数次复杂的权衡。

你支持引入 immut 吗？

面对“性能”与“简单”的博弈，你是否愿意为了消除数据竞争而接受 immut 带来的“类型传染”？在你的项目中，是否也曾深受“防御性”的性能困扰？

欢迎在评论区分享你的看法，或者聊聊你最期待的 Go 演进方向！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。