Introduces the custom little-endian SLM1 file, section ordering, versioning, supported dtypes, tokenizer choices, tied-output flag, and admission stages.
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.
Section order
- Fixed v1 header.
- Tokenizer section:
BTOKorBPE1. - Tensor directory containing 64-byte entries.
- 64-byte-aligned tensor data and quantization scales.
Format identity
The active implementation is a custom .slm format. It is not GGUF, ONNX, Safetensors, or a standard named SLM format. Compatibility exists only with this parser/writer version.
Supported tensor storage
- dtype 1: little-endian f32 values.
- dtype 2: q8_0 signed bytes with one f32 scale per row.
- dtype 3: q4_0 packed signed nibbles with per-block f32 scales.
Admission stages
Runtime parsing checks structural safety. The native packer validator adds tensor-contract and tokenizer checks. Provenance validation and quality gating are separate layers; passing parser admission does not establish trained quality.
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?