实时LLM应用工程指南：延迟优化与流式架构实战

实时 LLM 应用的延迟通常用两个指标来衡量：首 token 响应时间（TTFT）和 token 间延迟（ITL）。要让交互感觉是即时完成的，TTFT 通常应该保持在 300 毫秒以下，ITL 应该足够低，让文本呈现为流畅的流式输出，而不是断断续续的跳跃。要实现这一点，需要全双工流式传输、高效的 prompt 处理，以及没有冷启动问题的推理基础设施——冷启动会给每个会话增加数秒的不可预测延迟。

亚秒级推理的架构模式

传输层很重要。对于基于浏览器的客户端，通过 HTTP/2 的 Server-Sent Events（SSE）可以提供单向流，具有自动重连和广泛的兼容性。WebSocket 适用于双向二进制流量，比如语音代理中的音频字节，但会引入额外的连接管理开销。无论使用哪种协议，都要保持连接活跃。重复的 TLS 握手和 DNS 查询会消耗延迟预算，所以要通过连接池重用 HTTP 会话。

在服务器端，使用异步运行时。在等待模型生成第一个 token 时阻塞事件循环会卡住所有并发用户。下面的示例展示了一个最小的 Python 异步生成器，它消费 SSE 流并在 token 到达时 yield 它们。

import asyncio
import os
from openai import AsyncOpenAI

client = AsyncOpenAI(
    base_url="https://api.oxlo.ai/v1",
    api_key=os.environ["OXLO_API_KEY"]
)

async def stream_tokens(prompt: str):
    response = await client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{"role": "user", "content": prompt}],
        stream=True
    )
    async for chunk in response:
        token = chunk.choices[0].delta.content
        if token:
            yield token

选择合适的模型和基础设施

模型大小直接影响推理速度。70B 参数模型提供高质量，但需要大量吞吐量优化才能用于实时场景，而更小的模型或混合专家架构可以提供强大的推理能力。