strata极致优化指南（参数篇）64GB RAM + RTX pro 5000 48GB， IQ3_XXS量化，prefill 4500t/s，decode 180t/s 同时缓存5个262k会话不重新prefill
-
fcme 是的 64k更快 不过我是放进用opencodex 放进codex和GPT-6一起配合用的 所以我觉得128k也不太够用 刚刚改成了256k 还行
@Marck-Wong
哦，是这样，agent时代上下文累积太快了，100多确实小了点。 我也是最后稳定在了245k。 -
@Marck-Wong
哦，是这样，agent时代上下文累积太快了，100多确实小了点。 我也是最后稳定在了245k。 -
@fcme 我不太懂 我就是设置了 autocompact 80% 所以不会用满256k
-
-
-
系统 于 取消固定此主题
-
，
K kop wang 引用了 此主题
-
-
@kop-wang
大神有没有升级Strata到0.2以上的版本？我也是RTX PRO 5000，一直跑着0.1.43版本，很稳，看到Strata更新很积极，但是似乎没有针对RTX PRO 5000的优化。不知道大神有没有升级测试？ -
@wml-ai 0.2.x版本本质上就是0.1.45以及以上内核，提升了一点效率。
一个是默认状态不是贪心算法了，也就是温度是1，而不是0。但是速度基本没降。
一个是对于nvfp4而言，优化了一些吞吐效率，目前我的普遍经验是nvfp4能跑到大概3500t/s的prefill，130t/s的decode。我目前基本已经不用IQ3_XXS了。
-
-
@kop-wang
大神有没有升级Strata到0.2以上的版本？我也是RTX PRO 5000，一直跑着0.1.43版本，很稳，看到Strata更新很积极，但是似乎没有针对RTX PRO 5000的优化。不知道大神有没有升级测试？ -
-
前言：strata最近已经火出圈了，火到RAM又翻了个倍。目前京东自营，海力士颗粒的64GB的DDR5 6000内存已经几近破万。
十一长假回来，笔者也是暂时小试牛刀了一把，发现有一些关键参数，会直接影响整个LLM引擎的本质体验，但是默认值并不是特别合理。所以发个tips小文供大家交流。欢迎批评指正。
本文全程手打，无任何AI含量，请放心阅读。
1、Harness会频繁唤起子代理（sub agent），导致切换会话prefill浪费太多时间，怎么办？
答：开启--conversation-cache-mib
这个参数会让strata使用RAM来缓存历史对话，从而不让LLM反复重新prefill老的session。增加会话切换时的速度，对于agent、harness场景有奇效。
开启conversation-cache-mib后，monitor面板会有如下展示：
分别表述当期缓存了多少个会话，以及目前占用了多少RAM。
这个机制有两个痛点：1、不支持多显卡。2、最大只支持20GB的对话缓存（如果是8bitkvcache，大概就是4各半的262k context）。
2、我的显卡显存总是占不满，浪费一些，怎么破？
答：配置--expert-cache，不要用auto档位。手动指定
让更多的专家进驻显存。注意，手动指定的是下限，所以要反复测试量力而行。
3、我想使用上文的conversation-cache，但是我RAM都快满了，怎么办？
答：启用低内存模式：--resident-experts
小科普，正常默认情况下，strata加载的专家是内存+SSD加载全量，vRAM加载高命中概率专家。相当于RAM和vRAM之间，是有一定的重复加载的。
官方这样指定默认值是有道理的，一旦VRAM的专家没能命中，直接可以读取RAM的进入vRAM。
代价就是这会导致RAM的极大浪费。通过配置低内存模式，能够让vRAM+RAM分别加载不同专家，分工合作。这样能节省巨量RAM。代价是一旦VRAM中的专家没能命中，除了从RAM读取以外，还要从vRAM剔除一个回写到RAM。但相较于直接节省40GB的RAM空间而言，这点回写简直可以忽略不计。而且你显卡的显存越大，遇到回写的概率越低。
笔者的是48GB的 rtx pro 5000，专家命中率一直保持在99%。
4、我想多个聊天会话一起聊（并发），怎么办？
答，配置parallel: X（X是并发会话数，最大8）会占用显存，我个人实测，IQ3_XXS量化下，会话长度262k，每个并发占用5.2GB显存。
以上，欢迎列为交流，指正。最后列出我个人的全套参数，供各位参考。
"args": [ "--pack", "C:\\work\\Strata-data\\packs\\iq3_xxs", "--native", "C:\\work\\Strata-data\\models\\IQ3_XXS\\Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS-00001-of-00002.gguf", "--ple-gguf", "C:\\work\\Strata-data\\models\\IQ3_XXS\\Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS-00002-of-00002.gguf", "--expert-profile", "C:\\work\\Strata\\data\\expert-profile.bin", "--resident-experts", "--expert-cache", "19000", "--prefill", "auto", "--spec", "4", "--mtp", "C:\\work\\Strata-data\\mtp\\rt", "--max-context", "262144", "--kv", "k8v4", "--vision", "--vram-reserve-mib", "3400", "--pcie-frac", "0.00", "--spec-min-p", "0.70", "--conversation-cache-mib", "20480", "--conversation-cache-slots", "6", "--conversation-cache-min-free-mib", "13824", "--prompt-cache-every", "8192" ],@kop-wang
Strata的并发是假并发，实际上是排队的。不过你卡牛逼，速度快体验会好很多吧 -
@fcme 如果配置parallel: X，从技术上讲是假并发，从效果上讲是真并发（热缓存，可以实现并排decode）。但是总token输出速度甚至会因为batch不支持mtp反降。
和vllm以及sglang的并发有很大不同。这个取决于他是借鉴的llama.cpp的一部分引擎逻辑。
这个并发，其实主要是和conversation-cache相对而言的。
不配置并发，就是纯排队，会有队列queue列出。但是就可以通过conversation-cache机制在RAM实现温缓存。对应的，sglang的hicache和conversation-cache也有一定渊源，具体的我没深究。
虚心交流，一起进步
-
@fcme 如果配置parallel: X，从技术上讲是假并发，从效果上讲是真并发（热缓存，可以实现并排decode）。但是总token输出速度甚至会因为batch不支持mtp反降。
和vllm以及sglang的并发有很大不同。这个取决于他是借鉴的llama.cpp的一部分引擎逻辑。
这个并发，其实主要是和conversation-cache相对而言的。
不配置并发，就是纯排队，会有队列queue列出。但是就可以通过conversation-cache机制在RAM实现温缓存。对应的，sglang的hicache和conversation-cache也有一定渊源，具体的我没深究。
