Kev 1.0

Kev 1.0 — первый версионированный релиз всего семейства Kev: четыре модели принятия решений, которые читают документ и набор типизированных вопросов и возвращают калиброванные вероятности по вариантам за один прямой проход, за API System One от TypeSafe. Ничего в нём не обучено заново. Он фиксирует чекпойнты, карточки моделей, оценочные наборы и код обслуживания, с которыми будет сравниваться следующее поколение Kev, с одним и тем же тегом (v1.0) в каждом репозитории Hub.

Что входит в 1.0

Ключевые числа (путь оценки fp32, каждая модель при своей поставляемой температуре; тест transfer-v4 закрыт и читался по одному разу на модель):

У hard-v1, devtools-v1 и documents-v1 есть обучающие сплиты, на которых обучался каждый Kev: эти строки измеряют отложенные элементы тренированных семейств, а не transfer. Строки breadth-v1 и transfer-v4 — это наборы данных, на которых ни один Kev не обучался. Jev читался только на девелоперских партициях и на тесте breadth-v1. Каждое число прослеживается до закоммиченного отчёта через docs/claims.json; остальное, с интервалами, есть в карточках моделей (docs/model-cards/).

Что изменилось с прошлого релиза семейства

Отсчитывается от GitHub-релиза kev-family в его первом собранном виде для текущего семейства 2026-09-24 (Kev-27B v1, Kev-9B v1 и те же Kev-4B и Kev-0.8B, что и здесь). Его обновления от 2026-09-30 (Kev-27B v2, Kev-9B v2) здесь тоже перечислены, поскольку именно в 1.0 они становятся частью версионированного релиза.

• Kev-27B v2: полные веса. Каждый вес Qwen3.8-27B дообучен на одну эпоху на корпусе из 145 840 записей, затем усреднён 0.85 / 0.15 с v1. Против v1 на тесте: отложенные наборы данных +1.2 п.п. [+0.3, +2.2], отложенные семейства задач +5.3 [+3.7, +6.8], навыки, инструменты и документы +8.9 [+7.5, +10.3]; закрытый тест вне домена 0.889 против 0.896, Brier 0.154 против 0.160. Хуже и самоувереннее на длинных контрактах (CUAD ECE 0.053 против 0.007). v1 находится в jaredpalmer/kev-27b@v1-lora.
• Kev-9B v2. v1 плюс одна эпоха на данных документов и навыков, которые уже были у Kev-4B и Kev-0.8B. Против v1 на тесте: hard-v1 + devtools-v1 +18.7 п.п. [+16.7, +20.8], documents-v1 +7.1 [+4.7, +9.2]; без изменений на закрытом тесте вне домена (0.852 в обоих) при Brier 0.199 против 0.224. v1 находится в jaredpalmer/kev-9b@v1.
• Никакого молчаливого усечения. Раньше сервер обрезал состояние длиннее своего лимита, не сообщая об этом. Теперь он отклоняет состояние свыше 65 536 токенов с 422, где указаны число токенов и лимит; KEV_TRUNCATE_STATES=1 возвращает усечение обратно, и тогда каждый ответ такого сервера говорит truncated. Навыки deploy и fine-tune фиксируют KEV_REF на коммите с этим исправлением и с изменениями для длинных документов и MLX ниже (71d4829), а Space был переопубликован после исправления.
• Длинные документы на всех размерах. Путь оценки держал внимание fp32 для длинных строк на математическом ядре, поэтому Kev-0.8B, 4B и 9B упирались в нехватку памяти GPU на состояниях в 32k–64k токенов. Теперь длинные строки используют экономичное по памяти ядро в fp32: Kev-4B читает состояние в 61k токенов за 17.2 с при 17.2 ГиБ сверх весов на H100, а короткие строки сохраняют свои логиты бит-в-бит. Именно это делает измеримыми проверенные длины контекста выше.
• Apple Silicon. Бэкенд MLX загружает чекпойнты с полными весами как есть, без слияния, что даёт Kev-27B путь на Mac (ожидается около 51 ГБ плюс рабочая память; на этом размере ещё не запускался). Длинные состояния префиллятся по 1 024 токена за раз, а кэш вытесняется перед прямым проходом, поэтому Kev-4B обслуживает состояние в 65 000 токенов на 32 ГБ M5 при пике 13.0 ГБ (84.5 с заново, 716 мс из кэша).
• Происхождение ядер. Каждый отчёт об оценке и каждый прогон теперь фиксирует набор ядер, от которого зависят его логиты (версии пакетов, GPU, dtype, реализации attention и DeltaNet), после того как изменение ядра в образе оценки сдвинуло чтения Kev-27B v1 на 0.03–0.06 по вероятности без изменений в собственном коде Kev.
• Аудит оценки. Три набора были удалены как непригодные для выбора моделей: scienthoon (шаблонные тикеты, один вопрос, на который текст ответить не может), WANLI-v2 / WANLI-v1 (четверть золотых меток — это выбор одного из двух несогласных аннотаторов) и публичные оценки TypeSafe (золото от двух закрытых моделей, слишком мало вопросов). Ключевые панели исключают элементы, которые аудит счёл неотвечаемыми или неразмеченными. Цифры прошлых релизов по этим наборам сохранены в их записях, а не в карточках 1.0.
• Калибровка. Kev-4B и Kev-0.8B поставляются с температурами, подогнанными на отложенных элементах их обучающих данных. Зарегистрированная перенастройка на отложенных наборах данных была оценена для обеих и принята ни для одной: она не улучшила Kev-4B (разница Brier −0.0001 [−0.0005, +0.0003]) и ухудшила калибровку Kev-0.8B на его семействах документов и навыков сильнее зарегистрированного допуска. Kev-9B и Kev-27B уже поставляются с температурами по отложенным наборам данных.
• Обучающие данные опубликованы. Обучающие партиции documents-v1 и hard-v1 находятся в датасете jaredpalmer/kev-suites, поэтому обучающие данные малых моделей можно получить и проверить по хешам.
• Проверенная длина контекста. Каждая карточка теперь указывает самое длинное состояние, на котором точность на контрактах CUAD остаётся в пределах 3 п.п. (95 % нижняя граница) от точности той же модели при 8k токенов. Kev-27B держится до 65 536 токенов, то есть до лимита обслуживания (его 64k нижняя граница −2.4 п.п.). Kev-0.8B, 4B и 9B подтверждают только свои обученные 8 192: каждый уже выходит за допуск на 16k (нижние границы −8.5, −3.4 и −3.7 п.п.), поэтому за пределами 8k токенов их ответы на длинных документах измерением не покрыты.
• Формальные карточки моделей. Все четыре карточки следуют одной структуре: сводка, детали, назначение и области вне охвата, как использовать, обучающие данные и процедура, оценка, ограничения, риски, вычисления, происхождение.

Известные ограничения

• Прирост в распределении. Большие улучшения последнего года — на наборах, чьи обучающие сплиты входят в обучающие данные. На наборах данных, где ни один Kev не обучался, Kev-27B отстаёт от Jev на 1.7 пункта индекса на тесте breadth-v1, а меньшие размеры — на 13–31 пункт.
• Необученные длины. Kev-0.8B, 4B и 9B обучались на состояниях не длиннее 7 552 токенов, а Kev-27B — не длиннее 32 768; сервер принимает 65 536. Используйте проверенную длину контекста, а не лимит обслуживания.
• Kev-27B на длинных контрактах менее точна, чем v1, и самоуверенна (CUAD test ECE 0.053 против 0.007); перенастройте температуру на собственных документах или используйте @v1-lora для проверки контрактов.
• Kev-0.8B и маршрутизация инструментов. Её точность When2Call упала ниже случайной (0.133 на тесте) после стадии документов и навыков; не используйте её для маршрутизации вызовов инструментов.
• Арифметика дат — самое слабое семейство на каждом размере ниже 27B (точность политики deadline 0.35 / 0.65 / 0.725 против 0.95 у Jev); KEV_DATE_FACTS=1 помогает.
• Знания задаются базой (MMLU-Pro 0.230–0.675 против 0.840 у Jev).
• Kev-9B на Mac не измерялась, а Kev-27B на Mac, как ожидается, помещается в 96–128 ГБ, но не запускалась.
• Отбор. Kev-27B v2 и Kev-9B v2 были пересмотрены по правилу после аудита с известными предыдущими девелоперскими чтениями; их тестовые запасы оптимистичны.
• Одна температура на модель не может переупорядочить уверенности, поэтому при бюджете ошибок 5 % модели автоматизируют меньше решений, чем Jev, вне домена.

Как запустить

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

Из тарболла релиза:

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

TypeSafe SDK работает без изменений: TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8009", model="kev-latest"). Kev-27B нужен один B200, H200 или H100 80 ГБ: --run jaredpalmer/kev-27b@v1.0. Чтобы развернуть HTTPS-эндпоинт на Modal, см. skills/kev-deploy.

Ассеты

Каждый тарболл содержит один чекпойнт в том виде, в каком он есть на Hub на своей ревизии весов (LoRA-адаптер, head.pt с температурой, файлы токенизатора, result.json обучающего прогона, provenance.json, training_config.json, training_metrics.json и журнал), карточку модели Kev 1.0 как README.md и закрытое чтение transfer-v4 как locked_test.json. Они собираются с помощью scripts/build_release_assets.py из docs/releases/kev-1.0-assets.json, и повторная сборка даёт те же байты. Каждый файл в них датирован 2026-10-01 00:00 UTC, что kev.serve сообщает как дату релиза распакованного чекпойнта. Тарболлы, впервые прикреплённые 2026-10-01, датировали свои файлы 1970-01-01, поэтому kev.serve сообщал 1969-12-31; в тот же день они были заменены на эти. Веса и каждый другой файл побайтово идентичны; изменились только хеши тарболлов.

Kev-27B не прикреплён, потому что его 51 ГБ весов превышают лимит GitHub в 2 ГБ на ассет. Скачайте его с Hub: jaredpalmer/kev-27b@v1.0 (коммит весов 28be62e9, head.pt 7968f17b…).

В каждом репозитории Hub тег v1.0 указывает на коммит, который загрузил карточку Kev 1.0. Этот коммит изменил только README.md, поэтому его веса — те же байты, что и ревизия весов в первой таблице: kev-0.8b bf75a6a8, kev-4b 6cfce5c2, kev-9b db029f08, kev-27b af0e6d55.

План релиза (для сопровождающего; не часть опубликованных заметок)

Сделано 2026-10-01 (запись runs/release/kev-1.0.json; PLAN.md «Released: Kev 1.0»). Шаги 3 и 4: коммиты только с карточками, с v1.0 на каждом коммите карточки (0.8B bf75a6a8, 4B 6cfce5c2, 9B db029f08, 27B af0e6d55; все прочие файлы без изменений). Шаги 5 и 6: ассеты собраны дважды с идентичными хешами, релиз опубликован и помечен как Latest. Шаг 7: kev-family сохранён, его ассеты удалены, его тело — указатель на kev-1.0, его прежние заметки в runs/release/kev-family-notes-retired.md. Шаг 8: пины без изменений. Шаг 9: коллекция и Space проверены; Space не переопубликовывался. Далее следует план в том виде, в каком он был написан до релиза. Порядок:

1. Плейсхолдеры: заполнены (2026-10-01) из зарегистрированного чтения контекста раунда 28, runs/r28-readout/context.json (scripts/longdoc_report.py --context-margin -0.03 по runs/r28-{4b-r10,08b-r15}-longdoc, runs/r29-9b-r18a-longdoc и runs/r23-27b-k-w85-longdoc; сырые runs/r28-context, ECE при поставляемой T runs/r28-context-served), с числами в docs/claims.json.

2. Смёржить этот PR.

3. Карточки Hub. Загрузить каждую карточку 1.0 только как README.md (без весов): kev.publish для коммита только с карточкой не нужен; hf upload jaredpalmer/kev-<size> docs/model-cards/kev-<size>.md README.md --commit-message "Kev 1.0 model card (weights unchanged)". Проверить через HfApi().model_info(..., files_metadata=True), что adapter_model.safetensors / head.pt (27B: model.safetensors.index.json и каждый шард) имеют хеши, как ниже.

4. Теги Hub. v1.0 во всех четырёх репозиториях. По умолчанию (как указано): точные ревизии весов; если шаг 3 выполнен первым, вместо этого пометить тегом коммит карточки, чтобы @v1.0 показывал карточку 1.0 (веса побайтово идентичны; зафиксировать оба коммита в PLAN.md).

   Репозиторий	цель v1.0 (веса)	adapter / head sha256
   jaredpalmer/kev-0.8b	9a45d25eb2ab761841196625383fa1dff0e56c1e	9b908623… / f400bd12…
   jaredpalmer/kev-4b	139fdd94f1b6a6ad80cc15e08fcb99cac885a101	90e81735… / dd633435…
   jaredpalmer/kev-9b	b5d8c18e44c60888d138b65cb6507ff0a5a448a0	2b2a70cf… / 8e1dab2c…
   jaredpalmer/kev-27b	main (сегодня ef78cc8a34d5f426fb229c52089db189218cfe5c: веса 28be62e9, затем три коммита только с карточками)	веса d27af6ab… / head 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. Ассеты. uv run python scripts/build_release_assets.py --release docs/releases/kev-1.0-assets.json --out /tmp/kev-1.0-assets собирает kev-0.8b.tar.gz, kev-4b.tar.gz, kev-9b.tar.gz (каждый: снимок Hub на ревизии выше, то есть адаптер, head.pt с температурой, файлы токенизатора, result.json прогона, provenance.json, training_config.json и training_metrics.json; карточка 1.0 как README.md; закрытое чтение как locked_test.json), SHA256SUMS.txt и manifest.json (sha256 каждого члена). Он отклоняет загрузку, чей хеш адаптера или головы отличается от спецификации. Kev-27B не ассет (51 ГБ; GitHub ограничивает ассет 2 ГБ): заметки указывают на Hub.

6. Релиз GitHub. Пометить тегом kev-1.0 коммит слияния; создать релиз как черновик с опубликованной частью этих заметок в теле (всё выше этого раздела), прикрепить три тарболла и SHA256SUMS.txt, скачать их обратно, shasum -a 256 -c SHA256SUMS.txt, распаковать один и запустить его, затем опубликовать и пометить как Latest.

7. Один релиз на размер. Политика релизов оставляет в GitHub-релизе только лучшую версию каждого размера. Как только kev-1.0 опубликован, kev-family его дублирует: удалить его три тарболла и SHA256SUMS.txt и заменить его тело указателем на kev-1.0 (либо удалить релиз; решать Jared). Более ранние версии остаются на тегах Hub, перечисленных в каждой карточке.

8. Пины деплоя. skills/kev-deploy и skills/kev-finetune фиксируют KEV_REF 71d4829; чекпойнтам 1.0 более новый код не нужен. Двигайте пин только если более позднее исправление обслуживания должно выйти с 1.0.

9. Коллекция и Space. Коллекция Kev уже перечисляет четыре репозитория. Space обслуживает Kev-4B и Kev-0.8B из main, а это и есть веса 1.0; переопубликовывать нечего, если только kev/model.py, kev/api.py или kev/checkpoint.py не изменились после его последней публикации.