| ▲ | tecleandor 7 hours ago |
| I'm confused... This has no relation with the Jev team, isn't it? It's trying to "emulate" Jev behavior using a regular small LLM model (Qwen3 0.6B or MiniCPM5 2B). And with the smallest model it takes like between half to two seconds to run in my M2 Max, so it's not super fast. I mean, it's faster than asking to a regular LLM, but I think that's not proper to have Jev on the name (also legally...) Edit: no shade, and I'll give it a try for some ideas. I'd also like to have an open weights Jev but I think the naming is misguiding. I also have to try Jev that, BTW, got access pretty quickly, less than a day I think... |
|
| ▲ | CharlieDigital 7 hours ago | parent | next [-] |
| 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) |
| |
| ▲ | Uehreka 5 hours ago | parent | next [-] | | What’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. | | | |
| ▲ | Foobar8568 7 hours ago | parent | prev | next [-] | | I still don't get the point of jev....it's basically an optimized models/runner on really short context and output? | | |
| ▲ | orbital-decay 6 hours ago | parent [-] | | It'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. | | |
| ▲ | Foobar8568 3 hours ago | parent [-] | | Well 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 I 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 |
|
| |
| ▲ | tecleandor 6 hours ago | parent | prev [-] | | I get the point, and it's nice, but I think the "Jev" naming is confusing (and it could be legally dangerous). |
|
|
| ▲ | cmrdporcupine 5 hours ago | parent | prev [-] |
| Performance 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". I 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. |
