LLM API 调用全链路解析：从请求到流式响应

物理旅程与地域延迟税

你输入一个 prompt，点击发送，不到一秒，响应就开始流式输出。丝滑、即时。你感觉自己仿佛正在对着一台机器说出内心的想法。

可到了第二天——同一个模型、同一个 prompt——你却开始等待。三秒。五秒。光标不停闪烁，什么都没有。然后，所有内容突然一次性涌了出来。

你可能会怪自己的 Wi-Fi。

但那多出来的几秒钟里，真正发生的事情，是一个从你永远不会踏足的建筑开始，穿过铺设在海底的电缆，最后抵达某块 GPU 的故事——而在轮到处理你的思考之前，它还正忙着处理别人的思考。

如果你在非洲开发产品，或者身处弗吉尼亚、爱尔兰、法兰克福以外的任何地方——这个故事里，还有专门属于你的一章。

一次 API 调用的旅程

让我们跟随一个请求，看看从你点击发送的那一刻起，它经历了什么。

你的 prompt 离开设备，以数据包的形式经过 ISP，进入海底光纤电缆，跨越海洋，到达数据中心，被路由到正确的服务器，等待 GPU 空闲，接受处理，然后响应再沿着同样的路径返回。

整个往返过程快得让人感觉什么都没发生。

但并不是什么都没发生。每一步都需要时间。而其中一些步骤的耗时，会因为你身处地球上的位置不同而增加。

数据中心究竟是什么

在进入更有意思的部分之前，我们先打好基础。

数据中心是一栋建筑——有时占地面积相当于好几个足球场——里面装满了服务器。这些服务器是没有屏幕的计算机，被一台台堆叠在金属机架中，数量成千上万。它们一天二十四小时、一周七天不停运行，从不关机。

你发起的每一次 API 调用、在 WhatsApp 上发送的每一条消息、进行的每一次 Google 搜索、观看的每一个 YouTube 视频——所有这些操作，都会触达某个地方这样一栋建筑里的服务器。

这栋建筑需要三样东西才能运转：电力、冷却和网络连接。电力驱动服务器运行。冷却系统防止服务器熔毁——在如此高的密度下，服务器会产生巨量热量。网络连接则依靠光纤电缆，将这栋建筑接入互联网的其他部分。

尼日利亚有 17 座这样的建筑。美国则有超过 5,500 座。

这个差距非常重要。后面我们还会谈到它。

延迟：没人提醒过你的物理问题

延迟，是数据从 A 点传输到 B 点再返回所需的时间。

它受物理规律限制。数据在光纤中的传播速度大约是光速的三分之二。你无法让它变得更快，只能缩短传输距离。

拉各斯到伦敦大约有 5,000 公里。以三分之二光速计算，仅仅因为这段距离，理论上的最短往返时间就约为 50 毫秒。再算上路由、网络拥塞和处理时间，在你的请求真正到达服务器之前，可能已经过去了 100 到 150ms。

然后模型还需要思考。

接着，响应还要沿原路返回。

大多数在尼日利亚开发产品的程序员，连接的都是 us-east-1（弗吉尼亚）或欧洲西部（爱尔兰或法兰克福）的 LLM 服务器。这并不是抱怨——服务器就在那里。但这意味着，在 inference 甚至还没开始之前，每次 API 调用仅仅因为地理距离，就已经要承担 100 到 200ms 的延迟。

对于流式聊天机器人，你能够切实感受到这种延迟。第一个 token 出现之前的那段停顿，并不是模型太慢，而是光速作用在实际距离上的结果。

Inference：GPU 实际上在做什么

当你的 prompt 到达服务器时，它的处理方式并不像你想象的那样——并不是像搜索引擎一样匹配关键词。

模型会让你的 prompt 逐层经过数十亿次数学运算，以预测最有可能出现的下一个 token。然后是再下一个，再下一个。每个 token 都按顺序逐一生成，直到整个响应完成。

一个 token 大约相当于四分之三个英文单词。"hello" 是一个 token，"infrastructure" 是两个。你现在正在阅读的这段响应，会包含数百个 token。

这为什么重要？因为每一个 token 都会消耗算力。更长的 prompt 会在输入侧消耗更多算力，更长的响应则会在输出侧消耗更多算力。所有这些计算，都发生在数据中心的一块 GPU 上，并消耗着真实的电力。

GPU：为什么偏偏是这种硬件

你的笔记本电脑里有 CPU——中央处理器。它是为通用任务设计的：运行浏览器、编译代码、处理操作系统。它非常擅长高速地逐个处理任务。

GPU——图形处理器——最初是为了渲染电子游戏而设计的。它拥有数千个更小的核心，能够同时执行大量计算。事实证明，这种并行架构恰好满足 LLM inference 的需求：同时对数十亿个参数执行相同的数学运算。

一块用于 LLM inference 的高端 GPU——NVIDIA H100——价格约为 30,000 美元。运行 frontier model 的数据中心里，通常有数千块这样的 GPU。

当你调用 LLM API 时，请求会被路由到其中一块 GPU。如果这块 GPU 正忙着处理其他用户的请求，你的请求就只能等待。这种等待是真实存在的，最终会以延迟的形式出现在你这一端。

rate limits 真正限制的，正是硬件的物理处理能力。

冷启动：为什么第一个请求更慢

你可能已经注意到，有时隔了一段时间后发起的第一次调用，会明显更慢。

这不是错觉，而是一次 cold start。

模型非常庞大。一个 frontier model 的 weights 可能达到数百 GB——这些数字编码了模型掌握的知识。在执行 inference 之前，必须先把这些 weights 加载到 GPU 内存中。如果一段时间内没有请求进入，系统可能会卸载模型的一部分，为其他任务释放内存。

第一个请求必须等待模型重新加载。后续请求则可以直接使用已经预热的模型，因此感觉更快。

serverless LLM 部署尤其容易出现这种情况。流量低时，你支付的费用更少，但在经历一段安静期之后，你的用户会感受到第一个请求的等待。

为什么特别要谈尼日利亚

尼日利亚的 17 座数据中心中，有 14 座位于拉各斯，它们几乎完全依靠柴油发电机运行。该国国家电网平均每天只能供电四小时。每座数据中心都必须用发电机弥补其余时间的电力缺口，全天候燃烧柴油。

这非常昂贵。这也是当地云基础设施未能像电力稳定的市场那样实现规模化发展的原因。

这对开发者意味着：你发起的每一次 LLM API 调用，都会被路由到尼日利亚以外的服务器。它不在西非，很多时候甚至不在非洲大陆。对于你拥有的每一个用户、他们发起的每一个请求，你都要为这段距离付出延迟成本。

这不是软件问题，而是地理与基础设施问题。它会直接影响用户使用 AI 产品时的实际体验。

这对开发意味着什么

有三件实用的事情需要注意：

流式输出响应。不要等完整响应生成后才显示内容。让 token 在到达时即时显示，即使实际速度没有变，也会让体验感觉更快。因为用户能看到系统正在工作，感知延迟会显著降低。

积极使用缓存。如果你反复调用相同或高度相似的 prompt，请缓存响应。Inference 很昂贵，延迟也很昂贵。对于重复查询，缓存可以同时消除这两项成本。

为任务选择合适的模型。一个拥有 700 亿参数的模型，会比 70 亿参数的模型更慢、成本更高。对于许多任务——分类、提取、短文本生成——较小的模型已经足够，而且能以快得多的速度返回结果。frontier model 并不总是正确的工具。

数据中心之所以存在，是因为计算必须依托某个具体的物理空间。要运行这些让 AI 显得毫不费力的基础设施，就必须消耗电力、水资源和土地，并具备网络连接。

非洲拥有全球 18% 的人口，却只占全球数据中心容量的不到 1%。非洲大陆产生的数字需求，与其实际拥有的基础设施之间存在巨大差距——延迟来自这个差距，依赖来自这个差距，价值被抽取也发生在这个差距之中。

当你知道这是物理问题，而不是代码问题时，你寻找原因的方向会发生变化。当你知道 Equinix、AWS 和 Microsoft 掌握着非洲大陆大部分可用容量时，你看待这件事的方式也会发生变化。

问题很可能不在你的代码，而在某个地方一栋依靠柴油运行的建筑里。

AI 帮助我研究、组织并编辑了这篇文章。其中的论点、案例和观点都属于我。文章中无论有什么错误，也同样属于我。

部分评论可能仅对已登录的访客可见。请登录以查看全部评论。

如需采取进一步操作，你可以考虑屏蔽此人和/或举报滥用行为。