Kidobjuk a soha-nem-
használt szakértőket?

A profilozó: egy llama.cpp eval-callback

Új példa az llama.cpp tree-ben, ami minden forward pass alatt elcsípi a router döntéseit.

// build_moe_ffn() in llama-graph.cpp:
//   cb(selected_experts->src[0], "ffn_moe_argsort", il);  // [256, n_tokens] I32, contiguous
//   cb(selected_experts,         "ffn_moe_topk",    il);  // [8, n_tokens] — VIEW (gotcha!)

static bool moe_cb_eval(ggml_tensor *t, bool ask, void *ud) {
    if (ask) return strncmp(t->name, "ffn_moe_argsort", 15) == 0;
    if (!is_argsort) return true;
    int il = atoi(strrchr(t->name, '-') + 1);
    int32_t *ids = (int32_t*) backend_get(t);             // contiguous parent
    for (int tok = 0; tok < n_tokens; ++tok)
        for (int rank = 0; rank < n_used; ++rank)         // top-8 per token
            counts[il][ ids[tok * n_expert + rank] ]++;
    return true;
}

Inputja a meglévő GGUF model + egy korpusz; outputja egy JSON: rétegenként × expertenként hány selection.

Buktató — kis híján kísérlet-gyilkos

Amikor a tökéletes egyenlőség a hiba

A valódi routing-tömeg

Mennyit fed le a TOP-K expert a routing tömegnek per layer, összevont dev+pm+family korpuszra. A worst layer oszlop a kritikus: az limitálja az uniform GGUF pruningot.

• · per-layer max/min expert-usage ratio: median 2810 (uniform = 1.0)
• · deeper layers ferdébbek: layer 0 std/mean=1.75, layer 39 = 3.19
• · 0 teljesen halott expert (load-balancing loss tervezett mellékhatása)

Sebészet: raw-slab gather, nincs requant

A trükk ami miatt nem kell dequantálni: a 4 expert-hordozó tensorban az expert-index a legkülső ggml-tengely. A gguf-py numpy byte-shape-ben az axis 0 = expert → data[keep_indices] egy fancy-index és KÉSZ. A Q4_K/Q5_K/Q6_K blokk-kvantálás betűre megőrződik.

# prune_gguf.py — the core
for t in reader.tensors:
    data = t.data
    if expert_tensor_re.match(t.name):          # ffn_{gate,up,down}_exps
        il = layer_from_name(t.name)
        data = np.ascontiguousarray(data[keepset(il)])   # axis 0 = expert
    elif router_re.match(t.name):                # ffn_gate_inp
        data = np.ascontiguousarray(data[keepset(il)])
    writer.add_tensor_info(t.name, data.shape, data.dtype, data.nbytes, t.tensor_type)
    # *_shexp (shared expert) -> copied verbatim, never pruned

• · 4 érintett tensor / MoE layer: gate_exps + up_exps + down_exps + gate_inp (router)
• · *_shexp (shared expert, mindig aktív) érintetlenül átmásolva
• · globális metadata: expert_count = K, expert_used_count marad 8
• · 23 GB → pruneolt GGUF: ~12 másodperc lemezírással együtt

Sebesség: prefill skálázódik, generation nem

llama-bench gfx1150 Vulkan-on, ngl=99. Érdekes minta: a prefill (prompt processing) szépen skálázódik K-val — de a generation lényegében változatlan, mert per-token mindenképpen csak 8 expert aktív.

Mellesleg: K=128 modell ugyanolyan sebességgel generál (23 t/s), mint a baseline 35 B — viszont a fele méreten. Bizonyos use-case-ekre (gyors draft MTP-hez, telefonra) ez érdekes.

Egy darab nyitva maradt rejtély

K=128 + llama-perplexity + Vulkan = GPU-fagyás

A K=128 fájl betöltése a perplexity-mérőben uninterruptible kernel-állapotba ragadt amdgpu-buffer-allokáció közben. kill -9 nem fogta. Két amdgpu_gpu_recover sem oldotta fel. Reboot kellett.