双3090，哪个qwen 3.8 模型才是最好的呢？
-
众所周知，27B需要131K的上下文才能有基本的智商和思考能力，目前我比较关注，同样配置条件下，131K上下文 和 256K上下文，同一模型，在131K以内的综合表现差别到底有多大？ 因为我目前配置跑256K也不能说完全顺畅，但KV缓存池有520K容量，既然如此，我何不把VLLM改成4个并发，跑满满的131K上下文呢？ @xiaote
-
众所周知，27B需要131K的上下文才能有基本的智商和思考能力，目前我比较关注，同样配置条件下，131K上下文 和 256K上下文，同一模型，在131K以内的综合表现差别到底有多大？ 因为我目前配置跑256K也不能说完全顺畅，但KV缓存池有520K容量，既然如此，我何不把VLLM改成4个并发，跑满满的131K上下文呢？ @xiaote
-
@stxpnet 好问题，先把结论说清楚：窗口设 131K 还是 256K，本身不影响 131K 以内的模型表现——注意力只覆盖实际存在的 token，窗口只是个上限。同一个模型、同样的实际输入长度，配 131K 窗口和配 256K 窗口，生成结果基本没差别。
真正的差别在资源侧：
- KV 分配：窗口配 256K 时，vLLM 的 KV 池要按最大窗口预留，同样的池子容量能服务的并发就少一半。你 KV 池 520K，如果单请求按 256K 窗口跑，一次就吃掉接近一半。
- 显存 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 窗口只是给偶尔超长留的余量，不是智商开关。
-
我目前的情况是，配置了hindsight ,某些会话完成后，hindsight会疯狂调用 llm来进行记忆整理，目前使用的这个 twolven/Qwen3.8-27B-abliterated-AWQ-MTP 在超过131K上下文，或者并发较高的时候，由于 多并发没法控制，速度非常缓慢.而且作者的bench 也说明了，超过131K 上下文，prefill 会超过100秒。 这可能也是缓慢的根源之一。
-
@stxpnet 我也用的hindsight作为长期记忆，不过我不用主模型来运行记忆整理，而是用专门的EDGE模型来处理，因为这个必须用短小精悍的模型，建议用9B或14B。另外重排和向量模型也可以自定义模型而不是hindsight内置的，模型也很小，不用多少显存，效率也高，因为内置模型用的是CPU。
不过我不用主模型来运行记忆整理，而是用专门的EDGE模型来处理，因为这个必须用短小精悍的模型，建议用9B或14B。另外重排和向量模型也可以自定义模型而不是hindsight内置的
用一個小型的MoE模型 Q4_K_M來整理記憶不知道合適不？
只要語意理解能力夠高 應該不錯
突然想到TernaryBonsai-8B Q2prism-ml/Ternary-Bonsai-8B-gguf
https://huggingface.co/prism-ml/Ternary-Bonsai-8B-gguf -
不过我不用主模型来运行记忆整理，而是用专门的EDGE模型来处理，因为这个必须用短小精悍的模型，建议用9B或14B。另外重排和向量模型也可以自定义模型而不是hindsight内置的
用一個小型的MoE模型 Q4_K_M來整理記憶不知道合適不？
只要語意理解能力夠高 應該不錯
突然想到TernaryBonsai-8B Q2prism-ml/Ternary-Bonsai-8B-gguf
https://huggingface.co/prism-ml/Ternary-Bonsai-8B-gguf -
當時使用Highsight 跑Qwen3.6-27B Dense 模型 好像每跑幾輪對話就會一直壓縮
顯卡就一直跑壓縮整理記憶,
假如有多的顯卡或免費API, 可以改其他API端點來進行記憶體整理 不要共用主模型就好 減少顯卡的運作壓力
