Kev-9B

Resumo do modelo

O Kev-9B é um modelo de decisão. Lê um documento (o estado) e um conjunto de perguntas tipadas sobre ele, e devolve uma distribuição de probabilidade calibrada sobre as opções fornecidas com cada pergunta, numa única passagem direta e sem gerar texto. Destina-se a programadores que classificam, encaminham, triam ou verificam documentos e que precisam de probabilidades que possam ser usadas com limiares, por exemplo para enviar casos incertos para revisão humana. Implementa a API pública System One da TypeSafe (POST /v1/systemone), por isso o SDK da TypeSafe funciona com ele sem alterações. É um adaptador LoRA e uma cabeça de ponteiro sobre o Qwen3.5-9B-Base e cabe numa GPU da classe dos 24 GB. Esta ficha descreve a versão 2, lançada em 2026-09-30 e incluída no Kev 1.0.

Detalhes do modelo

Entrada. Um estado (texto, ou um objeto ou array JSON renderizado como texto etiquetado) e qualquer número de perguntas nomeadas, cada uma de um de três tipos:

Cada pergunta é respondida como a sua própria linha que continua a partir do estado partilhado, por isso as perguntas não se podem influenciar mutuamente; o estado é calculado uma vez e colocado em cache.

Utilizações previstas

• Decisões tipadas sobre documentos de alguns milhares de tokens: classificação, encaminhamento, triagem, escolhas de extração, verificações de política e elegibilidade, e avaliação de uma resposta proposta contra critérios indicados.
• Fluxos de trabalho que agem com base na confiança: automatizar os casos com confiança e pôr o resto em fila, com os limiares fixados numa amostra etiquetada da carga de trabalho do próprio utilizador.
• Um substituto auto-alojado e imediato para um endpoint System One numa única GPU da classe dos 24 GB, e um ponto de partida para ajuste fino nas próprias etiquetas do utilizador (kev.train --init_from jaredpalmer/kev-9b).

Utilizações fora do âmbito

• Geração de texto, conversa, resumo ou resposta a perguntas abertas. O modelo apenas pontua as opções que lhe são dadas.
• Decisões totalmente automatizadas com consequências legais, médicas, financeiras, laborais ou semelhantes para pessoas, sem revisão humana.
• Perguntas cuja resposta depende de factos que não estão no estado e não são conhecimento geral, e exames com muito conhecimento (vê Limitações).
• Aritmética de datas com precisão ao dia sem o pré-processador KEV_DATE_FACTS=1, estados com mais de 65,536 tokens e idiomas diferentes do inglês.

Como usar

Serve-o com o repositório do Kev. Em CUDA corre em bf16 com kernels DeltaNet fundidos e grafos CUDA (uma L40S ou uma H100; cerca de 22 GB residentes); em Apple Silicon o mesmo comando serve-o através do MLX, escolhido automaticamente.

git clone https://github.com/jaredpalmer/kev.git && cd kev && uv sync --extra serve
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-9b --port 8008          # v2, Kev 1.0 (this card)
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-9b@v1 --port 8008       # v1

from typesafe_sdk import Choice, Noul, TypeSafeClient

client = TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8008", model="kev-latest")
response = client.system_one(
    state="I was charged twice for order 1182. Please refund one of the charges.",
    questions={
        "team": Choice(instructions="Which team should handle this?",
                       criteria={"billing": "Charges and refunds", "shipping": "Deliveries", "returns": "Exchanges"}),
        "urgent": Noul(instructions="Does this need a reply today?"),
    },
)
print(response.choices["team"].choice, response.nouls["urgent"].noul)

A temperatura calibrada é aplicada por predefinição; KEV_TEMPERATURE=1.0 devolve as probabilidades em bruto. KEV_DTYPE=fp32 seleciona o caminho exato usado para avaliação. KEV_DATE_FACTS=1 acrescenta o número de dias entre cada par de datas encontradas no estado, que o modelo foi treinado para usar. Um estado com mais de 65,536 tokens é recusado com um 422 que indica a sua contagem de tokens.

Dados de treino

As duas etapas de ajuste fino repetem 2,000 e 10,000 registos de decision-v7. Não foi usada nenhuma saída do Jev (o modelo de decisão alojado da TypeSafe). O CodeReviewer e o FlakeFlagger vêm do Zenodo; as narrativas do CFPB são obras do governo dos EUA; as licenças e revisões por fonte ficam registadas nos manifestos das suites. As suites apenas de avaliação abaixo (breadth-v1, tasksource-heldout-v1, transfer-v4, longdoc-v1, e as fontes When2Call e de injeção de prompt do devtools-v1) nunca entram no treino.

Procedimento de treino

1. Receita base. Duas épocas em decision-v7 a partir da base: LoRA de rank 16, α 32; taxa de aprendizagem 5e-5, agenda de ciclo único; lote efetivo 8 (4 × 2 de acumulação); autocast bf16, gradient checkpointing. A perda é a entropia cruzada sobre as opções de cada pergunta. A ordem das opções é baralhada, opções “nenhuma das anteriores” e distratores são inseridos ao acaso, e um quarto dos registos choice também produz um par mínimo (a pergunta com uma opção “nenhuma das anteriores”, uma vez com a opção correta presente e outra com ela removida).
2. Datas e prova em falta. Uma época a partir da etapa 1 com taxa de aprendizagem 2e-5 e 2,000 registos repetidos. Isto é a v1.
3. Documentos e skills. Uma época a partir da v1 nos três conjuntos de treino em conjunto, com taxa de aprendizagem 2e-5 e 10,000 registos repetidos; lote 2 × 4 de acumulação; estados de no máximo 7,552 tokens; semente 1; 3,318 passos do otimizador.
4. Calibração. Uma única temperatura, T = 2.19, que minimiza a log-verosimilhança negativa em 648 perguntas de conjuntos de dados reservados: 448 da partição de calibração do transfer-r3 (seis conjuntos de dados públicos, QNLI, SciQ, TweetEval-offensive, PAWS, MMLU e Emotion, mais duas famílias reservadas de registos de política gerados) e 200 perguntas MMLU-Pro (transfer-v9 development). O pool foi verificado contra as suites de treino do checkpoint antes do ajuste.

Avaliação

Metodologia. Cada comparação é contra o Kev-9B v1 em itens idênticos, cada modelo à sua própria temperatura de serviço (v1: 2.30). As comparações e os seus níveis foram registados antes das leituras de confirmação; as partições de teste foram lidas uma vez para este checkpoint; o teste transfer-v4 está bloqueado (lido uma vez por candidato). Os intervalos emparelhados são bootstraps de 95 % que reamostram registos inteiros (2,000 reamostragens), por isso as perguntas que partilham um estado movem-se em conjunto. As diferenças são em pontos percentuais (pp). O Jev (o modelo alojado da TypeSafe, consultado através do Vercel AI Gateway) é mostrado onde foi lido nos mesmos itens. As suites:

• breadth-v1: 14 conjuntos de dados públicos reservados em cinco áreas (conhecimento, linguagem, recuperação, ferramentas, artes), nunca treinados.
• transfer-v4: decisões fora da distribuição de seis fontes públicas nunca treinadas mais estruturas de política e regras reservadas.
• transfer-r3: um painel de estados curtos das mesmas oito fontes reservadas que o pool de calibração.
• hard-v1: as famílias de skills acima; a partição de teste reserva templates de geradores treinados.
• devtools-v1: decisões de ferramentas de desenvolvimento de seis fontes com licenças verificadas (quatro treinadas, duas apenas de avaliação).
• documents-v1 / documents-v2: narrativas de reclamações do CFPB; a v2 é um conjunto de teste reservado privado.
• longdoc-v1: contratos comerciais CUAD e conjuntos de acordos gerados, com estados de 4k a 64k tokens.

Os painéis de destaque do devtools-v1 excluem duas tarefas cujas etiquetas o estado não determina (flakeflagger, tipo de alteração de commit); as mesmas linhas saem dos dois lados.

Resultados contra a v1 (confirmação registada).

Dados reservados (nunca treinados).

Contra a v1, a diferença de precisão do breadth-v1 é +0.3 [−0.7, +1.3] no development e +0.6 [−0.4, +1.6] no test. O tasksource-heldout-v1 development foi lido para este checkpoint mas a sua leitura não está completa; não é reportado aqui.

Famílias treinadas (itens e templates reservados).

Diferenças de teste contra a v1: hard-v1 +25.0 [+22.0, +28.1], devtools-v1 (todas as fontes) +15.4 [+11.0, +19.4], documents-v2 +8.0 [+5.9, +10.2].

Documentos longos.

• Comprimento de contexto validado: 8,192 tokens, o comprimento treinado. O intervalo de 16k está fora da tolerância: o seu limite inferior é −3.7 pp, abaixo de −3 pp, por isso nenhum comprimento maior é validado.
• Regra, fixada antes da leitura: o comprimento validado é o tamanho nominal do maior intervalo a partir de 16,384 tokens tal que ele, e cada intervalo entre ele e 8,192, está dentro da tolerância. Dentro da tolerância significa que a diferença de precisão CUAD em relação ao intervalo de 8k (estados de 6,553–7,618 tokens, o comprimento treinado), emparelhada no mesmo contrato, repetição e pergunta, tem um limite inferior de 95 % de pelo menos −3 pp, e todos os registos foram respondidos. Se o intervalo de 16k falhar, o comprimento validado é 8,192 tokens.

Precisão CUAD, ECE e a diferença emparelhada em relação ao intervalo de 8k por comprimento nominal do estado (longdoc-v1 development):

ECE à temperatura de distribuição T = 2.19. Δ é emparelhado nas 445–447 perguntas feitas sobre os mesmos contratos em ambos os comprimentos. O intervalo de 4k contém contratos diferentes e não é referência para a regra. Fonte: runs/r28-readout/context.json (leitura registada da ronda 28, runs/r29-9b-r18a-longdoc).

Calibração (erro de calibração esperado, ECE, tal como servido; mais baixo é melhor):

O intervalo bootstrap de 90 % da temperatura é [2.05, 2.41]. O 2.30 da v1 foi ajustado em linhas de desenvolvimento da sua própria distribuição de treino; a v2 é o primeiro 9B servido a uma temperatura ajustada em conjuntos de dados reservados.

Outros resultados.

Serviço. CUDA, bf16 com kernels fundidos e grafos CUDA; tempo de modelo por pedido (mediana de 20) para um estado novo / repetido, medido na v1 (a mesma arquitetura e forma de adaptador):

A memória de GPU residente é 21.9 GB. As probabilidades servidas mantêm-se dentro de 0.017 do caminho de avaliação fp32 em 280 perguntas, sem respostas alteradas. No caminho de avaliação fp32 (H100, v2), estados de 16k / 32k / 64k tokens demoram 5.1 / 10.9 / 25.4 s e 4.6 / 9.1 / 18.2 GiB acima dos pesos.

Apple Silicon (MLX): as medições de estados longos feitas para o Kev-0.8B e o Kev-4B não foram feitas neste tamanho; no M5 de 32 GB usado para elas, o backbone bf16 de 19.3 GB e o seu conjunto de trabalho não cabiam na memória disponível.

¹ O índice corrigido para o acaso do Decision Index 0.2 da comunidade: por conjunto de dados (pontuação − acaso) / (1 − acaso), com média dentro de cada área e depois 100 × a média das cinco áreas. O índice do Jev vem de uma leitura separada dos mesmos itens de teste.

Limitações e compromissos

• Seleção. Este checkpoint foi treinado e lido em dados de desenvolvimento numa ronda anterior, e re-selecionado sob uma regra posterior com esses números conhecidos. As partições de teste e a leitura bloqueada, cada uma lida uma vez para ele, são a salvaguarda; trata as margens de desenvolvimento como otimistas.
• Os seus grandes ganhos são em distribuição. As partições de treino do hard-v1, devtools-v1 e documents-v1 estão nos seus dados de treino; esses ganhos são itens e templates reservados de famílias treinadas, não transferência para novas tarefas.
• Não é melhor do que a v1 em trabalho novo. breadth-v1 test +0.6 pp [−0.4, +1.6], transfer-v4 development −0.2 pp [−2.4, +1.8], transfer-r3 test +0.0 pp [−1.2, +1.2]. O Kev-27B lidera-o por 11 pontos no índice breadth-v1, o Jev por 13.
• O conhecimento é determinado pela base. O MMLU-Pro é 0.590, contra 0.675 do Kev-27B e 0.840 do Jev.
• A aritmética de datas é a sua família mais fraca: 0.725 nas perguntas da política deadline contra 0.95 do Jev; o pré-processador KEV_DATE_FACTS=1 ajuda.
• Calibração. O devtools-v1 é a sua suite menos calibrada (test ECE 0.098). O intervalo da temperatura é [2.05, 2.41]. A temperatura foi escrita em head.pt a partir do ajuste registado do pool com o motivo registado, porque o script de calibração não consegue listar as fontes do ficheiro de treino combinado para reverificar o próprio pool; a verificação da própria ronda já o tinha coberto. Essa verificação não cobre os dados de datas e prova em falta da v1, cujo manifesto não lista fontes; esses registos são quatro famílias geradas, nenhuma delas no pool.
• Comprimentos não treinados. Os estados de treino eram no máximo 7,552 tokens. Estados mais longos são servidos até 65,536 tokens; até onde a precisão aguenta é o comprimento de contexto validado acima.
• A ordem das opções pode mudar uma resposta; o isolamento das perguntas não impede isto.

Enviesamento, riscos e considerações éticas

• As probabilidades calibradas podem criar uma confiança infundada. A temperatura foi ajustada em conjuntos de dados públicos reservados e não se transfere para todas as cargas de trabalho; mede a precisão e a calibração numa amostra etiquetada dos teus próprios dados, e reajusta aí a temperatura (python -m kev.calibrate), antes de definires limiares.
• A precisão e a calibração mudam com a mudança de domínio. Monitoriza as taxas de erro em produção em vez de confiares nos números acima.
• Não o uses para decisões automatizadas consequentes sobre pessoas sem revisão humana. Os enviesamentos do modelo base e dos dados de treino (incluindo etiquetas produzidas por outros modelos) não são medidos.
• Os estados podem conter dados pessoais ou confidenciais. O auto-alojamento mantém as entradas no teu próprio hardware; o servidor está aberto a menos que KEV_API_KEY esteja definido, por isso aplica o teu próprio controlo de acesso e política de tratamento de dados.

Computação

• Receita base e etapa de datas (v1): GPUs NVIDIA H100 individuais.
• Etapa de documentos e skills: 2.6 horas numa NVIDIA H200 (pico 74.1 GB).
• Verificações de avaliação e serviço: GPUs H100 / H200 / L40S individuais no Modal.

Proveniência e reprodutibilidade

• Código, suites e relatórios de avaliação: github.com/jaredpalmer/kev. Números de lançamento: runs/release/kev-9b-r27.json (scripts/release_numbers.py --release kev-9b-r27); regra e veredictos registados experiments/rounds/r27.json, runs/r27-readout/, runs/r27-verdict/; as leituras da família de 2026-09-30 runs/fam-9bnew-breadth/, runs/fam-9b-breadth/ e runs/fam-breadth-test-report/; ood-v2 runs/r29-9b-r18a-ood/; o serviço runs/serve-9b-l40s/, runs/serve-9b-h100/, runs/long-state-9b-h100/.
• Etapas: ensaio base q35-9b/01-trial-1 (tag v7-base); datas night2-9b-du/00-trial-0 (v1, tag v1); documentos e skills ronda 18 braço (a) r18-9b/00-trial-0 (experiments/round18/joint.json), selecionado e confirmado como o 9b-r18a da ronda 27.
• Pesos lançados: commit do Hub b5d8c18e; sha256 do adaptador 2b2a70cf4ef4440b6c22899e1f72c2f8ea5c6f65b19aa344539b4b8971d1f13d, sha256 do head.pt 8e1dab2c… (T = 2.1936).
• Verificação: carregado anonimamente do Hub, reproduziu as respostas da avaliação de pré-lançamento em 252 de 252 linhas do SemIf e 764 de 764 linhas do transfer-v4 development a T = 2.19 (runs/rel9-public/).

Citação

@misc{palmer2026kev9b,
  title        = {Kev-9B: a calibrated decision model on Qwen3.5-9B},
  author       = {Palmer, Jared},
  year         = {2026},
  howpublished = {\url{https://huggingface.co/jaredpalmer/kev-9b}},
  note         = {Version 2, released 2026-09-30; Kev 1.0}
}

Contacto

Perguntas e problemas: github.com/jaredpalmer/kev/issues.