Oumi Investigates Jev’s Likely Architecture and Training
Oumi researchers used behavioral probes, benchmark results and serving profiles to estimate which model TypeSafe’s Jev may be based on and how it may have been trained and served. Without insider knowledge, they say Jev is likely built on Qwen 3.5 or 3.6 in a 35B-A3B configuration, with a tokenizer merging Qwen and GPT-OSS. They also speculate that its RLCD method uses soft-label cross-entropy on synthetic data rather than PPO or GRPO. For serving, they propose tree batching and either a form of sparse attention or deployment on two GPUs with the prefill split between them.
The analysis offers a public, experimental approach to identifying the components of a local decision model. However, Oumi explicitly presents its base-model, architecture, tokenizer, training and serving conclusions as best guesses based on tests rather than confirmed details from TypeSafe.
| Full disclosure: I'm one of the authors of this blog, and work at Oumi. I thought folks here would find our investigation interesting, especially anyone interested in building local decision models. We ran several experiments to investigate which model Jev may be based on and how it might be trained and served. The TypeSafe team has publicly mentioned that they are not interested in pretraining a model from scratch, so Jev is almost certainly built from a recently-released publicly available model -- we were curious if we could identify exactly which one! We don't have any insider knowledge, so these are our best guesses based on the results: - Jev is likely built on Qwen 3.5 or 3.6, based on obscure / famous knowledge comparisons, name probing, and sensitive question responses - Jev is likely a 35B-A3B model, based on the benchmark performance and serving profiles we ran (see in particular the Rare Facts analysis and curves) - Its tokenizer is likely a merge of Qwen and GPT-OSS - Its training methodology (RLCD) is likely standard soft-label cross entropy from synthetic data. It's likely being framed as RL because of a parallel with RLHF (for which the human feedback part was the unique part), but it likely isn't using PPO or GRPO or anything like that. - This synthetic data is a mix of teacher-taught from reasoning models and programmatic answers to code-generated questions. - Serving is likely done with tree batching (pack all questions + 1 state into single request with per-question attention mask) rather than the standard serving path on vLLM - Based on long document performance, they're likely using a form of sparse attention or serving on two GPUs and splitting the prefill between them. Most likely on B200 GPUs or above. Our nitty gritty analysis is in the article for those curious. Hope you folks enjoy! submitted by /u/Taenin [link] [comments] |
#Jev#TypeSafe#Oumi#Qwen 3.5#Qwen 3.6#GPT-OSS#RLCD#vLLM#NVIDIA B200