Runtime & Engine

Veizik is a local AI-video runtime built on the LimML engine. This page describes the engine internals and — just as importantly — draws a hard line between what the public v0.1.0 download does today, what is experimental, and what is not yet public. Every number here is internal: v0.1.0 is a Public Preview and there are no external reproductions yet.

1What v0.1.0 actually ships

We split every capability into three honest buckets. Nothing in the "not yet public" list is present in the download you can install today.

$ veizik doctor
  # standard-library hardware scan + model-family support tiers
  platform        : detected at runtime
  nvidia / cuda   : detected at runtime (report prints with or without a GPU)
  entitlement     : free (server-signed)

  model family        engine path            tier
  ----------------    -------------------    ---------------------
  LTX-Video           native CUDA DiT        internally verified
  HunyuanVideo        native CUDA DiT        internally verified
  Wan 2.1             native CUDA DiT        internally verified
  Step-Video 30B      native CUDA DiT        internally verified
  CogVideoX           native CUDA DiT        internally verified
  FLUX.1-dev          native CUDA DiT        internally verified
  (others)            universal fallback     experimental

2The LimML engine

LimML is the execution layer under Veizik. Its job is to run large open diffusion-transformer (DiT) video and image models on a single consumer GPU with predictable memory behaviour. It combines three pieces: a capacity-compute weight tiering scheduler that keeps only the working set in VRAM, a set of native CUDA DiT kernels for the flagship families, and a universal fallback path for everything else. The value proposition is execution quality and depth of optimization, not secrecy or copy protection.

3Capacity-compute: low-VRAM tiering

A 30B-class video model does not fit weights-resident on a 24 GB card. Capacity-compute treats model weights as a tiered store — hot / warm / cold placement — and streams the layers needed for the current step through the GPU while the rest stay in host memory. Because activations, not the full weight set, dominate the resident footprint, the peak stays well under the card's capacity.

4Native CUDA DiT

The flagship families run on Veizik's own CUDA DiT kernels — N-layer streaming with fp16 tensor-core matmuls — rather than the stock PyTorch module graph. The kernel outputs are compared against the reference implementation at the block and engine level, matching to a relative L2 error on the order of 1e-6 to 1e-7 (numerically indistinguishable, not bit-identical).

5Quantization

The engine uses mixed INT8 quantization: weights are stored in INT8 to cut memory, with mixed-precision compute on the sensitive paths. We evaluated full-INT8 including the residual-projection path and disabled it — its accuracy fell short of the fp16 reference, so it is not enabled in the shipped engine. Quantization is applied where it holds up numerically and left off where it does not.

6Numerical verification methodology

For each supported family we take the reference module's inputs, run both the reference and the native engine path, and compare outputs with a relative L2 error. To date, 6 model-family engine paths have been numerically checked at the block/engine level, each landing on the order of 1e-6 to 1e-7. The table lists the internal block-level figures; read them as "the native block reproduces the reference block", not as end-to-end output equality.

These are block/engine-level checks measured internally. They are not end-to-end generation verifications, and there are no external reproductions yet — v0.1.0 is a Public Preview.

7Benchmark methodology

Render time and throughput are profile-conditional — they depend on resolution, frame count, step count, and model. To avoid publishing numbers that cannot be reproduced under a fixed profile, we are holding them back for v0.1.0.

The only hardware measurement we publish today is peak VRAM. We will publish render-time and throughput figures once they are measured under a fixed, reproducible profile.

8Model adapters

Each supported family has an adapter that maps the reference model's module graph onto the LimML engine — matching layer shapes, attention layout, conditioning, and the diffusion schedule so the native path is a drop-in for that family. Families outside the native set are routed through the universal fallback path, which is experimental in v0.1.0 and depends on your local torch / diffusers environment. We describe the fallback as a compatibility path under active work, not a guarantee for every model.

9ComfyUI integration

ComfyUI integration is an upcoming preview. The intended design is a drop-in that runs existing ComfyUI graphs on the Veizik runtime (run / serve) so the LimML low-VRAM and native-DiT paths apply without rewriting the graph. This is not part of the v0.1.0 public download — it is planned for a later Preview build and will be described as available only once a specific build carries it.

10Support tiers

Where each configuration stands today, stated conservatively. v0.1.0 is a Public Preview with no external reproductions on record, so nothing below is presented as universal.

"Internally verified" means we reproduced it on our own hardware. It is not a claim about every GPU, every model, or every render — those results are still ahead of us.

11Operating entity