← 返回概念解读

Concept Fable精修版

延迟

Latency · Inference

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

急诊门口量的不是医生多聪明,而是病人等了多久

山城医馆有几位名医,诊断很准。掌柜常对外说医馆医术高明,直到急诊门口开始排起长队,病人才把真正的不满说出来。

他们并不关心药方最终有多漂亮,至少在疼痛最急的时候不关心。他们先问第一句话什么时候有人回应,什么时候能拿到药,什么时候能回家。

掌柜先在墙上贴满名医资历,又增加问诊表格。医馆看起来更专业,病人等待却更久,焦躁也更明显。有人等到一半,转身去了隔壁小铺。

有人只统计一天看了多少人,声称效率很高。可其中一些病人等了两个时辰才见到医生,另一些只等了一盏茶。平均数掩盖了真正痛苦。

一位管事把流程拆开:进门到回应、回应到诊断、诊断到拿药、拿药到复诊。每段都记录常见等待、慢尾等待和最坏情况。

他们发现,慢不只在医生问诊。挂号、找病历、等药炉、复核禁忌,每一步都可能让整体体验变差。医术再准,若第一声回应来得太晚,信任已经漏掉一半。

医馆开始按场景设目标:急症先回应,慢病可等完整检查;简单处方要快,复杂会诊要解释等待。不同病人不再被塞进同一条队。

后来医馆评估新流程时,不再只问诊断准不准,还问从病人敲门到第一声回应、到完整结果,各花了多久。速度的结构,就是服务质量的一部分。管事还把慢尾病人单独拿出来看。少数人等得特别久,往往正是最危险或最着急的病人。若只看平均,医馆会把这些人藏在漂亮数字里。真正影响口碑的,常常是最坏那几段等待。医馆后来把第一声回应当成一味药。它不能治病,却能让病人知道自己已经进入照护之中;这一步慢了,后面再准也难挽回。后来复盘时,众人把这条经验写进日常规矩:先看现场哪里真正改变了结果,再决定该保留什么、修补什么、限制什么。病人感受最清楚。

揭示

这个故事讲的是:延迟

延迟是模型或 Agent 系统从收到请求到返回响应、或生成 token 所花的时间。它可能包括排队、路由、检索、工具调用、预填充、首 token、解码和后处理。

企业系统不应只看平均延迟,还要看 p95、p99 这类分位数。因为少数很慢的请求,往往才是用户体验和 SLA 违约的真正问题。

隐喻映射

  • 医馆:LLM / Agent service
  • 病人等待:end-to-end request latency
  • 第一句话回应:TTFT or first meaningful response
  • 挂号、病历、药炉:queueing, retrieval, tool calls, prefill, decode
  • 平均数掩盖痛苦:mean latency hides p95/p99 tail latency
  • 急症和慢病:不同 workflow 的 latency SLO
  • 最后洞察:Latency 衡量用户等多久,必须按链路和分位数管理,而不是只看模型本身

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

throughputtime to first tokentokens per secondserving

相关辨析

这个概念容易和相邻概念混用,建议继续看对比页。