$ cat ~/map/pi-ttft.md

pi-ttft

页脚上的首 token 时间（TTFT）HUD，慢请求才展开拆分，仅当网络或服务器明显占主导才指认瓶颈。

extensions✓ 9月19日

事实速查

安装

运行 pi install git:github.com/quanxinwang18-a11y/pi-ttft@v1.1.0，或用 pi -e git:github.com/quanxinwang18-a11y/pi-ttft 临时试用单个会话。要求 pi 0.85.1 或更高版本。

## 速览

一个面向首 token 时间的 pi 页脚 HUD：本轮运行时只保持紧凑的 TTFT 读数，首 token 偏慢时才拆分为网络响应时间与服务器端 prefill，且仅当一方明显占主导时才指认瓶颈。

$四个字段各有定义：TTFT 是请求到首个流事件；resp 是请求到响应头（含网络与服务器排队）；prefill 是响应头到首个分块——这一段飙升通常意味着提示词缓存未命中；tok/s 是本轮的解码速度。
$宽度随状态变化：运行中报告当前状态，空闲时报告上一轮，只有在变慢时才展开——正常收尾只显示 TTFT 与 tok/s，偏慢时追加 resp 与 prefill 拆分及瓶颈标记。
$下结论要有主导性：仅当一方至少达到 dominantRatio（默认 2 倍）时才打印 network 或 server 标记；否则 HUD 不指认任何瓶颈。
$累计值不占状态栏：LLM 与工具的总计、均值和极值都在 /ttft 背后，该命令同时打印生效配置及各项来源；/ttft reload 重读设置，/ttft reset 清零计数。
$靠设置调参：slowMs（默认 3000）、slowTps（默认 20）与 dominantRatio（默认 2）放在全局或项目 pi 设置的 ttft 键下，项目文件按键覆盖全局；非法取值回退到默认值。

Q 为什么要把变慢的首 token 拆成 resp 与 prefill？

两半指向不同的瓶颈：resp 偏大说明延迟出在网络或 provider 排队，prefill 偏大是服务器端的问题，通常意味着提示词缓存未命中。

Q 调阈值要改扩展本身吗？

不用。阈值放在 pi 设置的 ttft 键下——slowMs、slowTps、dominantRatio——/ttft reload 无需重启即可生效；/ttft 始终打印生效值及其来源。