Features and abilities

A LoRA is merged into the model's weights on the CPU before they are uploaded to the chip, so the device runs ordinary Stable Diffusion with different numbers in it. The merge takes under a second and nothing is added per frame: 2.3 s per frame warm, with or without a LoRA.

$ python examples/generate.py --prompt "storybook anime illustration, a moonlit crypt" \
    --lora "neonforestmist/sd15-storybook-anime-lora:storybook_anime_lora.safetensors@0.85"

Stack LoRAs by repeating --lora; their deltas add. The file header is read before any model loads, and the run stops with a reason for an SDXL LoRA, a LoHa or LoKr file, a DoRA file, or a file without kohya lora_down / lora_up weights. The header's most common training tags are printed as trigger-word hints.

Crypt, seed 666, top to bottom: no LoRA, pixel art, storybook anime at 0.85, both stacked.

A full clip: the suspension bridge at Iguazu Falls

The contact sheet shows three frames per clip. These are the complete 16-frame clips, a pair for each of two seeds, without a LoRA and with the pixel art LoRA. Prompt: the suspension bridge at iguazu falls, with Pixel Art, in front for the LoRA column. 25 steps, 512×512, guidance 7.5.

The bridge is clear in seed 11 in both columns. Seed 33 drew the falls without a clear bridge, with or without the LoRA. Motion is slight, as with every clip from the default path. Made on 2026-10-14 through the v0.13.1 container image on one chip; each GIF is 2.5–3.9 MB and is the server's output, which was not re-encoded.

--lcm-lora merges latent-consistency/lcm-lora-sdv1-5 and samples with the LCM scheduler: 4 steps at guidance 1.5 instead of 25 steps at 7.5. It stacks with style LoRAs.

The operator defines a catalog of named variants in ANIMATEDIFF_LORAS. Each variant is a full model set kept on the chip, so a request picks one at no cost. Variants share one VAE. A request names a variant and never a repo id or a path.

tt-model serve has no option for the catalog. It forwards only HF_TOKEN from the host, so the catalog is part of the package. tt_model_package.yaml ships two serve profiles from one image: full (the default), with the pixel, pixel-fast and lcm catalog and the motion adapter, and plain, with neither.

$ tt-model serve episod/tt-animatediff-container-v5.1                    # full
$ tt-model serve episod/tt-animatediff-container-v5.1 --profile plain

A different catalog means a repackage, because the values are part of the published manifest. full downloads the LoRA files and the adapter at startup and keeps three more UNets on the chip.

$ curl -s localhost:8000/v1/videos/generations -H 'content-type: application/json' \
    -d '{"prompt": "a moonlit crypt", "lora": "pixel-fast", "num_frames": 8}'

• GET /v1/models lists the names under loras. An unknown name is a 400 that lists the valid ones.
• A variant that includes the LCM-LoRA samples with LCM and defaults to 4 steps and guidance 1.5 when the request leaves them out. Values you send are used as sent, up to 50 steps: more is a 400, because the LoRA was distilled on a 50-step schedule.
• The published LCM-LoRA is recognised by its repo id. Mark a local copy with #lcm after the scale, for example "/data/loras/my-lcm.safetensors@0.8#lcm"; without it the variant samples with PNDM at 25 steps.
• A bad catalog or incompatible file stops the server at startup, before it reports ready.
• LoRA files come from the Hugging Face cache or the network at startup, so a container with no network access needs them cached first.

GET /v1/videos/preview reports the generation in flight: {"step": n, "total": N, "gif_b64": "…"|null, "running": bool, "request_id": str|null}. It never waits on the device, so it answers while a generation runs (about 140 ms measured). The step counter always runs. The 256×256 GIF is rendered only when the request sets "preview": true, because each render costs about 0.4 s: 8 frames at 20 steps took 13.5–13.9 s without previews and 17.8–20.2 s with them. "preview_every": n renders every nth step.

A request can save its final latents under a name ("chain_save": "lh"). A later request that sets "chain_from": "lh" blends them into its starting noise at chain_alpha (default 0.6), so the new prompt inherits the old composition. The names belong to the server: it stores them in its own directory under a hash of the name, keeps the newest 32, and forgets them when it stops. An unknown chain_from is a 400.

The plain model samples with PNDM. "sampler": "euler" uses an Euler schedule on the same weights (the CLI's --lightning; no distilled weights are involved). 4 frames at 25 steps took 7.7 s with Euler and 7.9 s with PNDM, and the pictures differ. An LCM variant always samples with LCM, so naming a sampler with one is a 400.

The MotionAdapter's temporal attention can be injected into the UNet blocks. The operator enables it with ANIMATEDIFF_MOTION_ADAPTER=default (or a repo id or path) in the package's serve.env or a serve profile, which loads the adapter at startup; GET /v1/models then reports "motion_adapter": true. Requests set "motion_adapter": true, with motion_adapter_alpha (0 to 1) and motion_adapter_skip (any of down0 down1 down2 mid up0 up1 up2). It works with the Euler sampler, prompt schedules, chaining and style LoRA variants, and not with an LCM variant.

POST /v1/videos/generations. The response is {"created": ts, "data": [{"b64_json": "<GIF>"}]}.