One package for working with GGUF models locally: an OpenAI-compatible LLM
server, a diffusion image/video/audio generator and a GGUF metadata/tensor
editor with a built-in quantizer — three panels on one GUI, powered by one
unified engine compiled in a single build on top of gk, an independent
tensor library. There is no ggml anywhere in the tree.
Install
pip install ggk
The build compiles the bundled engine (CPU by default, Metal on macOS).
GPU backends are opt-in at install time:
add --diffusion-fa tag (turn on flash attention for diffusion model) to diffuser engine will get significantly faster process
*gk is our own experimental kernel, recently support multiGPU tensor split,
new features are coming very soon, please see reference for details
Layout
vendor/engine/ the unified ggk engine (one CMake build)
gk/ the gk compute kernels (CPU + optional GPU backends)
gk/compat/ the historical ggml C API, implemented on gk
src/ common/ mtmd/ GGUF LLM runtime
app/ the gguf-server HTTP server
diffusion/ diffusion runtime + CLI
quantizer/ quantizer shared library (its own quant kernels)
src/ggk/ the Python package
server/ diffuser/ editor/ the three panels (backend + web frontend each)
gui.py static/ the unified 3-panel GUI shell
Nothing above gk/compat/ knows gk exists: the runtimes include the same
ggml.h / ggml-backend.h / gguf.h headers and call the same functions
they always did, while graph building, allocation, scheduling and the kernels
themselves are gk's. See vendor/engine/README.md for the engine's own build
options.
The editor's quantizer stays independent — its qz_* codec is compiled both
into the quantizer library the editor drives and into gk itself, so the
encoder and the runtimes' decoder can never disagree about a GGUF block.