LEV (OpenLAIR)
Notas do quadrante
Ver o quadrante completoPontuação pela rubrica pública do quadrante (maturidade × capability; bolha = adoção). Revisamos conforme a evidência.
- Maturidade4.3/10
LoRA + pointer head Apache-2.0 sobre Ouro-1.4B, Ouro-2.6B e Nanbeige4.2-3B, com cards, arquivos de calibração, exemplos no GitHub, datasets e paper. O card diz uso só para pesquisa. Sem servidor, pacote, integrações nem SLA.
- Capability4.4/10
Probabilidades só sobre opções passadas pelo chamador (choice). Temperatura por profundidade, sem ECE no card. Lev-2.6B 63,2% → 76,2% nas 231 tarefas públicas do JevBench da profundidade 1 à 4 (autores). p50 51–200 ms numa H200 (autores).
- Adoção1/100
Cerca de 200 downloads e 4 likes nos três repos do HF (25/10); 105 upvotes no HF Papers; post do HuggingPapers em 24/10. Sem integração de terceiros nem uso em produção encontrados.
Vendor claims
- Lev-2.6B goes from 63.2% at depth one to 76.2% at depth four on JevBench (231 public tasks, fp32 readouts)[Claim do fornecedor — não verificado independentemente]
- On-demand depth saves 15% to 24% of the computation at a cost of under one accuracy point[Claim do fornecedor — não verificado independentemente]
- H200 bf16 batch-one p50 51.1 / 100.7 / 150.4 / 200.1 ms at depths 1–4 (Lev-2.6B)[Claim do fornecedor — não verificado independentemente]
publicado (OK do Fabricio 25/10 BRT). Notas calculadas do zero.
Não é o mesmo projeto do Lev (Interfaze, um LoRA sobre o Qwen3.5-4B). Mesmo nome, autores e método diferentes.
O que é
O LEV (paper, arXiv 2610.20951, 14/10/2026; GitHub; modelos) transforma um modelo de linguagem pré-treinado em loop num modelo de decisão tipado. O backbone repete a mesma pilha de camadas várias vezes. O LEV lê as opções depois de cada volta com um pointer head compartilhado e treina todas as profundidades juntas, então um único checkpoint responde na profundidade 1, 2, 3 ou 4. Mais profundidade custa mais computação, mas não gera tokens.
| Modelo | Backbone | Profundidades | JevBench público, primeira → mais funda (autores) |
|---|---|---|---|
| Lev-1.4B | Ouro-1.4B | 1–4 | 58,0% → 68,0% |
| Lev-2.6B | Ouro-2.6B | 1–4 | 63,2% → 76,2% |
| Lev-3B | Nanbeige4.2-3B-Base | 1–2 | 69,3% → 72,7% |
Cada repo traz o adapter LoRA do seed 0, o head de decisão, o tokenizer e as temperaturas por profundidade. O código é Apache-2.0 e deriva do Kev. É a mesma ideia do SanSi (leitura em loop sobre o Ouro), de outro grupo.
Limites (leia antes de usar em produção)
- Só opções. Você passa uma pergunta e as opções e recebe uma probabilidade por opção. Não há tipo sim/não ou score separado nem servidor
/v1/systemone. - Os autores dizem que o ganho depende da carga: o Lev-2.6B não passou no critério G3 do LevBench travado em nenhum dos três seeds, e uma passada mais funda pode virar uma resposta rasa que estava certa.
- O card original diz “research purposes only”. Tempos medidos numa H200, bf16, batch 1; a acurácia usa leitura em fp32.
Alegações dos autores (UnverifiedClaim)
- Lev-2.6B: 63,2% → 76,2% nas 231 tarefas públicas do JevBench, profundidade 1 → 4 (fonte)
- Profundidade sob demanda economiza 15–24% da computação por menos de um ponto de acurácia (fonte)
- p50 51–200 ms nas profundidades 1–4 numa H200 (fonte)
Sem linha no Decision Index, no placar do JevBench nem no Artificial Analysis.
Notas (do zero, 25/10/2026)
- Capability 4,4 = tipos 3 × 0,30 + calibração 4 × 0,25 + latência 6 × 0,25 + acurácia 5 × 0,20 = 0,90 + 1,00 + 1,50 + 1,00 = 4,40.
- Maturidade 4,3 = disponibilidade 7 × 0,30 + docs 6 × 0,25 + integrações 1 × 0,25 + suporte 2 × 0,20 = 4,25 → 4,3.
- Adoção 1 = engajamento 2 × 0,35 + ecossistema 0 × 0,35 + produção 0 × 0,30 = 0,70 → 1.