OP's point here is that the overall approach of restricting output token space and using parallel prompts to produce concurrent results and taking the most relevant ones isn't something novel to Jev (not saying there's nothing novel, but a facsimile can be created at the application layer using any small, fast model)
replyWhat’s novel is how fast and cheap Jev is while maintaining quality. If they’re trying to say they made the same thing, that is likely incorrect. Getting the same result 100x faster is in fact a breakthrough technology.
replyYes, agree, but also limited to specific types of use cases.
replyI still don't get the point of jev....it's basically an optimized models/runner on really short context and output?
replyIt's a specialized classifier model. It classifies input text into categories with a confidence score. Usually those classifiers are small like in the OP but jev is supposedly big, smart, and fast enough to play DOOM by having the scene described in text and classifying it into button presses.
replyIt is mostly Harness hype. People actually explore the capabilities of classifier models which up until this point weren't touched. You can recreate most of those with LFM 2.5 classifier locally
replyWell the Doom demo is again passing a textual structure....I am not really convinced on how it's different than any other llm that execute small context within 100ms.
On a MBP M3Max with LFM 2.5B, I get about 500ms -600ms on "source_text": "Invoice #4471 issued March 3, 2026 to Beaver Dam Logistics for $12,840.00, net 30." with a 4 property structure output https://docs.typesafe.ai/primitives/advanced
replyI can't test it on a better model / my main workstation, but sub 1sec for short prompts is not impressive? I am sure that we can get something like 100ms-300ms with a Qwen 3.8 27b model for a similar query on a 5090 class GPU.
edit: 203ms wall clock on a somewhat busy workstation with https://huggingface.co/LilaRest/gemma-4-31B-it-NVFP4-turbo
I get the point, and it's nice, but I think the "Jev" naming is confusing (and it could be legally dangerous).
replyPerformance for this kind of thing should be best on any hardware that has high prefill speeds. As basically this is "do prefill only, measure scores, skip decode entirely".
replyI don't know how the Mac stuff compares on that front.
I have the same thing replicated in my own bespoke inference engine (for DGX Spark, in Rust & CUDA) and get answers pretty much as fast as the Jev openrouter endpoint.
https://github.com/rdaum/eider/
It's running over Qwen3.6. Getting it working with Qwen3.8 Flash Next now and getting a battery of tests and examples before I go more public with it.