Pre-trained model from HuggingFace cannot be loaded: incompatible RVF format

[dolle-ship-it]

We downloaded the pre-trained model from HuggingFace (ruvnet/wifi-densepose-pretrained) and tried to load it via the –model flag when starting the sensing server. The server immediately reports an error and falls back to signal heuristics without loading the model.

The error message is: Progressive loader init failed: invalid magic at offset 0: expected 0x52564653, got 0x77455735

The downloaded model files include model-q4.bin, model-q8.bin, model-q2.bin, model.rvf.jsonl and model.safetensors. None of them load successfully. The server expects binary RVF format with magic bytes 0x52564653 (RVFS) but all downloaded files have a different format.

Without a working model the server falls back to pure signal heuristics only, which gives very inaccurate results — we see up to 10 persons reported when only one person is actually present, and the UI shows a single flickering blob instead of proper pose estimation.

It would be helpful to either provide a correctly formatted binary RVF file on HuggingFace, or document how to convert the existing model files to the expected format.

[ruvnet]

The magic byte mismatch tells the story:

• Expected: 0x52564653 = ASCII RVFS (RuView Format Signature — the packed binary container)
• Got: 0x77455735 — this is the raw header of a HuggingFace safetensors file, not an RVF container

The progressive loader expects a single packed .rvf binary. The HuggingFace repo distributes both the source files (model.safetensors, model.rvf.jsonl) and the packed binary. You likely downloaded the safetensors source file and the server is trying to open it as an RVF container.

Fix: Download model.rvf (the packed binary, not model.safetensors) from the release assets. If the packed binary isn't present in the HuggingFace repo, the model.rvf.jsonl manifest + model.safetensors weights need to be converted to the packed format using the wifi-densepose-nn conversion tool before the server can load them.

---

Generated by Claude Code

[ruvnet]

Half fixed, half still open — keeping this open to track the remaining half.

Fixed (PR #907, merged): the "up to 10 persons reported when 1 present" heuristic over-count. field_bridge returned the eigenvalue-based occupancy estimate unbounded (internal ceiling 10) while its sibling estimators on the same single-link data cap at 3 — so noisy/under-calibrated CSI inflated it. Now bounded to the single-link max (3).

Still open — the actual model-load failure you reported: the HF model ships model.safetensors + model.rvf.jsonl + quantized .bin, none of which match the sensing-server's binary RVF loader (expected 0x52564653 RVFS). The fix is either (a) add JSONL-RVF / safetensors support to the loader, or (b) republish the model in binary RVF format — a separate, deeper change. Leaving this issue open for that.

(Separately: if you were on a display-less board, the heuristic fallback was also degraded by #893 yield=0pps — now fixed.)

[ruvnet]

Full diagnosis — I pulled the actual artifacts and reverse-engineered the layout. The model is complete and valid; this is purely a loader format-gap, not a corrupt download.

What the HF bundle actually is (ruvnet/wifi-densepose-pretrained):

• model.rvf.jsonl (691 B) — a manifest, not weights: 5 JSON lines —
  • metadata: name wifi-densepose-csi-embedding, v1.0.0, architecture csi-encoder-8-64-128
  • encoder: w1_shape [8,64], w2_shape [64,128] (a 2-layer MLP: 8 CSI features → 64 → 128-dim embedding)
  • lora: rank 8, alpha 16, dropout 0.05, targets [encoder, task_heads]
  • ewc stats, quantization (q2/q4/q8)
• model.safetensors (48 KB) — the actual weights, flattened: encoder.w1 [512] (=8×64), encoder.b1, encoder.w2, lora.A [128,8], lora.B [8,128], lora.scaling [1], …
• The Rust --model loader (rvf_container::RvfReader) expects a single binary RVF with RVFS magic + weight segments inline. None of the HF files are that → invalid magic.

The two clean fixes (both tractable — the model is tiny + well-structured):

1. Converter (lowest risk): a small tool that reads model.safetensors + model.rvf.jsonl, reshapes per the manifest, and writes a binary .rvf via the existing RvfBuilder — reuses the proven binary-RVF inference path unchanged. Users (or a huggingface-cli download + convert step) run it once.
2. Native loader: teach the --model path to detect safetensors (8-byte header-len + JSON) / JSONL-manifest and load directly (e.g. via the safetensors crate), reshaping encoder.w1 [512] → [8,64] etc.

Recommending (1) — it doesn't touch the inference path, so correctness is inherited. This needs an inference-verification step (load the converted RVF, confirm the encoder emits sane 128-dim embeddings) before shipping, so I'm leaving the issue open as a well-scoped task rather than landing an unverified loader. Happy to build the converter in a focused pass with that verification.

[ruvnet]

Correction to my previous comment — I dug into the inference path and the "converter is the clean fix" recommendation was wrong. The real issue is an architecture mismatch, not just a format gap.

The Rust --model consumer (main.rs --embed path, lines ~5739-5764) builds an embedding::EmbeddingExtractor around a graph transformer:

TransformerConfig { n_subcarriers: 56, n_keypoints: 17, d_model, n_heads: 4, n_gnn_layers: 2 }
... extractor.transformer.unflatten_weights(&weights)   // expects transformer weights
... ProjectionHead::unflatten_from(&proj_weights, ...)  // + a projection head

But the HF wifi-densepose-pretrained model is a plain 2-layer MLP (csi-encoder-8-64-128): encoder.w1 [8,64], encoder.b1, encoder.w2 [64,128], lora.A/B/scaling — no attention, no GNN layers, no transformer weights at all (confirmed from the safetensors header). The two architectures are incompatible: converting the bytes to binary RVF would give a file the loader accepts, but transformer.unflatten_weights() would have nothing valid to load → the encoder would emit meaningless embeddings. That's strictly worse than the current honest "invalid magic" failure.

So the real options are:

1. Republish a model in the sensing-server's architecture — export the trained graph-transformer EmbeddingExtractor weights as a binary RVFS RVF (via RvfBuilder::add_weights + add_embedding). This is what --model is actually built to consume. The current HF bundle is from a different (JS/ruvllm MLP) training pipeline.
2. Add an MLP-encoder inference path to the sensing-server that matches csi-encoder-8-64-128, and load the safetensors into it.

Either is an architectural change, not a converter. I'm flagging this so nobody ships the converter thinking it fixes inference. Leaving open with the corrected scope; (1) is the cleaner direction since --model already expects binary-RVF transformer weights — it's a training-side export, verifiable against a known embedding.

[ruvnet]

PR #919 addresses the confusing-failure half of this: instead of the bare invalid magic ... 0x77455735, the server now detects what you actually passed (safetensors / model-q4.bin / .rvf.jsonl) and explains that those HuggingFace files are a different format and encoder architecture than the RVF binary container --model expects — so they don't load directly — and that it's continuing on signal heuristics.

To be transparent about scope: #919 does not make the published HF model loadable. The blocker is real — the HF encoder (an MLP csi-encoder shipped as safetensors + a quantized .bin) is a different architecture than the sensing-server's RVF progressive loader (graph-transformer EmbeddingExtractor). A format-only conversion would load but emit garbage, so it would be worse than failing cleanly. Producing a genuinely loadable RVF requires exporting a matching-architecture encoder from wifi-densepose-train to the RVFS container — tracking that as the remaining work here.

Separately, the "10 persons when 1 present" over-count you saw in heuristic fallback is being addressed in #892 (gate multi-person count on presence) + the merged count cap (#907).