Field Notes
Two models, two afternoons, six patches. Here's what the trending page doesn't tell you — and the measured numbers nobody publishes.
A trending list tells you what people are starring. It tells you nothing about whether the thing runs. We picked the two most interesting drops from this week's Hugging Face trending page and put them on real hardware. Both worked. Neither worked the way its documentation said it would.
Every number below was measured on our own machines. None of it is copied from a model card, a paper, or a vendor benchmark — which turns out to be the entire point of this post.
| Model | What it is | Why it matters |
|---|---|---|
| Bonsai-27B | 1-bit / ternary 27B | The story of the week. ~1.6M downloads. There's a demo running it in a browser tab on WebGPU. |
| Inkling | ~950B omni MoE, Apache 2.0 | Thinking Machines' first large open drop. Image + audio + text. |
| Hy3 | ~300B MoE, Apache 2.0 | Hunyuan 3. New frontier-class open weights. |
| Unlimited-OCR / OvisOCR2 | Document OCR | OCR is having a genuine moment — 2.1M downloads on the Baidu one. |
On the papers side, SkillOpt is the one worth your time — it treats agent skills as external trainable state optimised in text space, with zero inference overhead. LongStraw (2M-token RL post-training on a fixed GPU budget) and SEED (self-evolving on-policy distillation) are both worth a skim.
We ran two things: a music-to-dance video model, and a small video-understanding model.
Verdict: works, but it's an overnight tool
Wan-Dancer takes a reference image, a music track and a dance style, and produces dance video. The interesting architectural idea is that it's hierarchical: a global stage plans keyframes against the entire track before rendering anything, then a local stage refines. That's why it holds together past the five-second mark where ordinary image-to-video drifts into mush — it knows where the song is going.
It's genuinely good. Our throwaway validation render used 4 diffusion steps out of a recommended 48 and still produced a coherent human with stable identity, real weight-shifts and a geometrically stable room. That's a strong model.
| Measurement | On a single 96GB workstation GPU |
|---|---|
| Denoise speed | 127.6 s / step |
| Sequence length after patchify | 136,800 tokens |
| Peak VRAM | 73.4 GB |
| Weights on disk | ~86 GB |
| Full-quality render (48 + 24 steps) | ~2.5 hours |
That number is the whole story. The reference implementation targets an eight-GPU node using Ulysses sequence parallelism, and a 136,800-token sequence is exactly why. Run it on one GPU and you lose all of that. It still works — it is simply a batch tool you start before bed, not something you iterate with.
The README demands torch 2.6.0+cu124, flash_attn 2.6.3 and transformers 4.46.2. We nearly wrote the model off, because cu124 wheels have no kernels for current-generation GPUs.
Those pins are fiction. The actual requirements.txt is unpinned, and flash-attn is entirely optional — the code has a clean scaled-dot-product-attention fallback with a graceful try/except. It runs fine on torch 2.11+cu128 with no flash-attn at all. The blocker we spent an hour planning around did not exist.
Two were environment issues. Two were real upstream bugs:
assert world_size == 8 in the demo script — even though the underlying pipeline already defaults to single-GPU mode. A demo-script constraint masquerading as a hardware requirement.init_process_group is only ever called from inside the sequence-parallel path — but three bare dist.get_rank() calls remain outside it. Disable parallelism as the pipeline invites you to, and it crashes.UnboundLocalError that only fires on single-GPU. This one is a lovely Python trap: the parallelism helpers are imported by a function-local from … import inside an if block. That makes Python treat those names as local for the entire function — so a later line that calls one of them unconditionally hits an unbound local. One call site is guarded by short-circuit evaluation; the one 45 lines earlier isn't. It is invisible unless you turn parallelism off.Also worth knowing before you plan a project around it: the model knows five dance styles, and its prompts are short descriptors, not cinematic prose. It produces dancing. You cannot talk it into narrative footage.
Verdict: excellent for clips, unproven for long-form
VideoChat3-4B is a 4-billion-parameter video model that ships fully open — weights, training code, and all three training datasets. It punches well above its size.
| Measurement | On a 24GB laptop GPU |
|---|---|
| VRAM at rest | 8.3 GB |
| VRAM peak during inference | 9.7 GB |
| Answer an 11-second clip | 5.3 s end-to-end |
| Generation throughput | 49.7 tok/s |
| Cold / warm load | 6.7 s / ~1 s |
We checked its answers against extracted frames rather than taking them on faith. It correctly described the subject and — more impressively — correctly identified both scenes and the cut in a two-scene test clip. Temporal reasoning that frame-sampling approaches handle badly.
The standout feature is proactive streaming. Rather than answering once at the end, it emits control tokens as frames arrive — silence, standby, or respond — deciding for itself when it has enough evidence. Ask it to tell you when something appears and it stays quiet, then fires in exactly the round containing the event. It runs faster than real time.
The model card describes FlashAttention 2 as optional. For video, that is false. The bundled fallback path materialises a dense attention mask across the entire packed frame sequence — a 48 GB allocation on an eleven-second clip.
We worked around it with a segment-wise variable-length attention shim (mathematically identical, since frames are independent). But "optional" set an expectation that a 48GB allocation comfortably violates.
Two more traps worth flagging, because they fail quietly: the proactive mode's shipped defaults sample from the distribution and run at a low pixel budget, which together cause it to emit a single character and stop — you get "A" instead of a description, with no error. It needs greedy decoding and a higher resolution together. And the vision tower ignores the attention-implementation argument you pass it, reading a hardcoded value off the config instead.
Six patches across two models, and the pattern is identical in both: the documentation described a configuration nobody on the project had recently tested.
Wan-Dancer's pins pointed at a CUDA version that would fail on current hardware — while the real dependency list was unpinned and fine. VideoChat3 called a dependency optional when omitting it triggers a 48GB allocation. In both cases the single-GPU or fallback path was the untested one, because the authors ran the multi-GPU, fully-accelerated configuration.
None of this makes them bad releases. Both models are strong, both are Apache 2.0, and both did what they promised once running. But it does mean the useful question is never "what does the card claim" — it's what happens on your hardware, in your configuration.
Which is why we keep a diary of measured numbers, and treat anything unverified as a rumour until it runs on our own iron. Vendor throughput figures are almost always from different silicon, a different server and a different context length. They are not lies. They are just not about you.
The genuinely exciting thing on this week's list is the one we haven't run yet: a 27-billion-parameter model quantised to roughly seven gigabytes, coherent enough to run in a browser tab. If that holds up under real testing, the floor for what small hardware can host moves substantially. That's the next one on the bench.
ScrappyLabs builds and operates AI infrastructure. Everything above was measured on our own hardware.
Bring your own AI. We keep the receipts.