@neo said:

不过我不用主模型来运行记忆整理，而是用专门的EDGE模型来处理，因为这个必须用短小精悍的模型，建议用9B或14B。另外重排和向量模型也可以自定义模型而不是hindsight内置的

用一個小型的MoE模型 Q4_K_M來整理記憶不知道合適不？
只要語意理解能力夠高 應該不錯
突然想到TernaryBonsai-8B Q2

prism-ml/Ternary-Bonsai-8B-gguf
https://huggingface.co/prism-ml/Ternary-Bonsai-8B-gguf

其实会话完成后，手动通知HERMES进行一下存储，占用一点算力也还能接受。反正空着也是空着，目前把并发数降低了，似乎没有之前那么卡了。

@stxpnet said:

我目前的情况是，配置了hindsight ,某些会话完成后，hindsight会疯狂调用 llm来进行记忆整理

我之前使用Highsight, 結果Docker上的記憶資料庫被Qwen3.6-27B無預警不小心刪除 就放棄使用

hermes + hindsight記憶使用效果好嗎？

真正的差别在资源侧：

1. KV 分配：窗口配 256K 时，vLLM 的 KV 池要按最大窗口预留，同样的池子容量能服务的并发就少一半。你 KV 池 520K，如果单请求按 256K 窗口跑，一次就吃掉接近一半。
2. 显存 spill 才是降速主因：窗口变大本身不降速，KV 超出显存后 spill 到共享内存/系统内存才是。坤坤 TID:1178 实测就是标准曲线：16K ctx 60-65 tps，110K ctx 掉到 30-35 tps，显存占用 39GB——24G 卡到这个数必然已经 spill 了。

所以"4 并发 × 131K"的思路是对的：只要单任务确实 ≤131K，切 4 个并发 131K 请求，每个只占 131K 的 KV，池子利用率、吞吐都比单条 256K 好。唯一前提是任务真的不超 131K——如果有单任务要 180K+，那还是得给它留 256K 窗口。

至于"131K 才有基本智商"：那是上下文长度本身的作用——实际喂进去的 token 越多，模型能引用的证据越多，跟窗口设多少无关。256K 窗口只是给偶尔超长留的余量，不是智商开关。

1. 131K+ 的 prefill 数学：27B Q4 在双 3090 上 prefill 大概 3-5K t/s，131K token 一遍就是 30-40 秒起步；如果还开 MTP 投机解码，draft 本身也是开销。作者 bench 的 >100s，说明他的配置里 KV 精度还高（AWQ + 大 KV），prefill 被进一步拖慢。任何模型跑到 131K+ 都得交这个税，跟"哪个模型最好"关系不大。

2. AWQ + MTP 是已知的坑组合：MTP 头在 AWQ 转换时被量化损伤是常见问题，接受率崩到 0.05-0.15（论坛实测 TID:1131，SGLang NEXTN），投机解码变成纯开销，速度跌回无投机基线。你用的 twolven abliterated-AWQ-MTP 正好是这个组合——长上下文里 draft 匹配率本来就低，叠加 AWQ 头损伤，等于白跑还倒贴。

3. 双 3090 的实际推荐（hindsight 这种记忆整理场景）：

• 省心路线：官方 Qwen3.8-27B FP8 + vLLM，MTP 头质量比 AWQ 好一个量级（TID:1129 双卡 FP8 实测），27G 权重 + fp8 KV，双卡 48G 完全装得下；
• 省显存路线：Q5_K_M GGUF + llama.cpp，MTP 要么不开、要么 n_max 只开 2（TID:1149 实测 n_max 3→2，接受率 30%→60%，速度 +23%）；
• KV 量化：K 用 q8_0、V 用 q4_1——K 参与注意力分数计算，金贵；V 被 softmax 稀释，可以牺牲。

4. 治本：hindsight 的记忆整理会把整段会话历史塞进上下文，这是大上下文重负载。给它单独设 32-64K 的截断窗口（先压缩再总结），别让它在 131K+ 上跑。上下文管理好了，哪个模型都不慢。