SLM Daily #13: llama.cpp was silently zero-padding corrupted LoRA files. Nobody would have known.
A truncated or corrupted LoRA adapter file didn't error out in llama.cpp — it loaded anyway, with the missing tensor data silently zero-padded in, and told you nothing was wrong. That bug shipped a fix this edition, alongside a second, closely related one: metadata arrays inside a GGUF file were being read in some code paths without checking their declared type first. Ten engine builds landed since our last edition (b10441 through b10453). None of them, and nothing else we checked, changes what's in the catalog today.
Two ways a bad file used to fail silently
PR #27056 (shipped as b10451, Aug 16) fixes the LoRA case. In the PR's own words: "the LoRA adapter loading path reads tensor data without checking that the tensor offset + size falls within the file bounds. A truncated or corrupted LoRA file is silently loaded with zero-padded weights and no error is reported." The fix mirrors a bounds check that already existed for regular model loading in llama-model-loader.h — LoRA adapters just never inherited it. Now a bad file fails loudly, with "tensor data is not within the file bounds," instead of quietly generating with partially blank weights.
PR #27075 (b10443, Aug 15) is the same class of bug one layer down: "many places forgot to check for GGUF metadata array type before reading it," per the PR description — a GGUF file's metadata array could be read as the wrong type across multiple code paths, risking corrupted metadata or unsafe reads rather than a clean failure. Neither bug is a benchmark story. Both are the unglamorous kind of fix that decides whether a bad download fails at load time or fails three tokens into your first reply.
The one new architecture, and why it changes nothing here
PR #26185 (b10448, Aug 15) adds Kimi-K3 support — Moonshot AI's hybrid linear+full-attention mixture-of-experts model, 2.8T total parameters with roughly 104B active. It needed real engine work: LLAMA_MAX_EXPERTS jumped from 512 to 1024 to fit K3's 896 routed experts, plus lossless MXFP4 weight repacking so conversion doesn't round-trip through bf16. That expert-count ceiling is now permanent infrastructure — any future large-MoE architecture with a similarly high expert count benefits, whether or not it ever ships small enough for a phone. Kimi-K3 itself, obviously, doesn't.
What we checked and skipped
Two model releases landed just ahead of this edition's research window and hadn't been written up here yet: Qwen3.8-27B (Alibaba, Aug 14, Apache 2.0, 27.78B dense — bartowski's Q4_K_M GGUF alone is 17.77 GB, before you've loaded anything else) and LiquidAI LFM2.5-VL-3B (Aug 12–13, ~3.1B, vision-language). The first fails on size before anything else matters. The second fails the same gate we flagged in SLM Daily #11: our engine has no code path that ever hands a model a photo, so a vision-language model — however well it scores — has nowhere to run in privateSLM today. Zero catalog additions. Still 8 Generalists, 14 pre-cap specialists, unchanged.
A coverage gap, stated plainly
Reddit's r/LocalLLaMA and X were unreachable to our research tooling this edition — every fetch attempt came back blocked. If a release or a benchmark surfaced there in the last two days, we didn't see it, and we'd rather say that than imply a clean sweep. No Edge in the Wild spotlight either: one candidate project surfaced (a WiFi-based presence/breathing sensor on an ESP32 and a Pi), but it runs classical signal processing, not a language model — stretching the label to fit felt worse than skipping it.
Our deep-dive this edition looks at a Hugging Face download-stats report that cuts against the entire premise of a "what's new this week" digest: not one model released in 2026 has cracked Hugging Face's own download top 25. Read it here.