The catalog of official sealed models

Note

Part of the upcoming 0.2 line. The catalog is defined in tools/catalog/ on the main branch. Its artifacts are rolling out in the ANetResearch organization on Hugging Face; no catalog model has been confirmed as published yet.

The catalog is the list of public models that the kLLM team seals ahead of time and publishes, so that users can download and run them without running kllm seal themselves. Each catalog model is sealed under its own key, which approved applicants receive as a model key. Every published model can be checked: a holder of its key can rebuild it from the public base with the open-source sealing code and compare the result tensor by tensor.

Models

Catalog models are named after their base, with the suffix -kllm. Every entry pins the base to a revision of its Hugging Face repository and is sealed under perm, so every sealed weight of a language model is a bit-exact rearrangement of an original one; the image models also rotate their latent interfaces into a key-derived orthogonal basis for client-keyed serving. The language models can be served with the key or client-keyed; the image models are sealed for client-keyed serving only.

Catalog name

Base

Modality

Status

Qwen3-8B-kllm

Qwen/Qwen3-8B

Text

Rolling out

Qwen3-4B-Instruct-2507-kllm

Qwen/Qwen3-4B-Instruct-2507

Text

Rolling out

Qwen3-32B-kllm

Qwen/Qwen3-32B

Text

Rolling out

Qwen2.5-7B-Instruct-kllm

Qwen/Qwen2.5-7B-Instruct

Text

Rolling out

Llama-3.1-8B-Instruct-kllm

meta-llama/Llama-3.1-8B-Instruct

Text

Rolling out

Qwen3-30B-A3B-Instruct-2507-kllm

Qwen/Qwen3-30B-A3B-Instruct-2507

Text (mixture of experts)

Rolling out

Qwen3-30B-A3B-Instruct-2507-FP8-kllm

Qwen/Qwen3-30B-A3B-Instruct-2507-FP8

Text (mixture of experts, FP8)

Rolling out

Z-Image-kllm

Tongyi-MAI/Z-Image

Image

Rolling out

Z-Image-Turbo-kllm

Tongyi-MAI/Z-Image-Turbo

Image

Rolling out

MiniMax-H3-FL2VA-kllm

MiniMaxAI/MiniMax-H3 (FL2VA)

Video and audio

Held (Licenses)

The catalog is maintained in tools/catalog/models.json, with the pinned revision, license and transform of each entry; its README.md describes how the team builds the artifacts. Every entry also has an alias in the model library for the 0.2-line commands, for example qwen3:8b-sealed for Qwen3-8B-kllm (Official sealed models).

What a published model contains

A published catalog model is one directory. It is served from that directory with its key, or, after kllm cloud, client-keyed. It contains:

  • the sealed model, with its weights locked: every weight is encrypted in place under a key derived from the model key, so the files keep their names, shapes and dtypes and load in any engine, but compute nothing useful without the key and cannot be matched to the public base (Locked weights);

  • trusted.kllm, the permuted tokenizer encrypted under the model key;

  • the base’s LICENSE, NOTICE and USE_POLICY files, or the standard license text for a base that only declares its license, with any attribution the license requires appended to NOTICE;

  • a model card, README.md, with the key fingerprint and the commands to run and check the model;

  • kllm-manifest.json: the base repository and revision, the license, the modality, the transform, whether the model is prepared for client-keyed serving, the fingerprint and version of the model key, the kLLM version that sealed it, the release period (Release timing) and the SHA-256 digest of every file.

The manifest never contains key material. Its digests show that the files are those that were published; the reproducibility check in Checking a published model shows that they are what the open-source sealing code makes of the public base.

Keys

The kLLM team holds one secret for the catalog, a master key kept offline. The key of each catalog model is derived from it with HKDF-SHA256, under a label that names the base repository and a key version. As a consequence:

  • each catalog model has its own key, and a key issued for one model reveals nothing about the master key or about any other model’s key;

  • raising the key version of an entry rotates the key of that model: the next build is sealed under a new key, and keys issued earlier do not open it;

  • every applicant approved for a model receives the same key for that model, written to a passphrase-protected key file of the ordinary kLLM format.

Key files are issued per model and per applicant through the key-application service (The key-application service). How to apply, and what a model key does and does not provide, is described in Model keys.

Running a catalog model

The model card of each published model lists the commands for that model. For a language model, on a machine trusted with the key:

$ huggingface-cli download ANetResearch/Qwen3-8B-kllm --local-dir Qwen3-8B-kllm
$ kllm serve Qwen3-8B-kllm --key Qwen3-8B-kllm.key

kllm serve --key checks the key’s fingerprint, decrypts the tokenizer, unlocks the weights once into a 0700 cache directory (~/.cache/kllm/unlocked by default, KLLM_UNLOCKED_DIR to override) and serves the unlocked copy (Locked weights). The 0.2-line commands do the same through kllm run; see Quickstart.

For client-keyed serving, where the cloud holds neither the key nor the tokenizer, the user unlocks the cloud’s copy on their own machine and uploads only that copy:

$ kllm cloud Qwen3-8B-kllm -o Qwen3-8B-kllm-cloud --key Qwen3-8B-kllm.key
$ kllm serve Qwen3-8B-kllm-cloud --client                  # in the cloud
$ kllm client proxy Qwen3-8B-kllm --url http://CLOUD:8000 --key Qwen3-8B-kllm.key

For the image models the cloud serves the latent server and the user runs kllm client generate; see Client-keyed mode and Generating images in client-keyed mode.

Important

Wherever a catalog model is unlocked to run, on a server with the key or in the cloud’s copy that kllm cloud writes, its sealed weights are in the clear, and a holder of the public base can match them to it. The cloud in client-keyed mode receives unlocked weights. See Claims.

Checking a published model

The core command kllm verify rebuilds a sealed model from its public base and compares the two. It seals the base again in a temporary directory, under the same key and transform, and compares the result with the published model tensor by tensor (both unlocked), together with the decrypted tokenizer, every other file the seal writes and the manifest:

$ kllm verify Qwen3-8B-kllm --base Qwen/Qwen3-8B --key Qwen3-8B-kllm.key

For a Hugging Face base, the revision defaults to the one recorded in kllm-manifest.json; --revision overrides it, and --subfolder selects the model’s part of a repository. --workdir places the download and the second seal on a volume with enough room for both. Under perm every tensor must be equal to the bit. Tensors that sealing rewrites in floating point, which in the catalog are only the latent interfaces of the client-keyed Z-Image models, may differ by --ulps units in the last place (default 1), the difference that another device or library version can introduce. The command exits with status 0 when everything matches and 1 otherwise.

The check needs the model key, so only a key holder can run it. Because the sealing code is open source (src/kllm/keyed/), a successful check shows that the published files are what that code makes of the public base and nothing else. It is a reproducibility check, not a signature: it does not establish who published the files.

Measured by the kLLM team on one server with an NVIDIA A40, with the base downloaded through a Hugging Face mirror:

Model

Size

Download

Seal and lock

kllm verify

Qwen3-1.7B

4.1 GB

1213 s

36 s

41 s; 311 tensors equal to the bit

Z-Image (client-keyed)

20.5 GB

236 s

102 s

136 s; 1163 tensors equal to the bit

The download time depends on the mirror and dominates the check.

kllm check, a 0.2-line command, is a different check: it re-hashes a model in the local store against the manifest recorded when the model was downloaded or created (kllm check). It needs no key, and it says nothing about how the files relate to the public base.

Licenses

Each catalog model keeps the license of its base, and the published directory carries the base’s license files. A model key grants no rights to a model.

  • Qwen and Z-Image models are licensed under Apache 2.0.

  • Llama 3.1 is licensed under the Llama 3.1 Community License. Redistributed derivatives must have names that start with “Llama”, must display “Built with Llama” and must carry the license. The catalog enforces the naming rule (Llama-3.1-8B-Instruct-kllm), appends the attribution to NOTICE and copies the base’s LICENSE and USE_POLICY files. The base repository is gated on Hugging Face; kllm verify against it requires accepting Meta’s license and setting HF_TOKEN.

  • MiniMax H3 is held. Its community license excludes the European Union, the United Kingdom, the Republic of Korea and the United States, which a public Hugging Face repository, distributed worldwide, cannot honor. The entry stays in the catalog and is not built for publication until MiniMax authorizes it or a gated, territory-limited release is arranged. kLLM itself seals and serves MiniMax H3 pipelines; see Sealing and serving MiniMax H3.

Release timing

Day-zero support for newly released models is a kLLM Enterprise offering: Enterprise customers receive a sealed build of a newly supported model first, and the community release in the catalog follows after a period set per model. The catalog records that period for each entry, and the manifest of a published model carries it. Contact hi@anet0.com for Enterprise terms.

See also