Defines how to add real GGUF support as a distinct parser and model-adapter path while preserving honest SLM1 naming and tests.
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.
Do not alias formats
SLM1 and GGUF have different metadata, tokenizer, tensor naming, quantization, and compatibility contracts. Renaming a file or project label does not create interoperability.
Required components
- Version-bounded GGUF metadata and tensor parser.
- Architecture mapper from supported GGUF model families to the runtime tensor contract.
- Tokenizer import for each supported vocabulary type.
- Quantization kernels or a controlled conversion stage for named GGUF types.
- Malformed-file, overflow, duplicate-key, unsupported-architecture, and tensor-shape tests.
- Exact artifact compatibility records and differential logits against a trusted reference.
API boundary
Use a format-discriminated loader returning a common validated model interface. Preserve SLM1 as its own explicit format rather than silently interpreting it as GGUF.
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?