Мы перенесли методы криптоанализа в область искусственного интеллекта, создав точную инфраструктуру для диагностики и коррекции квантованных слоёв в модели gpt-oss-20b-TurboQuant-MLX-8bit. Вместо традиционного fine-tuning мы не меняли архитектуру и не дообучали модель. Вместо этого мы превратили квантованный слой из чёрного ящика в наблюдаемый, проверяемый и локально корректируемый объект.

Почему переход от криптографии к ИИ логичен

В криптографии мы научились видеть за подписью Schnorr не магию, а аффинную структуру: приватный ключ, nonce, challenge и подпись образуют линейную систему. Это позволило заменить слепое доверие протоколу на строгую математическую проверку.

В ИИ мы сделали то же самое. Вместо вопроса «отвечает ли модель хорошо?» мы спустились на уровень её внутренней линейной алгебры: квантованные коды, scale/bias, активации и эталонные выходы. Теперь главный вопрос — можно ли представить слой как точный аффинный объект, наблюдать его поведение и локально исправлять без разрушения всей модели?

Мы построили exact AI-forensics pipeline, в котором квантованный слой перестаёт быть чёрным ящиком и становится объектом инженерной диагностики.

Что мы взяли и что изменили

Мы не меняли архитектуру, attention, токенизатор или inference-пайплайн. Мы изменили способ работы с моделью:

• перестали воспринимать .safetensors как opaque-контейнер;
• научились извлекать квантованные коды, scale и bias;
• стали захватывать реальные BF16-активации с живого MLX-рантайма;
• свели коррекцию весов к задаче целочисленной оптимизации;
• реализовали безопасную запись патча обратно в модель;
• добавили smoke-check для проверки совпадения offline-математики и runtime-поведения.

Ключевые шаги метода

Шаг 1. Точный доступ к .safetensors

Мы написали мост к MLX-квантованию, позволяющий:

• находить нужный тензор;
• читать его raw-представление;
• извлекать квантованные коды и параметры масштабирования;
• записывать изменённые коды обратно.

Без этого веса остаются «готовым blob», и точная работа с ними невозможна.

Шаг 2. Детерминированный calibration cache

Мы собрали стабильный набор примеров для воспроизводимости экспериментов. Каждый запуск использует:

• один и тот же набор данных;
• один и тот же слой;
• один и тот же вход и эталонный выход;
• одну и ту же метрику ошибки.

Это исключает «кажется, стало лучше» и превращает анализ в инженерную процедуру.

Шаг 3. Захват реальных активаций

Мы не симулируем слой — мы захватываем pre_linear_input и linear_output_reference с последнего токена в реальном MLX-рантайме. Это данные, которые модель генерирует сама, а не абстрактная модель.

Математическая модель квантованного слоя

Квантованный слой мы представили как аффинную систему. Пусть веса разбиты на блоки. Для каждого блока:

• c — вектор квантованных кодов;
• s — scale;
• b — bias.

Деквантованный вес: w = s ⋅ c + b. Выход слоя — линейная комбинация входа и деквантованных весов. Это превращает слой в систему, поддающуюся точной оптимизации.

Оптимизация: локальная и консервативная

Мы ищем новый кодовый вектор, который:

• лучше воспроизводит эталонный выход;
• не уходит далеко от исходных кодов;
• ограничен по максимальному изменению одного кода.

Задача — регуляризованная целочисленная оптимизация с жёсткими ограничениями. Цель — не переписать слой целиком, а чинить локально и контролируемо.

Ключевое ограничение: нужен внешний эталон

Если цель оптимизации — сам квантованный слой, лучший патч — ничего не менять.

Без внешнего эталона (реальные активации, holdout, reference-output) любое «улучшение» будет иллюзорным. Именно поэтому наш pipeline строится вокруг захвата и holdout, а не самосравнения.

Результаты: q_proj vs router

Аудит q_proj: жёсткая структура

Слой q_proj оказался структурно «жёстким»:

• нет тривиальных повторов;
• нет клонов блоков;
• нет симметрий или компрессии.

Система не нашла non-identity патчей. Это не ошибка — это доказательство границ применимости метода.

Успех с router: устойчивое улучшение

Для слоя model.layers.0.mlp.router.weight мы построили полный pipeline:

• calibration cache;
• runtime capture;
• blockwise оптимизация;
• holdout validation;
• safe patch;
• smoke-check.

На train-shard MSE упал с 0.02297 до 3e-11. На holdout — с 0.02278 до 4.37e-5. Коэффициент переноса — 0.99. Это не переобучение, а устойчивая локальная корректировка.

Safe patch и smoke-check: от математики к реальности

После расчёта патч был безопасно записан в .safetensors с контролем readback. Но самый важный этап — smoke-check.

Он показал: вход в слой воспроизводится идеально, но реальный runtime-выход не совпал с offline-эталоном, несмотря на отличные метрики в solver-отчётах.

На первый взгляд — ошибка. На самом деле — прорыв:

Система умеет обнаруживать расхождение между offline-моделью и реальной семантикой MLX-рантайма.

Что мы реально изменили

Мы не меняли модель. Мы изменили логику работы с ней:

• точное чтение кодов;
• разбор по блокам;
• захват BF16-активаций;
• ограниченная integer-оптимизация;
• безопасная запись патча;
• проверка на несоответствие runtime.

Теперь MLX-дистрибутив — не чёрный ящик, а система, которую можно инструментировать и хирургически править.

Возможности системы

• Exact audit — разбор весов до уровня U32-кодов и block geometry.
• Runtime capture — снятие активаций с живого MLX-рантайма.
• Локальная коррекция — патчинг без разрушения слоя.
• Safe patching — запись с контролем точного совпадения.
• Holdout validation — отличие улучшения от переобучения.
• Runtime mismatch detection — обнаружение расхождения между математикой и исполнением.

Что мы пока не утверждаем

Мы не заявляем, что:

1. любой слой можно исправить;
2. q_proj уже улучшен;
3. семантика MLX полностью раскодирована;
4. AI усиливает криптоанализ end-to-end;
5. lattice-методы готовы к production.

Но мы можем утверждать:

Построена рабочая exact AI-forensics инфраструктура для квантованной MLX-модели.

Почему это важнее fine-tuning

Обычный fine-tuning спрашивает: «как сделать модель в среднем лучше?».

Мы спрашиваем: «что делает конкретный слой, как он устроен, и можно ли его локально исправить с полным контролем?».

Это другой уровень доступа — не «подкрутить поведение», а разобрать внутреннюю механику до уровня квантованных кодов.

Именно поэтому AI-ветка у нас выросла не из MLOps, а из криптоанализа. Задача одна и та же:

Перестать верить чёрному ящику и заменить веру — наблюдаемой структурой.

Итог

Мы добавили к модели не скрипт, а целую инфраструктуру:

• bridge к .safetensors;
• calibration cache;
• BF16 capture;
• blockwise optimization;
• safe patch;
• holdout validation;
• runtime smoke-check.

Подтверждённые результаты:

1. router-слой допускает осмысленную локальную коррекцию с переносом на holdout;
2. offline-модель и MLX-рантайм ещё не совпадают, но система это честно обнаруживает.

Сегодня мы умеем в ИИ то же, что делаем в криптографии:

Выделять объект, формализовать его как аффинную систему, локально исправлять и проверять, не обманывает ли нас среда исполнения.

AI перестаёт быть «магией модели» — он становится объектом точной инженерной диагностики. И это, похоже, только начало.

как мы взяли gpt-oss-20b-TurboQuant-MLX-8bit, изменили логику наблюдения и научились точечно исправлять квантованные слои

В прошлой статье я показывал, что подписьSchnorr / MuSig2можно рассматривать не как «чёрный ящик», а как систему наблюдаемых affine-структур: через строгий BIP340 membership bridge, семейства скрытых нонсов, compression/connectivity-метрики и protocol-valid линеаризацию MuSig2 partial signaturesХабр. Это меняет саму оптику: вместо «верим протоколу на слово» мы начинаем разбирать его на проверяемые математические блоки.

Следующий шаг оказался неожиданным, но логичным.

Мы перенесли ту же самую методологию в AI.

Не в смысле «взяли LLM и начали её тюнинговать». А в смысле:взяли квантованную MLX-модель и стали исследовать её внутреннюю математику так же, как раньше исследовали подписи.

Объектом эксперимента стал локальный дистрибутив:

Мы не меняли архитектуру модели, не переписывали attention и не занимались классическим fine-tuning. Мы сделали другое:

• научились читать.safetensorsкак точную структуру;
• построили детерминированный calibration cache;
• начали снимать реальные BF16-активации с конкретных слоёв;
• свели локальную коррекцию весов к ограниченной задаче целочисленной оптимизации;
• сделали безопасную запись patch обратно в модель;
• и добавили smoke-check, который проверяет, совпадает ли offline-математика с реальным runtime MLX.

Главный результат этой статьи звучит так:

мы не «улучшили модель магией», а построилиexact AI-forensics pipeline, в котором квантованный слой перестаёт быть чёрным ящиком и становится наблюдаемым, проверяемым и локально корректируемым объектом.

Почему переход от Schnorr к AI вообще естественен

В криптографии всё началось с очень простой идеи: если объект допускает строгую нормализацию, то его можно не только использовать, но иисследовать как геометрию скрытых параметров.

Для подписи Schnorr базовое соотношение имеет вид:

• — приватный ключ,
• — nonce,
• — challenge,
• — скаляр подписи.

Это уже не «магия подписи», а линейная структура.

В AI мы сделали тот же самый ход.

Мы перестали смотреть на модель как на функцию «промпттекст» и спустились ниже — к тому месту, где живёт её внутренняя линейная алгебра:

• квантованные коды,
• scale/bias,
• входные активации,
• эталонные выходы линейного слоя.

То есть вопрос поменялся.

«Модель отвечает хорошо или плохо?»

«Можно ли представить конкретный квантованный слой как точный affine-объект, наблюдать его поведение и локально исправлять без разрушения всей модели?»

Вот это и есть AI-forensics.

Что именно мы взяли

Базой стал MLX-дистрибутив:

Нас интересовали два конкретных слоя первого блока:

Почему именно они?

Потому что это хороший тест на два разных сценария:

1. слой, который может оказаться слишком «жёстким» для осмысленного patch без внешнего эталона;
2. слой, который, наоборот, допускает локальную корректировку.

Именно на этом контрасте и проявляется ценность метода.

Что именно мы изменили

Важно сразу зафиксировать:мы не меняли архитектуру модели.

Мы изменили не «мозг модели», аспособ работы с ним.

• .safetensorsкак opaque-контейнер;
• квантованные веса как «что-то внутри рантайма»;
• оценка модели только по финальному текстовому выходу.

• точный доступ к сырому весовому представлению;
• выделение кодов квантования, scale и bias;
• runtime-захват входа и выхода конкретного линейного слоя;
• локальная integer-оптимизация кодов;
• безопасная обратная запись патча;
• обязательная проверка, что математика offline не расходится с реальным исполнением.

Проще говоря:

мы превратили квантованный слой из «непрозрачной детали модели» в объект инженерной диагностики.

Шаг 1. Exact bridge к .safetensors

Первое, что пришлось сделать, — написать мост к MLX-квантованию.

• находить нужный тензор в модели;
• читать его raw-представление;
• извлекать квантованные коды;
• читатьBF16-масштабы и смещения;
• при необходимости записывать изменённые коды обратно.

Это важный момент.

Пока веса модели воспринимаются как «готовый blob», никакой точной работы с ними не получится. Нужно сначала развернуть этот blob в нормальную математическую структуру.

Шаг 2. Детерминированный calibration cache

Следующий шаг — calibration cache.

Мы заранее собрали стабильный набор примеров:

Всего примеров

Splitgeneral

Splitlogic

Размер шарда

Политика захвата

last-token

Тип активаций

Зачем это нужно?

Чтобы каждый следующий эксперимент был воспроизводимым. Не «кажется, стало лучше», а:

• вот тот же набор,
• вот тот же слой,
• вот тот же вход,
• вот тот же эталонный выход,
• вот та же метрика ошибки.

Без этого всё быстро превращается в storytelling.

Шаг 3. Захват реальных активаций

После этого мы добавили runtime-capture для конкретных линейных слоёв.

Для каждого выбранного примера сохранялись:

• pre_linear_input
• linear_output_reference

Причём именно для последнего токена.

Это очень важно.

Мы не симулируем слой отдельно от модели, а снимаем егос живого MLX-runtime. То есть дальше работаем уже не с абстрактной линейной алгеброй, а с данными, которые модель реально порождает сама.

Математическая модель квантованного слоя

Теперь можно записать слой в виде нормальной формулы.

Пусть строка весов разбита на блоки длины. Для строкии блокаобозначим:

• — вектор квантованных кодов длины;
• — scale;
• — bias.

Тогда деквантованный блок весов задаётся как

где— вектор из единиц длины.

Если входной вектор для примераразбит по тем же блокам:

то выход по координатеравен

или, после подстановки деквантования,

Вот здесь и появляется главный мост.

Квантованный слой перестаёт быть «набором непонятных байтов» и становитсяaffine-системой над дискретными кодами.

Что именно мы оптимизируем

Для выбранного блока мы ищем новый кодовый вектор, который лучше воспроизводит reference-output, но не уезжает слишком далеко от исходного.

Оптимизационная задача имеет вид:

при ограничениях

• — исходные коды блока;
• — коэффициент регуляризации;
• — максимально допустимое изменение одного кода.

В наших экспериментах для router-слоя использовались:

Размер блока

Ridge lambda

Max code delta abs

То есть patch изначально делалсяконсервативным:

• не переписывать слой целиком;
• не менять десятки тысяч параметров без контроля;
• не уходить далеко от исходной структуры;
• чинить локально и в ограниченном окне.

Важная теорема: почему без внешнего эталона честного patch не будет

Это ключевая граница метода.

Если в качестве цели мы используемтекущий же квантованный слой, то любой exact-поиск патча даёт тривиальный оптимум:ничего не менять.

Пусть исходное состояние слоя задаётся тройкой:

и пусть функционал ошибки имеет вид

1. для любой допустимой конфигурации;
2. ;
3. ноль достигается только в точке.

Тогда минимум уже достигнут в исходном состоянии, потому что меньше нуля уйти нельзя.

Следовательно, если мы пытаемся «улучшить» слой, используя как цель сам этот слой, то лучшая стратегия —ничего не менять.

Чтобы non-identity patch был математически осмысленным, нуженвнешний эталон:

• реальные runtime-активации;
• reference-output;
• отдельный holdout.

Именно поэтому в нашей системе pipeline строится вокруг capture и holdout, а не вокруг самосравнения модели с самой собой.

Что показал аудит q_proj

Первым тестовым кандидатом был слой

Мы прогнали по нему exact-аудит.

Структурная картина

Total rows

Decoded width

Blocks per row

Total blocks

Unique rows

Repeated rows

Unique blocks

Repeated blocks

Exact equal adjacent block pairs

Это очень показательная таблица.

Слой оказался структурно «жёстким»:

• без тривиальных повторов;
• без клонов блоков;
• без дешёвых exact-симметрий;
• без готовой компрессии, которую можно было бы легко использовать для patch.

В результате финальный вывод поq_projоказался жёстким, но правильным:

Итог поq_proj

Self-target identity optimum

External reference required

Non-identity patch justified

Exact patch candidates found

И это хороший результат.

Потому что система не «придумала улучшение», а доказала границу применимости метода.

Где patch действительно сработал: router

Совсем другая история получилась для слоя

Для него был построен полный pipeline:

• calibration cache,
• runtime activation capture,
• blockwise LWO-оптимизация,
• holdout validation,
• safe patch,
• smoke-check.

Параметры эксперимента

gpt-oss-20b-TurboQuant-MLX-8bit

model.layers.0.mlp.router.weight

Train shard

general_0000_0128

Holdout shard

logic_0000_0128

Train sample count

Holdout sample count

Block size

Ridge lambda

Max code delta abs

Результат на train

На train-shard улучшение получилось почти идеальным.

Baseline MSE

0.022966404894191328

Patched MSE

3.000931005970632e-11

0.022966404864182017

Changed blocks

Changed codes total

На этом месте легко было бы сказать: «готово, мы вылечили слой».

Но это был бы неправильный вывод.

Train почти всегда можно улучшить. Главный вопрос —переносится ли эффект дальше.

Проверка на holdout

Вот здесь начинается самое интересное.

Baseline MSE

0.022778386753429913

Patched MSE

4.3748027306868276e-05

0.022734638726123045

Transfer ratio

0.9899084711155454

Holdout improves

Overfit suspected

То есть improvement почти полностью перенёсся на отдельный shard.

Можно записать это совсем кратко:

Это уже не похоже на случайное попадание или подгонку под четыре точки. Это означает, что система действительно нашлалокальную корректировку, которая несёт устойчивый эффект.

Safe patch: почему это не просто красивый отчёт

После вычисления патча его нужно было ещё записать обратно в модель.

Для этого был реализован safe patch workflow:

1. сохранить backup;
2. упаковать новые коды вU32;
3. записать их в.safetensors;
4. перечитать и проверить exact match.

Результат записи

Changed blocks

Changed codes total

Rawu32words changed

Write applied

Readback exact match

То есть система умеет не только посчитать патч, но икорректно внедрить его в реальный модельный файл.

Именно здесь начинается инженерия, а не просто исследование на бумаге.

Самая честная часть всей истории: smoke-check

После записи патча был выполнен runtime smoke-check.

И вот здесь система показала, зачем вообще нужна строгая проверка.

Smoke-check: General

Input exact rows

Output exact rows

Input runtime vs reference MSE

Output runtime vs reference MSE

0.023193681612610817

Output changed raw BF16 values

Smoke-check: Logic

Input exact rows

Output exact rows

Input runtime vs reference MSE

Output runtime vs reference MSE

0.021752476692199707

Output changed raw BF16 values

Что это значит?

Очень просто:

• вход в слой воспроизводится идеально;
• а вот реальный runtime-output после записине совпалс offline-reference, несмотря на сильный результат в solver-отчётах.

На первый взгляд это выглядит как плохая новость. На самом деле — наоборот.

Это означает, что система умеет обнаруживать расхождение между:

• offline-моделью деквантования,
• и реальной семантикой исполнения в MLX runtime.

То есть она не просто «генерирует патчи», а умеет поймать момент, когда красивая математика перестаёт совпадать с реальностью исполнения.

Это очень важная способность.

Что мы реально изменили в модели

Чтобы не перегибать с формулировками, зафиксирую аккуратно.

Мыне меняли:

• архитектуру модели;
• число слоёв;
• механизм attention;
• tokenizer;
• high-level inference pipeline.

Мыизменили логику работы с её внутренними квантованными слоями:

• добавили точное чтение кодов;
• добавили разбор по блокам;
• добавили BF16 activation capture;
• добавили constrained integer patching;
• добавили safe write-back;
• добавили post-patch reality check.

То есть фактически мы превратили MLX-дистрибутив из «готовой коробки» всистему, которую можно инструментировать, диагностировать и хирургически править.

Что теперь умеет наша система

Если собрать всё вместе, получается уже довольно сильный capability map.

1. Exact audit квантованных слоёв

Система умеет разбирать внутреннее представление веса на уровне:

• U32-кодов,
• uint8-декодирования,
• BF16scale/bias,
• block geometry.

2. Runtime capture живой модели

Она умеет снимать реальные входы и выходы линейного слоя на настоящем MLX-runtime, а не на симуляторе.

3. Локальную integer-коррекцию

Она умеет искать ограниченный patch для конкретных блоков без разрушения всего слоя.

4. Safe patching

Она умеет записывать корректировку обратно в.safetensorsс контролем readback.

5. Holdout validation

Она умеет отличать реальное улучшение от переобучения на крошечном calibration-shard.

6. Runtime mismatch detection

Она умеет обнаружить, что offline-патч красив, но среда исполнения интерпретирует его иначе.

И вот это, пожалуй, одна из самых сильных возможностей системы на текущем этапе.

Что мы пока не заявляем

Чтобы статья оставалась инженерной, а не рекламной, зафиксирую и ограничения.

Мы покане утверждаем, что:

1. любой слой можно исправлять одинаково успешно;
2. q_projуже улучшен — нет, там система честно упёрлась в границу метода;
3. runtime-семантика MLX уже полностью раскодирована;
4. AI-ветка уже усиливает криптоаналитический recovery end-to-end;
5. вся lattice-ветка для AI уже production-ready.

Но мы вполне можем утверждать другое:

построенарабочая exact AI-forensics инфраструктурадля квантованной MLX-модели.

И это уже немало.

Почему это интереснее обычного fine-tuning

Обычный fine-tuning отвечает на вопрос:

как сделать модель в среднем лучше на задаче?

Наш подход отвечает на другой вопрос:

что делает конкретный квантованный слой, как он устроен в exact-представлении, и можно ли изменить его локально, не теряя контроля над каждым шагом?

Это другой уровень доступа.

Не «подкрутить поведение модели», аразобрать её внутреннюю линейную механику до уровня кодов квантования.

Именно поэтому эта AI-ветка выросла у нас не из MLOps, а из криптоанализа.

Потому что и там, и здесь задача одна и та же:

перестать верить чёрному ящику и заменить веру наблюдаемой структурой.

Если сформулировать совсем коротко, то произошло следующее.

Мы взялиgpt-oss-20b-TurboQuant-MLX-8bitи добавили к нему не «ещё один AI-скрипт», а целую exact-инфраструктуру:

• bridge к.safetensors,
• calibration cache,
• BF16 activation capture,
• constrained blockwise optimization,
• safe patch,
• holdout validation,
• runtime smoke-check.

Подтверждённый итог на текущем этапе двойной:

1. router-слой действительно допускает осмысленную локальную коррекцию, причём эффект переносится на holdout;
2. offline-модель патча и реальная MLX runtime-семантика ещё не совпадают полностью, и система это умеет честно обнаруживать.

А значит, сегодня наша система уже умеет делать не только криптографическую forensics-диагностику, но и то же самое внутри квантованной нейросети:

выделять слой, формализовать его как affine-объект, локально исправлять и проверять, не обманывает ли нас сама среда исполнения.

Именно в этом месте AI перестаёт быть «магией модели» и становитсяобъектом точной инженерной диагностики.

Короткое послесловие

Эта работа не про «волшебное улучшение LLM». Она про другое: как перенести дисциплину криптоанализа в AI и научиться работать с квантованной моделью так же строго, как мы работаем с протоколами подписи.

То есть не «верить, что внутри что-то происходит», авидеть, измерять, патчить и проверять.

И это, похоже, только начало.