p50与p99延迟：中位数基准测试为何误导AI代理工作负载

如果你对延迟分析还不熟悉，请先快速浏览一遍，之后按需查阅。

本文使用的唯一公式是 P = 1 − (1 − q)^n，即当每次调用独立地以概率 q 落入尾部事件时，n 次调用中至少有一次落入尾部的概率。该公式在首次出现的“智能体乘数”一节中会逐步解释。

• 一个干净的中位数配上糟糕的尾部，并不是四舍五入的误差。而是你的流量中固定比例的请求每天都体验不佳，这是由构造决定的。 在每天 10,000 次请求的情况下，1% 的尾部事件意味着每天有 100 个用户命中它，无论中位数看起来多好。这是一个数学恒等式，而不是基准测试的断言；我通过直接计算验证了它，并在下文中展示了公式，而不是让你盲目相信。
• 对于单个请求，三种不同的指标分别对应三种不同的工作负载。 流式聊天 UX 关注首 token 时间，语音和长流式输出关注 token 间延迟，而智能体和批处理任务则关注总完成时间。定义依据 Artificial Analysis 的已发布方法论。如果不指明你在说这三个中的哪一个，就宣称“最快的服务商”，这不是一个完整的论断。
• 对于智能体管道来说，数学发生了变化。链式顺序调用的延迟逐项累加，至少一次调用落入尾部的概率随着链长增加而上升。我检查了一个常见的说法，即这种概率会以多快的速度接近必然性，发现数据并不支持这一说法：在每次调用尾部概率为1%的情况下，10次调用的链给出的是9.6%，而非接近必然；这一点已通过直接计算验证，并在下节中完整展示。修正后的数学仍然是一个真实且实质性的风险，只是不像通常被夸大的那样。
• 在头条基准测试中胜出的模型可能会在任务中落败，而我对此是实测而非模拟。在2026年7月27日的DigitalOcean Serverless Inference上，Llama 4 Maverick在单次调用首Token延迟对比中，以4倍优势击败GPT-OSS 120B（中位数300毫秒对1,202毫秒）。在实测的10次调用智能体链上，排名发生了反转：GPT-OSS 120B以20.9秒的中位数完成了任务，而Maverick为26.7秒；Maverick测到的最差链耗时超过20分钟，因为一次调用的流在生成中途停滞了。
• 可重复的测试协议胜过信任任何单一已发布的数据，包括本文中的这些数据。我在三个模型上运行了完整协议，并对第四个模型进行了有界后续测试，从同一云环境中的GPU Droplet记录了超过1,500个请求。下面包含每一个数字、每一条注意事项以及确切脚本，以便你针对自己的流量形态重新运行。完整的证据库、测试工具、原始逐请求数据、控制台日志、分析代码和图表，公开在我为此研究创建的serverless-inference-tail-latency-study GitHub仓库中。

把这一点直说在最前面。如果你的中位数首Token时间是干净的300毫秒，但p99是4秒，并且你每天服务10,000个请求，那么每天大约有100个请求会遭遇比仪表盘上的数字长十倍以上的等待。这不是噪声。百分位数是一种定义，而非测量伪影：按照构造，p99就是你的流量中有1%会超过的值，并且在你以该速率运行的每一天都是如此。

对于单个请求，这已经是越过中位数去看的理由。对于包含多个请求的会话，风险会复合。如果会话中的每个请求有独立1%的概率落入尾部，那么一个包含20个请求的会话至少命中一次尾部事件的概率为：

P(at least one tail event) = 1 − (1 − 0.01)^20 ≈ 18.2%

我通过直接计算验证了这一点。在该长度的会话中，接近五分之一会包含至少一个坏请求，即使任何单个请求只有1%的可能是坏的。这正是整篇文章所基于的机制：独立的小风险，重复足够多次后，就不再是小事。

为什么p50和p99在推理场景下会产生分歧

这种分歧有一系列具体、机制性的原因，每一个都在关于推理芯片与架构的配套文章中深入讨论过。简要来说：

并发下的排队意味着你的请求开始时间取决于它前面有多少其他请求，而不仅仅取决于模型运行的速度。批处理动态意味着你的请求可能要先等待批处理窗口填满，GPU才会开始处理它。即使你自己的提示词很短，一个共享你的批次或GPU的长提示词邻居也可能延长你的prefill时间，因为prefill是计算密集型的，而大型并发提示词会消耗你的请求所需的那部分计算资源。在缩放到零的基础设施上，冷启动会为任何在空闲期后恰好排在第一个的请求增加完整的模型或适配器加载时间。DigitalOcean自己对微调无服务器部署的分析发现，冷启动会专门推高首Token延迟，而不是稳态生成速率；定期发送保活请求是一种实用的缓解措施。来源：无服务器架构上的微调LLM，DigitalOcean社区。

尾部是曲线下的一小部分面积。在真实流量规模下，它也是一个固定的、重复出现的真实请求数量，而非舍入误差。

何时中位数才是正确的指标

大规模、对延迟不敏感的批处理工作负载、评估套件、离线摘要、合成数据生成以及大规模内容审核，关心的是吞吐量和每个token的成本，而不是任何单个请求的等待时间，因为没有用户盯着加载动画。DigitalOcean自己的批处理推理明确地将该类流量与实时服务隔离。其文档化的限制指出，批处理调度不会使实时推理p99延迟降低超过5%，这正是平台自身的承诺，表明这两者属于具有不同指标的不同工作负载类别。来源：DigitalOcean推理限制。如果你的工作负载属于此类，那么吞吐量和每个成功请求的成本才是正确的指标，本文其余部分不会改变你的评估。

延迟不是单一数值。它可分解为三个测量项，每个测量项主导不同类型的工作负载。

1. 首Token时间是发送请求与收到第一个输出token之间的延迟。这就是聊天界面的用户在屏幕上出现任何内容之前所盯着的那段时间，它由prefill（预填充）主导，即在生成开始之前处理整个输入提示词的计算密集型步骤。

2. 令牌间延迟，有时称为每个输出令牌的时间，是生成开始后每个后续令牌之间的间隔。它决定了一个较长的流式响应是感觉顺畅还是断断续续，并且对语音接口和长格式流式答案最为重要，因为在这些场景中，读者或听者会连续消费令牌，而不是一次性等待。

3. 总完成时间是 TTFT 加上整个生成时间，当没有人在观看流式输出时，它是唯一重要的指标，而这正是批处理任务或代理管道中的中间调用的情况。这些定义的来源：Artificial Analysis 语言模型基准测试方法论。

三种不同的时钟，三种不同的工作负载。为其中之一优化的提供商不会自动在其他两个方面表现强大。

没有单一的“最快提供商”

询问哪个提供商的 TTFT 最快是一个规定不明确的问题，除非你还说明了并发数、提示长度以及你正在测量的输出长度，因为在这些条件下排名会重新排列。

这不是一种模糊的说法。你可以直接对照 Artificial Analysis 自己发布的提供商比较 进行验证，该比较明确按输入令牌数区分速度，并在判断默认基准工作负载不具有代表性时对其进行更新。他们在一个比较页面上的注释明确指出，“默认性能基准测试工作负载已更新为 10k 输入令牌，以更好地反映生产用例”，这是 Artificial Analysis 承认他们之前的默认值并不代表真实流量。

为相同模型服务的提供商之间的差距足够大，以至于在没有附加条件的情况下，“最快提供商”是一个毫无意义的短语。在 GLM-5.2 上，Artificial Analysis 报告最快和最慢提供商的输出速度之间相差 963%。在 gpt-oss-120b 上，报告差距为 4,149%，其中 Cerebras 以每秒 1,677.5 个令牌位居榜首。来源：Artificial Analysis，GLM-5.2 提供商比较 和 Artificial Analysis，gpt-oss-120b 提供商比较。我想准确说明哪些是我自己推导的，哪些是直接陈述的：Artificial Analysis 直接陈述了百分比差距和最快提供商的速度。根据这些百分比反推，意味着最慢的提供商在 GLM-5.2 上约为每秒 45 个令牌，在 gpt-oss-120b 上约为每秒 39 个令牌。这两个推断出的数字是我根据 Artificial Analysis 陈述的差距自己计算的，而不是 Artificial Analysis 作为独立数字发布的数据，你应该将它们视为估计值，而不是确认的数据点。

两种情况下模型完全相同。提供商不同，而最好和最差提供商之间的差距，使你在竞争模型之间发现的任何差异都相形见绌。

流式输出的错觉

一个提供商可以在 TTFT 上胜出，却在实际上决定你的用户是否在放弃之前读完的指标上落败。首个令牌很快，但令牌间延迟很慢，会在最初一刻给人响应迅速的感觉，然后就开始拖沓。对于长流式回答来说，这不是一个好的特征，但对于代理来说却几乎无关紧要，因为代理的编排层不会观察令牌是否到达，它是在等待完整响应后再决定下一步行动。这就是为什么脱离你的工作负载，就不存在单一的“最快提供商”答案。正确的问题应指明指标、并发数和令牌长度，而不仅仅是提供商名称。

这是数学必须完全正确的部分，所以我会展示我的推导过程，而不是直接断言结论。

代理任务很少通过一次模型调用完成。一个典型的代理工作流——工具调用、推理步骤、工具调用、综合——需要执行 5 到 20 次顺序模型调用才能完成一个任务。任务延迟不是任何单次调用的延迟，而是链中每次调用的总和，因为每次调用都要等待前一次调用的结果来确定其下一个输入。这重新定义了整个问题：预测用户体验的指标不是任何单个调用的 p50 或 p99，而是这个总和的分布。

关于链中尾部概率的修正断言

关于这种效应，我看到过一种说法，我想直接核查而不是重复：即针对每次调用 p99 尾部率的 10 次调用链，会使得尾部事件对该任务而言几乎必然发生。我直接检查了这一点，数字并不支持这种说法。

使用与上面单会话案例相同的公式，其中 q 是每次调用发生尾部事件的概率，n 是链中的调用次数：

P(at least one tail event in the chain) = 1 − (1 − q)^n

在每次调用 1% 的尾部率（即 p99 阈值所隐含的比率）下，一个 10 次调用链得出：

1 − (0.99)^10 ≈ 9.6%

使用以下七个问题来批判性地审视任何已发布的延迟声明。

• 报告的是哪个百分位数？
  仅报告中位数的声明只能告诉你典型请求的情况，而对尾部一无所知。

• 测试在什么并发度下运行？
  在并发度为1时测量的数字描述的是最佳情况，真实负载下的排队不会保持这种情况。

• 使用了什么提示词和输出长度？
  TTFT随提示词长度扩展，因为预填充受计算限制，而总时间随输出长度扩展。

• 实例是热还是冷？
  包含冷启动的基准测试与仅使用热实例的基准测试回答的是不同的问题。

• 测量了什么时间窗口和持续时间？
  非高峰时段的一次突发请求可能看起来与持续的生产流量截然不同；DigitalOcean自身的一致性测试发现，在营业时间内运行的基准测试可能看起来异常好，因为其他用户让模型保持了热状态。

• 使用的是流式还是非流式测量？
  没有流式，TTFT就无法定义。

• 测量位置是包含还是排除了真实网络路径？
  在与提供商相邻的基础设施上运行的基准测试会低估真实客户端所经历的延迟。

缺少这七个细节中任何一个的延迟声明，都是你尚无法据此行动的声明。它不一定是一个虚假的声明，只是一个不完整的声明。

不带怀疑地应用检查清单

谷歌研究人员2026年发表的一篇关于测量偏差的论文更进一步，指出了许多基准测试客户端构建方式中的一个具体技术故障模式：单进程、asyncio驱动的负载生成器在高并发下可能遇到自身的客户端排队瓶颈，作者将其建模为M/G/1队列，而这种客户端瓶颈可能会夸大基准测试想要测量的TTFT和每token延迟数据。来源：识别并缓解生产环境LLM推理基准测试中的系统性测量偏差，arXiv。作为读者，这对你的实际意义是：即使是出于真实意图运行的基准测试，其测量的对象可能既包括目标服务器，也同样包括其自身的客户端，这再次说明一个有记录、可复现的方法论比一个标题数字更有价值。

DigitalOcean自己的社区内容已经对自身进行了这种批判。其对同一模型在不同提供商上一致性的分析报告了变异系数（标准差除以平均值），在支持良好的提供商上低至21%，而在不同提供商上同一模型的变异系数高达710%，同一个模型，一致性却相差34倍。来源：为什么无服务器推理在相同模型上的一致性会有所不同，DigitalOcean社区。

来源：为什么无服务器推理在相同模型上的一致性会有所不同，DigitalOcean社区。该文将变异系数超过100%定义为冷启动和排队方差的特征，超过300%则视为不适合延迟敏感型工作的生产环境。

可预测的延迟，正确定义

“可预测的延迟”并不意味着低中位数。它意味着围绕任意中位数的低方差，而衡量这一点最简洁的单一数字就是p99与p50的比率。一个p50为300毫秒、p99为350毫秒的提供商，比一个p50为200毫秒、p99为2,000毫秒的提供商更可预测，即使后者的典型情况更快。DigitalOcean自己发布的对旗下两个模型的serverless行为分析发现，典型和最坏情况下的首token时间相差在几百毫秒内，其中一个模型在典型与最坏情况之间仅从0.29秒变为0.35秒。来源：Serverless推理中的关键指标，DigitalOcean社区。接近1的p99:p50比率正是该发现用本文所用术语所描述的情况；上文一致性文章中的变异系数衡量的是围绕均值的方差这一紧密相关的量，而不是两个命名百分位数之间的比率，两者都是量化同一底层属性的合法方式。

当架构被专门设计为使这一比率接近1，而非靠运气时，Groq的LPU采用的确定性调度方法是最清晰的例子，这在关于推理芯片的相关文章中有深入介绍。

尾部延迟对于承受它的公司来说也不是一个学术指标。在DigitalOcean发布的客户成果中，Hippocratic AI运行安全关键的医疗代理，报告称在平台上超过2000万次患者交互中，生产吞吐量是原来的2倍，p99延迟降低了40%。注意那句话中的指标是p99，而不是中位数。那些产品在尾部表现不佳时会崩溃的团队，会在尾部上进行协商和衡量，下次基准测试给你一个中位数并称其为速度时，这一点值得记住。

本节描述测试设计，然后报告实际运行的结果。我于2026年7月27日，从DigitalOcean NYC2区域的一个GPU Droplet（gpu-h200x1-141gb）上，针对DigitalOcean Serverless Inference执行了此测试，使用下方打印的确切脚本进行完整协议运行。运行产生的所有内容——测试框架、所有1,590个记录请求的原始逐请求JSON、控制台日志、分析代码和图表——都已添加到此公开Github仓库：github.com/anishsingh20/serverless-inference-tail-latency-study。

测试设计

针对单一模型运行，保持恒定，因此测试中的唯一变量是流量形态和并发度：

• 单次调用基线，三个并发级别。在并发1下，每个单元至少75个顺序请求，然后在并发5和并发20下重复相同的请求模式，以观察排队如何随负载上升改变分布。75个请求是DigitalOcean自己的一致性测试用来可靠暴露冷启动的阈值；请求太少可能会完全错过尾部。以下具体阈值以及高峰与低谷时段建议的来源：为什么同一模型上的Serverless推理一致性会变化，DigitalOcean社区。
• 两个时间窗口。在营业时间内运行一次完整的并发扫描，在夜间或周末再运行一次，因为当模型的背景流量最低时冷启动行为最差，而仅白天测试可能看起来人为地好。
• 链式多调用测试。构建一个模拟代理循环的10次调用顺序链，每次调用的输出作为下一次调用的输入，并至少运行30个独立链。记录每个完整链的总完成时间，而不仅仅是每次调用，并直接从这30个总数中计算链级p50、p95和p99，而不是试图从每次调用的数字重建。

测量和计算什么

对于每个单元：中位TTFT、p95 TTFT、p99 TTFT以及p99:p50比率。对于链式测试特别指出：总链完成时间的分布，而不是任何单个调用的分布，因为该总数是预测用户或下游系统实际等待时间的数字。

两个互补测试。并发扫描显示排队如何在负载下降低单次调用性能。链式测试显示真实代理工作负载端到端的实际体验。

针对DigitalOcean Serverless Inference运行此测试的设置清单

这里的每一步都是我为获得以下结果而实际执行的步骤，并针对DigitalOcean自己当前的页面进行了记录，以便你可以在操作时逐步验证。

1. 创建模型访问密钥。在DigitalOcean云控制台中，转到Inference部分并创建模型访问密钥。你可以将其范围限定到特定模型，也可以不限定。参见管理模型访问密钥。

测试框架

#!/usr/bin/env python3
"""
Latency benchmark for DigitalOcean Serverless Inference.

Measures, per request:
  - TTFT (time to first streamed token), timestamped client-side
  - total completion time
  - prompt and completion token counts, from the usage object

Workloads:
  1. baseline_sweep  - N requests at concurrency 1, 5, and 20
  2. chained_session - M independent chains of `chain_length` sequential
                        calls, each call's output feeding the next call's
                        input, with total chain time recorded per chain

Concurrency is implemented with a real OS-thread pool (ThreadPoolExecutor),
not a single-process asyncio loop. This is a deliberate choice: a 2026
measurement-bias paper (Chandrasekar and Kramberger, arXiv, cited in this
article) shows that single-process asyncio benchmarking clients can hit
their own client-side queueing bottleneck under concurrency, which
inflates the very TTFT numbers you are trying to measure. Real OS threads
release the GIL during blocking network I/O, which avoids that specific
failure mode at the modest concurrency levels used here.

Run:
  export DO_MODEL_ACCESS_KEY=your_key_here
  python3 do_latency_bench.py --model  --out results_daytime.json
  python3 do_latency_bench.py --model  --out results_overnight.json
"""

import argparse
import concurrent.futures
import json
import os
import time
import urllib.request


def percentile(sorted_vals, pct):
    """Linear-interpolation percentile, no external dependency required."""
    if not sorted_vals:
        return None
    k = (len(sorted_vals) - 1) * (pct / 100)
    f = int(k)
    c = min(f + 1, len(sorted_vals) - 1)
    if f == c:
        return sorted_vals[f]
    return sorted_vals[f] * (c - k) + sorted_vals[c] * (k - f)


def summarize(ttfts_ms):
    s = sorted(t for t in ttfts_ms if t is not None)
    if not s:
        return {"n": 0}
    p50 = percentile(s, 50)
    p95 = percentile(s, 95)
    p99 = percentile(s, 99)
    return {
        "n": len(s),
        "p50_ms": round(p50, 1),
        "p95_ms": round(p95, 1),
        "p99_ms": round(p99, 1),
        "p99_to_p50_ratio": round(p99 / p50, 2) if p50 else None,
    }


def streamed_request(base_url, api_key, model, messages, max_tokens=64):
    """Send one streaming chat completion. Return TTFT and total time in ms."""
    payload = {
        "model": model,
        "messages": messages,
        "max_tokens": max_tokens,
        "temperature": 0,
        "stream": True,
        "stream_options": {"include_usage": True},
    }
    req = urllib.request.Request(
        base_url + "/chat/completions",
        data=json.dumps(payload).encode(),
        headers={
            "Content-Type": "application/json",
            "Authorization": f"Bearer {api_key}",
        },
    )
    start = time.perf_counter()
    ttft = None
    content_parts = []
    usage = {}
    try:
        with urllib.request.urlopen(req, timeout=120) as r:
            for raw in r:
                line = raw.decode(errors="ignore").strip()
                if not line.startswith("data:"):
                    continue
                body = line[5:].strip()
                if body == "[DONE]":
                    break
                chunk = json.loads(body)
                if chunk.get("usage"):
                    usage = chunk["usage"]
                for choice in chunk.get("choices", []):
                    delta = choice.get("delta", {})
                    if delta.get("content"):
                        if ttft is None:
                            ttft = (time.perf_counter() - start) * 1000
                        content_parts.append(delta["content"])
    except Exception as e:
        return {"error": str(e), "ttft_ms": None, "total_ms": None}
    total = (time.perf_counter() - start) * 1000
    return {
        "ttft_ms": round(ttft, 1) if ttft is not None else None,
        "total_ms": round(total, 1),
        "prompt_tokens": usage.get("prompt_tokens"),
        "completion_tokens": usage.get("completion_tokens"),
        "content": "".join(content_parts),
    }


def baseline_sweep(base_url, api_key, model, n_requests, concurrency_levels, prompt):
    results = {}
    messages = [{"role": "user", "content": prompt}]
    for c in concurrency_levels:
        print(f"[baseline] concurrency={c}, {n_requests} requests", flush=True)
        records = []
        with concurrent.futures.ThreadPoolExecutor(max_workers=c) as pool:
            futures = [
                pool.submit(streamed_request, base_url, api_key, model, messages)
                for _ in range(n_requests)
            ]
            for f in concurrent.futures.as_completed(futures):
                records.append(f.result())
        ttfts = [r.get("ttft_ms") for r in records]
        results[f"concurrency_{c}"] = {
            "summary": summarize(ttfts),
            "records": records,
        }
    return results


def chained_session(base_url, api_key, model, n_chains, chain_length, prompt_prefix):
    chains = []
    for i in range(n_chains):
        history = [{"role": "user", "content": f"{prompt_prefix} Chain {i}, step 0."}]
        start = time.perf_counter()
        calls = []
        for step in range(chain_length):
            r = streamed_request(base_url, api_key, model, history)
            calls.append(r)
            history.append({"role": "assistant", "content": r.get("content") or "ok"})
            history.append(
                {"role": "user", "content": f"Chain {i}, step {step + 1}. Continue."}
            )
        total_chain_ms = (time.perf_counter() - start) * 1000
        chains.append({"chain_index": i, "total_chain_ms": round(total_chain_ms, 1), "calls": calls})
        print(f"[chained] chain {i} done: {total_chain_ms:.0f} ms total", flush=True)
    chain_totals = sorted(c["total_chain_ms"] for c in chains)
    return {
        "chain_summary": {
            "n_chains": len(chain_totals),
            "p50_ms": round(percentile(chain_totals, 50), 1),
            "p95_ms": round(percentile(chain_totals, 95), 1),
            "p99_ms": round(percentile(chain_totals, 99), 1),
        },
        "chains": chains,
    }


def main():
    ap = argparse.ArgumentParser()
    ap.add_argument("--base-url", default="https://inference.do-ai.run/v1")
    ap.add_argument("--model", required=True, help="Exact model ID from GET /v1/models")
    ap.add_argument("--n-requests", type=int, default=75)
    ap.add_argument("--n-chains", type=int, default=30)
    ap.add_argument("--chain-length", type=int, default=10)
    ap.add_argument("--out", default="latency_bench_results.json")
    args = ap.parse_args()

    api_key = os.environ.get("DO_MODEL_ACCESS_KEY")
    if not api_key:
        raise SystemExit("Set DO_MODEL_ACCESS_KEY before running.")

    results = {
        "model": args.model,
        "timestamp": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
    }

    print("== Baseline sweep ==", flush=True)
    results["baseline_sweep"] = baseline_sweep(
        args.base_url,
        api_key,
        args.model,
        args.n_requests,
        concurrency_levels=[1, 5, 20],
        prompt="Reply with a two-sentence summary of why caching matters for LLM inference.",
    )

    print("== Chained session ==", flush=True)
    results["chained_session"] = chained_session(
        args.base_url,
        api_key,
        args.model,
        args.n_chains,
        args.chain_length,
        prompt_prefix="You are debugging a production incident.",
    )

    with open(args.out, "w") as f:
        json.dump(results, f, indent=2)
    print(f"Wrote {args.out}", flush=True)


if __name__ == "__main__":
    main()

完全按照文档字符串中所示的方式运行它，在每个时间窗口各运行一次。脚本会在运行时打印进度，并将每一条原始记录写入输出文件。

实际运行了什么，以及运行条件是什么

以下所有内容均来自该协议的一次执行，这些是运行条件，在给出数据之前先说明以便您衡量其参考价值：

• 客户端：DigitalOcean NYC2 区域中的一个 GPU Droplet（gpu-h200x1-141gb，24 个 vCPU）。网络路径位于云内部且路径很短，这意味着这些数据可能略微低估了公共互联网上客户端实际会遇到的情况。但另一方面，这也是一类读者的真实场景：如果您的应用程序已经运行在 DigitalOcean 上，紧邻推理端点，那么这里测得的短路径正是您生产流量实际经过的路径，中间没有跨云跳转或出口流量。该 Droplet 的 GPU 与本次测试无关；它只是当时可用的机器。
• 端点和负载：https://inference.do-ai.run/v1/chat/completions，启用流式输出，temperature 为 0，max_tokens 为 64，每个基线请求都使用相同的简短提示词，与上面的脚本发送的内容完全一致。
• 测试量：每个模型的完整协议包括 225 个基线请求（并发数 1、5、20 各 75 个）加上 30 条独立的 10 次调用链，即每个模型 525 个请求。共有三个模型完成了测试：Mistral 3 14B、GPT-OSS 120B 和 Llama 4 Maverick，共计记录 1,575 个请求，其中零失败请求。
• 时间窗口：我只在一个时间窗口内执行了测试，即 2026 年 7 月 27 日星期一 08:39 至 10:53 UTC，对应美国东部时间凌晨 4:39 至 6:53，属于低流量时段。协议要求第二个对比窗口，但本次运行没有；请将这里的每个数据都视为单窗口测量结果。
• 一个测量注意事项：测试框架将 TTFT 定义为第一个内容token 的时间。少数 GPT-OSS 120B 响应（并发 1 时 75 个中有 3 个，并发 5 时 75 个中有 10 个，并发 20 时 75 个中有 1 个）将其全部 64 个 token 预算用在了内部推理 token 上，没有产生任何内容，因此它们有总时间但没有 TTFT，该模型的 TTFT 行是基于剩余请求计算的。

测量结果

按并发级别划分的首 token 时间，每个单元格 75 个请求：

并发数为 1 时单次调用的总完成时间，以及本文一直在讨论的一致性指标：

实测的 10 次调用 agent 链，每个模型 30 条链，每条链的总任务时间：

剔除 Maverick 那条流中断的链（上文 agent 倍增部分已描述），其剩余 29 条链仍测得 p50 为 26.6 秒，p95 为 47.2 秒，最长 57.7 秒：即使去掉了灾难性事件，它在每个百分位上都比 GPT-OSS 120B 更慢且分布更宽。

每条线代表 75 个真实请求。关键在于形状而非起点：Maverick 起点快但散布很宽；GPT-OSS 起点慢但保持稳定。

如何解读该图表：在线条上任选一点，它表示“这个百分比的请求（纵轴）在该时间内获得了第一个 token（横轴）。”几乎垂直上升的线代表可预测的模型：几乎所有请求的等待时间大致相同。快速上升然后向右弯成一条长而平缓的斜线的线代表存在尾部的模型：大多数请求很快，但最后几个百分比的请求等待时间要长得多。这个弯曲处正是 p95 和 p99 所在的位置，如果只发布线条跨越 50% 的点，这个尾部就完全看不见了。

在这张图表中，Mistral 3 14B 在典型和最坏情况延迟方面都“胜出”：它不仅中位首 token 时间最低，而且几乎所有请求都紧密聚集在一起——即使在尾部也是如此。Llama 4 Maverick 在中位数上接近，但其尾部宽得多，意味着少数请求耗时明显更长。GPT-OSS 120B 起步较慢，但保持着短而一致的尾部。Mistral 兼具快速起步和紧密分布，当您同时关心典型和最坏情况延迟时，它是明显的赢家。

中位数几乎不随并发从1升至20而移动。尾部移动更多，这恰恰是为什么并发为1时的中位数是基准报告中最缺乏信息量的数字。

如何阅读此图表：每个面板代表一个模型，底部从左到右表示同时处理中的请求数量，每个面板中的三条线分别代表典型请求（p50，实线）、慢请求（p95，虚线）和非常慢的请求（p99，点线）。实线平坦意味着典型体验在负载上升时保持不变。需要关注的是实线与点线之间的垂直间距：当该间距向右移动时变宽——就像GPT-OSS 120B在并发20时那样——说明队列开始拉长尾部，尽管中位数看起来仍未受影响。正是这一机制让提供商的基准数字与您的生产体验悄悄分道扬镳。

哪个模型胜出以及原因：Mistral 3 14B，且优势明显。它在每个百分位和每个并发级别上都实现了最快的首个令牌，无论有1个还是20个并发请求，中位数约为172至182毫秒，p99从未超过628毫秒；即使其测量到的最差百分位也大约是GPT-OSS 120B最佳中位数的一半。Llama 4 Maverick以快速的中位数（214至320毫秒）位居第二，但p99高出四到五倍，约为1.4至1.6秒。GPT-OSS 120B在两项指标上均垫底：启动最慢（中位数1.1至1.3秒），并且是唯一在负载下尾部明显恶化的模型，随着并发从1升至20，p95从2.0秒拉长到3.1秒，p99从2.1秒拉长到3.6秒。

可能的原因主要是模型大小以及首个令牌之前发生的事情：Mistral 3 14B是这里最小的模型，因此每个请求在输出任何内容之前所需的预填充工作成本很低，在此期间，共享池吸收了20个并发请求而没有出现可测量的排队。GPT-OSS 120B大约大一个数量级，并且在此部署中，会将其部分预算用于首个内容令牌出现之前的内部推理，因此其TTFT起点较高，并且最先感受到排队压力。不过，本文其余部分的告诫仍然适用：赢得首令牌时间只是赢得了流式聊天指标。在总完成时间和实测的10次调用链上，Mistral 3 14B也确实最先完成，但GPT-OSS 120B却击败了Llama 4 Maverick，尽管它在这张图表的每个面板上都输给了对方。

第四个模型本身就是一项发现

我原本打算在llama3.3-70b-instruct上运行完全相同的完整协议。我使用上述测试工具中的同一streamed_request函数运行了15个顺序请求，并包裹了一个看门狗，对每个请求强制设置150秒的硬性挂钟上限，并在每个结果完成时立即写入磁盘，因此一个停滞的流最多只会花费150秒，而不会拖垮整个运行。

所有15个请求都在上限内完成。TTFT中位数为2.1秒。64个令牌的总时间中位数为43.5秒。15个请求中有两个分别等待了37秒和68秒才获得首个令牌，这是排队或冷路径的典型特征，而其他13个请求在1.6至3.4秒内获得了首个令牌。按照这种速度，在此模型上执行10次调用的代理链在中位数情况下需要超过7分钟，因此没有运行链式测试，该模型的数字来自15个请求而非525个，应据此权重来解读。

这是本文中最尖锐的论点，而且并非事先计划：在该特定时间段内，目录中最知名的模型名称在同一端点上每个已完成的请求比三个不太知名的替代方案慢一至两个数量级，然而没有任何显眼的TTFT数字会提醒您这一点，因为其TTFT中位数是看起来合理的2.1秒。真正说明问题的是几乎没有人发布的数字：总完成时间及其分布。

解读你的发现

右尾肥厚且主体看似正常的分布表明存在排队或批处理争用：典型请求没有问题，但一部分请求在其他流量之后等待。Maverick的实测TTFT正是这种模式：中位数300毫秒，p99是它的五倍，变异系数为75%，而GPT-OSS 120B为27%。双峰分布——一群快速请求和一组与之分离的慢速请求，两者之间存在间隔——是冷启动或拥塞路径的特征：一些请求命中了热副本，另一些没有，中间几乎没有过渡。Llama 3.3 70B的有界运行显示了这种形态，13个请求在3.4秒内获得首个令牌，2个请求等待了37秒和68秒。

对于肥尾模式，直接的缓解措施是专用端点或预留容量，因为其根本原因是与其他租户流量的竞争。具体到DigitalOcean，无服务器和专用推理属于同一平台的一部分，从共享容量转向专用容量被视为容量决策而非迁移项目，这一点很重要，因为做出该决定的正确时机是在像这样的测量之后，而不是之前。对于双峰模式，直接的缓解措施是预热池或定期的保活流量，以从根本上防止副本数降至零。如果您跨多个模型或提供商路由，会话固定可以让一系列调用保持在同一条热路径上，而不是在任务中途重新触发冷启动；这在我写的关于提示缓存和会话固定的相关文章之一中直接讨论过。

当您的工作负载是交互式、基于会话或受延迟SLA约束时，请使用p95和p99进行评估。单个面向用户的请求或短会话正是尾部真实影响用户体验的情况。

当您的工作负载是包含三个或更多顺序调用的代理流水线时，请根据任务完成时间进行评估。从您的任务时间目标推导出所需的每次调用p99，然后反向工作，而不是先选择每次调用的目标并期望总时间能令人满意。如果您的任务预算是10次调用共5秒，那么您实际的每次调用预算在尾部应接近500毫秒，而不是中位数；本文前面的实测结果说明了为什么显眼的单次调用指标是用于核对这一预算的错误数字：在实测TTFT上快4倍的模型，在实测10次调用任务中却慢了28%。

当你的工作负载是离线批处理或异步管道，没有用户或下游系统在等待任何单个请求完成时，请以吞吐量和成本为评估标准，将尾部延迟放在一边。

如果你按成本与延迟的对比来跨模型路由请求，那么对于延迟关键路径，应依据实测的p99画像进行路由，而对于成本容忍路径，则按价格路由——鉴于具体路由机制已在推理路由器文档中说明，本文仅简要提及这一决策。

三种工作负载形态，三种正确的指标。使用错误指标不仅会误导你，还可能让你完全选错模型，如上文实测的TTFT与任务时间反转所直接显示的那样。

尾延迟复合公式以及从中推导出的每一个计算数值都是我的直接计算，并通过一个简单脚本进行核对，你可以针对自己的每次调用尾率及链长度重新运行同样的公式。本文中的实测延迟数据来自对已发布测试协议的一次执行，由作者于2026年7月27日从同一云环境中的GPU droplet对DigitalOcean Serverless Inference运行，使用了测试框架部分打印的精确脚本；原始的逐请求JSON已保留，所有表格均由它计算得出，完整证据库已发布在GitHub仓库中，任何人都可以从原始记录重新计算每个表格和图表。这些数字是真实的，但它们也只是一个时间窗口、一个客户端位置和一天的情况。它们描述的是该端点在那个窗口内的行为，而不是它在你的窗口内会如何表现，这正是包含脚本的全部原因。重采样的链长度曲线被明确标记为实测单次调用数据的bootstrap扩展，并与直接测量的链一起展示；当两者不一致时，实测链是基准真相。Artificial Analysis的供应商分布数据以及DigitalOcean的一致性和指标数据是真实的、已引用并直接链接的；TTFT排名部分中的两个“隐含最慢供应商”数据是我根据Artificial Analysis公布的百分比分布自行计算得出的，并非Artificial Analysis直接发布的数字，我已在出现时标明了这一区别。如果你运行该协议，并且你的结果与这里报告的任何内容（包括在DigitalOcean自己的serverless inference上）不同，那么这一修正比本文更有价值，我更希望你发布它，而不是假设本文已经涵盖了你的情况。

1. 低中位延迟是否可能是一个坏迹象？

本身不是。低中位数加上低p99:p50比率是最佳结果。低中位数加上高p99:p50比率意味着典型情况很快，但你的流量中有相当一部分并非如此，而单独的中位数永远不会告诉你这一点。

2. 如果每次调用1%的尾部概率听起来如此小，为什么它很重要？

因为“小”是相对于你承担风险的次数而言的。单个请求有1%的概率命中尾延迟。一个20次调用的代理链有18%的概率链中至少一次调用命中尾延迟，这个数字是本文直接验证而非假设的。

3. 这是否意味着我应该总是选择尾部延迟最紧的提供商，而不是中位数最好的提供商？

并非自动如此，完全取决于你的工作负载。对于流式聊天界面中的单个交互式请求，低TTFT加上可接受的p95可能是正确的选择。对于任何将顺序调用链成一个任务的工作负载，本文的实测结果显示，TTFT胜者在中位数上以28%的差距输掉了10次调用的任务，在p95上以84%的差距输掉，这就是为什么正确的评估指标取决于你的调用次数以及你的用户实际在等待什么，而不是对某一醒目数字的固定偏好。

4. 这些结果是否意味着GPT-OSS 120B比Llama 4 Maverick“更好”？

不，本文不应被引用为表达了这种意思。测量结果是某一天的一个时间窗口，固定64个token的输出上限，且没有评估答案质量，而答案质量通常是模型之间的决定因素。结果确实表明排名取决于指标：在此窗口内，Maverick确实赢得了TTFT，也确实输掉了任务完成时间。持久的启示是方法，而不是排行榜：在选择之前，用你自己的流量形态测量你的工作负载实际感受到的指标。

基准测试生态系统报告的是易于测量且有利于发表的内容。一个干净的中位数易于测量，而且总是令人满意。生产环境的痛点在于单个请求的分布形态，而对于智能体（agent）而言，则在于其调用链上每次调用的总和。本文对您应如何解读延迟数字提出了两点改变。对于任何单个交互式请求，要看分布而非中心值。对于任何将调用串联起来的工作负载，要看总任务时间而非单次调用的百分位数，并且要从任务级目标倒推每次调用的需求，而不是反过来。

请根据您自己的流量形态、并发度和调用链长度，运行本文中的测试协议。这是了解您自己生产环境体验的唯一途径。

1. 自行运行测试协议的GitHub仓库

• GitHub上的serverless-inference-tail-latency-study：本文中每个测量数字的完整证据基础——测量工具、编排和有界扫描脚本、所有1,590条记录的每请求原始JSON、未编辑的控制台日志、分析脚本以及四张图表，均采用MIT许可证。

2. DigitalOcean文档与工程内容

• 提示缓存与成本盈亏平衡
• Inferentia2、TPU、Groq LPU与GPU在LLM推理服务中的对比
• 无服务器推理指标参考
• 推理功能，可观测性部分
• 推理限制
• 为什么无服务器推理在同一模型上的一致性会有所不同
• 无服务器推理中重要的指标
• 针对您的每种使用场景的DigitalOcean推理模式对比
• 无服务器架构上的微调LLM
• 如何使用推理路由器
• DigitalOcean无服务器推理：深入解析
• 为什么一切看起来正常时p99首令牌时间（TTFT）却很高？LLM推理中尾延迟的调试

3. 外部来源

• Artificial Analysis，语言模型基准测试方法论
• Artificial Analysis，GLM-5.2（max）提供商对比
• Artificial Analysis，gpt-oss-120b（high）提供商对比
• Ashok Chandrasekar和Jason Kramberger，“识别并减轻生产环境LLM推理基准中的系统性测量偏差，”arXiv，2026。