Kev 1.0

O Kev 1.0 é o primeiro release 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, em uma única passada direta, por trás da API System One da TypeSafe. Nada nele foi treinado de novo. Ele fixa os checkpoints, as fichas dos modelos, as suítes 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 todo repositório do Hub.

O que há no 1.0

Números principais (caminho de avaliação em fp32, cada modelo na sua temperatura de entrega; o teste do transfer-v4 é bloqueado e foi lido uma vez por modelo):

O hard-v1, o devtools-v1 e o documents-v1 têm partições de treinamento em que todo Kev treinou: 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. Todo número remonta a um relatório versionado por meio de docs/claims.json; as fichas dos modelos (docs/model-cards/) têm o resto, com intervalos.

O que mudou desde o último release da família

Medido a partir do release kev-family do GitHub como montado 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 daqui). As suas atualizações de 2026-09-30 (Kev-27B v2, Kev-9B v2) também estão listadas aqui, já que o 1.0 é onde elas passam a fazer parte de um release versionado.

• Kev-27B v2: pesos completos. Todo peso do Qwen3.8-27B ajustado por uma época em um corpus de 145,840 registros, depois promediado 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 tarefa reservadas +5.3 [+3.7, +6.8], habilidades, ferramentas e documentos +8.9 [+7.5, +10.3]; teste bloqueado fora do domínio 0.889 contra 0.896, Brier 0.154 contra 0.160. Pior e confiante demais 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 habilidades 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]; nível no teste bloqueado fora do domínio (0.852 nos dois) com Brier 0.199 contra 0.224. A v1 está em jaredpalmer/kev-9b@v1.
• Sem truncamento silencioso. O servidor costumava cortar um estado maior que o seu limite sem avisar. Agora ele recusa um estado acima de 65,536 tokens com um 422 que informa a contagem de tokens e o limite; KEV_TRUNCATE_STATES=1 volta a optar pelo truncamento, e toda resposta de um servidor assim passa a dizer truncated. As skills de deploy e de ajuste fino fixam KEV_REF em um commit que tem essa correção e as mudanças de documento longo e MLX abaixo (71d4829), e o Space foi republicado depois da correção.
• Documentos longos em todos os tamanhos. O caminho de avaliação mantinha atenção em fp32 para linhas longas no kernel matemático, então o Kev-0.8B, o 4B e o 9B ficavam sem memória de GPU em estados de 32k–64k tokens. As linhas longas agora rodam o 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 em uma H100, e as linhas mais curtas mantêm os seus logits bit a bit. É isso que torna mensuráveis os comprimentos de contexto validados acima.
• Apple Silicon. O backend MLX carrega checkpoints de pesos completos como salvos, sem mesclagem, o que dá ao Kev-27B um caminho em Mac (espera-se que precise de cerca de 51 GB mais memória de trabalho; ainda não executado nesse tamanho). Estados longos são preenchidos 1,024 tokens por vez e o cache é esvaziado antes de uma passada, então o Kev-4B serve um estado de 65,000 tokens em um M5 de 32 GB com pico de 13.0 GB (84.5 s novo, 716 ms em cache).
• Procedência do kernel. Todo relatório de avaliação e trial agora registra o conjunto de kernels de que os seus logits dependem (versões de pacotes, GPU, dtype, implementações de atenção e DeltaNet), depois que uma mudança de kernel na imagem de avaliação foi descoberta movendo as leituras do Kev-27B v1 em 0.03–0.06 de probabilidade sem mudança no código do próprio Kev.
• Auditoria de avaliação. Três suítes foram removidas por insólidas para selecionar modelos: scienthoon (tickets templated, uma pergunta que o texto não consegue responder), WANLI-v2 / WANLI-v1 (um quarto dos rótulos gabarito são de um de dois anotadores em discordância) e as avaliações públicas da TypeSafe (gabarito de dois modelos fechados, perguntas poucas demais). Os painéis principais excluem itens que a auditoria considerou irrespondíveis ou não rotulados. Os números de releases passados nessas suítes são mantidos nos seus registros, não nas fichas do 1.0.
• Calibração. O Kev-4B e o Kev-0.8B entregam temperaturas ajustadas em itens reservados dos seus dados de treinamento. Um reajuste registrado em conjuntos de dados reservados foi avaliado para os dois e adotado para nenhum: não melhorou o Kev-4B (diferença de Brier −0.0001 [−0.0005, +0.0003]), e deixou o Kev-0.8B pior calibrado nas suas famílias de documento e habilidade por mais que a tolerância registrada. O Kev-9B e o Kev-27B já entregam temperaturas de conjuntos de dados reservados.
• Dados de treinamento publicados. As partições de treinamento do documents-v1 e do hard-v1 estão no conjunto de dados jaredpalmer/kev-suites, então os dados de treinamento dos modelos pequenos podem ser obtidos e verificados por hash.
• Comprimento de contexto validado. Cada ficha agora declara o estado mais longo no qual a acurácia em contratos CUAD fica dentro de 3 pp (limite inferior de 95%) da do mesmo modelo em 8k tokens. O Kev-27B se mantém até 65,536 tokens, o limite de serviço (o seu limite inferior em 64k é −2.4 pp). O Kev-0.8B, o 4B e o 9B validam apenas os seus 8,192 treinados: cada um já perde a tolerância em 16k (limites inferiores −8.5, −3.4 e −3.7 pp), então além de 8k tokens as suas respostas em documentos longos não são cobertas pela medição.
• Fichas de modelo formais. As quatro fichas seguem uma estrutura: resumo, detalhes, usos pretendidos e fora de escopo, como usar, dados e procedimento de treinamento, avaliação, limitações, riscos, computação, procedência.

Limitações conhecidas

• Ganhos dentro da distribuição. Os grandes ganhos do último ano estão em suítes cujas partições de treinamento estão nos dados de treinamento. 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. Use o comprimento de contexto validado, não o limite de serviço.
• O Kev-27B em contratos longos é menos acurado que a v1 e confiante demais (CUAD test ECE 0.053 contra 0.007); reajuste a temperatura nos seus próprios documentos ou use @v1-lora para revisão de contratos.
• Kev-0.8B e roteamento de ferramentas. A sua acurácia no When2Call caiu abaixo do acaso (0.133 no teste) depois do seu estágio de documentos e habilidades; não o use para roteamento de chamadas de ferramenta.
• A aritmética de datas é a família mais fraca em todo tamanho abaixo de 27B (acurácia na política deadline 0.35 / 0.65 / 0.725 contra 0.95 do Jev); KEV_DATE_FACTS=1 ajuda.
• O conhecimento é definido pela base (MMLU-Pro 0.230–0.675 contra 0.840 do Jev).
• O Kev-9B em um Mac não foi medido, e espera-se que o Kev-27B em um Mac caiba em 96–128 GB, mas ele não foi executado.
• 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 confianças, então com um orçamento de erro de 5% os modelos automatizam menos decisões que o Jev fora do domínio.

Como executar

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 release:

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 implantar um endpoint HTTPS no Modal, veja skills/kev-deploy.

Artefatos

Cada tarball contém um checkpoint como ele está no Hub na sua revisão de pesos (adaptador LoRA, head.pt com a temperatura, arquivos do tokenizador, o result.json do trial de treinamento, provenance.json, training_config.json, training_metrics.json e log), a ficha do Kev 1.0 como README.md, e a leitura bloqueada do transfer-v4 como locked_test.json. Eles são construídos por scripts/build_release_assets.py a partir de docs/releases/kev-1.0-assets.json, e reconstruir dá os mesmos bytes. Todo arquivo neles está datado de 2026-10-01 00:00 UTC, que o kev.serve reporta como a data de release de um checkpoint desempacotado. Os tarballs anexados pela primeira vez em 2026-10-01 datavam os seus arquivos de 1970-01-01, então o kev.serve reportava 1969-12-31; eles foram substituídos no mesmo dia por estes. Os pesos e todos os outros arquivos são idênticos byte a byte; apenas os hashes dos tarballs mudaram.

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

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

Plano de release (para o mantenedor; não faz parte das notas publicadas)

Concluído em 2026-10-01 (registro 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 de ficha (0.8B bf75a6a8, 4B 6cfce5c2, 9B db029f08, 27B af0e6d55; todo outro arquivo inalterado). Passos 5 e 6: artefatos construídos duas vezes com hashes idênticos, o release publicado e marcado como Latest. Passo 7: kev-family mantido, os seus artefatos 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 como escrito antes do release segue. Ordem:

1. Placeholders: preenchidos (2026-10-01) a partir do read-out de contexto registrado da rodada 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; ECE bruto runs/r28-context, ECE na T de entrega runs/r28-context-served), com os números em docs/claims.json.

2. Merge deste PR.

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

4. Tags do Hub. v1.0 nos quatro repositórios. Padrão (como especificado): as revisões exatas dos pesos; se o passo 3 rodou primeiro, marque o commit da ficha em vez disso, para que @v1.0 mostre a ficha do 1.0 (os pesos são idênticos byte a byte; registre os dois 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 só de 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. Artefatos. 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, isto é, adaptador, head.pt com a temperatura, arquivos do tokenizador, o result.json do trial, 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 (o sha256 de cada membro). Ele recusa um download cujo hash de adaptador ou cabeça difira da especificação. O Kev-27B não é um artefato (51 GB; o GitHub limita um asset a 2 GB): as notas apontam para o Hub.

6. Release do GitHub. Marque a tag kev-1.0 no commit de merge; crie o release como rascunho com a parte publicada destas notas como corpo (tudo acima desta seção), anexe os três tarballs e o SHA256SUMS.txt, baixe-os de volta, shasum -a 256 -c SHA256SUMS.txt, extraia um e sirva-o, então publique e marque como Latest.

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

8. Pins de deploy. skills/kev-deploy e skills/kev-finetune fixam KEV_REF 71d4829; os checkpoints do 1.0 não precisam de código mais novo. Mova o pin apenas se uma correção de serviço posterior deva sair 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 do 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.