Clarifies that GGUF.MiRust.com currently implements SLM1 rather than GGUF and defines honest routes for future GGUF support or naming.
Implementation evidence: this topic is grounded in the reviewed GGUF.MiRust.com source snapshot. It documents observed code and artifacts without claiming broad deployment, model quality, or production readiness.
Observed fact
No GGUF parser, metadata reader, quantization decoder, or llama.cpp-compatible tensor mapping was found in the active runtime. All local artifacts use SLM1.
Why the distinction matters
GGUF is an established external format with its own metadata, tensor naming, quantization families, tokenizer data, and compatibility ecosystem. A custom extension cannot be presented as GGUF because both contain quantized transformer weights.
Future options
- Add a real GGUF import/conversion tool while keeping SLM1 as the execution container.
- Add direct GGUF loading with exact supported architecture/quantization matrix.
- Clarify that GGUF in the project name denotes the broader project rather than current file compatibility.
Claim rule
Until implemented and tested, model pages must list .slm v1, not GGUF, as the observed format.
Scope
This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.
Engineering considerations
- Identify the source, version, target environment, and owner.
- Separate observed values from estimates and externally reported values.
- Record trade-offs, unsupported cases, and fallback behavior.
- Link performance statements to a compatible benchmark methodology.
Verification questions
- What exact artifact, revision, backend, and environment were reviewed?
- Which assumptions could change the result?
- Which data should be retained so another engineer can reproduce the conclusion?