vjepa2-vitg-fpc64-256-GGUF

V-JEPA 2 ViT-g/16 (fpc64, 256) — GGUF for jepa.cpp

Meta's V-JEPA 2 ViT-g/16 — the 1.03 B-parameter video encoder, with its masked latent predictor — converted to GGUF for jepa.cpp, a ggml C/C++ engine that runs it on a plain CPU with no Python and no PyTorch. 40 layers of 1408 dims, 22 heads, ffn 1408x48/11 = 6144; tubelets of two frames and 3-D RoPE in Meta's tiled layout, a whole clip through one graph.

1035 M parameters; D = 1408, 40 layers, 22 heads, patch 16, tubelet 2, 256x256. Everything the engine needs — dimensions, positional scheme, preprocessing recipe, and class labels where there are any — travels inside the file, so inference needs one binary and one GGUF and nothing else.

Run it

git clone --recursive https://github.com/aselimc/jepa.cpp && cd jepa.cpp
cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release && cmake --build build -j
hf download jepacpp/vjepa2-vitg-fpc64-256-GGUF vjepa2-vitg-fpc64-256-f16.gguf --local-dir models/gguf

# a clip (THWC uint8 .npy, written by scripts/video_frames.py) -> a pooled feature
build/jepa-embed -m vjepa2-vitg-fpc64-256-f16.gguf --frames-npy clip.npy --pool mean -t 32 -o feat.npy

--pool selects mean, cls, lewm or none (the full token map); -o writes a .npy. scripts/download_models.sh fetches whole sets at once. The C API is one header, include/jepa.h — full reference on the C API page.

Files

_{ᵖ tests/test-parity on the CPU backend, stored reference input, 32 threads, worst sample — docs/parity.md. ᵈ scripts/gguf_dequant_selftest.py: the dequantized weights through the numpy reference graph at f32 activations, so the figure is the weight error alone — docs/quantization.md. cos mean is the mean per-token cosine of last_hidden_state, worst its single worst token.}

Tiers. exact — reproduces the PyTorch reference to the printed precision on the CPU. parity — passes its family's test-parity thresholds. advisory — below 8 bits per weight, which is not a parity configuration: the results are reported, only the derived tensors and the top-1 are gated. Which file to ship: Accuracy → which dtype.

Full checksums:

78499878d5d178ee4d0812b572cb3ed699e2a4bb93429371abe0c3ba359f2477  vjepa2-vitg-fpc64-256-f32.gguf
bf0320a74693e9eeb0520582534df375dbaff035767ffc33b1f30d6bf6ad4f2f  vjepa2-vitg-fpc64-256-f16.gguf
311b5cda94f752ae71f154278721af3429ca5cb7d125084c395da155f4b11443  vjepa2-vitg-fpc64-256-q8_0.gguf
8ac6d79e719de689f743c743e1a0da40284684ee76681c12013328b34d4901c1  vjepa2-vitg-fpc64-256-q4_0.gguf
a8ff401332e950ce3983ee40b46b3323e86f78d5eab1650d22c28541c30c3cf8  vjepa2-vitg-fpc64-256-q4_k.gguf

Verify a download with sha256sum -c. The other types jepa-quantize can produce (q4_1, q5_0, q5_1, q5_k, q6_k, measured in quantization) are not published here; make them locally with build/jepa-quantize vjepa2-vitg-fpc64-256-f16.gguf out.gguf q6_k -t 32.

Measured

Every figure below is read from a committed artifact of jepa.cpp 00bfd4e by scripts/hf_publish.py — parity, quantization, accuracy, performance and tests/results/*.json.

Speed — the encoder graph at f16 on 32 threads (AMD Ryzen Threadripper PRO 7995WX 96-Cores): 2384 ms per 16-frame clip; 16286 ms per 64-frame clip. The same shape on NVIDIA RTX 4500 Ada Generation: 142.8 ms. Peak RSS at f16: 2546 MiB.

The widest and deepest encoder in the set, and the one whose per-token tail is longest: at f16 the worst token of a 2048-token clip reads cosine 0.30 while the median reads 0.99986 and the pooled feature is exact to six digits. Pool it, or use f32 if you consume individual tokens. Its f32 CPU rel_max also sits above a bound calibrated on ViT-L on one of six calibration clips (2.3e-03 against 1e-03) at cosine 0.999975 — accumulated float32 round-off over 40 blocks, measured and explained in parity.

-q4_k.gguf self-reports general.file_type = q4_0, and that is correct. K-quants need ne[0] % 256 == 0, and this model's width is 1408 = 5.5 x 256, so every [*, 1408]-row matrix falls back to q4_0 and only the ffn_down matrices stay q4_K — 158 q4_0 against 52 q4_K. The file-type field is the most common stored type, so the honest majority answer is q4_0. The filename says what was asked for; jepa-info lists the real mix. (The V-JEPA 2-AC bundle, whose predictor is 1024-wide, tips the other way and reports q4_k.)

Source, licence and attribution

Converted from facebook/vjepa2-vitg-fpc64-256.

Apache-2.0, as the source model card facebook/vjepa2-vitg-fpc64-256 states. These GGUF files are the same weights re-serialised into the GGUF container, quantized where the file name says so. Cite the V-JEPA 2 paper.

The licence travels inside every GGUF as general.license and the origin as general.source_url; build/jepa-info <file> --kv prints them. jepa.cpp's own code is MIT.

Conversion

Produced by jepa.cpp 00bfd4e:

scripts/download_models.sh --convert vjepa2-vitg
python scripts/convert.py --family vjepa2 --src models/facebook/vjepa2-vitg-fpc64-256 --ftype f16
#   ... and again with --ftype f32 for the f32 file

for q in q8_0 q4_0 q4_k; do
  build/jepa-quantize models/gguf/vjepa2-vitg-fpc64-256-f16.gguf \
      models/gguf/vjepa2-vitg-fpc64-256-$q.gguf $q -t 32
done

jepa-quantize re-types only the 2-D attention / FFN / projection / classifier matrices; patch embeddings, position tables, norms and biases keep the source type. The rules are in docs/gguf-schema.md.

Links

• Code: https://github.com/aselimc/jepa.cpp
• Documentation: https://aselimc.github.io/jepa.cpp/
• Parity fixtures: https://huggingface.co/datasets/jepacpp/jepa.cpp-fixtures
• All jepa.cpp GGUFs: https://huggingface.co/jepacpp