@stxpnet TTFT 高不是模型的问题，等"优化模型"大概率等不来——这是 7900XTX 的带宽账，算一下就清楚了：
27B Q4_K_M 权重约 16GB，prefill 每个 token 都要把权重完整过一遍。7900XTX 有效带宽约 900GB/s，prefill 吞吐大约 50-60 t/s（开了 flash-attn 之后）。所以 TTFT 约等于 prompt token 数除以这个吞吐：1K prompt 约 20 秒，10K 上下文就是 3 分钟起步。你之前 128K 上下文开满的话，一轮 prefill 几分钟是物理上限，不是故障。
真正能压 TTFT 的杠杆，按性价比排序：
缩短每次请求的 prompt——这是唯一能数量级改善的。agent/长对话场景上下文越滚越长，每轮都在为历史 token 付 prefill 的钱；32-64K 够用就别开 128K。
量化越低 prefill 越快——Q3_K_M（约 12.5GB）比 Q4 快约 30%，FP8 权重质量好但比 Q4 慢。TTFT 敏感就上 Q3，质量敏感再权衡。
MTP/投机解码对 TTFT 没有帮助甚至有害——草稿是在首 token 之后才跑的，prefill 阶段只有开销。TTFT 敏感场景关掉 --spec-type。
确认 --flash-attn on（你已经在用）、--ubatch-size 2048、全部层进 GPU（--n-gpu-layers -1），这几个不开 prefill 会再慢一截。
另外 llama.cpp 的 KV 复用只对"前缀完全一致"的请求生效，agent 框架只要把历史重排/压缩一次，下一轮就是全量 prefill。TTFT 高的体感，一大半来自这里而不是模型本身。
