TTFT 优化：把大模型首 token 时延降下来的工程路径
TTFT 由排队、prefill 重算与 KV 读回三部分构成。长上下文场景 prefill 重算是大头，KV Cache 外置读回可将其大幅消除：铭信实测 TTFT p50 降 26–32%。
TTFT 高的根源
用户感知的「卡顿」主要是 TTFT。对长上下文（几万 token 的会话历史、代码库上下文），prefill 需要对全部历史做一遍前向计算，GPU 时间以十秒计；并发一上来还要排队，TTFT p99 会雪崩。
R2 实测给出量化：480B 模型并发 16 档，无外存重算基线 TTFT p50 高达 149.5s——这就是不管 KV 的代价。
分层读回的实测效果
同一负载下，FX100 外置 KV 读回把 TTFT p50 压到 11.85s（对重算 12.6×）；对比本地 NVMe 盘（17.31s）也低 32%。三档并发（8/16/32）全面成立，吞吐同步提升 29–40%（R2/R3）。
读回带宽是关键工程量：LMCache 并行读补丁把单卡冷读带宽从 0.98 GB/s 提到 5.23 GB/s（5.3×），TTFT 相应改善 4.1×（R1）。该补丁以 git patch 全文提供（R8）。
常见问题
TTFT 优化对短对话有用吗？
作用有限——短上下文 prefill 本来就快。TTFT 优化的主战场是长上下文与会话恢复，这类负载在 Agent 与代码助手场景占比持续上升。
p50 降了，p99 呢？
R3 做了九档全指标（TTFT p50/p90/p99、TPOT、吞吐、盘带宽）测量，报告可在证据库下载查证各分位数表现。
这些数字在什么平台测的？
8×AMD MI308X、ROCm 7.2、vLLM 0.20.1、Qwen3-Coder-480B-FP8，标准生产部署形态（TP=8），条件全文公开（R2）。
数据出处（可查证）
相关阅读
本站内容为商务合作信息展示，不构成投资要约或任何收益承诺。实测数据均出自签字级/正式版测试报告（见证据库）；厂商口径、公开口径、估算口径均如实标注。