免费 LLM 延迟优化：TTFT 指标与流式输出

免费模型访问解决了成本问题，却带来了延迟问题，而且大多数团队测量的指标本身就是错的。我的立场很明确：首 token 时间的 p95 决定了用户是否认为你的产品"快"，而花一个下午测量得到的信息，比任何基准排行榜都更有价值。免费层不是妥协，而是一种约束——它暴露了你的架构实际上能承受多少延迟。

为什么延迟是免费层的隐藏税

每次 API 调用都有一组响应时间分布，而用户感受到的恰恰是尾部的部分。一个平均 800 毫秒但在 p95 达到 6 秒的模型，无论平均值多漂亮，产品都会让人觉得坏了。免费端点通常与更繁忙的租户共享基础设施，这让尾部延迟更长、更不可预测。

平均延迟隐藏了最慢用户的真实体验。

共享基础设施意味着你的延迟也是别人的变量。

流式响应把 6 秒的等待变成了 2 秒的首 token 体验。

第一步是测量正确的指标，第二步是根据发现的结果做设计。

一个可复现的延迟测试

下面的脚本测量首 token 时间、总时间和 p95，支持配置请求数量。它故意做得很小，因为一个不能在五分钟内跑起来的延迟测试，最终会变成一个你根本不会去跑的测试。

import asyncio
import json
import statistics
import time

from openai import AsyncOpenAI

client = AsyncOpenAI(
    base_url="https://api.monkeycode.ai/v1",  # verify the current endpoint
    api_key="your-key-here",
)

async def one_request(prompt: str, model: str) -> dict:
    start = time.perf_counter()
    stream = await client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
        temperature=0,
    )
    first_token = None
    async for chunk in stream:
        if first_token is None and chunk.choices[0].delta.content:
            first_token = time.perf_counter() - start
    total = time.perf_counter() - start
    return {"first_token": first_token, "total": total}

async def run(prompt: str, model: str, n: int = 30):
    results = await asyncio.gather(*[one_request(prompt, model) for _ in range(n)])
    first_tokens = sorted(r["first_token"] for r in results)
    totals = sorted(r["total"] for r in results)
    return {
        "model": model,
        "requests": n,
        "p50_first_token": statistics.median(first_tokens),
        "p95_first_token": first_tokens[int(len(first_tokens) * 0.95)],
        "p50_total": statistics.median(totals),
        "p95_total": totals[int(len(totals) * 0.95)],
    }

if __name__ == "__main__":
    import sys
    model = sys.argv[1] if len(sys.argv) > 1 else "default-model"
    result = asyncio.run(run("Explain the difference between a mutex and a semaphore.", model))
    print(json.dumps(result, indent=2))

在不同时间段运行它，因为免费层有高峰期。用不同的提示词长度跑，因为 token 数量对延迟的影响比你想象的更大。从用户实际所在的地区运行，而不是从你的笔记本上跑。

慢车道的应对设计模式

一旦你知道了真实的延迟数据，设计工作就开始了。下面的模式按侵入程度从低到高排列。

流式响应不是可选项——它是用户感知"两秒"和"八秒"之间的分水岭。大多数 OpenAI 兼容的 SDK 只需一个 flag 就能支持它，用户体验的提升是立竿见影的。

控制并发上限

免费端点的限流策略非常激进，简单的并行化反而会让一切更慢。一个将并发请求数限制在小数字的信号量通常能提升总吞吐量，因为它避免了重试和退避惩罚。

import asyncio

semaphore = asyncio.Semaphore(3)  # tune this number

async def limited_request(prompt: str):
    async with semaphore:
        return await one_request(prompt, "default-model")

缓存确定性内容

如果你的提示词和参数完全相同，答案通常也完全相同。一个使用规范化提示词 key 的简单 TTL 缓存可以吸收相当比例的流量，而且几乎零成本。

import hashlib
import time

cache: dict[str, tuple[float, str]] = {}

def cached_response(prompt: str, ttl_seconds: int = 300) -> str | None:
    key = hashlib.sha256(prompt.encode()).hexdigest()
    entry = cache.get(key)
    if entry and time.time() - entry[0] < ttl_seconds:
        return entry[1]
    return None

构建降级阶梯

免费层最终一定会出问题，而且失败模式通常是响应变慢，而不是直接报错。降级阶梯在 p95 超过阈值时将流量路由到备用路径：首先是缓存响应，然后是更简单的提示词，最后是启发式答案。降级阶梯是"体验降级的产品"和"死掉的产品"之间的分水岭。

决策表：何时应该选择免费层

这张表是起点，不是结论。你的数据会告诉你该选哪一列，而上面的测试脚本就是你获取数据的方式。

局限性以及谁应该跳过这个方案

这个工作流假设你使用的是 OpenAI 兼容端点；如果你的提供商不支持流式响应，延迟的计算方式就完全变了。并发调优是和 workload 强相关的，所以信号量值 3 只是一个起点，不是建议。如果你的产品有合同约定的延迟要求，无论你围绕它做多少工程优化，免费层都是错误的基础。

本文描述的延迟工程是在 MonkeyCode 免费层上测试的，该层目前宣传提供 1000 万 token 和免费服务器选项。在以此为基础构建之前，请核实当前的条款，因为免费层会不经通知地更改限制。

披露：本文是 MonkeyCode 产品推广的一部分。

免费模型访问不是降级；它是一种设计约束，暴露了你的架构实际上能承受多少延迟。测量 p95，流式传输响应，限制并发，构建降级阶梯。把慢车道当作工程问题来处理的团队会交付感觉很快的产品，而忽视它的团队会交付感觉坏掉的产品。区别只在于一次测量。

如果你想了解你的 workload 在免费层上的表现，用上面的测试脚本针对任何 OpenAI 兼容端点跑一跑。数据会告诉你这笔交易是否值得做。