Technical overview: how Lizard Native keeps Direct3D 12 inference resident

[lizardadmin]

Lizard Native is Lizard's stable, Windows-first native provider. For a supported model, it uploads quantized tensors to GPU-resident buffers and executes decode through Direct3D 12 compute shaders. The model-fit decision happens before execution and uses the exact GGUF identity plus the machine's available memory.

The layers

1. Hardware and model-fit planning — CPU, memory, Direct3D 12 capabilities, model family, quantization, and live budget are evaluated before a native lane is selected.
2. Resident model tensors — supported quantized weights stay in device buffers while the model is active instead of being reloaded for every request.
3. Compute shaders — quantized operations run through Direct3D 12 compute; compiled shader artifacts are cached on disk.
4. Memory discipline — residency is budgeted, and compatible UMA hardware can use a shared-memory path.
5. Provider identity — a native row stays labeled Lizard Native. A llama.cpp or Ollama fallback is not reported as native.

The boundary matters

Lizard Native implements a tested native subset; it does not claim that every GGUF architecture and quantization runs on this provider. Unsupported combinations stay eligible for an explicit bundled llama.cpp or optional Ollama fallback.

Read the complete layer map and comparison: https://lizard-llm.qendryx.com/technical-overview.html

Question: On your Windows hardware, is the limiting factor available memory, shader execution, model coverage, or per-token scheduling?