clip-vit-h-14-laion2b-s32b-b79k.safetensors: what this file is and where to get it
You probably arrived here for one of two reasons. A Stable Diffusion or ComfyUI workflow told you a file named clip-vit-h-14-laion2b-s32b-b79k.safetensors is missing, or you are evaluating CLIP checkpoints for image-text search. Both answered below, in that order.
The file, decoded
The name packs the full training recipe. CLIP is the model family (OpenAI’s contrastive image-text architecture from 2021). ViT-H/14 is the vision tower: a Huge Vision Transformer with 14-pixel patches. laion2B means it was trained by the LAION community using OpenCLIP on the 2-billion-image English subset of LAION-5B. s32B is 32 billion training samples seen; b79K is the batch size, 79,000.
The official repository is laion/CLIP-ViT-H-14-laion2B-s32B-b79K on Hugging Face. It ships two weight files, and picking the wrong one is the usual failure:
model.safetensors: Hugging Face transformers formatopen_clip_model.safetensors: single-file OpenCLIP format, which is what ComfyUI-style workflows typically expect as a “CLIP vision” model
Download whichever your tool asks for, rename only if the workflow insists on the exact filename, and put it in the directory your tool documents (for ComfyUI, usually models/clip_vision/).
Why does image generation tooling want a retrieval model? Stable Diffusion 2.0 and 2.1 use OpenCLIP ViT-H as their frozen text encoder, per the SD 2.x model cards, and various image-conditioning workflows use the same family’s image tower to encode reference images. The checkpoint got bundled into enough community workflows that its filename now out-searches the model itself. That is the whole mystery.
Spec sheet
| Spec | ViT-H/14 laion2B | ViT-B/32 laion2B | openai ViT-L/14 | openai ViT-B/32 |
|---|---|---|---|---|
| Embedding dims | 1,024 | 512 | 768 | 512 |
| Parameters | 986M | 151M | 428M | ~151M* |
| Max text length | 77 tokens | 77 | 77 | 77 |
| ImageNet zero-shot | 78.0% | 66.6% | n/a on card | n/a on card |
| License | MIT | MIT | not specified | not specified |
| Released | Sep 2022 | Sep 2022 | Jan 2021 | Jan 2021 |
*Not stated on the OpenAI card; inferred from the identical ViT-B/32 architecture.
Two rows deserve attention. The 77-token text limit is architectural and applies to every CLIP variant; long captions get truncated, which is why CLIP-family models make poor text-to-text retrievers. And the OpenAI checkpoints carry no license tag on Hugging Face, with model cards that scope them to research use. The LAION checkpoints are MIT. For commercial deployment that difference decides it.
As an embedding model: the numbers
We serve and benchmark all four checkpoints. On Flickr30k image-to-text retrieval (NDCG@10, measured on an L4, published on each catalog page):
| Model | NDCG@10 | Cost $/1M tokens |
|---|---|---|
| ViT-H/14 laion2B | 0.862 | $0.508 |
| openai ViT-L/14 | 0.782 | $0.227 |
| ViT-B/32 laion2B | 0.774 | $0.218 |
| openai ViT-B/32 | 0.717 | $0.232 |
The LAION ViT-H wins on quality, at roughly 2.3x the serving cost of the small checkpoints. The 2021 OpenAI ViT-B/32 loses to its LAION twin at the same price; four years of better training data did that.
Before you standardize on any of them: google/siglip-so400m-patch14-384 scores 0.900 on the same benchmark at $0.493 per million tokens, less than the CLIP ViT-H. We think SigLIP is the better default for new image-text search builds, and we wrote up the comparison in the SigLIP reference. CLIP ViT-H remains the right answer when a workflow or an existing index requires this exact checkpoint.
Serving any of these through SIE is the same /encode call as a text model; images go in, 1,024-dim vectors come out, batched across callers. Details in the encode docs.