抡锤者

blackjack

你是根据什么指标得出以上结论的，Tensor core数量，缓存带宽？大家都是Blackwell，都支持nvf4

blackjack

@CS6 说:

@williamlouis 好奇大大為何這樣說？我看他也沒什麼數據不是嗎？

论坛版主质量参差不齐，这不是他第一次离谱了

blackjack

24g纠结啥啊，就老老实实llama.cpp单槽用

blackjack

@johnnybegood 说:

@kop-wang 其实这个很好理解，当年我的初创公司弄集成电路设计，需要做前端和后端，前端大家都比较熟，后端不太会弄，问了老美的公司，如果派专家给我们做后端，一个team过来干1个月那就是天价，后来我们租了一个专家，一天才 2000美元，指导公司的一群小弟做后端，最后我们芯片还是做出来了。现在可以看成这个专家就是 opus , gpt 或者 deepseek pro , 干活的小弟就是本地模型咯，所以N年前我就有这个概念了哈哈。

大哥，你这是设计芯片的前端和后端，千万别让人误会成互联网的前端后端。完全天上地下的差别，拜一个先。现在不做了吗？

blackjack

blackjack 说:

配置web search工具，申请注册填入taviliy key

nba-查分.png

blackjack

配置web search工具，申请注册填入taviliy key

blackjack

@Michael-Zhou 说:

@blackjack 图片更新了

非常感谢，人在日本啊

blackjack

@williamlouis 说:

@blackjack 这么喜欢帮AI纠错。给你个网站你可以找它问。畅聊。https://chat.deepseek.com/
而且你可以用上科学训练法。好好的发泄下。

你得对你发出来的东西负责啊，要不最后都被垃圾淹没了，也就没人来了

blackjack

@williamlouis 说:

@c0aster AI制作的方案是完美隔离。它后续说的问题很好解决。部署成功后做个人工培训的周期。2周左右。提前训练下就可以。这个过程是联网的。但是不连你公司的数据。拿一批虚拟的案例训练它即可。这样你们常用的数据就加载全了。之后根据 AI的方案实施就可以了。

ai怎么就盯着2024年qwen2.5 72b不放呢？仅用过时的训练数据回答呢？

blackjack

@stakira 说:

但 prefill 怎么也快不起来。无论 rocm 还是 vulkan，prefill 速度相当不稳定，哪怕是长段 prompt 最多也就 500+ t/s，常常只能跑到 300+ t/s。

这个信息很关键啊，ai了一下：

作为一张拥有 960 GB/s 显存带宽、24GB VRAM 的旗舰级显卡，7900 XTX 跑出 300~500 t/s 的 Prefill（首字延迟/提示词处理）速度绝对是不正常的。正常情况下，在全显存（无内存交叉）时，7900 XTX 处理长文本的 Prefill 应该能飙到 1500~2000+ t/s。相比之下，3060 哪怕带宽只有 360 GB/s，但在 CUDA 生态下其算力核心利用率非常稳定。7900 XTX Prefill 速度慢且极度不稳定的根源，不在于硬件本身，而在于 AMD 软件栈在特定推理框架下的 Kernel（算力核心）调度、内存分配以及算子缺失。

致命伤：FlashAttention 算子没有真正跑起来Prefill 阶段是算力受限（Compute-bound）的，需要极其密集的矩阵乘法。

Nvidia 显卡默认使用极致优化的 FlashAttention（甚至 FlashAttention-3）。
痛点：在 ROCm 或 Vulkan 下，如果框架没有正确调用专门针对 RDNA3（GFX1100）优化的 FlashAttention 算子，系统会自动降级去跑极慢的传统 SDPA（PyTorch 默认注意力）或者非对齐算子。这会导致显卡空有几百 W 功耗，算力利用率却极低。

解决办法（vLLM）：在启动 vLLM 时，检查日志中关于 Attention Backend 的输出。确保其使用的是针对 AMD 优化的后端。可以通过环境变量强制指定：bashexport VLLM_ATTENTION_BACKEND=TRITON_ATTN

或者在最新版本的 vLLM 尝试

export VLLM_USE_FLASH_ATTN=1
请谨慎使用此类代码。
(注：如果使用 Llama.cpp，请确保编译时开启了 GGML_HIPBLAS=ON 或者是最新的开源统一注意力 AITER)。

blackjack

@Xiaote 说:

Qwen3.6-72B（预算 15-18 万）

大哥，qwen3.6只有27b没有72b吧？
小特眼花了吧？一个A100就够10-20并发了吧

blackjack

每个人配一个5090游戏本吧，你给他们配好Hermes

blackjack

@terry 说:

@blackjack 相信你的测试个结果，但我实际跑hermes过程中，Q4_0确实拉胯，跑OpenClaw更是如此，就是经常会陷入死循环。

qwen的工具调用极弱，让他专门做过patch工具测试，分不清工具名称patch和参数名称path。这个就是模型能力问题，再怎么提示也白扯，只能在hermes里把参数名称path改成路径等其他严重不让他花眼的文字，还有各种对他人性化的反馈。死循环基本就是掉入到各种工具调用的汪洋大海中了，你可以开个ai让他研究一下日志

blackjack

配上x99套装，直接上RTX pro 6000，一切都在GPU里内循环

blackjack

@老用户说:

kv cache type 使用q4_0精度，有没有在长上下文的情况下测试过稳定性，智商、工具调用如何。我在使用中发现，上下文到7-8W的时候就开始飘了。所以有时候我认为256K上下文有没有必要，不如把kv cache type精度调高点

我今天正好做了个测试,

Hermes 长会话 KV `q8_0` vs `q4_0` A/B（2026-05-26）

结论

这次真实 Hermes 多轮长会话基准里，KV q8_0 和 KV q4_0 没有表现出可见的语义或结构优势差异。
两边都是：
- 12 / 12 turn 全过
- 最终精确召回通过
- 最终文件状态召回通过
- chain_diff 只有 first_request + exact_message_append
- 没有 message_prefix_drift
- 没有 forcing full prompt re-processing
- 没有 server 侧 class=prefix-drift

更直接地说：
在这条真实 Hermes replay/tool/file 多轮链路上，至少这一次跑下来，q8_0 没有比 q4_0 明显更稳，q4_0 也没有出现明显漂移退化。

基准配置

日期：2026-05-26
benchmark 脚本：~/custom-agent-stack/local-agent-setup/scripts/benchmark_hermes_long_session_kv.py
结果目录：~/.cache/local-agent-setup/benchmarks/hermes-long-kv-20260526-ab1
Hermes 运行时：仓库版 ~/custom-agent-stack/hermes
llama-server：~/src/ik_llama.cpp/build-mmq/bin/llama-server
模型：~/models/Qwen3.6-27B-MTP-IQ4_KS.gguf
ctx：128000
block chars：30000
toolset：file
compression：off
ignore_rules：on

任务形态

不是单问单答，也不是直接打 OpenAI-compatible /chat/completions 的伪 benchmark。
这次走的是真实 Hermes 多轮链路：

HermesCLI.chat() 连续多轮追加 history
中间混合长 reference turn
中间混合 write_file / patch / read_file
结尾做精确 JSON 召回
同时抓：
- Hermes request diagnostics
- llama-server console log
- 最终语义结果和文件状态

结果表

KV	Passed Turns	Final Recall	Final File Recall	Max Approx Tokens	`exact_message_append`	`message_prefix_drift`	`forcing_full`	`prefix_drift`	acceptance avg
`q8_0`	`12/12`	yes	yes	`41221`	`15`	`0`	`0`	`0`	`0.73017`
`q4_0`	`12/12`	yes	yes	`41221`	`15`	`0`	`0`	`0`	`0.75664`

解释

1. 结构稳定性

这部分两者完全一样：

first_request = 1
exact_message_append = 15
message_prefix_drift = 0
session_changed = 0
forcing full prompt re-processing = 0

这说明：

Hermes replay 没有在这组任务里引入可见 prefix 漂移
llama-server 的 checkpoint / prompt cache 路径工作正常
q4_0 没有比 q8_0 更容易把 replay 链打崩

2. 语义结果

这部分两者也一样：

长 reference 块记忆没丢
文件工具链没错
结尾 JSON 精确召回通过
最终文件尾部状态召回通过

所以就“长会话漂移”这个问题看，这次没有证据表明 q8_0 更稳。

3. acceptance

这次单次 run 里：

q8_0: 0.73017
q4_0: 0.75664

q4_0 略高，但差距不大，而且这只是一次跑出来的平均值。
在没有重复样本之前，不能据此下结论说 q4_0 优于 q8_0，更不能据此反推“q8_0 在真实 Hermes 长会话里一定更聪明”。

目前更可信的判断

至少在你这条链路里：

KV q8_0 对 patch/path 这类错误并没有表现出明确额外优势
真正影响 tool 成功率的主因，仍然更像是：
- 模型文件本身
- chat template / replay 一致性
- Hermes 侧 prefix 稳定化 hack
- llama-server 侧 checkpoint / single-slot 行为

而不是简单的：

“把 KV 从 q4_0 提到 q8_0，模型就突然会分辨 patch/path”

blackjack

@joker_chang 说:

7900xtx+Ubuntu性能这么好？
我Windows10+RTX3090Ti，

--n-gpu-layers 999 ^
--ctx-size 131072 ^
--batch-size 2048 ^
--ubatch-size 1024 ^
--flash-attn on ^
--cache-type-k q4_0 ^
--cache-type-v q4_0 ^
--cache-type-k-draft q4_0 ^
--cache-type-v-draft q4_0 ^

不开MTP跑Qwen3.6 27B只能跑到30tokens/s;
开MTP变得更慢

特别是在长上下文时，例如：我让模型分析一个大约128K的md文件，然后就爆了

你可以查一下编译llama-server的时候，用的mmq还是cuBLAS，或者有没有fallback到cuBLAS。亲测，两者性能差距巨大。

blackjack

@joker_chang 说:

@rock-shi 那就对了，24G跑128K上下文+MTP资源不够

我27 q4量化，kv均q8_0量化，上下文128k，MTP, 5090laptop 24GRAM，开thinking，50+tps，快的起飞啊

blackjack

我试了下，效果不如我hack的Hermes好啊。

以下是我详细的测试结果。
在当前这套本地栈里，froggeric/Qwen-Fixed-Chat-Templates 没有带来更好的 KV 复用，反而比我现在用的 Qwen3-stable-reasoning.jinja 更差。

关键结论：

两组都没有出现 forcing full prompt re-processing due to lack of cache data
两组都能稳定走完 8 轮真实工具调用
但 froggeric 模板每轮需要重算的 token 明显更多
受控重跑里，现有模板的 cache hit 更高，uncached token 更少

所以社区帖子里“fixed chat template 大幅提高 Hermes + Qwen3.6 cache 命中率”这件事，至少不能直接外推到我当前这套：

custom-agent-stack/hermes 本地定制
ik_llama.cpp/build-mmq/bin/llama-server
单槽 MMQ + MTP + 128k ctx
本地 replay / save-restore / diagnostics 改造后的工作流

更像是：

对方原始模板或运行栈本来就更容易漂
而我当前本地模板已经处在一个相对稳定的状态

测试目的

验证这篇帖子里的说法，是否适用于我当前本地工作流：

https://lcz.me/topic/298/...
主题：Qwen-Fixed-Chat-Templates 是否能显著降低 Hermes 长会话下的 cache miss / forcing full

测试原则：

同一个 llama-server 二进制
同一个模型
同一套 MMQ / MTP / 128k 参数
同一个 Hermes 启动链
只换 chat template

模板 A / B

A 组：当前本地模板

文件：~/custom-agent-stack/local-agent-setup/templates/Qwen3-stable-reasoning.jinja

B 组：froggeric 模板

来源：https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates
本地文件：~/.cache/local-agent-setup/templates/froggeric/chat_template.jinja
sha256：4649b3fa3db3fda4d51173ed4ff0175fde7ece8bbceb9d595d04d862020c9746

运行环境

模型：~/models/Qwen3.6-27B-MTP-IQ4_KS.gguf
server：~/src/ik_llama.cpp/build-mmq/bin/llama-server
launcher：~/custom-agent-stack/local-agent-setup/start-llama-server-ik-mmq.sh
Hermes：~/custom-agent-stack/local-agent-setup/start-hermes-mmq.sh

共用参数：

CTX_SIZE=128000
ENABLE_VISION=off
--parallel 1
-ngl 999
--cache-type-k q8_0
--cache-type-v q8_0
--flash-attn on
--multi-token-prediction
--draft-max 2
--draft-p-min 0.0
--merge-qkv
--merge-up-gate-experts
--cache-ram 32768
--ctx-checkpoints 32
--jinja
--reasoning off

对照方法

这次实际做了两轮测试。

第一轮：普通多轮工具请求

~/.cache/local-agent-setup/ab-qwen-fixed-template-iq4ks-20260526-060644

这一轮能看出大方向，但有一个污染点：

A 组首轮没有调用工具，模型直接答出了 alpha beta gamma
B 组首轮走了真实 terminal

所以这轮只能算：

初筛结论
不能作为最终严肃证据

第二轮：受控随机文件重跑

~/.cache/local-agent-setup/ab-qwen-fixed-template-iq4ks-controlled-20260526-061256

这轮才是有效结论。

控制方式：

预先生成 8 个随机文件
每轮都要求模型必须用 terminal 执行 cat <file>
文件内容是模型不可能预知的随机 UUID
两组都达成 8/8 真实工具调用

这保证了：

不是“模型猜中了输出”
不是“某组首轮偷答绕过工具”
两边历史链条的结构尽量一致

受控重跑结果

总结指标

A 组：当前本地模板

tool_preview_count = 8
forced_full_reprocess_count = 0
avg_cache_hit_pct = 96.81
avg_uncached_tokens = 87.38
post_t1_avg_cache_hit_pct = 97.29
post_t1_avg_uncached_tokens = 80.43

B 组：froggeric 模板

tool_preview_count = 8
forced_full_reprocess_count = 0
avg_cache_hit_pct = 94.74
avg_uncached_tokens = 168.38
post_t1_avg_cache_hit_pct = 95.00
post_t1_avg_uncached_tokens = 168.71

turn-by-turn

A 组：当前本地模板

turn	prompt_tokens	cached_tokens	uncached_tokens	cache_hit_pct
1	2089	1953	136	93.49
2	2338	2270	68	97.09
3	2590	2451	139	94.63
4	2844	2774	70	97.54
5	3098	3027	71	97.71
6	3353	3282	71	97.88
7	3609	3537	72	98.00
8	3866	3794	72	98.14

B 组：froggeric 模板

turn	prompt_tokens	cached_tokens	uncached_tokens	cache_hit_pct
1	2348	2182	166	92.93
2	2623	2457	166	93.67
3	2901	2732	169	94.17
4	3181	3013	168	94.72
5	3461	3292	169	95.12
6	3742	3573	169	95.48
7	4024	3854	170	95.78
8	4307	4137	170	96.05

结果怎么解读

1. 这不是 forcing full 级问题

两边都没有出现：

forcing full prompt re-processing due to lack of cache data

说明当前本地链路已经比较稳定。

也就是说，这次 A/B 主要比较的是：

谁的共享前缀更长
谁每轮需要补算的 token 更少

而不是比较“谁会炸、谁不会炸”。

2. froggeric 模板在我这里更重

受控重跑里，froggeric 模板几乎每轮都比本地模板多重算接近一倍的 token：

本地模板后 7 轮平均 uncached：80.43
froggeric 后 7 轮平均 uncached：168.71

这不是小抖动，而是明显更差。

3. 社区帖子和我这里不矛盾，但条件不同

更合理的解释不是“帖子错了”，而是：

对方的原始模板更容易在 tool_call / tool_response / think 边界上漂
我本地模板和 Hermes replay 链路已经被专门收拾过
froggeric 模板在我这套本地定制栈里没有形成更短、更稳的共享前缀，反而引入了更多稳定额外 token

所以它在我这里没有收益，甚至有负收益。

blackjack

@terry 说:

一分钱一分货，Pro6000这种卡的意义就是跑DeepSeek本地，原版2张就够了，阉割版两张不够，就必须要4张。跑其他的又用不到这么大显存。卖的永远比买的精。4万五又不知道是哪个野鸡厂商卖的，京东就没这么便宜的。

就跑qwen 27b，单机多并发也挺好啊

blackjack

多上几张机箱和拓展坞还有连接的图啊

抡锤者

blackjack

帖子

或者在最新版本的 vLLM 尝试

Hermes 长会话 KV q8_0 vs q4_0 A/B（2026-05-26）

结论

基准配置

任务形态

结果表

解释

1. 结构稳定性

2. 语义结果

3. acceptance

目前更可信的判断

测试目的

模板 A / B

A 组：当前本地模板

B 组：froggeric 模板

运行环境

对照方法

第一轮：普通多轮工具请求

第二轮：受控随机文件重跑

受控重跑结果

总结指标

A 组：当前本地模板

B 组：froggeric 模板

turn-by-turn

A 组：当前本地模板

B 组：froggeric 模板

结果怎么解读

1. 这不是 forcing full 级问题

2. froggeric 模板在我这里更重

3. 社区帖子和我这里不矛盾，但条件不同

Hermes 长会话 KV `q8_0` vs `q4_0` A/B（2026-05-26）