Records XorShift64 seeding, generation-local versus continuation RNG state, and the exact conditions required for reproducible token sequences.
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.
Generator
The runtime uses a project-owned XorShift64 generator. A zero seed is normalized by the constructor to avoid the all-zero absorbing state.
Full generation
run_generation creates a fresh RNG from the configured seed for every prompt, so identical accepted model bytes, prompt tokens, configuration, and floating-point execution should replay the same sequence.
Single-token continuation
generate_next_token uses the runtime-owned RNG and advances it across calls.
Limits
Reproducibility is not guaranteed across changed source revisions, compilers, math implementations, architectures, quantized artifacts, tokenizer bytes, or floating-point semantics. The seed is one field in a reproduction record, not a complete proof.
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?