The Jev vs Laya argument this week is being settled with numbers from Tesla T4s, RTX 5090s and Mac Studios. I wanted in on the conversation, but Jev is a closed, paid, cloud-only API — and I’m not spending money I don’t have on a benchmark. What I do have is a 2019 Acer Aspire 7, a GTX 1650 with 4 GB of VRAM, and a free weekend. So that’s what I tested on, and here are the numbers.
Quick honesty note before anything else: I only used Laya, the open-source one. People have already run Laya locally on Macs, desktop GPUs, even a browser tab — I’m not claiming to be first at anything. My contribution is narrower: I couldn’t find numbers from hardware this small, the 4 GB laptop card that thousands of students own. Now there are some.
Results
The numbers, first
| questions | my p50 (ms) | my p95 (ms) | published T4 p50 (ms) |
|---|---|---|---|
| 1 | 847.08 | 852.28 | 38.4 |
| 10 | 2,389.86 | 2,630.56 | 156.0 |
| 50 | 11,202.70 | 11,896.01 | 721.4 |
The T4 column is the model card’s published figure — quoted, never measured here. Cross-hardware comparisons are indicative only.
So: my laptop is 15–22× slower than the T4 figures everyone quotes — and every single-question decision still completes in under a second. Not fast, but real, local, free and offline. Cold load is its own tax: 29.7 s and 57.1 s on two consecutive runs from a warm cache.
Finding 1
The 50-question batch doesn’t fit in 4 GB
This is the part the T4 tables can’t show you. On the 50-question scenario, my mean (26.5 s) came out 2.4× higher than my own median (11.2 s) — and above my p95 (11.9 s). A few runs took minutes instead of seconds. That’s too extreme to be ordinary noise.
The 50-question batch briefly needs more memory than the GTX 1650’s 4 GB, and Windows spills into “shared GPU memory” — system RAM reached over the PCIe bus, which is brutally slow. Thermal throttling alone doesn’t produce a mean above the p95; memory spillover does. This is my best diagnosis, not yet an instrumented finding.
If you want to run something like this on a 4 GB card: batch smaller, or check your headroom first. The published tables won’t show you that ceiling, because on their hardware it’s nowhere in sight.
Finding 2
Batching still pays off on weak hardware
Per-question cost drops from 847 ms to 224 ms — a 3.8× reduction. The “one forward pass for everything” design argument, which is Laya’s whole pitch against paying per API call, holds even on a GTX 1650. It is just uniformly slower.
Finding 3
The phishing detector actually works; my schema didn’t
I ran ten hand-labeled emails — billing complaints, phishing attempts, HR notices, bug reports, a lottery scam — and asked the model three questions about each.
Phishing was the standout — the separation between scams and legitimate mail was decisive. Department routing was the interesting failure: every miss was a scam or complaint email routed into “billing” or “technical”, because my answer space had no security option. The model reads your option descriptions and routes into the best semantic overlap. One of my own labels was arguably wrong, too.
With this class of model, your question schema is part of the model. Design the answer space badly and you measure your own schema, not the model.
Ten emails is a smoke test, not an accuracy benchmark. The model’s own card says base Laya scores near chance zero-shot on decision benchmarks — the intended workflow is fine-tuning on your own data.
Context
What are Jev and Laya, anyway?
Skip this if you’ve been following the debate. On September 15, 2026, TypeSafe launched Jev — a “System 1” decision model. You hand it a state (an email, a ticket, a JSON document) plus typed questions, and it returns choices, scores and calibrated probabilities instead of paragraphs. Three days later, Nandakishor Mukkunnoth of Convai Innovations released Laya: the same idea, but open weights, Apache 2.0, 421 million parameters, installable with pip install laya. Every Jev figure in this post is a third-party published number, quoted as context — I never called the API.
Methodology
What I actually measured
A small benchmark harness (published, with raw JSON output) measuring cold load time and warm latency for 1, 10 and 50 typed questions answered in a single call — the three scenarios the model card publishes T4 numbers for. Each ran 100 timed calls after 5 warmup calls, reporting p50, p95 and mean.
Two details matter more than they sound. First, torch.cuda.synchronize() fires before every timer stops — CUDA calls are asynchronous, and without the sync you time the launch, not the work. Second, every timed call receives a different input email, so no pass sees byte-identical input. My environment is in the repo, because a latency number without its environment attached doesn’t mean much.
Fine print
Honest caveats
- I did not use or measure Jev. It is a closed, cloud-only, paid product; all Jev figures mentioned anywhere in this post are third-party published numbers.
- The T4 column is the model card’s published figure. I did not measure it.
- The spillover explanation for the mean anomaly is my best diagnosis, a hypothesis until instrumented with GPU memory telemetry.
- One machine, one session, fp32, plugged into power.
Takeaway
Why I’m still glad I ran it
On a 2019 gaming laptop, the open model answers any single typed question in under a second — free, offline, on my own weights. The cloud one is faster and bills per call. Neither number alone tells you which is right for you; but only one of them runs when the wifi is down, and only one of them I can fine-tune on a free Kaggle GPU and keep in the same folder as my college notes.
The gap between the benchmark world and my laptop is 15–22×, measured. That’s not a reason to stay out of the conversation — it’s my entry ticket into it.
Credits & sources
pip install laya · project site