16G 5070Ti把用Strata的flash next换成Basalt，实测快1.4倍！白拿的性能！
-
-
-
-
-
-
The Intel
Xeon Gold 6252 Processor
• Cores and Threads: 24 cores and 48 threads看来还是超多核心才会有的效果，我想升级xeon了
@imbiplaza-ASUS
主要是CPU支持的AI加速指令集要到位 -
@imbiplaza-ASUS
主要是CPU支持的AI加速指令集要到位 -
等strata 作者不断想办法榨取电脑的资源，然而我也想知道amd 的epyc是不是更好
-
-
，
T terry 固定了此主题
-
背景：一直对Strata的在5070Ti 16G 跑的8030 端口之前跑的Strata 0.2.9（IQ3_XXS，204800 上下文）的速度不太满意，今天突然发现一个青出于蓝而胜于蓝的选项。直接开测。
Basalt 是 Strata 的 fork，改动集中在 CPU 调度层：更细的 row-range 任务切分、i-quant 走 AVX-VNNI、单文件 .basalt 格式。社区里常见 2 倍的说法，所以拿同机同模型做了对比。
结论：确实更快，但没有 2 倍，实测 1.26 到 1.42 倍。
一、前后对比
同一台机器、同一个模型（Qwen3.8-Flash-Next GSQ-RCO IQ3_XXS）、同一张卡（250 W 锁功耗），basalt-bench 固定 seed：
指标 Strata 0.2.9 Basalt 0.3.0 倍率 prefill 64K 1960 tok/s 2725 tok/s 1.39 decode（MTP 接受率 65-70%） 58 tok/s 73 tok/s 1.26 decode（接受率 97-98%） 104 tok/s 148 tok/s 1.42 decode 的差异主要来自 MTP 接受率：接受率高时窗口里挤进更多 token，固定开销被摊薄。两个引擎都是这个规律。
二、为什么不是 2 倍
社区里 2 倍的数据基本出自 5 GHz、带 AVX-VNNI 的桌面 CPU（9950X、285K 之类）。这台是 Xeon Gold 6252，2019 年的 Cascade Lake，2.1 GHz。
从三个 fixture 反推窗口开销，能拟合出：每个 decode 窗口约 19 ms 固定 + 4.1 ms/token。48 层摊下来每层约 0.4 ms，花在 CPU 侧串行的专家点积和主机与卡之间的握手上，不在显卡算力。
几个直接证据：
- 引擎启动日志自己写了：
this CPU has no AVX-512: the expert kernels run on AVX-2。这颗 U 有 AVX512-VNNI，但缺 VBMI/VBMI2，Basalt 判定不可用退回 AVX2；而 AVX-VNNI（VEX 版）它也没有，恰好是 Basalt 重点优化的那条路。 - 把显存里的专家数从 6.7 GiB（Strata）提到 13.3 GiB（Basalt），翻了一倍，速度只涨 1.2 到 1.4 倍。瓶颈不在显存。
basalt-bench --hardware实测：RAM 读 48.6 GB/s，PCIe 3.0 x16、H2D 13.8 GB/s。宿主链路 LnkCap 支持 32 GT/s，LnkSta 只跑 8 GT/s，因为 6252 平台本身就是 PCIe 3.0。- 内存拓扑更隐蔽：宿主 node0 有 46.9 GB（带核），node1 有 48.3 GB 但没有核。虚拟机 74 GiB 必然跨两个节点，约一半内存每次访问都要过跨节点链路。
所以这台机器上是两个引擎同时撞同一堵墙：Strata 慢是因为墙，Basalt 也只快在墙内能优化的那部分。
三、容器化，损失多少
原来是裸进程（systemd），现在跑容器：
- 镜像
basalt-5070ti-256k-img:latest，3.05 GB，基于nvidia/cuda:13.0.0-runtime-ubuntu24.04，只装 python3、jinja2、regex、numpy。 - 权重只读挂载，配置只读挂载，状态目录可写。
同口径基准：
指标 裸进程 容器 差值 prefill 64K 2725 2648 -2.8% decode conv 73 72 0% decode struct 148 151 +2% decode prose 72 72 0% 基本在噪声里。关键是三个参数别省：
--ulimit memlock=-1（否则专家页锁失败退回文件映射，速度直接掉）、--shm-size给够、不要设 CPU 配额。四、预热和跨对话缓存
容器入口脚本会在模型加载完后自动预热 23 秒：DSH 的系统提示词（7.3K token）、Hermes 的提示词（0.8K）、一段 300 字生成、一张图（识图路径）。都是为了把专家缓存和 MTP 状态跑热。
效果是数量级的：
同一个 2 万 token 提示词，冷启动 31.5 秒，预热后 7.1 秒。这解释了「刚启动那几轮为什么慢」——不是配置坏了。
第二层是会话检查点：离开再回到同一个对话，日志里是
restored 13037 tokens (checkpoint) in 65.4 ms，同一提示词从 4.3 秒掉到 90 毫秒。第三层是磁盘停放：容器重启后照样能读回，
read 13037 tokens from disk in 457.4 ms。实测快照约 8.1 KB/token，一个 19.5 万 token 的会话落盘 1.5 GiB，32 GiB 预算大概放得下 20 个 20 万 token 的会话。五、配置与启动
{ "version": 2, "models": [{ "model": "/models/Qwen3.8-FN-GSQ-RCO-IQ3_XXS.basalt", "alias": "5070Ti-QFNext-iQ3xxs-Basalt", "gpu": "0", "max-context": 262144, "kv": "int8", "vision": "dynamic" }], "engine": { "resident-experts": true, "vram-reserve-mib": 256, "spec": 8, "expert-profile-save": "/state/expert-profile-learned.bin", "conversation-cache-mib": 2048, "conversation-cache-slots": 4, "conversation-cache-min-tokens": 8192, "conversation-cache-disk-mib": 32768, "conversation-cache-dir": "/state/conversations" }, "server": { "host": "0.0.0.0", "port": 8030 } }启动：
docker run -d --name Basalt-5070ti-256K-img \ --gpus "device=0" \ --ulimit memlock=-1 \ --shm-size=2g \ -p 8030:8030 \ -v /data/aimodels/basalt:/models:ro \ -v /data/basalt-state:/state \ -v /data/basalt-state/warmup:/warmup:ro \ -v /path/basalt_config.json:/config.json:ro \ --restart unless-stopped \ basalt-5070ti-256k-img:latest加载 43.8 GiB（显存 13.0 + 内存 30.8），冷启动约 85 秒，262144 上下文可用，识图一张图 1 到 2 秒。
参数是实测筛过的，别照抄网上的：
kv k8v4省 23% 的 KV 但 prefill 掉 7%；spec 4让结构化输出从 148 掉到 133；resident-budget-gib压到 26 GiB 会触发专家溢写到 SSD，prefill 直接腰斩。256K 上下文相对 66K 的 prefill 只差 0.2%，所以直接拉满。六、容器化踩到的三个坑
- CUDA 版本门槛：镜像标签写着
cuda>=13.5就要求驱动支持 13.5。这台驱动 580.159.03 报的 CUDA 是 13.0，用 13.5 的 runtime 镜像直接起不来，必须退到13.0.0-runtime。 - 源码树路径写死：二进制会 chdir 到编译时的源码树，容器里没有那个目录就报
cannot enter the source tree。加一条软链/home/fcc/build/basalt -> /opt/basalt即可。 - serve 依赖不全：
serve/会往sys.path塞tools/，只拷 bin 和 serve 会在model_file、regex上炸，记得把tools/一起打进去。
七、结语
Basalt 本身没问题，它的优势是 CPU 调度和专家管理；问题在于瓶颈会不会被让出来。16G 卡 + 老 Xeon + PCIe 3.0 这套组合，换引擎能拿到 1.2 到 1.4 倍；如果你是新平台（5 GHz + AVX-VNNI + 本地内存），社区那些 2 倍数据应该更接近。
仓库：https://github.com/jesdga95/basalt
权重：https://huggingface.co/jesdga/Qwen3.8-Flash-Next-Basalt - 引擎启动日志自己写了：
-
@fcme
Strata 0.2.12也优化了 DFlash2 ，应用程序和终端的版本是 0.2.12。控制和所有引擎软件包的版本是 0.1.58。UD-IQ4_XS-v31 和 UD-Q4_K_XL 的prefill提高了3倍。 -
背景：一直对Strata的在5070Ti 16G 跑的8030 端口之前跑的Strata 0.2.9（IQ3_XXS，204800 上下文）的速度不太满意，今天突然发现一个青出于蓝而胜于蓝的选项。直接开测。
Basalt 是 Strata 的 fork，改动集中在 CPU 调度层：更细的 row-range 任务切分、i-quant 走 AVX-VNNI、单文件 .basalt 格式。社区里常见 2 倍的说法，所以拿同机同模型做了对比。
结论：确实更快，但没有 2 倍，实测 1.26 到 1.42 倍。
一、前后对比
同一台机器、同一个模型（Qwen3.8-Flash-Next GSQ-RCO IQ3_XXS）、同一张卡（250 W 锁功耗），basalt-bench 固定 seed：
指标 Strata 0.2.9 Basalt 0.3.0 倍率 prefill 64K 1960 tok/s 2725 tok/s 1.39 decode（MTP 接受率 65-70%） 58 tok/s 73 tok/s 1.26 decode（接受率 97-98%） 104 tok/s 148 tok/s 1.42 decode 的差异主要来自 MTP 接受率：接受率高时窗口里挤进更多 token，固定开销被摊薄。两个引擎都是这个规律。
二、为什么不是 2 倍
社区里 2 倍的数据基本出自 5 GHz、带 AVX-VNNI 的桌面 CPU（9950X、285K 之类）。这台是 Xeon Gold 6252，2019 年的 Cascade Lake，2.1 GHz。
从三个 fixture 反推窗口开销，能拟合出：每个 decode 窗口约 19 ms 固定 + 4.1 ms/token。48 层摊下来每层约 0.4 ms，花在 CPU 侧串行的专家点积和主机与卡之间的握手上，不在显卡算力。
几个直接证据：
- 引擎启动日志自己写了：
this CPU has no AVX-512: the expert kernels run on AVX-2。这颗 U 有 AVX512-VNNI，但缺 VBMI/VBMI2，Basalt 判定不可用退回 AVX2；而 AVX-VNNI（VEX 版）它也没有，恰好是 Basalt 重点优化的那条路。 - 把显存里的专家数从 6.7 GiB（Strata）提到 13.3 GiB（Basalt），翻了一倍，速度只涨 1.2 到 1.4 倍。瓶颈不在显存。
basalt-bench --hardware实测：RAM 读 48.6 GB/s，PCIe 3.0 x16、H2D 13.8 GB/s。宿主链路 LnkCap 支持 32 GT/s，LnkSta 只跑 8 GT/s，因为 6252 平台本身就是 PCIe 3.0。- 内存拓扑更隐蔽：宿主 node0 有 46.9 GB（带核），node1 有 48.3 GB 但没有核。虚拟机 74 GiB 必然跨两个节点，约一半内存每次访问都要过跨节点链路。
所以这台机器上是两个引擎同时撞同一堵墙：Strata 慢是因为墙，Basalt 也只快在墙内能优化的那部分。
三、容器化，损失多少
原来是裸进程（systemd），现在跑容器：
- 镜像
basalt-5070ti-256k-img:latest，3.05 GB，基于nvidia/cuda:13.0.0-runtime-ubuntu24.04，只装 python3、jinja2、regex、numpy。 - 权重只读挂载，配置只读挂载，状态目录可写。
同口径基准：
指标 裸进程 容器 差值 prefill 64K 2725 2648 -2.8% decode conv 73 72 0% decode struct 148 151 +2% decode prose 72 72 0% 基本在噪声里。关键是三个参数别省：
--ulimit memlock=-1（否则专家页锁失败退回文件映射，速度直接掉）、--shm-size给够、不要设 CPU 配额。四、预热和跨对话缓存
容器入口脚本会在模型加载完后自动预热 23 秒：DSH 的系统提示词（7.3K token）、Hermes 的提示词（0.8K）、一段 300 字生成、一张图（识图路径）。都是为了把专家缓存和 MTP 状态跑热。
效果是数量级的：
同一个 2 万 token 提示词，冷启动 31.5 秒，预热后 7.1 秒。这解释了「刚启动那几轮为什么慢」——不是配置坏了。
第二层是会话检查点：离开再回到同一个对话，日志里是
restored 13037 tokens (checkpoint) in 65.4 ms，同一提示词从 4.3 秒掉到 90 毫秒。第三层是磁盘停放：容器重启后照样能读回，
read 13037 tokens from disk in 457.4 ms。实测快照约 8.1 KB/token，一个 19.5 万 token 的会话落盘 1.5 GiB，32 GiB 预算大概放得下 20 个 20 万 token 的会话。五、配置与启动
{ "version": 2, "models": [{ "model": "/models/Qwen3.8-FN-GSQ-RCO-IQ3_XXS.basalt", "alias": "5070Ti-QFNext-iQ3xxs-Basalt", "gpu": "0", "max-context": 262144, "kv": "int8", "vision": "dynamic" }], "engine": { "resident-experts": true, "vram-reserve-mib": 256, "spec": 8, "expert-profile-save": "/state/expert-profile-learned.bin", "conversation-cache-mib": 2048, "conversation-cache-slots": 4, "conversation-cache-min-tokens": 8192, "conversation-cache-disk-mib": 32768, "conversation-cache-dir": "/state/conversations" }, "server": { "host": "0.0.0.0", "port": 8030 } }启动：
docker run -d --name Basalt-5070ti-256K-img \ --gpus "device=0" \ --ulimit memlock=-1 \ --shm-size=2g \ -p 8030:8030 \ -v /data/aimodels/basalt:/models:ro \ -v /data/basalt-state:/state \ -v /data/basalt-state/warmup:/warmup:ro \ -v /path/basalt_config.json:/config.json:ro \ --restart unless-stopped \ basalt-5070ti-256k-img:latest加载 43.8 GiB（显存 13.0 + 内存 30.8），冷启动约 85 秒，262144 上下文可用，识图一张图 1 到 2 秒。
参数是实测筛过的，别照抄网上的：
kv k8v4省 23% 的 KV 但 prefill 掉 7%；spec 4让结构化输出从 148 掉到 133；resident-budget-gib压到 26 GiB 会触发专家溢写到 SSD，prefill 直接腰斩。256K 上下文相对 66K 的 prefill 只差 0.2%，所以直接拉满。六、容器化踩到的三个坑
- CUDA 版本门槛：镜像标签写着
cuda>=13.5就要求驱动支持 13.5。这台驱动 580.159.03 报的 CUDA 是 13.0，用 13.5 的 runtime 镜像直接起不来，必须退到13.0.0-runtime。 - 源码树路径写死：二进制会 chdir 到编译时的源码树，容器里没有那个目录就报
cannot enter the source tree。加一条软链/home/fcc/build/basalt -> /opt/basalt即可。 - serve 依赖不全：
serve/会往sys.path塞tools/，只拷 bin 和 serve 会在model_file、regex上炸，记得把tools/一起打进去。
七、结语
Basalt 本身没问题，它的优势是 CPU 调度和专家管理；问题在于瓶颈会不会被让出来。16G 卡 + 老 Xeon + PCIe 3.0 这套组合，换引擎能拿到 1.2 到 1.4 倍；如果你是新平台（5 GHz + AVX-VNNI + 本地内存），社区那些 2 倍数据应该更接近。
仓库：https://github.com/jesdga95/basalt
权重：https://huggingface.co/jesdga/Qwen3.8-Flash-Next-Basalt - 引擎启动日志自己写了：
-
@fcme
我在2 x 5060TI 16G, RAM:64G 上跑, 單發OK, P2速度就崩了.AI:崩速根因定案為③ layer-split 在對面 slot 解碼時自動關閉 → 兩條長 prefill 在 GPU0 串行，不是 KV 搶 VRAM。16 GB×2 上 GPU1 的 VRAM 已滿載 peer experts，沒空間借給 prefill.
版主审定：本帖设为优秀，作者 +3 积分奖励，继续加油！
