hdae/karume-wan2.2

Wan2.2 TI2V 5B — Karume

What is this

A text-to-video and image-to-video distribution of Wan2.2 TI2V 5B, converted into the WebGPU inference runtime Karume's container format (a .krm part sequence whose first part carries the graph and model descriptors).

• Seven graphs: text_encoder (the umT5-XXL text encoder in int8, referenced from hdae/karume-umt5-xxl), transformer (the diffusion transformer in int8, on patchified latent tokens), vae_decoder_first / vae_decoder_next (the Wan2.2 video VAE decoder, one latent frame per call, with the causal cache passed in and out) and vae_encoder_pre / vae_encoder_attn / vae_encoder_post (the Wan2.2 video VAE encoder for one conditioning image, split around its middle attention).
• Text to video by default; image to video when generate() is given an image (the first frame — see Usage and Accepted inputs). The image is fitted to the output size, encoded once by the VAE encoder, and at every step the first latent frame of the transformer's input is replaced with it (the diffusers form: the tokens of that frame are marked by the condition mask and take timestep 0). The first output frame is therefore the fitted image after a round trip through the VAE.
• The rest runs on the host in TypeScript: the prompt cleaning and the tokenizer (or, with textEncoder: "precomputed", the lookup of the precomputed embeddings), the relative-position buckets, the patchify and RoPE tables, classifier-free guidance as two batch-1 passes, the flow-matching UniPC scheduler, the tiled VAE decode and the unpatchify of its output, and for image to video the resize, normalization and patchify of the image and the replacement of the first latent frame. The output is [3, frames, height, width] float32 in [-1, 1], at 24 fps.
• Text to video was verified end to end in Deno (Intel Arc B570, Deno 2.9.6) with the f16+dit8 quant in 2-step runs of 17 frames — at 1280 × 704 and 704 × 1280 with the precomputed embeddings, and at 1280 × 704 with the text encoder on the GPU — each pinned by the SHA-256 of its frames; and in full 50-step runs of both quants at 1280 × 704 with 33 frames (see Resources).
• Image to video was verified end to end in Deno on an NVIDIA GeForce RTX 3080 Ti with the precomputed embeddings, in 2-step runs of 9 frames and (opt-in) 50-step runs of 33 frames pinned by the SHA-256 of their frames (see Determinism and verification).
• In a browser, Chrome on an NVIDIA GeForce RTX 5070 Ti finished one 50-step run (the f16+dit8-a8-attn8-s16 quant with the text encoder on the GPU, 1280 × 704, 121 frames) in 40.3 minutes. Shorter text-to-video clips, the f16+dit8 quant and the precomputed embeddings have not been run in a browser yet. Image to video finished there with the same quant and the text encoder on the GPU, from an 896 × 1152 image cropped to 704 × 1280, in 20-step runs with shift 7: 390.0 s for 33 frames and 1,346.5 s for 121 frames. These browser runs were not compared with a reference.
• Not readable by diffusers (it's a different container with an embedded graph); the reader is a pipeline that implements wan-ti2v/1.
• Exporter used for the conversion: karume/0.14.0. The distribution manifest is karume.json (karume/5).

Base weights and attribution

Converted into the container format — the original checkpoint is not distributed here.

• ti2v-5b: Wan-AI/Wan2.2-TI2V-5B-Diffusers at commit b8fff7315c768468a5333511427288870b2e9635, licensed apache-2.0 (as of retrieval; full text — a verbatim copy is in LICENSE.md).
• Authors: Wan2.2 is released by Wan-AI (technical report).
• Changes made here (listed in full in NOTICE.md, per Apache 2.0 §4(b)): conversion into the Karume container format; the transformer shipped only in int8, its linear weights quantized per output channel (biases and normalization weights kept in float32 at the source values); every parameter of the VAE decoder rounded to the nearest float16 value (weight matrices and kernels stored as float16, computation in float32); the transformer graph re-expressed on patchified tokens, with the RoPE tables built on the host from per-axis base tables and applied in a pair-swap form, and with the image-conditioning inputs (a condition mask and a second timestep — in image to video the tokens of the first latent frame are masked in and take timestep 0, in text to video the mask is all false); the VAE decoder re-expressed as two one-frame graphs with an explicit causal cache that return the patchified output for the host to unpatchify, always decoded in overlapping tiles; the part of the VAE encoder that encodes one conditioning image re-expressed as three graphs split around its middle attention, with its parameters rounded to float16 like the decoder's; the tokenizer converted into one table together with lookup tables for the upstream prompt cleaning. No retraining and no fine-tuning.
• The text encoder is not stored here. karume.json references the encoder of google/umt5-xxl (this checkpoint's text_encoder holds the same encoder rounded to bfloat16), converted to int8, at commit c66a8db12e005ba3… of hdae/karume-umt5-xxl (with the size and the SHA-256 of every part); that repository's NOTICE.md lists the changes made to it.
• Precomputed embeddings and tokenizer: the repository also ships the encoder's outputs for a fixed set of prompts (see below), computed in bfloat16 with the umT5-XXL encoder of Wan-AI/Wan2.1-T2V-1.3B-Diffusers at commit 0fad780a534b6463e45facd96134c9f345acfa5b and stored as float32, for use without the text encoder, and the tokenizer table converted from the same commit (its tokenizer files are the same as this checkpoint's).

Models

Model	Pipeline	Quants	Default quant
ti2v-5b (default)	wan-ti2v/1	f16+dit8 / f16+dit8-a8-attn8-s16	f16+dit8-a8-attn8-s16

model selects one of these; omitted, it is ti2v-5b. quant defaults to that model's own default quant.

Usage

import { encodePng, wanFrameToRgba, WanTi2vPipeline } from "jsr:@karume/models";

await using pipeline = await WanTi2vPipeline.fromPretrained({
  repo: "hdae/karume-wan2.2",
  // Pin a commit for reproducible builds — without it you track `main`, and a future
  // repo update (renamed files, new manifest format) may break your app.
  // Copy the full hash from this repo's "Files and versions" tab:
  // revision: "<full commit sha>",
}, {
  // model: "ti2v-5b", // default — available: ti2v-5b
  // quant: "f16+dit8-a8-attn8-s16", // default — available: f16+dit8 / f16+dit8-a8-attn8-s16
  // textEncoder: "gpu", // default — "precomputed" skips the text encoder (see Prompts below)
});

const video = await pipeline.generate({
  prompt: "A cat walks on the grass, realistic style.",
  seed: 42,
  // negativePrompt: "low quality, blurry", // default: the official negative prompt
  // frames: 33, // 4n+1, 5 to 121
  // width: 1280, height: 704, // or 704 × 1280
});

for (let frame = 0; frame < video.frames; frame += 1) {
  const rgba = wanFrameToRgba(video, frame);
  const png = await encodePng(rgba, video.width, video.height);
  await Deno.writeFile(`frame-${String(frame).padStart(2, "0")}.png`, png);
}

generate() opens one stage at a time — the text encoder session is disposed before the transformer session is opened, and the transformer session before the VAE sessions — so no two stages are resident together. Concurrent calls are queued. Weights are fetched once and cached (verified against karume.json's size / sha256). GPU memory and time per clip are listed under Resources below.

For image to video, pass the first frame as image. Decoding the image file is up to the caller: the Deno example in the Karume repository (examples/wan) uses fast-png and jpeg-js, and in a browser createImageBitmap and a canvas work. generate() takes 8-bit RGB, so convert what the decoder gives: a canvas gives RGBA, and so does jpeg-js by default (formatAsRGBA: false gives RGB, as the example uses) — drop the alpha channel.

The bit-for-bit match with Pillow (Accepted inputs) starts from the RGB8 pixels, so the decoding decides whether a file gives the reference's input. The official Wan2.2 code reads the file with Pillow, drops the alpha channel without compositing it over a background, and does not apply the EXIF orientation. createImageBitmap applies the orientation by default, and a canvas can lose precision in partly transparent pixels (it stores premultiplied alpha). For PNG, fast-png gives the same pixels as Pillow; JPEG decoders differ slightly, so jpeg-js and a browser can give pixels a little different from Pillow's for the same JPEG file.

// `rgb`: the decoded image, 3 bytes (R, G, B) per pixel, row by row.
const clip = await pipeline.generate({
  prompt: "A cat walks on the grass, realistic style.",
  image: { data: rgb, width: imageWidth, height: imageHeight },
  seed: 42,
  // fit: "crop", // default — "stretch" resizes without keeping the aspect ratio
  // width / height: omitted — the accepted size closest to the image's aspect ratio
});

With an image, the VAE encoder stage runs first and is disposed before the next stage (the text encoder, or the transformer with the precomputed embeddings) is opened. In Deno, image to video has so far been run only with the precomputed embeddings; with the text encoder on the GPU (the default in this example) it has been run only in Chrome (see What is this).

Prompts

With the text encoder (textEncoder: "gpu", the default), generate() accepts free text. The prompt goes through a port of the upstream prompt cleaning and the umT5 tokenizer on the host, and these are rejected with ModelInputError before anything runs on the GPU, where the upstream pipeline would silently truncate them, repair them or map them to an unknown token instead:

• fewer than 2 or more than 512 tokens (the end token included) — an empty prompt, or one too long;
• characters outside the tokenizer's vocabulary, and special tokens such as </s> written in the text;
• what the cleaning would treat as an HTML character reference (write R & D, not R&D) or as mojibake;
• C1 control characters and code points unassigned in Unicode 16.0.0.

When negativePrompt is omitted, the official negative prompt (the negative row below) is used, and it goes through the text encoder too.

With textEncoder: "precomputed", the text encoder is not fetched: the repository's umT5-XXL outputs of the prompts below are used, and generate() accepts exactly these strings (the original text or its normalized form — pipeline.prompts lists both). Any other string is rejected with ModelInputError. The texts are shown here for reading; pass the strings from pipeline.prompts, since the match is exact (ferret, for one, starts and ends with a line break).

Name	Role	Source
boxing-cats	positive	source
ferret	positive	source
cat-dog-baking	positive	source
negative	negative	source

boxing-cats:

Two anthropomorphic cats in comfy boxing gear and bright gloves fight intensely on a spotlighted stage.

ferret:

The camera rushes from far to near in a low-angle shot,
revealing a white ferret on a log. It plays, leaps into the water, and emerges, as the camera zooms in
for a close-up. Water splashes berry bushes nearby, while moss, snow, and leaves blanket the ground.
Birch trees and a light blue sky frame the scene, with ferns in the foreground. Side lighting casts dynamic
shadows and warm highlights. Medium composition, front view, low angle, with depth of field.

cat-dog-baking:

A cat and a dog baking a cake together in a kitchen. The cat is carefully measuring flour, while the dog is stirring the batter with a wooden spoon. The kitchen is cozy, with sunlight streaming through the window.

negative:

色调艳丽，过曝，静态，细节模糊不清，字幕，风格，作品，画作，画面，静止，整体发灰，最差质量，低质量，JPEG压缩残留，丑陋的，残缺的，多余的手指，画得不好的手部，画得不好的脸部，畸形的，毁容的，形态畸形的肢体，手指融合，静止不动的画面，杂乱的背景，三条腿，背景人很多，倒着走

Accepted inputs

• prompt / negativePrompt: see Prompts above.
• size: 1280 × 704 or 704 × 1280.
• frames: 4n+1 from 5 to 121. Text to video has been checked end to end on the GPU: 17 frames at both sizes in 2-step runs, and 33 frames at 1280 × 704 in 50-step runs. 49 frames at 1280 × 704 ran 50 steps through the same pipeline stages, driven by a development script rather than the pipeline class. 121 frames at 1280 × 704 (the f16+dit8-a8-attn8-s16 quant) ran 50 steps the same way on an NVIDIA GeForce RTX 3080 Ti (12 GiB) in Deno, and in Chrome on an NVIDIA GeForce RTX 5070 Ti. 704 × 1280 has been run only in the 2-step runs at 17 frames. On the RTX 3080 Ti, the memory in use on the whole GPU (read with nvidia-smi) peaked at 11.09 GiB during the transformer stage, about 0.9 GiB below the card's 12 GiB; by the runtime's own count, that stage allocated 10.64 GiB of weights and buffers. The headroom Deno actually has can be thinner, since Deno stops allocating at a ceiling below the card's size that varies over time, and on a 12 GiB GPU shared with other programs 121 frames may not fit (an estimate — not run). On a GPU with about 10 GB, such as the Intel Arc B570 (where Deno can allocate about 9.4 GiB in total), clips up to 57 frames have been checked: the longest 50-step runs there were 49 frames with both quants and 57 frames with the f16+dit8-a8-attn8-s16 quant, driven by the development script (its rows under Resources stop at 49 frames). Longer clips are not supported there, because none of them has been run on the B570. A memory estimate made before the runs covers only two of those lengths and puts both beyond that ceiling: the next length after 77 frames with the f16+dit8-a8-attn8-s16 quant, and 121 frames with both quants (the 10.64 GiB the transformer stage allocated at 121 frames on the RTX 3080 Ti is above it too). The other lengths were not estimated, so whether they fit is not known. The accepted set does not depend on the GPU, so such a request is still accepted, and if it does not fit it fails during the run — with an out-of-memory error (GpuOutOfMemoryError), or a lost device near the limit — rather than with ModelInputError, and the time spent on the stages before it is lost.
• steps ≥ 1, guidance ≥ 1 (1 turns classifier-free guidance off and the negative prompt is then rejected), shift > 0.
• seed (the host noise generator — not torch's randn) or the initial noise as latents.
• image: the first frame for image to video, as decoded RGB8 pixels { data, width, height } (data a Uint8Array with 3 bytes per pixel, row by row; any size), used as given (no color-space conversion). Without width / height, the accepted size closest to the image's aspect ratio is used — 1280 × 704 when the image is at least as wide as it is tall, 704 × 1280 otherwise. A given width and/or height must match one accepted size, and that size is used. The official Wan2.2 code also picks sizes outside this set (1248 × 704 for a 16:9 image), so the same image can lose more to the crop here.
• fit (only with image): "crop" (the default, as in the official Wan2.2 code) scales the image to cover the output size, keeping its aspect ratio, and cuts out the center; "stretch" (as in diffusers' WanImageToVideoPipeline) resizes the width and the height separately. Both resize with a port of Pillow's LANCZOS filter that gives the same bytes as Pillow 12.3.0 for the same RGB8 input. fit without image throws ModelInputError; a value other than these two throws a plain Error (the one exception to the sentence below).

Anything outside these sets throws ModelInputError before any weight reaches the GPU.

Determinism and verification

• Bit-identical runs: the same request (prompt, seed or latents, knobs) produces the same bytes on the same GPU and driver. Release verification pins the SHA-256 of the 8-bit frames per test environment and fails on any change — the check is never relaxed to a tolerance.
• Text to video against the upstream reference (the f16+dit8 quant, with the precomputed embeddings): a 2-step run at 1280 × 704 with 17 frames and injected noise is compared with diffusers on CPU in float32 (the same int8 transformer weights, the same f16-rounded VAE weights and tiled decode), and single transformer forwards of up to 8,190 tokens (1280 × 704 with 33 frames among them) against a float64 reference. Differences stay within tolerances measured on separate decision cases. The f16+dit8-a8-attn8-s16 quant is compared with f16+dit8 on the same GPU: the first step's latent at 1280 × 704 with 33 and 121 frames stays within twice the measured relative error, differs from f16+dit8, and repeats bit for bit. It became the default after a visual check of 12 clips (3 prompts × seeds 42–45, 1280 × 704 with 33 frames, 50 steps) on an NVIDIA GeForce RTX 3080 Ti in Deno on 2026-10-06, and the same 12 clips side by side with f16+dit8 showed no clear degradation on 2026-10-09. On image to video the same first-step check holds at 1280 × 704 with 33 frames (one image, crop, an opt-in case: relative RMS error 0.046, within twice the measured error), and 12 clips (3 images × seeds 42–45, 1280 × 704 with 33 frames, 50 steps) side by side with f16+dit8 showed no clear degradation on 2026-10-10 either.
• Image to video against the upstream reference (the f16+dit8 quant, with the precomputed embeddings, on an NVIDIA GeForce RTX 3080 Ti): the resized image and the encoder input match Pillow and the upstream preprocessing bit for bit. The encoded image is compared with the upstream untiled VAE encode (diffusers on CPU in float32) for three images, each at the two accepted sizes and at a small 256 × 160 size outside them: the largest absolute difference of the normalized latent stays within 7.8e-5, where the latent's values reach about 3 to 4. A 2-step run at 1280 × 704 with 9 frames, injected noise and the same three images is compared with diffusers' WanImageToVideoPipeline on CPU in float32 (the same int8 transformer weights, the same f16-rounded VAE weights and tiled decode). The largest difference, relative to the reference's largest value, stays within 2.9e-3 for the latent after the first step, 3.5e-3 after the second, 3.9e-3 for the latent passed to the VAE and 8.9e-3 for the frames, and the encoded image inside the run stays within the encoder's 7.8e-5. Each tolerance is five times the worst of two deciding images, and the third image is checked against it.
• Why the image-to-video latent tolerances are wider than the text-to-video ones (3.5e-3 against 9.5e-4 after the second step): the difference gathers in the tokens of the conditioning frame. On the image that sets these tolerances, the encoder's output differs from the reference by 1.26e-5 at most (well inside its own tolerance), and the transformer amplifies that about 250 times on those tokens. With the reference's encoded image put in its place, the difference falls back to the text-to-video size, so it does not come from the transformer's own precision.
• Injected faults: five deliberate faults in the conditioning (an all-false condition mask, the mask shifted by one token, the two timestep inputs swapped, the first frame not replaced, the encoded image not normalized) put the latent after the second step 138 to 358 times its tolerance away, and each also fails a direct check of the input it breaks. Five faults in the encoder land 15,000 times its tolerance away or more.
• Pinned image-to-video runs: the same request with the same image and fit repeats bit for bit, and the SHA-256 of the frames is pinned for one image at 1280 × 704 with 9 frames (2 steps) with both quants — the f16+dit8-a8-attn8-s16 result is also required to differ from the f16+dit8 one, so the quant is known to be in use — and, in an opt-in set, for the other two images and for 704 × 1280 with the f16+dit8 quant. In the same opt-in set, 50-step image-to-video runs at 1280 × 704 with 33 frames are pinned with both quants on the NVIDIA GeForce RTX 3080 Ti, the f16+dit8-a8-attn8-s16 result again required to differ from the f16+dit8 one.
• Tiled decode: the VAE always decodes in overlapping tiles, blended in the patchified space before the unpatchify, so the frames differ slightly from the upstream untiled decode.

Resources

The 33- and 49-frame rows were measured on an Intel Arc B570 in Deno 2.9.6 on 2026-10-05, at 1280 × 704 with 50 steps, shift 5 and guidance 5 (classifier-free guidance runs two transformer passes per step, so 100 passes); the 121-frame row at the same size, steps, shift and guidance on an NVIDIA GeForce RTX 3080 Ti (12 GiB) in Deno 2.9.6 on 2026-10-06:

Quant	Frames	Pass	Transformer peak	Transformer stage	VAE decode	Clip
f16+dit8	33	21.8 s	7.86 GiB	2,143 s	439 s	43 min 3 s
f16+dit8	49	not measured	8.45 GiB	3,360 s	647 s	66 min 53 s
f16+dit8-a8-attn8-s16	33	9.9 s	7.84 GiB	960 s	439 s	23 min 19 s
f16+dit8-a8-attn8-s16	49	not measured	8.49 GiB	1,504 s	655 s	36 min 5 s
f16+dit8-a8-attn8-s16	121	not measured	11.09 GiB	3,068 s	710 s	63 min 8 s

Pass is one transformer pass (batch 1, 7,920 tokens) timed on its own on 2026-10-04. For the B570 rows, Transformer peak is the total allocation during the transformer stage (the driver's fdinfo). The stage and the tiled decode of the whole clip are timed within the 50-step run. The 33-frame runs went through WanTi2vPipeline; the 49-frame runs drove the same pipeline stages from a development script instead, whose transformer peak read 0.12 GiB lower than the class's in the one run measured both ways (33 frames). The VAE stage peaked at 4.36 GiB at 33 frames and 4.51 GiB at 49 frames with either quant.

The 121-frame row comes from a different GPU and a different reading, so it is not comparable with the B570 rows: it was driven by the same development script with another prompt (cat-dog-baking, where the B570 rows used boxing-cats) and the text encoder on the GPU (that stage took 9.1 s and is included in Clip); its transformer peak is the memory in use on the whole GPU as read by nvidia-smi, not the driver's fdinfo; and its times include thermal throttling (the GPU reached 93 °C). The 121-frame clip has not been run for 50 steps with the f16+dit8 quant.

The text encoder stage (textEncoder: "gpu") has been measured with this distribution only in the 121-frame run above. In a browser, Chrome on an NVIDIA GeForce RTX 5070 Ti finished the same 121-frame request in 2,417.5 s (40.3 minutes) — a different GPU and runtime from the rows above.

All of the above is text to video. Image to video adds the VAE encoder stage, which runs once before the others and is released before the next stage opens. Run on its own on the RTX 3080 Ti in Deno 2.9.6, the encoder kept the whole process at a peak of 1,421 MiB (nvidia-smi) while encoding images at 1280 × 704, 704 × 1280 and 256 × 160. On the same GPU on 2026-10-09, 50-step image-to-video runs at 1280 × 704 with 33 frames and the precomputed embeddings took 1,395.3 s with f16+dit8 and 723.5 s with f16+dit8-a8-attn8-s16 in all, the encoder stage under 1 s of it; the GPU memory of those runs was not read, so an image-to-video clip's peak has not been measured.

• Quality of f16+dit8-a8-attn8-s16: after the first step its latent differs from f16+dit8's (the same int8 weights, computed in float32) by a relative RMS error of 0.044 at 33 frames and 0.049 at 121 frames. Side by side with f16+dit8 on twelve 50-step clips at 1280 × 704 with 33 frames (seeds 42 to 45 with the three fixed prompts), no clear degradation was seen. Both were measured with text to video; on image to video the first-step error is 0.046 at 33 frames (one image, crop) and twelve 50-step clips (3 images × seeds 42–45) side by side showed no clear degradation either.
• Download: the quant table's Download column includes the text encoder (5.30 GiB from hdae/karume-umt5-xxl); with textEncoder: "precomputed" it is not fetched.
• GPU memory: the B570 rows' peaks are of the total allocation (the driver's fdinfo), and the 121-frame row's is the memory in use on the whole GPU (nvidia-smi). The stages are never resident together, so a clip's peak is the largest stage peak.
• Storage buffer size: at these sizes some of the transformer's intermediate tensors are larger than WebGPU's default maxStorageBufferBindingSize (128 MiB) — the feed-forward activation [S, 14336] in float32 alone is about 433 MiB at 33 frames (S = 7,920), about 626 MiB at 49 frames (S = 11,440) and about 1.46 GiB at 121 frames (S = 27,280); the largest binding at 121 frames is about 1.96 GiB (a block of rows of the self-attention scores). The runtime requests the adapter's own limits, which Deno grants on the B570 and the RTX 3080 Ti; in a browser the environment has to grant the adapter's limits as well. Chrome on the RTX 5070 Ti granted them (bindings of up to 2,147,483,644 bytes) and ran the 121-frame clip above; other browsers and GPUs have not been checked.
• karume.json does not declare these figures: its declared limits cover the resident weights and state, not the intermediate tensors a run allocates.
• Declared limits: every quant declares maxBufferSize ≥ 1,050,148,864 bytes and maxStorageBufferBindingSize ≥ 1,050,148,864 bytes in karume.json — the largest resident weight is the text encoder's int8 vocabulary embedding, held as one buffer. The declaration belongs to the quant, so it applies whether or not the text encoder is used.

Model: ti2v-5b

Quants

Quant	What it is	Download	Weights	Compute
f16+dit8	int8 transformer, f32 compute — Transformer weights stored as int8 (one scale per output channel) and computed in f32; the VAE stays f16.	12.1 GiB (5.30 GiB shared)	vae_encoder_pre = f16 / vae_encoder_attn = f16 / vae_encoder_post = f16 / text_encoder = i8 / transformer = i8 / vae_decoder_first = f16 / vae_decoder_next = f16	—
f16+dit8-a8-attn8-s16 (default)	int8 transformer, int8 activations — The int8 transformer with per-token int8 activations in its linear layers and attention (integer dot products), and attention scores held in f16.	12.1 GiB (5.30 GiB shared)	vae_encoder_pre = f16 / vae_encoder_attn = f16 / vae_encoder_post = f16 / text_encoder = i8 / transformer = i8 / vae_decoder_first = f16 / vae_decoder_next = f16	linearCompute = a8 / attentionCompute = a8 / attentionScoreStorage = f16

If no quant is given, it runs as f16+dit8-a8-attn8-s16 (this model's recommended default). In a quant name, dit is the transformer component. Per-file size and sha256 live in karume.json — verify against that at the fetch layer. Dtype labels use the runtime's storage dtype vocabulary (f16 / i8 / i4 / i2), not the fp16 spelling common elsewhere in the ecosystem. Weights ship as Karume container files (.krm), split into numbered parts; a part is fetched and verified on its own. Some components are fetched from hdae/karume-umt5-xxl at commit c66a8db12e005ba3… — those bytes are identical to this model's own, so they are not stored here a second time.

Defaults

Any of these knobs not passed to generate() is filled in from the manifest:

• steps: 50
• guidance: 5.0
• shift (flow-matching shift): 5.0