Reverse-engineered Jev-like model | Hacker News Reader

Reverse-engineered Jev-like model

github.com

169 pointsrochansinha24 comments

Any diffusion model is potentially a Jev in disguise: https://github.com/vllm-project/vllm/pull/57250

Runs ~0.2s per decision on my DGX Spark.

  10/10 programming language detection
  9/10 human language detection
  10/12 unit magnitude comparison

All incorrect answers are marked with low-P.

It (DiffusionGemma with the Jev mode) can also solve an ASCII maze.

Your maze demo gave me the idea to try out the "speculative fan-out" pattern [1]. It seemed interesting to try solving mazes in one-shot. Unfortunately it seems like Jev can't reliably solve basic mazes even with a step count of 1! [2] I was very surprised. Could you point me in the direction of your maze solving code so I can see if it's a skill issue? The only other explanation I can come up with is that Jev was not trained on spatial reasoning tasks at all, and on the other hand DiffusionGemma has a vision tower and significantly more spatial data in its training set.

[1] https://docs.typesafe.ai/patterns/fan-out [2] https://github.com/Bud-ro/jev-demos/tree/master/packages/maz...

https://x.com/harshagundal/status/2100044305536889015?s=20

> They were building in stealth for 2 years, I was building in stealth for 2 hours…

> Happy to open source Qwen-2.5-1B-RLCD, 5x faster on-device inference for JSON workloads that need to be type-safe.

No question OSS is amazing, but this video is a satire at best. It doesn't take much attention to see the results on right vs. left side are significantly different.

Jev is not interesting if it's not "smart", a 1B param model is most definitely not smart.

Jev has a 32k context window. I doubt it's a large model.

Taking their spiel at face value, it's intended as a mimic of System One in humans. System One is also not smart.

It can be smart and not knowledgeable, as long as all the data is in the question you really don't need much in term of general knowledge, it might be even beneficial to stay on track. It mostly depend son what you do with it. For example in the doom demo I don't think you need astra level knowledge to know "enemy = bad" and "enemy is at my left = turn gun left"

In their own demo the left and right panels almost never agree on anything. So it's X times faster but doesn't tell you if it's still right

You can ask this Redditor saying he made it. https://old.reddit.com/r/LocalLLaMA/comments/1wihgum/i_liter... I think.

Out of curiosity and semi unrelated — why do so many of these projects with customized encoder-decoder setups use earlier Qwen versions like 2.5 and 3 and not the smallest 3.5? Purely the few 100m params, or something else in the latter’s arch or pretraining?

In my experience if you tell Claude to port LLM-like stuff without explicit steering for versioning, it will default to the most popular thing for this in its training window to reduce errors. 3.5 is outside its training data.

My guess would be qwen 2.5 predates linear attention which would be more complex to use.

I came across this recently. I was scanning for tiny models from HF using their search API. The script was generated by an agent. When I ran it, Qwen 3.5 did not make it at the top. Turns out, models generally prefer older content (training) but that the scanner also did not give any importance to recency.

Anecdotally qwen2.5-14b runs a lot faster on my mini than the small 3 models ¯\_(ツ)_/¯

From the readme

> A Jev-like model takes a piece of text and a list of N text options. It returns one probability for each option. It does this in one pass instead of writing an answer word by word.

I’ve read TypeSafe’s announcement, watched the home assistant demo, and still had no idea what it was. If instead those three sentences were in the announcement…

If you watch the Doom demo video, pay attention to the bars on the side. For every possible action, that's the likelihood it should take that action, for that iteration. They all update all the time. I thought that was a good visualization of how Jev differs from LLM generation.

Can play Doom too - https://x.com/vinnylarouge/status/2100281651930513460

https://xxcancel.com/vinnylarouge/status/2100281651930513460

I've seen a lot of LLM uses that are really just zero/few-shot classifiers with a lot of extra steps, so it is interesting to see more models that are taking advantage of all the intelligence encoded in the latent spaces of these models with really efficient output. It feels like this is an under-explored area of LLMs right now and I'm excited to see what comes out of it.

I like it! I suspect Jev may have more going on under the hood, but I like the idea of efficient universal transformers

Everyone's making comparisons to a regular LLM. The point is not to get text back. The point is probability weightings and confidence levels. This isn't going to be for everyone. If everything is as they claim (still on the waitlist so haven't been able to experiment), it would plug the boring holes in my workflows.

1. All of my hooks can move off of deterministic regexes, which are limited and cannot tell you more than if a certain string is present or not. 2. My PostGres second brain on Neon currently relies totally on LLM inference to classify signal vs. noise. Jev probably slots in perfectly here. 3. I see interesting use cases for detecting AI slop. Currently we're relying on a model's inference based on some exemplars to emulate and bad examples to avoid. Sometimes it works, sometimes it doesn't. 4. My mediagen workflow where my LLM helps me write the optimal prompt depending on the image/video model called, calling a diffusion model on fal.ai, generating images, and iterating if necessary, all rely on a preflight cost check that is currently extremely unreliable. We're talking orders of magnitude differences in expected costs vs. actual costs. A preflight score from Jev before a paid generation could be valuable. 5. Model-routing, obviously. 6. For me personally, I have around sixty skills (I know, I have to prune) whose descriptions compete for the same triggers, and my check_skill_collisions.py script can only compare description text. A 'Choice' primitive over skill names is another potential use case.

That was super quick.

Insane

Wow

Reply on news.ycombinator.com