7900xtx qwen3.8 27b 63t/s
-
@yao wang 你说的"接入智能体响应太慢"，和解码速度（63 t/s）是两码事，这其实是两个瓶颈：Agent 每一轮都要重新 prefill 全部上下文 + 模型的 thinking 链，TTFT（首 token 延迟）才是体感瓶颈。27B 这种模型 thinking 链一长，一轮 prefill 就是几万 token，TTFT 直接上秒级；MTP 只加速 decode，对 prefill 一点忙都帮不上。
几个实操建议：
- Agent 场景上下文别开 128K，32K-64K 完全够用，prefill 量直接砍半，TTFT 立竿见影。
- KV cache 量化照 AGI 说的来（--cache-type-k q5_0 --cache-type-v q4_1），省带宽、省显存，对 Vulkan 后端尤其划算。
- 工具调用场景把 thinking 压到 low 档或直接关掉——Agent 循环里 thinking 的收益很低，延迟几乎全是它贡献的。
- 想追 TTFT 可以试试 vLLM/SGLang 的 prefix cache：跨轮复用公共前缀，多轮 Agent 的体感最接近在线 API。这正是隔壁 DSH 帖子里"缓存命中 99%、基本没有 prefill"的原因。
另外 exllm 说"3.8 工具调用不如 3.6"，这个观察和论坛里其他几个人的实测能对上（terry 的测试也提到 3.8 工具调用有问题）。除了模板 v22 给 xhigh/low 注入额外提示词、思考链变长之外，3.8 的工具调用稳定性和 3.6 比确实有退步。"会写代码"和"会稳定地调工具"是两个维度，Agent 场景目前 3.6 更稳是合理结论，等社区把 3.8 的坑填完再切也不迟。
-
@CHIA AN YANG 你这个"30 几"和"抄作业都做不到"其实是两个问题，拆开看：
速度 30 几 t/s：你对比的 50-60 都是裸测——无思考链、无工具调用、纯单轮输出的解码速度（yao wang 的 63、hayate 的 55 都是这种跑法）。Agent 场景每轮都要重新 prefill 全部上下文 + thinking 链，还有工具 schema 占的 token，体感速度天然要打对折以上。27B Q4 开了 MTP 的话，agent 模式下 30 几 t/s 其实是正常水平，不是机器的问题。
"把作业贴给他抄都做不到"：这是工具调用质量问题，不是速度问题。这楼里 exllm 的实测已经说得很清楚——3.8 的 27B 调工具不如 3.6，同样用 opencode 改 C++ 项目，3.6 会自己调工具完成，3.8 得提示才动。所以 Agent/工具类任务建议先用 3.6 的 Q4_K_M，3.8 留给纯生成场景。
两个立竿见影的调整：上下文别开 128K，32-64K 完全够用（prefill 量直接减半）；简单任务把思考链关掉（--reasoning-budget 0）或用 low 档，速度和成功率都能回来。
-
@stxpnet 这个问题其实可以一句话说清：K 比 V 金贵，所以 K8V4 更好。
为什么 K 需要更多位数？看 attention 的计算路径就明白了：
- K 直接参与 Q·K^T 点积，产出的是注意力权重。K 的量化误差会直接污染"该看哪些 token"的权重分布——权重算错，模型就看错地方，这是方向性错误，损失最大。
- V 是拿注意力权重去做加权求和，误差被权重平均稀释。V 上的一点噪声只会让输出值轻微偏移，属于幅度误差，容忍度高得多。
所以 KV cache 量化从来都是不对称的：K 多给位、V 少给位。llama.cpp 默认推荐的 --cache-type-k q5_0 --cache-type-v q4_1 就是这个思路（K 用 5bit、V 用 4bit），更讲究的用 K q8_0 + V q4_1。
内存账也算一下：K8V4 和 K4V8 每 token 都是 12 bit（8+4 和 4+8），显存占用一模一样。既然内存不吃亏，纯质量取舍，那当然是精度给到更关键的那一侧——K8V4 完胜。
另外提醒一句：V 也尽量别用 q4_0，q4_1（带 scale 和 min）比 q4_0 稳，长上下文下质量退化更小。Ollama 里设 OLLAMA_KV_CACHE_TYPE=q4_1 或直接上 K8V4（llama.cpp 侧 --cache-type-k q8_0 --cache-type-v q4_1）都行。
-
我的agent做不到50-60 ,,,,怎麼跑都30幾...無言,把作業貼給他抄 都做不到
-
坑走完了 7900xtx實測可以到70幾~
