From GGUF to token stream

1. Own GGUF reader — metadata and tensors are read by Caterpillar's standalone loader.
2. Typed DAG validation — shapes and dependencies are checked before execution.
3. Lifetime-reused activation arena — temporary storage can be reused when tensor lifetimes do not overlap.
4. Precompiled graph plan — repeatable work is represented as a plan instead of rediscovered blindly for every decoded token.
5. Coalesced CPU spans — compatible CPU operations can replay in grouped spans; supported paths can add speculative draft and verification.

Caterpillar does not include llama.cpp, ggml, ik_llama, or Lizard Native source units. The providers can be measured beside each other, but they are not the same implementation.

The engine is actively evolving, so supported native combinations are narrower than the compatibility paths. The landing page names that boundary instead of turning planned coverage into a present-tense claim.

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

Question: Which part should we publish next in more depth: graph validation, activation lifetimes, compiled spans, or speculative verification?