14 篇博文 含有标签「inference」

大多数在 LLM 上构建应用的工程师都将延迟视为一个单一的刻度盘。他们调整一些参数——批处理大小（batch size）、量化级别（quantization level）或实例类型（instance type）——观察“它是否变快了”，然后就收工了。这在上线生产环境之前一直有效，直到你发现 p50 TTFT 看起来不错，而 p99 却超过了 3 秒，或者发现让吞吐量翻倍的优化不知为何却让单个用户感觉系统变慢了。

TTFT 和吞吐量（throughput）并不是同一个滑块的两端。它们是由根本不同的物理特性引起的，受不同瓶颈的影响，并由不同的技术修复。将它们视为可互换的是我在生产环境中看到的大多数 LLM 推理事故的根本原因。

大多数 LLM 延迟建议往往会陷入以下两种失败模式之一：要么关注错误的指标，要么推荐的优化过于依赖特定硬件，除非你运行自己的推理集群，否则难以应用。如果你是基于托管 API 或受管推理提供商进行构建，那么这类建议中的大部分都是噪音。

本文专注于真正能产生影响的因素 —— 无论你是否控制整个技术栈，这些技术都适用，且基于生产数据而非基准测试的实验室条件。