Kev 1.0

O Kev 1.0 é o primeiro lançamento versionado de toda a família Kev: quatro modelos de decisão que leem um documento e um conjunto de perguntas tipadas e devolvem probabilidades calibradas sobre as opções, numa única passagem direta, atrás da API System One da TypeSafe. Nada nele é treinado de novo. Fixa os checkpoints, as fichas de modelo, as suites de avaliação e o código de serviço com que a próxima geração do Kev será medida, com a mesma tag (v1.0) em cada repositório do Hub.

O que está no 1.0

Números de destaque (caminho de avaliação fp32, cada modelo à sua temperatura de distribuição; o teste transfer-v4 está bloqueado e foi lido uma vez por modelo):

O hard-v1, o devtools-v1 e o documents-v1 têm partições de treino em que todos os Kev treinaram: essas linhas medem itens reservados de famílias treinadas, não transferência. As linhas do breadth-v1 e do transfer-v4 são conjuntos de dados em que nenhum Kev treinou. O Jev foi lido nas partições de desenvolvimento e apenas no breadth-v1 test. Cada número remonta a um relatório confirmado através de docs/claims.json; as fichas de modelo (docs/model-cards/) têm o resto, com intervalos.

O que mudou desde o último lançamento da família

Medido desde a release kev-family do GitHub tal como foi montada pela primeira vez para a família atual em 2026-09-24 (Kev-27B v1, Kev-9B v1, e os mesmos Kev-4B e Kev-0.8B que aqui). As suas atualizações de 2026-09-30 (Kev-27B v2, Kev-9B v2) são também listadas aqui, uma vez que é no 1.0 que passam a fazer parte de um lançamento versionado.

• Kev-27B v2: pesos completos. Todos os pesos do Qwen3.8-27B afinados durante uma época num corpus de 145,840 registos, depois combinados por média 0.85 / 0.15 com a v1. Contra a v1 no teste: conjuntos de dados reservados +1.2 pp [+0.3, +2.2], famílias de tarefas reservadas +5.3 [+3.7, +6.8], skills, ferramentas e documentos +8.9 [+7.5, +10.3]; teste fora da distribuição bloqueado 0.889 contra 0.896, Brier 0.154 contra 0.160. Pior e demasiado confiante em contratos longos (CUAD ECE 0.053 contra 0.007). A v1 está em jaredpalmer/kev-27b@v1-lora.
• Kev-9B v2. A v1 mais uma época nos dados de documentos e skills que o Kev-4B e o Kev-0.8B já tinham. Contra a v1 no teste: hard-v1 + devtools-v1 +18.7 pp [+16.7, +20.8], documents-v1 +7.1 [+4.7, +9.2]; igual no teste fora da distribuição bloqueado (0.852 ambos) com Brier 0.199 contra 0.224. A v1 está em jaredpalmer/kev-9b@v1.
• Sem truncagem silenciosa. O servidor costumava cortar um estado mais longo do que o seu limite sem o dizer. Agora recusa um estado com mais de 65,536 tokens com um 422 que indica a contagem de tokens e o limite; KEV_TRUNCATE_STATES=1 volta a optar pela truncagem, e cada resposta desse servidor passa então a dizer truncated. As skills de implementação e de ajuste fino fixam o KEV_REF num commit que tem esta correção e as alterações de documentos longos e de MLX abaixo (71d4829), e o Space foi republicado após a correção.
• Documentos longos em todos os tamanhos. O caminho de avaliação mantinha atenção fp32 para linhas longas no kernel de matemática, por isso o Kev-0.8B, o 4B e o 9B ficavam sem memória de GPU em estados de 32k–64k tokens. As linhas longas passam agora pelo kernel eficiente em memória em fp32: o Kev-4B lê um estado de 61k tokens em 17.2 s com 17.2 GiB acima dos pesos numa H100, e as linhas mais curtas mantêm os seus logits bit a bit. É isto que torna os comprimentos de contexto validados acima mensuráveis.
• Apple Silicon. O backend MLX carrega checkpoints de pesos completos tal como estão guardados, sem fusão, o que dá ao Kev-27B um percurso em Mac (esperado precisar de cerca de 51 GB mais memória de trabalho; ainda não corrido nesse tamanho). Os estados longos são pré-preenchidos 1,024 tokens de cada vez e a cache é despejada antes de uma passagem, por isso o Kev-4B serve um estado de 65,000 tokens num M5 de 32 GB com um pico de 13.0 GB (84.5 s novo, 716 ms em cache).
• Proveniência do kernel. Cada relatório de avaliação e ensaio passa a registar o conjunto de kernels de que os seus logits dependem (versões de pacotes, GPU, dtype, implementações de atenção e DeltaNet), depois de se ter descoberto que uma alteração de kernel na imagem de avaliação movia as leituras do Kev-27B v1 em 0.03–0.06 de probabilidade sem qualquer alteração ao próprio código do Kev.
• Auditoria de avaliação. Três suites foram removidas por serem infundadas para selecionar modelos: scienthoon (tickets com templates, uma pergunta que o texto não consegue responder), WANLI-v2 / WANLI-v1 (um quarto das etiquetas gold são de um de dois anotadores em desacordo) e as avaliações públicas da TypeSafe (gold de dois modelos fechados, perguntas demasiado poucas). Os painéis de destaque excluem itens que a auditoria considerou sem resposta possível ou sem etiqueta. Os números dos lançamentos anteriores nessas suites são mantidos nos seus registos, não nas fichas do 1.0.
• Calibração. O Kev-4B e o Kev-0.8B trazem temperaturas ajustadas em itens reservados dos seus dados de treino. Um reajuste registado em conjuntos de dados reservados foi avaliado para ambos e adotado para nenhum: não melhorou o Kev-4B (diferença de Brier −0.0001 [−0.0005, +0.0003]), e tornou o Kev-0.8B pior calibrado nas suas famílias de documentos e skills em mais do que a tolerância registada. O Kev-9B e o Kev-27B já trazem temperaturas de conjuntos de dados reservados.
• Dados de treino publicados. As partições de treino do documents-v1 e do hard-v1 estão no conjunto de dados jaredpalmer/kev-suites, por isso os dados de treino dos modelos pequenos podem ser obtidos e verificados por hash.
• Comprimento de contexto validado. Cada ficha indica agora o estado mais longo em que a precisão em contratos CUAD se mantém dentro de 3 pp (limite inferior de 95 %) do mesmo modelo a 8k tokens. O Kev-27B aguenta até 65,536 tokens, o limite de serviço (o seu limite inferior a 64k é −2.4 pp). O Kev-0.8B, o 4B e o 9B validam apenas os seus 8,192 treinados: cada um já falha a tolerância a 16k (limites inferiores −8.5, −3.4 e −3.7 pp), por isso para além de 8k tokens as suas respostas em documentos longos não estão cobertas pela medição.
• Fichas de modelo formais. As quatro fichas seguem uma estrutura: resumo, detalhes, utilizações previstas e fora do âmbito, como usar, dados e procedimento de treino, avaliação, limitações, riscos, computação, proveniência.

Limitações conhecidas

• Ganhos em distribuição. Os grandes ganhos do último ano são em suites cujas partições de treino estão nos dados de treino. Em conjuntos de dados em que nenhum Kev treinou, o Kev-27B está 1.7 pontos de índice abaixo do Jev no breadth-v1 test, e os tamanhos menores estão 13–31 pontos abaixo.
• Comprimentos não treinados. O Kev-0.8B, o 4B e o 9B treinaram em estados de no máximo 7,552 tokens e o Kev-27B em no máximo 32,768; o servidor aceita 65,536. Usa o comprimento de contexto validado, não o limite de serviço.
• O Kev-27B em contratos longos é menos preciso do que a v1 e demasiado confiante (CUAD test ECE 0.053 contra 0.007); reajusta a temperatura nos teus próprios documentos ou usa @v1-lora para revisão de contratos.
• Kev-0.8B e encaminhamento de ferramentas. A sua precisão no When2Call caiu abaixo do acaso (0.133 no test) após a sua etapa de documentos e skills; não o uses para encaminhamento de chamadas de ferramentas.
• A aritmética de datas é a família mais fraca em todos os tamanhos abaixo de 27B (precisão da política deadline 0.35 / 0.65 / 0.725 contra 0.95 do Jev); o KEV_DATE_FACTS=1 ajuda.
• O conhecimento é determinado pela base (MMLU-Pro 0.230–0.675 contra 0.840 do Jev).
• O Kev-9B num Mac não foi medido, e espera-se que o Kev-27B num Mac caiba em 96–128 GB mas não foi corrido.
• Seleção. O Kev-27B v2 e o Kev-9B v2 foram re-selecionados sob a regra auditada com leituras de desenvolvimento anteriores conhecidas; as suas margens de teste são otimistas.
• Uma temperatura por modelo não consegue reordenar as confianças, por isso, com um orçamento de erro de 5 %, os modelos automatizam menos decisões do que o Jev fora da distribuição.

Como correr

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-4b@v1.0 --port 8009    # CUDA, or MLX on Apple Silicon

A partir de um tarball do lançamento:

shasum -a 256 -c SHA256SUMS.txt
tar -xzf kev-4b.tar.gz
uv run --extra serve python -m kev.serve --run kev-4b --port 8009

O SDK da TypeSafe funciona sem alterações: TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8009", model="kev-latest"). O Kev-27B precisa de uma B200, H200 ou H100 80 GB: --run jaredpalmer/kev-27b@v1.0. Para implementar um endpoint HTTPS no Modal, vê skills/kev-deploy.

Recursos

Cada tarball contém um checkpoint tal como está no Hub na sua revisão de pesos (adaptador LoRA, head.pt com a temperatura, ficheiros do tokenizer, o result.json do ensaio de treino, provenance.json, training_config.json, training_metrics.json e o log), a ficha de modelo do Kev 1.0 como README.md, e a leitura bloqueada do transfer-v4 como locked_test.json. São construídos por scripts/build_release_assets.py a partir de docs/releases/kev-1.0-assets.json, e reconstruí-los dá os mesmos bytes. Cada ficheiro neles tem a data 2026-10-01 00:00 UTC, que o kev.serve reporta como a data de lançamento de um checkpoint desempacotado. Os tarballs anexados pela primeira vez em 2026-10-01 datavam os seus ficheiros de 1970-01-01, por isso o kev.serve reportava 1969-12-31; foram substituídos no mesmo dia por estes. Os pesos e todos os outros ficheiros são idênticos byte a byte; só os hashes dos tarballs mudaram.

O Kev-27B não está anexado, porque os seus 51 GB de pesos ultrapassam o limite de 2 GB por recurso do GitHub. Descarrega-o do Hub: jaredpalmer/kev-27b@v1.0 (commit dos pesos 28be62e9, head.pt 7968f17b…).

Em cada repositório do Hub, a tag v1.0 aponta para o commit que carregou a ficha do Kev 1.0. Esse commit alterou apenas o README.md, por isso os seus pesos são os mesmos bytes que a revisão de pesos na primeira tabela: kev-0.8b bf75a6a8, kev-4b 6cfce5c2, kev-9b db029f08, kev-27b af0e6d55.

Plano de lançamento (para o responsável; não faz parte das notas publicadas)

Concluído em 2026-10-01 (registo runs/release/kev-1.0.json; PLAN.md “Released: Kev 1.0”). Passos 3 e 4: commits apenas da ficha, com v1.0 em cada commit da ficha (0.8B bf75a6a8, 4B 6cfce5c2, 9B db029f08, 27B af0e6d55; todos os outros ficheiros inalterados). Passos 5 e 6: recursos construídos duas vezes com hashes idênticos, o lançamento publicado e marcado como Latest. Passo 7: kev-family mantido, os seus recursos removidos, o seu corpo um ponteiro para kev-1.0, as suas notas antigas em runs/release/kev-family-notes-retired.md. Passo 8: pins inalterados. Passo 9: coleção e Space verificados; o Space não foi republicado. O plano tal como escrito antes do lançamento segue abaixo. Ordem:

1. Marcadores de posição: preenchidos (2026-10-01) a partir da leitura de contexto registada da ronda 28, runs/r28-readout/context.json (scripts/longdoc_report.py --context-margin -0.03 sobre runs/r28-{4b-r10,08b-r15}-longdoc, runs/r29-9b-r18a-longdoc e runs/r23-27b-k-w85-longdoc; em bruto runs/r28-context, ECE à temperatura de distribuição runs/r28-context-served), com os números em docs/claims.json.

2. Fundir este PR.

3. Fichas no Hub. Carrega cada ficha do 1.0 apenas como README.md (sem pesos): o kev.publish não é preciso para um commit apenas da ficha; hf upload jaredpalmer/kev-<size> docs/model-cards/kev-<size>.md README.md --commit-message "Kev 1.0 model card (weights unchanged)". Verifica com HfApi().model_info(..., files_metadata=True) que adapter_model.safetensors / head.pt (27B: model.safetensors.index.json e cada shard) têm o hash abaixo.

4. Tags no Hub. v1.0 nos quatro repositórios. Predefinição (conforme especificado): as revisões de pesos exatas; se o passo 3 correu primeiro, marca antes o commit da ficha, para que @v1.0 mostre a ficha do 1.0 (os pesos são idênticos byte a byte; registra ambos os commits no PLAN.md).

   Repositório	Alvo de v1.0 (pesos)	sha256 do adaptador / cabeça
   jaredpalmer/kev-0.8b	9a45d25eb2ab761841196625383fa1dff0e56c1e	9b908623… / f400bd12…
   jaredpalmer/kev-4b	139fdd94f1b6a6ad80cc15e08fcb99cac885a101	90e81735… / dd633435…
   jaredpalmer/kev-9b	b5d8c18e44c60888d138b65cb6507ff0a5a448a0	2b2a70cf… / 8e1dab2c…
   jaredpalmer/kev-27b	main (hoje ef78cc8a34d5f426fb229c52089db189218cfe5c: pesos 28be62e9, depois três commits apenas da ficha)	pesos d27af6ab… / cabeça 7968f17b…

   hf repos tag create jaredpalmer/kev-0.8b v1.0 --revision 9a45d25eb2ab761841196625383fa1dff0e56c1e -m "Kev 1.0"
   hf repos tag create jaredpalmer/kev-4b   v1.0 --revision 139fdd94f1b6a6ad80cc15e08fcb99cac885a101 -m "Kev 1.0"
   hf repos tag create jaredpalmer/kev-9b   v1.0 --revision b5d8c18e44c60888d138b65cb6507ff0a5a448a0 -m "Kev 1.0"
   hf repos tag create jaredpalmer/kev-27b  v1.0 --revision <main at release> -m "Kev 1.0"

5. Recursos. uv run python scripts/build_release_assets.py --release docs/releases/kev-1.0-assets.json --out /tmp/kev-1.0-assets constrói kev-0.8b.tar.gz, kev-4b.tar.gz, kev-9b.tar.gz (cada um: o snapshot do Hub na revisão acima, ou seja, adaptador, head.pt com a temperatura, ficheiros do tokenizer, o result.json do ensaio, provenance.json, training_config.json e training_metrics.json; a ficha do 1.0 como README.md; a leitura bloqueada como locked_test.json), SHA256SUMS.txt e manifest.json (sha256 de cada membro). Recusa um download cujo hash do adaptador ou da cabeça difira da especificação. O Kev-27B não é um recurso (51 GB; o GitHub limita um recurso a 2 GB): as notas apontam para o Hub.

6. Lançamento no GitHub. Marca kev-1.0 no commit de fusão; cria o lançamento como rascunho com a parte publicada destas notas como corpo (tudo acima desta secção), anexa os três tarballs e o SHA256SUMS.txt, descarrega-os de novo, shasum -a 256 -c SHA256SUMS.txt, extrai um e serve-o, depois publica e marca como Latest.

7. Um lançamento por tamanho. A política de lançamentos mantém apenas a melhor versão de cada tamanho num lançamento do GitHub. Depois de kev-1.0 ser publicado, kev-family duplica-o: apaga os seus três tarballs e o SHA256SUMS.txt e substitui o seu corpo por um ponteiro para kev-1.0 (ou apaga o lançamento; decisão do Jared). As versões anteriores ficam nas tags do Hub listadas em cada ficha.

8. Pins de implementação. skills/kev-deploy e skills/kev-finetune fixam o KEV_REF 71d4829; os checkpoints do 1.0 não precisam de código mais recente. Move o pin apenas se uma correção de serviço posterior deva ser lançada com o 1.0.

9. Coleção e Space. A coleção do Kev já lista os quatro repositórios. O Space serve o Kev-4B e o Kev-0.8B a partir de main, que são os pesos do 1.0; nada a republicar a menos que kev/model.py, kev/api.py ou kev/checkpoint.py tenham mudado depois da sua última publicação.