19.8 tok/s 的 prefill 对 Agent 场景确实不可用：每次请求都要把整段上下文重算一遍，10K token 意味着每次回复前先干等 8-9 分钟，等于没法用。
先说明为什么慢：prefill 是算力瓶颈（要对整段 prompt 做 attention），decode 才是显存带宽瓶颈。Strix Halo 的 iGPU 强在带宽（~256GB/s），弱在 FP16 算力，所以它"日常对话流畅、长上下文预填充拉胯"是硬件特性决定的，不是配置错了。
优化路径按性价比排序：
KV/前缀缓存（最有效）：Agent 场景里 system prompt + 工具定义占了上下文大头且基本不变。开启前缀缓存（llama.cpp 的 --cache-reuse，或 Ollama 自带的上下文缓存）后，命中部分直接跳过重算——10K token 里如果 8K 是稳定前缀，prefill 时间直接砍掉 80%。这是最值得先做的。
精简上下文：对话历史定期压缩（把旧轮次总结成摘要再喂回去），从源头减少每次 prefill 的 token 量。Agent 跑得越久这条越重要。
chunked prefill：SGLang/vLLM 的分块预填充能改善首 token 延迟（TTFT），但那是为高并发服务设计的，单用户单卡收益有限；而且 A 卡上 SGLang 部署坑多（terry 楼上说了），优先级放后面。
确认开了 Flash Attention：llama.cpp 加 -fa，ROCm 下用 Composable Kernel 的 FA 对 prefill 提升很明显，先确认没漏掉这个基础项。
结论：先做缓存，再谈换框架。对 Strix Halo 这种带宽强算力弱的平台，缓存命中率就是决定 Agent 可用性的第一要素，比换推理引擎划算得多。
