Compatibility is a chain of independent checks. A single badge cannot safely collapse file structure, architecture, tokenizer, tensor storage, kernels, memory, operating system, framework, backend probing, execution, and application evidence.
Compatibility checks
| Check | Evidence required | Failure meaning |
|---|---|---|
| GGUF container validity | Bounded parser or strict-validator result. | The container cannot proceed through the reviewed parser path. |
| Model architecture | Architecture metadata plus a matching model loader. | A valid GGUF can still be an unsupported architecture. |
| Tokenizer metadata | Required tokenizer fields and matching implementation. | Prompt/token conversion cannot be assumed. |
| Tensor storage type | All required tensor types and block geometries recognized. | A model graph may be known while storage remains unsupported. |
| Kernel coverage | Executed operators have available implementations. | Registration or declaration alone is insufficient. |
| Memory availability | Measured or conservatively estimated load/context demand. | The host may fail despite format compatibility. |
| Host OS and target framework | A tested build and runtime environment. | Roadmap intent is not platform evidence. |
| Backend package and probe | Package identity, registration, local probe, selection. | Presence does not prove execution. |
| Execution adapter proof | Retained model-load and inference result. | The lane is not proven until work executes. |
| Application test evidence | Host-specific scenario, limits, cancellation, disposal, and error checks. | Package evidence does not certify the application. |
Decision tree
- Does the artifact pass bounded GGUF validation?No → reject and retain diagnostics. Yes → continue.
- Does a reviewed loader recognize the architecture, tokenizer, and tensor storage?No → report the exact unsupported boundary. Yes → continue.
- Can the host satisfy path, memory, framework, and operating-system constraints?No → do not attempt load. Yes → continue.
- Has the chosen backend completed local probing and selection?No → label it registered or declared only. Yes → continue.
- Did model loading and bounded inference execute on the selected path?No → record failure state. Yes → retain path-specific evidence.
- Did the host scenario pass its own tests?Only then describe that exact tested scenario as evidence available.
Never display one universal “Compatible” result unless every required application check has retained evidence. Use precise states such as container valid, loader recognized, probe complete, selected, loaded, executed, and application-tested.
Operational boundary
What this page covers: The independent checks required before a host-specific compatibility statement.
Available now: The public runtime exposes GGUF parsing, verified intake, explicit backend contracts, and managed CPU execution paths.
Host responsibility: Define the application’s required architecture, tokenizer, storage, kernel, memory, OS, backend, and test evidence.
Not claimed: Universal GGUF compatibility, universal LLaMA-family compatibility, tested platform parity, or GPU execution from package installation alone.
Canonical sources: Runtime capabilities · GGUF package guide · Evidence and benchmarks
Last reviewed UTC: