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 |
|---|---|---|---|
|
|
Text |
Rolling out |
|
|
Text |
Rolling out |
|
|
Text |
Rolling out |
|
|
Text |
Rolling out |
|
|
Text |
Rolling out |
|
|
Text (mixture of experts) |
Rolling out |
|
|
Text (mixture of experts, FP8) |
Rolling out |
|
|
Image |
Rolling out |
|
|
Image |
Rolling out |
|
|
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,NOTICEandUSE_POLICYfiles, or the standard license text for a base that only declares its license, with any attribution the license requires appended toNOTICE;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 |
|
|---|---|---|---|---|
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 toNOTICEand copies the base’sLICENSEandUSE_POLICYfiles. The base repository is gated on Hugging Face;kllm verifyagainst it requires accepting Meta’s license and settingHF_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
Model keys for how to apply for the key of a catalog model.
Model library and naming for model references and the local store.
Attacks for what locking does and does not protect.
kllm verify and kllm cloud in the command-line reference.