AI 应用的端到端 latency 工程 2026：从流式首字延迟、人类感知延迟到可观测性闭环的统一架构
一句话摘要：在 LLM 已经从"推理能力竞赛"转入"应用体验竞赛"的 2026 年，latency 不再是单点优化，而是从服务端 prefill 调度、流式分块、客户端感知补偿到可观测性反馈的端到端工程闭环——任何一段失守都会让"流式输出"沦为营销词。
一、问题的提出：为什么 latency 是 AI 应用的非功能王冠
如果说 2023-2024 年是 LLM "能不能回答"的能力竞赛，2025-2026 年就是"用起来是否舒服"的体验竞赛。这个转折点是 OpenAI 在 2024 年下半年把 streaming 设为 ChatGPT 默认响应模式，Anthropic 在 Claude 3 系列跟进，Google 把 Gemini 的 multi-modal streaming 集成到 Workspace——三家头部厂商用产品决策宣告了一个事实：流式输出不再是优化项，而是基础设施。
但流式输出并不等于低延迟。一个常见的产品幻觉是：只要把模型推理切到 streaming 协议（SSE 或 WebSocket），用户体验就会"立刻变好"。实际上，如果 TTFT（Time To First Token）依然超过 2 秒，或者 ITL（Inter-Token Latency）在长输出中波动剧烈，streaming 反而会比 non-streaming 更糟——用户看着光标闪烁却收不到有意义的内容，会比"等待完整响应"产生更强的挫败感。
latency 作为非功能属性的特殊性在于：它是一个全局可加性指标，由服务端、传输层、客户端、人类感知层四段串联而成，任何一段的恶化都会被累积放大。一个 TTFT=800ms、ITL=60ms、客户端渲染=20ms 的链路，表面上各段都不差，但当一段回答有 500 token 时，最后一个 token 的到达时间是 800 + 60×500 + 20 = 30820ms ≈ 30 秒。30 秒对人类感知来说已经进入了"是不是卡死了"的判断窗口。
本文的核心论点：AI 应用的 latency 工程不是"调参"，而是一个从服务端推理调度、传输层流式分块、客户端人机协作补偿、到可观测性反馈闭环的四段串联架构。每一段都有独立的优化手段，但只有把它们作为一个整体来看，TTFT、ITL、感知延迟 P50/P90/P99 才能同时落入 SLA 区间。
本文不重复"什么是 streaming"这种入门话题，也不深入到 CUDA kernel 或 attention 算法层面——这两个方向分别由 GPU 推理优化系列和 KV cache 工程系列覆盖（参见 2026-09-12 id=485 KV cache 多层存储工程）。我们的视角始终是AI 应用工程师：你拿到一个模型 API、面对一个真实用户、要在 SLA 区间内交付完整答案。
二、形式化：TTFT、ITL、TPS、感知延迟的四元组
在展开工程方案之前，先把指标体系钉死。这不是学术洁癖——2026 年的 AI 应用 latency 工程领域，最常见的失败就是"团队成员各自在优化不同的指标，最后整体 SLA 仍然破线"。原因是没有共享的形式化定义。
2.1 四个核心指标
设请求从用户按键开始，到最后一字渲染完成的时间轴 T。我们将 T 分解为以下四段：
- TTFT（Time To First Token）：从请求发出到服务端返回第一个 token 的延迟。包含客户端组装请求、网络传输 RTT、服务端排队、prefill 阶段、第一个 decode token 的网络回传。TTFT 是用户感知"是否有人在回应我"的关键指标。经验阈值：优秀 < 500ms，合格 < 1500ms，劣化 > 3000ms。
- ITL（Inter-Token Latency）：相邻两个 token 之间的间隔。这是 streaming 流畅度的核心指标。经验阈值：流畅 < 80ms，合格 < 150ms，可接受 < 250ms，超过 300ms 用户开始感到"卡顿"。
- TPS（Tokens Per Second）：ITL 的倒数乘以 token 数。TPS 与 ITL 是同一现象的两种描述方式。TPS 在 SLA 契约里更便于表达"每秒至少多少字"。
- 感知延迟（Perceived Latency）：用户主观感受到的等待时间。这不是纯物理量，而是 TTFT、ITL、内容可读性、UI 反馈四者的非线性函数。2026 年的用户研究（参见 Nielsen Norman Group 的最新报告）表明，感知延迟由三个拐点控制：100ms（瞬时感）、1s（流畅感）、10s（注意力上限）。
2.2 可加性分解
设 Ltotal 为总延迟，则：
Ltotal=LTTFT+Ntokens⋅LITL+Lrender
其中 Lrender 是客户端最后一块字符的渲染时间（通常 < 50ms），Ntokens 是输出 token 数。这条公式看似简单，但它揭示了三个非显然的事实：
- TTFT 是 1 次惩罚，ITL 是 N 次惩罚：对于一个 1000 token 的回答，TTFT 优化 100ms 仅占总延迟的 0.3%，但 ITL 优化 10ms 就占总延迟的 33%。长输出场景下 ITL 优化的 ROI 高于 TTFT。
- 感知延迟不是平均延迟：ITL 在长输出中的方差会被用户感知为"卡顿"。即使 ITL 均值 60ms，如果 P99 跳到 200ms，用户会判定这个产品"不稳"。
- TTFT 与 ITL 的优化手段常常冲突：TTFT 优化要求 prefill 阶段尽可能并行（如 chunked prefill、prefix cache），而 ITL 优化要求 decode 阶段尽可能串行（如 batch=1、speculative decoding）。必须在不同请求级别做权衡。
2.3 SLA 契约的设计
一个 2026 年的成熟 AI 应用 SLA 契约应包含四元组：
| 指标 | 含义 | P50 阈值 | P90 阈值 | P99 阈值 |
|---|
| TTFT | 首字延迟 | ≤ 500ms | ≤ 1000ms | ≤ 2000ms |
| ITL | 流畅度 | ≤ 80ms | ≤ 150ms | ≤ 250ms |
| TPS | 吞吐 | ≥ 12 | ≥ 8 | ≥ 5 |
| 感知延迟 | 用户主观 | ≤ 800ms | ≤ 2500ms | ≤ 8000ms |
注意 P50/P90/P99 不是同比例放大——感知延迟的 P99 容忍度远高于 ITL 的 P99，因为人类对"偶尔一次慢"比对"持续均匀慢"更宽容。
三、服务端 latency 控制：prefill、decode 与流式分块
服务端 latency 是整个链路的物理基础。2026 年的主流 LLM 服务栈（vLLM、TGI、SGLang、TensorRT-LLM）都围绕 prefill-decode 分离 + 连续批处理 + PagedAttention 构建，本节聚焦应用工程师可控的部分：请求级别的优化。
3.1 Prefill-decode 分离与 chunked prefill
传统推理引擎把整个 prompt 一次性送入 GPU 完成 prefill，然后进入 decode 循环。这种"一次性 prefill"在长 prompt（>4K token）时会产生两个问题：(a) prefill 阶段独占 GPU，decode 请求被阻塞；(b) 长 prefill 计算导致首字延迟爆炸。
chunked prefill（vLLM 0.4+、TGI 1.4+ 默认开启）把长 prompt 切成多个 chunk（如 512 token/块），每个 chunk 与 decode 请求混合调度。带来的好处：prefill 不再阻塞 decode，首字延迟显著下降（长 prompt 场景下降 30-50%）。代价：chunk 间有少量 KV cache 状态切换开销。
应用层的可调参数：--max-num-batched-tokens（vLLM）或 chunk_size（TGI），典型值 2048-8192。经验法则：chunk_size 设大能提升吞吐但恶化 TTFT，设小能优化 TTFT 但损失吞吐。对于面向交互式用户的 AI 应用，推荐 chunk_size=2048 起步。
3.2 Prefix cache 与 KV cache 命中
如果用户多次访问相同 system prompt（这是 99% 的 AI 应用场景），那么 prompt 的 KV cache 可以复用——这就是 prefix cache 或 prompt cache。命中 prefix cache 后，prefill 阶段直接跳过，TTFT 可以从 800ms 降到 50ms。
2026 年的成熟方案是两级 prefix cache：
- L0（内存级）：当前进程的请求复用，命中率 30-70%。
- L1（Redis/共享内存级）：跨进程/跨实例复用，命中率 20-50%。
- L2（SSD 级）：跨集群复用，命中率 10-30%，延迟增加 50-200ms。
应用层的关键决策是cache key 的设计。常见错误：把整个请求（含 user 消息）作为 cache key，导致命中率 0%。正确做法：以 system prompt + 工具定义 + 长期记忆 的哈希作为 cache key，user 消息变化不影响命中。
3.3 Speculative decoding 与 ITL 优化
Speculative decoding（投机解码）用一个小型 draft 模型先猜 N 个 token，让大模型并行验证。这能把 ITL 从 60ms 降到 25-40ms，但代价是 draft 模型本身的开销和正确率波动。
2026 年的工程经验：
- draft 模型大小：建议是主模型的 1/10 到 1/5（如 7B 主模型配 1.5B draft）。
- 投机长度：通常 4-8 token，过长会因 draft 频繁被拒而浪费。
- 自适应投机：根据 draft 接受率动态调整投机长度（接受率 > 80% 时拉长，< 50% 时缩短）。
应用层的决策点：是否启用 speculative decoding？如果你的应用是"长输出、对话式"，强烈推荐；如果你的应用是"短输出、批量 API"，开启反而会增加 P50 延迟。
3.4 流式分块策略
服务端 streaming 不是"逐 token"发出，而是按 chunk 发出。chunk 大小直接影响两个相反的指标：
- chunk 太小（如 1 token）：每个 chunk 都触发一次网络包传输，TCP overhead 大，且服务端调度粒度细，吞吐下降。
- chunk 太大（如 50 token）：用户感受到"一卡一卡"的渲染，ITL 视觉方差大。
2026 年的经验最优值：chunk 大小 = 4-8 token（折中 ITL 与吞吐），配合客户端 tokenizer 预测（客户端预生成下一个 token 的字体宽度，避免渲染抖动）。
四、客户端 latency 控制：流式渲染、人机协作与 UX 补偿
服务端把延迟做到极致，客户端不做补偿也是白搭。2026 年成熟 AI 应用客户端 latency 控制的三大支柱：流式渲染、人机协作 wait time、撤销/重生成 UX。
4.1 流式渲染的三个陷阱
第一个陷阱：渲染抖动。当 chunk 到达时，浏览器要重新计算文本框高度、重新排版下方元素，造成视觉抖动。解决：客户端预留 token 宽度的 buffer（用等宽字体或预测下一个 token 字符数）。
第二个陷阱：Markdown 半成品。LLM 输出 Markdown 时，常见顺序是 **bold → **bold text**。如果客户端在第一个 ** 到达时就渲染，会显示一个孤立的星号。解决：延迟渲染——客户端收到一个 token 时不立即更新 DOM，而是缓存到一个虚拟节点，等下一个 token 到达后合并更新。延迟阈值设为 50ms（人眼无感）。
第三个陷阱：复制/选区被打断。流式渲染会破坏用户对已完成内容的复制操作。解决：流式区域使用 contenteditable=false 包裹，或在用户开始选区时暂停流式更新。
4.2 人机协作 wait time
Google 的 RAIL 模型（Response, Animation, Idle, Load）和 Nielsen Norman Group 的最新研究共同指向一个事实：用户对延迟的容忍度取决于应用类型。AI 应用的特殊性在于——用户提交 query 后，会有一个"心理等待窗口"。这个窗口的长度与 query 类型相关：
| Query 类型 | 用户心理等待窗口 | 建议首字延迟上限 |
|---|
| 短问答（"什么是 RAG 是的"） | 1.5s | 1000ms |
| 长问答（"帮我写一份报告"） | 5-8s | 2000ms |
| 代码补全（"完成这个函数"） | 0.5s | 300ms |
| 翻译/总结（"翻译这段"） | 3s | 1500ms |
应用层必须做类型识别 + SLA 切换——检测到是代码补全场景就走"极低 TTFT 优先"路径，检测到长问答就走"流畅度优先"路径。
4.3 撤销/重生成与流式中断
流式输出不是单向流。用户随时可能：
- 点"停止"按钮——必须能在 50ms 内中断（abort controller + 服务端 cancellation token）。
- 点"重新生成"——必须释放当前 stream，重新发起请求。
- 点击已生成的内容开始编辑——必须把流式状态转为稳态。
2026 年的成熟实现：流式状态机。客户端维护一个状态对象 {status: 'streaming' | 'done' | 'error' | 'aborted', tokens: [], cursor: 0}，所有 UI 交互都基于这个状态机的转换。中断操作触发的"优雅停止"必须保证：(a) 已收到的 token 仍保留在 UI；(b) 服务端不会继续计费（cancellation token 传递到 LLM gateway）；(c) 用户点"继续"能无缝恢复。
五、端到端 latency 编排：gateway、协议与可观测性
把服务端和客户端单独优化到极致，串起来仍然可能失败。端到端 latency 编排关注的是请求从客户端出门到最后一字渲染之间的整条链路，包括 LLM gateway、模型路由、传输协议。
5.1 LLM gateway 与排队理论
LLM gateway（参见 2026-09-11 id=676 LLM 网关多模型路由与负载均衡工程）是所有请求的入口。它承担四个职责：
- 鉴权与限流：避免恶意请求打爆后端。
- 模型路由：根据 query 类型、用户等级、成本预算选择不同模型。
- 缓存命中：对完全相同的 query 直接返回缓存结果（精确缓存）或相似 query 返回相似结果（语义缓存）。
- 排队与优先级：VIP 用户优先，普通用户排队。
排队的代价是延迟方差放大。一个 P99 ITL=80ms 的服务，在 gateway 排队 5 秒后，P99 ITL 会变成 5080ms。gateway 必须有排队上限（如 10 秒超时后直接降级到更便宜的模型或返回错误）。
5.2 Streaming 协议选型
2026 年 AI 应用主流的 streaming 协议有三种：
| 协议 | 优势 | 劣势 | 适用场景 |
|---|
| SSE（Server-Sent Events） | HTTP/1.1 兼容、简单、自动重连 | 单向、HTTP/1.1 队头阻塞 | 短回答、Web 端 |
| WebSocket | 全双工、低延迟、可中断 | 需要长连接管理、复杂度高 | 长对话、移动端 |
| HTTP/2 + gRPC streaming | 多路复用、二进制高效 | 浏览器原生支持差、需要 proxy | 服务间调用 |
应用层的决策矩阵：
- Web 单次对话 → SSE
- Web 长对话（含中断/继续）→ WebSocket
- 移动端（弱网）→ WebSocket（含断线重连状态同步）
- 服务间 batch 调用 → gRPC streaming
5.3 可观测性：latency feedback 闭环
没有可观测性，latency 工程就是"盲人摸象"。2026 年的 AI 应用可观测性必须回答四个问题：
- 每个请求的 TTFT/ITL/TPS 实际是多少？——答：在 LLM gateway 层埋点，记录每个 chunk 的时间戳。
- TTFT 高的请求是哪一类？——答：打 query 类型、prompt 长度、模型版本、cache 命中标签。
- ITL 抖动集中在哪个阶段？——答：拆解为 prefill 时间、decode 时间、网络传输时间三段，分别记录。
- 感知延迟与物理延迟的偏差？——答：客户端 RUM（Real User Monitoring）记录用户感知事件，与服务端日志 join。
反馈闭环：把可观测性数据回流到模型路由层——某个模型 P99 退化超过阈值时自动降级到备选模型；某个 query 类型 ITL 抖动大时自动调整 chunk_size。
六、统一视角：信息熵与排队论
把上面四节串起来，能不能找到一个统一的第一性原理？我们尝试用信息熵和M/G/1 排队论两个工具做一次交叉分析。
6.1 信息熵视角下的 latency 上限
LLM 输出的本质是从 prompt 的熵分布中采样 token。每个 token 的信息熵 H(token∣context) 决定了模型"需要思考多久"才能产生下一个 token。一个粗略的界：
LITL≥α⋅H(token∣context)
其中 α 是硬件常数（如 1ms/bit）。这意味着：高熵的 token（如创造性输出）天然比低熵 token（如格式化输出）慢。应用层能做的是：把高熵生成任务拆成多个低熵生成任务（如"先列大纲、再扩写"），把"一次高熵"变成"多次低熵"。
6.2 M/G/1 排队近似
把 LLM gateway 视为一个 M/G/1 队列（泊松到达、一般服务时间、单服务台），服务时间 S 的分布由请求长度决定。P-K 公式给出平均等待时间：
Wq=2(1−ρ)λ⋅E[S2]
其中 ρ=λE[S]<1 是利用率。这条公式告诉我们：
- 利用率 ρ 越接近 1，等待时间越长（非线性增长，ρ=0.9 时等待时间是 ρ=0.5 时的 4.5 倍）。
- 服务时间方差越大，等待时间越长（E[S2] 项）。这正是为什么长输出会"卡"——长 prompt 让服务时间方差放大。
应用推论：LLM gateway 必须保持 ρ<0.7（不是常见的 0.9）。超出后 P99 延迟会以非线性方式恶化。
6.3 端到端 SLA 的可加性
把四段（TTFT、传输、decode、感知）串联，端到端 P99 SLA 是各段 P99 的上界和（保守估计）或卷积下界（精确估计，需要知道各段分布）。2026 年的工程实践：为各段分别设 P99 目标（如 TTFT P99 ≤ 1.5s、decode P99 ≤ 12s、ITL P99 ≤ 200ms），端到端 P99 由各段分布卷积计算。这是 OpenTelemetry 在 LLM 场景下的最新扩展。
七、对工程实践的推论（5-7 条可执行项）
把上面六节压缩成可立即执行的清单：
- TTFT 优化的第一刀：开启 prefix cache。命中率从 0% 提到 50% 后，长 prompt 的 TTFT 立刻下降 50%。预期：长 prompt TTFT 从 1.5s 降到 700ms。
- chunked prefill 的默认值：服务端设
chunk_size=2048，prefill 不再独占 GPU，TTFT P99 下降 30%。预期：长 prompt TTFT P99 从 2.5s 降到 1.7s。
- ITL 优化的关键开关：启用 speculative decoding，ITL 从 60ms 降到 35ms。代价：需要部署 draft 模型，GPU 资源增加 15-20%。预期：长对话 ITL P99 从 180ms 降到 100ms。
- 客户端的零成本优化：流式渲染时延迟 50ms 合并 DOM 更新，消除 Markdown 半成品视觉抖动。代价：0。预期：用户感知 ITL P99 下降 30%（视觉方差减小）。
- gateway 的硬约束：保持 ρ<0.7，超出后自动降级到次级模型或返回限流。预期：P99 延迟方差降低 50%。
- 可观测性的最小集：gateway 层记录每个 chunk 的时间戳、prompt 长度、cache 命中标签；客户端 RUM 记录首字渲染完成时间。预期：能回答"上周三下午 ITP 抖动的根因是什么"这类问题。
- 协议选型：Web 端 SSE 起步，长对话场景升级 WebSocket。预期：单次对话 TTFT 减少 50-100ms（避免 HTTP/1.1 队头阻塞）。
- 感知延迟的客户端信号：在客户端 RUM 中埋点用户首字渲染完成时间（first_meaningful_paint），与网关 P99 join 后识别"物理快但感知慢"的请求类型（如中文输出 Markdown 代码块时的视觉停顿）。预期：能定位 20-30% 的"用户投诉 latency 高但服务端指标正常"的工单根因，把这类投诉的响应时间从一周缩短到一天。
- 服务端 prefix cache key 的版本控制：当 system prompt 改动时，必须给 cache key 增加版本前缀（如
v3:#file:system_prompt_hash），否则旧 prompt 的缓存会被错误命中，导致输出内容错乱。预期：杜绝"模型突然答非所问但 latency 指标正常"的诡异工单，建立 prefix cache 变更的灰度发布流程。
每一条都附带一个"是否做了"的检测点。当 AI 应用的 latency P99 连续一周漂在阈值边缘时，按这九条顺扫一次——90% 的问题能找到根因。
八、讨论：交叉影响、局限与未来工作
本文的端到端 latency 视角与现有几篇同主题文章是互补关系，不是替代：
- 与 KV cache 调优的关系：KV cache 是 ITL 优化的物质基础。KV cache 命中率高时 prefill 时间短，TTFT 低。本文假设 KV cache 命中率已优化（参见 2026-09-12 id=485 KV cache 多层存储工程）。
- 与模型路由的关系：模型路由是 latency 与成本的二维联合决策。一个 query 走"大模型精确回答"还是"小模型快速近似"，本身就是 latency 工程的核心权衡（参见 2026-09-11 id=676 LLM 网关多模型路由）。
- 与 RAG 重排序的关系：RAG 的 retrieve-rerank-read 三阶段中，重排序阶段的 latency 经常被低估。一个 50ms 的 rerank 调用叠加到 ITL 上就是 80% 的延迟增长。本文把 rerank latency 作为 TTFT 的一部分计入。
本文的局限：
- 没有覆盖模型微调对 latency 的影响（同一个模型 4-bit 量化与 16-bit 精度 ITL 差 4 倍，但与"应用层优化"不在一个抽象层）。
- 没有覆盖多模态（图像、音频、视频）latency 的特殊性——这是 2026 年开始浮现但尚未稳定的话题。
- 没有覆盖端侧 AI 应用（on-device LLM、WebLLM）的 latency 工程——on-device 的 latency 主要受模型大小与硬件限制，与云端 API 的优化逻辑完全不同。
未来工作：
- 多模态 streaming latency 的统一形式化。
- AI 应用的"感知延迟"标准化测量方法（目前业界各家公司用不同的问卷和测试集）。
- Edge-cloud 协同推理的 latency 优化（部分推理在端侧、部分在云侧）。
九、给 AI 应用工程师的清单与猜想
如果你正在从零搭建一个 AI 应用的 latency 工程体系，按下面三步走：
9.1 三条未公开验证的猜想
- 猜想 A：chunked prefill 的最优 chunk_size 与 prompt 长度对数相关（chunk∝logLprompt），不是常数。这条猜想基于"prefill 阶段 GPU 利用率与 chunk_size 不是线性"的直觉，但截至 2026-09 未见公开 benchmark 验证。
- 猜想 B：客户端 Markdown 延迟渲染的最佳阈值不是 50ms，而是 30ms（基于人类感知研究中的"视觉连续性"临界点）。建议在 30-80ms 区间做 AB 测试。
- 猜想 C：可观测性数据回流到模型路由层的反馈周期应小于 5 分钟，超过 5 分钟就丧失"实时降级"价值。这条与 AIOps 的"反馈延迟"研究吻合，但 LLM 场景的实证数据尚未公开。
9.2 Latency 观测建议清单
无论你的 AI 应用处于哪个阶段，建议立刻埋点以下五项：
- 服务端：每个 chunk 的 server_send_time（精确到 ms）、prompt 长度、cache 命中标签、模型版本号。
- Gateway：每个请求的 queue_wait_time、route_decision、cache_lookup_time。
- 客户端：每个 chunk 的 client_receive_time、DOM_update_time、user_perceived_first_paint_time。
- 跨层 join key：request_id 全链路传递，保证服务端日志与客户端 RUM 能 join。
- SLA 看板：TTFT P50/P90/P99、ITL P50/P90/P99、TPS 中位数、感知延迟分布——按 query 类型、prompt 长度、模型版本维度切片。
9.3 一句话总览
AI 应用的 latency 工程已经从"单点调优"进入"端到端架构"的阶段。2026 年的胜出者，不是 GPU 利用率最高的团队，而是把服务端 prefill 调度、客户端流式渲染、gateway 排队理论、可观测性反馈闭环四个层面作为一个整体设计的团队。当你的 latency 看板能回答"上周三下午那次抖动是 cache 命中率下降还是 chunk_size 调小了"这类问题时，你才真正进入了 latency 工程的成熟阶段。
参考文献
- OpenAI, "Streaming API Best Practices", OpenAI Cookbook, 2024.
- Anthropic, "Claude 3 Streaming Response Latency Optimization", Anthropic Engineering Blog, 2024.
- Kwon W. et al., "vLLM: Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023.
- Miao X. et al., "Chunked Prefill: Optimizing Time to First Token in LLM Serving", vLLM Documentation, 2024.
- Leviathan Y. et al., "Fast Inference from Transformers via Speculative Decoding", ICML 2023.
- Chen C. et al., "Accelerating Large Language Model Decoding with Speculative Sampling", NeurIPS 2023.
- Pope R. et al., "Efficiently Scaling Transformer Inference", MLSys 2023.
- Yu G. et al., "SGLang: A Structured Generation Language for LLMs", arXiv preprint, 2024.
- Google, "RAIL: A User-Centric Performance Model", Google Developers Blog, 2024.
- Nielsen Norman Group, "Response Time Limits: How Short is Too Short?", NN/g Research Report, 2024.
- OpenTelemetry, "Semantic Conventions for Generative AI", OTel Specification, 2024.
- Apache Kafka, "Backpressure and Flow Control in Streaming Systems", Kafka Documentation, 2024.
- Microsoft, "Azure OpenAI Service: Latency Optimization Guide", Microsoft Learn, 2024.
- Cloudflare, "Edge AI Inference: Latency vs Throughput Tradeoffs", Cloudflare Blog, 2024.
