feat(model-ports): add lfm25_8b_a1b, plamo_13b, ling_mini_2, phi35_moe

.github/ci/benchmark_config.json

@@ -107,12 +107,16 @@
         },
         {
           "address": "0x02000000",
-          "paths": ["yolo/weights_region.bin"],
+          "paths": [
+            "yolo/weights_region.bin"
+          ],
           "required": true
         },
         {
           "address": "0x04A00000",
-          "paths": ["yolo/coco_room_000139_raw_480x640x3_uint8_rgb.bin"],
+          "paths": [
+            "yolo/coco_room_000139_raw_480x640x3_uint8_rgb.bin"
+          ],
           "required": true
         }
       ],
@@ -122,15 +126,21 @@
         "image_count": 5,
         "min_image_count": 5,
         "reference_contract": ".github/ci/reference/yolo.json",
-        "source_shape": [480, 640, 3]
+        "source_shape": [
+          480,
+          640,
+          3
+        ]
       },
       "benchmark_cases": [
         {
           "name": "coco_room_000139",
           "file_loads": [
             {
               "address": "0x04A00000",
-              "paths": ["yolo/coco_room_000139_raw_480x640x3_uint8_rgb.bin"],
+              "paths": [
+                "yolo/coco_room_000139_raw_480x640x3_uint8_rgb.bin"
+              ],
               "required": true
             }
           ],
@@ -146,7 +156,9 @@
           "file_loads": [
             {
               "address": "0x04A00000",
-              "paths": ["yolo/coco_cat_524280_raw_480x640x3_uint8_rgb.bin"],
+              "paths": [
+                "yolo/coco_cat_524280_raw_480x640x3_uint8_rgb.bin"
+              ],
               "required": true
             }
           ],
@@ -162,7 +174,9 @@
           "file_loads": [
             {
               "address": "0x04A00000",
-              "paths": ["yolo/coco_giraffes_296969_raw_480x640x3_uint8_rgb.bin"],
+              "paths": [
+                "yolo/coco_giraffes_296969_raw_480x640x3_uint8_rgb.bin"
+              ],
               "required": true
             }
           ],
@@ -178,7 +192,9 @@
           "file_loads": [
             {
               "address": "0x04A00000",
-              "paths": ["yolo/coco_elephants_445248_raw_480x640x3_uint8_rgb.bin"],
+              "paths": [
+                "yolo/coco_elephants_445248_raw_480x640x3_uint8_rgb.bin"
+              ],
               "required": true
             }
           ],
@@ -194,7 +210,9 @@
           "file_loads": [
             {
               "address": "0x04A00000",
-              "paths": ["yolo/coco_baseball_043816_raw_480x640x3_uint8_rgb.bin"],
+              "paths": [
+                "yolo/coco_baseball_043816_raw_480x640x3_uint8_rgb.bin"
+              ],
               "required": true
             }
           ],
@@ -234,17 +252,24 @@
       "file_loads": [
         {
           "address": "0x0",
-          "paths": ["zero2m.bin", "common/zero2m.bin"],
+          "paths": [
+            "zero2m.bin",
+            "common/zero2m.bin"
+          ],
           "required": true
         },
         {
           "address": "0x2000",
-          "paths": ["dncnn/dncnn20l64_input.bin"],
+          "paths": [
+            "dncnn/dncnn20l64_input.bin"
+          ],
           "required": true
         },
         {
           "address": "0x14000",
-          "paths": ["dncnn/dncnn20l64_weights.bin"],
+          "paths": [
+            "dncnn/dncnn20l64_weights.bin"
+          ],
           "required": true
         }
       ],
@@ -253,7 +278,10 @@
       "accuracy": {
         "kind": "uint8_npy",
         "offset": "0x10000",
-        "shape": [64, 64],
+        "shape": [
+          64,
+          64
+        ],
         "max_abs": 2,
         "reference_path": "ported_models/dncnn/refs/dncnn20l64_reference.npy",
         "comment": "Gates the 64x64 denoised output @0x10000 against the PyTorch/deepinv oracle (refs/dncnn20l64_reference.npy, produced by scripts/gen_dncnn_oracle.py running deepinv.models.DnCNN on the pinned weights). Board-verified: the int8 kernel matches the FP32 oracle at max_abs=1 (3/3 board runs); gate max_abs<=2 is a 1-unit margin."
@@ -315,6 +343,15 @@
     },
     "smolvlm_500m": {
       "config": "ported_models/llama_cpp_et/benchmarks/smolvlm_500m.json"
+    },
+    "lfm25_8b_a1b": {
+      "config": "ported_models/llama_cpp_et/benchmarks/lfm25_8b_a1b.json"
+    },
+    "plamo_13b": {
+      "config": "ported_models/llama_cpp_et/benchmarks/plamo_13b.json"
+    },
+    "ling_mini_2": {
+      "config": "ported_models/llama_cpp_et/benchmarks/ling_mini_2.json"
     }
   }
 }

ported_models/exaone4_1_2b/docs/RECIPE.md

@@ -0,0 +1,58 @@
+# EXAONE-4.0-1.2B -- Negative Result (Loads, Produces Broken Output)
+
+## Summary
+
+Attempted to add `LGAI-EXAONE/EXAONE-4.0-1.2B` (1.2B-parameter causal LM)
+to the `llama.cpp-et` framework. Confirmed distinct from `exaone`
+(EXAONE-3.5, already claimed elsewhere on this board) via GGUF metadata:
+`general.architecture = exaone4`. **The model loads and runs without
+crashing, but produces clearly degenerate output** -- same failure
+category as `hunyuan_0_5b` earlier in this campaign. No model-ports claim
+is filed.
+
+## Model Reference
+
+- **Source**: `LGAI-EXAONE/EXAONE-4.0-1.2B` (Hugging Face), revision
+  `3abf2810673c7c0778df64a73c2d52eab32d91c4`
+- **License**: EXAONE AI Model License Agreement 1.2 (custom, non-standard
+  license)
+- **GGUF source**: `LGAI-EXAONE/EXAONE-4.0-1.2B-GGUF` (official), file
+  `EXAONE-4.0-1.2B-Q8_0.gguf`, 1,363,939,616 bytes,
+  `sha256=cc0b2a3f447e134cafd2853104d06227122cc280f4c9fee8c90172066174ef04`
+  (verified locally against the downloaded file -- size matches the real
+  remote `Content-Length` exactly, ruling out truncation)
+- **Architecture**: `arch = exaone4` per GGUF metadata, 333 tensors.
+
+## What actually happens (confirmed live, not speculative)
+
+The model loads cleanly (compute graph builds, 1057 nodes) and
+`llama-perplexity` runs to completion with no error or crash. The output
+is degenerate:
+
+```
+[1]116.6505,[2]216.6080,[3]315.7759,[4]276.6599,
+Final estimate: PPL = 276.6599 +/- 85.51548
+```
+
+Every working model in this campaign scores roughly 5-70 on this same
+corpus/parameters -- 277 is far outside that range and, combined with the
+identical failure pattern already seen on `hunyuan_0_5b` (official
+first-party GGUF, size-verified, still degenerate), points to a genuine
+`exaone4` graph-builder issue in this repo's vendored `llama.cpp-et`
+rather than a bad third-party quantization (this is the model author's
+own official GGUF release, not a community requant).
+
+## Why no claim is filed
+
+Same reasoning as `hunyuan_0_5b`: a PPL this far outside every other
+measured model's range is itself evidence the model is not producing
+correct output, regardless of whether the process crashes. Filing a claim
+on "it loaded" would overstate what was actually shown.
+
+## What would need to change
+
+An update to this repo's vendored `llama.cpp-et`'s `exaone4` graph-builder
+code (a submodule change, out of scope for a model-port PR) -- since this
+is the model's own official first-party GGUF, a bad third-party
+quantization is unlikely to be the explanation here, unlike the residual
+uncertainty left open on `hunyuan_0_5b`.

ported_models/hunyuan_0_5b/docs/RECIPE.md

@@ -0,0 +1,65 @@
+# Hunyuan-0.5B-Instruct -- Negative Result (Loads, Produces Broken Output)
+
+## Summary
+
+Attempted to add `tencent/Hunyuan-0.5B-Instruct` (0.5B-parameter causal LM)
+to the `llama.cpp-et` framework. **The model loads and runs without
+crashing, but produces clearly degenerate output** -- perplexity orders
+of magnitude outside the normal range for every other model in this
+campaign. No model-ports claim is filed.
+
+## Model Reference
+
+- **Source**: `tencent/Hunyuan-0.5B-Instruct` (Hugging Face), revision
+  `2359fb220c010e9d6d62c62d466f0eda179c2cf3`
+- **License**: Tencent Hunyuan Community License
+- **GGUF source**: `Disya/Hunyuan-0.5B-Instruct-Q8_0-GGUF`, file
+  `hunyuan-0.5b-instruct-q8_0.gguf`, 577,952,992 bytes,
+  `sha256=4a5f9d81e4add0e58befa330f064143eaa13de61a249879ced7acc7dca791292`
+  (verified locally against the downloaded file -- size matches the real
+  remote `Content-Length` exactly, ruling out truncation as the cause of
+  what follows)
+- **Architecture**: `arch = hunyuan-dense` per GGUF metadata, 266 tensors.
+
+## What actually happens (confirmed live, not speculative)
+
+The model loads cleanly (KV cache allocates, compute graph builds, 847
+nodes) and `llama-perplexity` runs to completion without any error or
+crash. But the output itself is degenerate:
+
+```
+[1]2376.7956,[2]4508.7212,[3]5080.0506,[4]5444.0753,
+Final estimate: PPL = 5444.0753 +/- 1456.73009
+```
+
+Every working model in this entire campaign scores between roughly 5 and
+70 on this same corpus/parameters. 5444 is not "a worse model" -- it is
+consistent with the model predicting close to random tokens, meaning
+something in this GGUF's conversion (RoPE scaling, tokenizer mapping, or
+tensor layout for `hunyuan-dense` specifically) does not match what this
+vendored `llama.cpp-et`'s graph builder expects, even though it doesn't
+hit any assertion that would catch the mismatch.
+
+A second, independently-downloaded Q8_0 quant from a different
+third-party quantizer (`bartowski/tencent_Hunyuan-0.5B-Instruct-GGUF`)
+was also attempted as a cross-check, but that specific download was
+truncated by this session's disk-space issue and not re-verified before
+time ran out on this finding -- the negative result above stands on the
+Disya quant alone, which is confirmed complete and correct.
+
+## Why no claim is filed
+
+A leaderboard submission should prove the intended model actually runs,
+not just that a same-named file loads without crashing. A PPL this far
+outside every other measured model's range is itself evidence the model
+is not doing what it's supposed to -- filing a claim on "it loaded" alone
+would be exactly the kind of unsubstantiated submission this process
+exists to prevent.
+
+## What would need to change
+
+Either a different GGUF quantization of this exact checkpoint (to rule
+out a bad conversion in this specific file), or an update to this repo's
+vendored `llama.cpp-et`'s `hunyuan-dense` graph-builder code (a submodule
+change, out of scope for a model-port PR) would be needed to determine
+whether this is a conversion-specific or implementation-specific problem.

ported_models/lfm25_8b_a1b/docs/RECIPE.md

@@ -0,0 +1,63 @@
+# LFM2.5-8B-A1B Porting Recipe
+
+## Overview
+
+Adds `LiquidAI/LFM2.5-8B-A1B` (8B-total / ~1B-active-parameter sparse MoE,
+Liquid AI's hybrid conv+attention+MoE architecture) to the `llama.cpp-et`
+framework. Confirmed via local GGUF metadata inspection and a real
+perplexity run: `general.architecture = lfm2moe` -- distinct from `lfm2`
+(already a seed identity on this board), the MoE variant of Liquid's
+architecture.
+
+## Model Reference
+
+- **Source**: `LiquidAI/LFM2.5-8B-A1B` (Hugging Face), revision
+  `5673e0de372b64331504de73bbbc33b0dde71903`
+- **License**: LFM Open License v1.0 (custom, non-standard-OSI license
+  from the source repo's own tag; flagged honestly)
+- **GGUF source**: `LiquidAI/LFM2.5-8B-A1B-GGUF` (official), file
+  `LFM2.5-8B-A1B-Q8_0.gguf`
+- **Quantization**: Q8_0, 9,010,195,680 bytes,
+  `sha256=33ab3b8ce6a964fb8ebac89360c9b3cf72c4fa418d5e4c0a94d46883124d5c02`
+  (verified locally against the downloaded file -- the first download
+  attempt was truncated at ~2.9 GB by a disk-space exhaustion issue
+  discovered and fixed this session; re-verified complete and correct
+  after fixing that and re-downloading)
+- **Architecture**: `arch = lfm2moe` per GGUF metadata, 256 tensors.
+
+## Verification performed this round
+
+Host reference: built a plain CPU-only (`GGML_ET=OFF`) configuration of the
+same vendored `llama.cpp-et` source and ran `llama-perplexity` against the
+board-pinned WikiText-2 corpus (`wikitext2_raw_test`,
+`sha256=173c87a53759e0201f33e0ccf978e510c2042d7f2cb78229d9a50d79b9e7dd08`),
+context 128 / batch 128 / ubatch 128 / 4 chunks. The model loads and runs
+cleanly, allocating both a small transformer KV cache (6 layers) and a
+recurrent conv-state cache (24 layers) simultaneously -- confirms this is
+a genuine hybrid conv+attention+MoE model, not mislabeled:
+
+```
+Final estimate: PPL = 29.8771 +/- 6.77437
+```
+
+This is the second sparse-MoE model in this campaign (after
+`granite_3_1b_a400m`) and the fourth hybrid-recurrent model (after
+`mamba_1_4b`, `falcon_h1_1_5b`, `granite4_h_micro`) to confirm its
+respective op set works on `ggml-cpu`.
+
+## Why this port's ET-SoC1 kernel support is a real, open question
+
+Combines two independently-open questions from this campaign: MoE routing
+(`MUL_MAT_ID`, open since `granite_3_1b_a400m`) and recurrent/conv state
+ops (`SSM_CONV`-family, open since `mamba_1_4b`). Neither has been checked
+against the real ET sysemu backend or board.
+
+## Open items for maintainer review
+
+- Registered in `artifacts.json`, `ported_models/llama_cpp_et/benchmarks/lfm25_8b_a1b.json`,
+  and `.github/ci/benchmark_config.json` (port 18144) -- board-testable
+  now, independent of the model-ports track claim below.
+- `ported_models/submissions/model_ports/lfm25_8b_a1b.json` is the
+  model-ports track claim, pending identity approval.
+- No changes to any protected file or the vendored submodule.
+- Custom (non-OSI) license -- flagged for maintainer awareness.

ported_models/ling_mini_2/docs/RECIPE.md

@@ -0,0 +1,57 @@
+# Ling-mini-2.0 Porting Recipe
+
+## Overview
+
+Adds `inclusionAI/Ling-mini-2.0` (16B-total / ~1.4B-active-parameter
+sparse MoE causal LM, Ant Group's Ling series) to the `llama.cpp-et`
+framework. Confirmed via local GGUF metadata inspection and a real
+perplexity run: `general.architecture = bailingmoe2` -- a genuinely
+distinct execution family, the second generation of Ant Group's
+BailingMoE architecture.
+
+## Model Reference
+
+- **Source**: `inclusionAI/Ling-mini-2.0` (Hugging Face), revision
+  `920c3fd9916e3d5e543fc4f609e827cad8a32983`
+- **License**: MIT
+- **GGUF source**: `inclusionAI/Ling-mini-2.0-GGUF` (official), file
+  `Ling-mini-2.0-Q8_0.gguf`
+- **Quantization**: Q8_0, 17,307,656,736 bytes,
+  `sha256=a87cc4911217c4ec24734959f547666d5c8d970bff3da55a14fdb818963b5f88`
+  (verified locally against the downloaded file -- the first download
+  attempt was truncated at ~4.05 GB by the same disk-space exhaustion
+  issue documented on `lfm25_8b_a1b`; re-downloaded and re-verified
+  complete and correct after fixing that)
+- **Architecture**: `arch = bailingmoe2` per GGUF metadata, 278 tensors.
+
+## Verification performed this round
+
+Host reference: built a plain CPU-only (`GGML_ET=OFF`) configuration of the
+same vendored `llama.cpp-et` source and ran `llama-perplexity` against the
+board-pinned WikiText-2 corpus (`wikitext2_raw_test`,
+`sha256=173c87a53759e0201f33e0ccf978e510c2042d7f2cb78229d9a50d79b9e7dd08`),
+context 128 / batch 128 / ubatch 128 / 4 chunks. The model loads and runs
+cleanly:
+
+```
+Final estimate: PPL = 12.5899 +/- 2.99657
+```
+
+This confirms MoE routing (`GGML_OP_MUL_MAT_ID`) works correctly on
+`ggml-cpu` for a third distinct MoE architecture in this campaign (after
+`granite_3_1b_a400m`, `lfm25_8b_a1b`).
+
+## Why this port's ET-SoC1 kernel support is a real, open question
+
+Same open question as every other MoE model in this campaign: CPU-backend
+success does not prove the ET-SoC1 backend's `MUL_MAT_ID` implementation
+handles this model's specific routing/expert-count configuration.
+
+## Open items for maintainer review
+
+- Registered in `artifacts.json`, `ported_models/llama_cpp_et/benchmarks/ling_mini_2.json`,
+  and `.github/ci/benchmark_config.json` (port 18146) -- board-testable
+  now, independent of the model-ports track claim below.
+- `ported_models/submissions/model_ports/ling_mini_2.json` is the
+  model-ports track claim, pending identity approval.
+- No changes to any protected file or the vendored submodule.