它把第 4 到 27 层这 24 层当成一个块，连续跑两遍，两遍用同一份权重。前面 0 到 3 层、后面 28 到 31 层只跑一遍。所以官方写的是约 9B 参数，推理时相当于约 14.6B。
省下来的是存储。社区转的 Q4_0 GGUF 只有 5.33 GB，16GB 的卡放得很宽松。
但本地跑，decode 速度主要卡在带宽上。
每出一个 token，参与计算的权重都要从显存读一遍。循环块有 50 多亿参数，GPU 的 L2 缓存最多也就一百来 MB，第二遍没法从缓存里拿，只能再从显存读一遍。
我按 config 粗算了一下：
1. 一层大约 2.2 亿参数，循环块占了全部参数的六成左右
2. 每个 token 实际要读的字节数，比文件本身多四成多
3. 速度要按 13B 到 14B 的稠密模型去预期
那份 GGUF 有实测，RX 5700 XT 跑 Q4_0 是 31.4 tok/s。
这张卡带宽 448 GB/s。如果每个 token 只读一遍 5.33 GB，理论上限 84 tok/s 左右。按循环块读两遍算，上限是 57 左右。31.4 是前者的 37%、后者的 55%，后者更像一张老卡的正常效率。
KV cache 也跟着变大。
它是 3 层线性注意力加 1 层全注意力交替，32 层里只有 8 层全注意力。但循环块跑两遍，每一遍的输入不一样，K 和 V 也不一样，要分开存。按 config 数下来，每个 token 要过 14 次全注意力：
1. 每次 4 个 KV 头，每头 256 维
2. BF16 下每个 token 每次 4 KB，14 次就是 56 KB
3. 128K 上下文大约 7.5 GB
没有循环的话只有 8 次，128K 大约 4.3 GB。
线性注意力那 42 次，每次有一个固定大小的状态，FP32 下 2 MB，一个请求加起来 84 MB 左右，不随上下文变长。
prefill 是算力活，循环块多跑一遍，计算量也按 14.6B 走。
这种结构适合显存小、带宽还行的卡，比如 16GB 的消费卡，用 9B 的显存换来更深的网络。
DGX Spark 这种机器正好反过来。128GB 内存不缺容量，缺的是带宽，只有 273 GB/s，循环恰好多吃带宽。
llama.cpp 官方现在还加载不了它，那份 GGUF 要用转换者自己的分支，视觉和 MTP 也没导出。
官方说 MTP 已经可用，DSpark 和 DFlash2 还在训练。投机解码一次验证多个 token，循环多读的那一遍会被摊薄一些。
我的判断是它适合 16GB 以下的卡。放到大内存的机器上，速度要按 14B 的稠密模型去算。