Z-Image · Image · DiT pipeline
Z-Image
Text-to-image pipeline served in client-keyed mode; results are encrypted to the requester.
Commands
Pull, seal and run
kllm pull downloads a library tag into the local store and records the hash of every file. Sealing and serving this pipeline use kllm seal and kllm serve.
# Download the library tag into the local store; a manifest records each file's hash
$ kllm pull z-image:6b
# Print the local path and metadata
$ kllm show z-image:6b
Requests to the running server
# No plain HTTP example: each request carries token ids under the key's
# vocabulary permutation and a one-off X25519 public key, and each reply
# is ciphertext. Use kllm client generate or the Python client.
Official sealed models
Pre-sealed under model keys
The kLLM team seals selected public models at a pinned revision under the perm transform, locks the weights and publishes them under ANetResearch on Hugging Face. Each model has its own model key, issued to approved applicants. The artifacts are rolling out; a repository is available once it appears in the organization.
| Repository | Base and revision | Modality | Licence | Transform | Client-keyed | Status |
|---|---|---|---|---|---|---|
| Z-Image-kllm | Tongyi-MAI/Z-Image@04cc4abb7c | Text to image | Apache-2.0 | perm | Yes | Rolling out |
| Z-Image-Turbo-kllm | Tongyi-MAI/Z-Image-Turbo@f332072aa7 | Text to image | Apache-2.0 | perm | Yes | Rolling out |
- Each repository carries kllm-manifest.json: the base and its revision, the key fingerprint and key version, the kLLM version and the SHA-256 digest of every file.
Check a published model against its public base
With the model key, kllm verify seals the public base again under the same key and transform in a temporary directory and compares the result tensor by tensor, unlocked, together with the tokenizer, every other file and the manifest.
$ hf download ANetResearch/Z-Image-kllm --local-dir Z-Image-kllm
$ kllm verify Z-Image-kllm --base Tongyi-MAI/Z-Image --revision 04cc4abb7c5069926f75c9bfde9ef43d49423021 --key Z-Image-kllm.key
Library tags
Tags
Each tag pins an upstream Hugging Face revision, so the same alias downloads the same bytes on every host. Sizes and minimum GPU memory are taken from the kLLM library.
| Alias | Upstream | Size | Min. GPU memory | Transforms | Copy |
|---|---|---|---|---|---|
| z-image:6bdefault | Tongyi-MAI/Z-Image | 21 GB | 25 GB | orth, perm |
Validated variants
Measured variants
Variants that the team has sealed and served, with their measured engines and hardware.
| Variant | Transforms | Engines | GPU | Sealing time | Input and output |
|---|---|---|---|---|---|
| Z-Image (client-keyed) | orth (measured), perm | kLLM latent server (diffusers), not SGLang or vLLM | One A40 48 GB (cloud side) | 57 s for the 20 GB pipeline | Text in, image out |
Measured results
Plain against sealed
Published measurements for this model, each with its conditions. Single runs; they do not generalize beyond the configurations shown.
Client-keyed Z-Image (orth) against the plain diffusers pipeline
1024x1024, 28 steps, guidance 4; three prompts x two seeds from the same noise; one A40 (benchmarks/zimage_client.py). The noise-floor row runs plain DiT attention on PyTorch's math kernel.
| Run | Latent rel. error | PSNR | End to end |
|---|---|---|---|
| Plain pipeline | - | - | 48.4 s |
| Plain, math attention kernel (noise floor) | 7.2% | 33.9 dB | - |
| --client (cloud, then VAE on the same GPU) | 11.5% | 31.6 dB | 48.1 s |
The encrypted reply carries 1 MB of float32 latents for 1024x1024. The user-side VAE (160 MB) decodes them in 0.27 s on an A40 and 3.1 s on an Apple M3 with 16 GB (MPS, fp16).
Security
What sealing does not hide for this model
- In client-keyed mode, latents in GPU memory show the image (a principal component analysis recovers a thumbnail without the key); the response is encrypted to a one-off X25519 key. Only five DiT tensors are re-based, so the DiT's activations are not hidden.
- The sealed weights derive from a public checkpoint. Locked files cannot be matched to it without the key; once unlocked to run, a holder of that checkpoint recovers the transforms and 98.5% of the vocabulary permutation (measured on Qwen3-8B), for unmodified public models and fine-tunes alike.
- Client-keyed mode keeps the key and the tokenizer on the user's machine. The copy that the cloud serves is unlocked on the user's side (kllm cloud --key), because the cloud computes with the weights. The cloud server (kllm serve --client) binds 0.0.0.0 by default and has no authentication; bind it to 127.0.0.1 or place it behind a gateway.
- Unless sealed with --no-lock, the weights on disk are locked: encrypted in place with AES-256-CTR under a key derived from the model key. kllm serve --key unlocks them into ~/.cache/kllm/unlocked (KLLM_UNLOCKED_DIR, mode 0700) before the engine starts, so whoever runs the model holds the unlocked weights. Each tensor's largest binary exponent is stored in the clear.
- Every approved holder of an official model's key holds the same model key, and the team derives it from an offline master key. A model key is not a confidentiality boundary between its holders; for a key known to no one else, seal the model under a private key.
- Outside a confidential VM, kllm serve --key decrypts the tokenizer into host /dev/shm and offers no protection from the host. It is a development mode.