CogVideoX runs a text-to-video model locally, with code and 2B weights under Apache 2.0
Summary
CogVideoX is the open-source counterpart of the model behind QingYing. Five checkpoints span 720 by 480 to 1360 by 768, memory needs fall from 18GB to 3.6GB with INT8, and the 2B weights share the code's Apache 2.0 licence.
Recommend- Name
- CogVideoX
- Version
- 2
- Pricing
- Free
- Open source
- Open source
- Operating system
- WindowsLinuxmacOS
- Updated
- 2026-10-06 18:37
People who have used Zhipu's QingYing may not know that the model behind it is open source. The official repository says so plainly in the model description: CogVideoX is the open-source version of the video generation model that comes from QingYing. Put another way, the capability people queue for in a browser has a counterpart that can be taken onto a local machine and run.

The two are not the same thing, and the page makes the relation clear near the top: for the larger commercial generation model, go to QingYing and the API platform; what this repository offers is the corresponding open-source release. The commercial one serves large-scale online generation, while the open-source one puts the weights and the code in your hands.
Five checkpoints, and the specs differ
The model table lists everything currently offered: CogVideoX1.5-5B, CogVideoX1.5-5B-I2V, CogVideoX-2B, CogVideoX-5B and CogVideoX-5B-I2V. The I2V suffix means image to video; the rest are text to video. The release rhythm shows how the line evolved: CogVideoX-2B on 6 August 2024, the 5B on 27 August, the open-source image-to-video 5B-I2V on 19 September, and the 1.5 update on 8 November.
The specifications separate the tiers cleanly. CogVideoX-2B outputs 720 by 480 at 8 frames per second for 6 seconds. CogVideoX1.5-5B reaches 1360 by 768 at 16 frames per second, for either 5 or 10 seconds. CogVideoX1.5-5B-I2V has a looser rule: the shorter side takes the smaller of width and height at 768, the longer side sits between 768 and 1360 and must divide by 16, and any resolution inside that range works. From 720 by 480 through 1360 by 768 to the flexible image-to-video ratios, the common output formats are mostly covered.
Memory and speed: will it run on your machine
The official notes give three memory figures, all measured on CogVideoX-2B: SAT with FP16 takes 18GB; under diffusers with FP16 the floor is 4GB; with INT8 quantisation through torchao it presses down to 3.6GB at minimum. The same note warns that INT8 exists to fit smaller cards and slows inference down — it is not free.

On speed, the measured conditions are 50 steps at FP16 or BF16 precision. CogVideoX-5B needs about 180 seconds on a single A100 and about 90 seconds on a single H100. The newer CogVideoX1.5-5B, which has to deliver high-resolution video of 5 or 10 seconds, needs about 550 seconds for a 5-second clip on an H100 under the same conditions: more capable, at the price of a visibly longer wait. The notes add that these tests enabled every optimisation in the diffusers library and were not validated for real memory use on hardware outside A100 and H100; with optimisations off, peak memory runs about three times the tabulated figure.
Two things to settle before starting
The first is the Python version. Both inference paths, SAT and diffusers, state the same requirement: Python between 3.10 and 3.12, with 3.10 and 3.12 included. The repository carries two code bases; SAT holds inference and fine-tuning code for SAT weights, while the diffusers one documents the common parameters in more detail and suits a first run before any modification.

The second is prompt language. The model only accepts English input, so other languages need translating first. The prompt-optimisation section suggests using GLM-4 or a comparable large model to polish the input into the long text the model expects — it was trained on long prompts, and prompt quality feeds straight into the result. The repository puts the prompt length ceiling at 224 to 226 tokens.
Licensing: code and weights are separate questions
The code is released under Apache 2.0, and there is no ambiguity there. The models have to be checked one by one: CogVideoX-2B, including its Transformer and VAE modules, is also Apache 2.0; CogVideoX-5B, meaning the Transformer module including I2V and T2V, carries its own CogVideoX LICENSE. If licensing latitude matters in your case, the 2B tier has the clearer boundary; before committing to 5B, read that licence to the end.
What sits in the repository
The top level is plain: sat and inference hold the two inference code bases, finetune holds fine-tuning, resources stores assets, tools holds utility scripts. Licensing is split across two files, LICENSE for the code and MODEL_LICENSE for the weights. The repository currently stands at 13k stars and 1.3k forks, and the registered version is CogVideoX-1.0.

The past year of updates
The changelog also shows how active the line is. March 2025 brought CogKit, a fine-tuning and inference framework for the CogView4 and CogVideoX families; February added DDIM Inverse support for CogVideoX-5B and CogVideoX1.5-5B; January updated the diffusers-based LoRA fine-tuning code. Further back, the fine-tuning framework released in October 2024 let CogVideoX-5B fine-tune on a single 4090, and the notes add that CogVideoX-2B runs on older cards such as the GTX 1080Ti, while 5B maps to a desktop tier like the RTX 3060.

Who it suits
If you want video generation inside your own workflow without being governed by a service's queue, quota or content policy, CogVideoX offers a controllable local path: open weights, open code, and a memory floor that can be pressed down to 3.6GB. It suits people with a GPU and the patience to work on the environment — Python version, dependencies, quantisation precision and prompt language all have to be checked personally.
Conversely, if you only generate a clip now and then, or would rather not deal with environments and dependencies, an online service is less trouble. Local operation saves you the restrictions and costs you time plus a card that can carry it.
One more thing worth knowing in advance: the model only eats English prompts. A Chinese-speaking user has to solve the step of turning an idea into a long description the model understands, and the quality of that step usually matters more than switching to a bigger checkpoint.
The real value of an open model is not reproducing every capability of an online service. It is moving the generation back onto your own machine. Check first whether the card and the environment can take it, then talk about results.