Итог дня
Читаю результаты прогона…
| Метрика | До | После | Разница |
|---|
- Повторов на вопрос — нет данных. Разница в один-два вопроса между осями может быть шумом температуры, а не свойством оси.
- нет данных
- Мерено на ноутбуке, а не на проде: на прод переносятся качество и ограничения модели, не секунды.
- Оценку ставит судья — нет данных, то есть модель, а не код; на десяти вопросах статистики нет.
- Порога шума у скорости и памяти нет: разница в токенах и мегабайтах измеряется, а не оценивается.
- Признаков и полного времени по каждой оси в файле страницы нет — только оценка судьи и ток/с. Полная причина, по которой ось не вошла в «после», видна в каталоге замеров, а не здесь.
- Сочетания осей не мерены вовсе: метод дня — одна ось за раз, и как оси ведут себя вместе, замер не говорит.
- Память по осям не мерена, и в таблицах на её месте стоит «нет данных», а не оценка на глаз.
- Поиск во всех прогонах один и тот же: предмет дня — генерация, а не качество поиска.
Как это мерено
База — конфигурация дня 28: тот же индекс ноутбука, тот же набор из десяти контрольных вопросов, тот же промпт реестра агентов. От неё менялась ровно одна вещь, и каждый вариант прогонялся один раз на всех десяти вопросах.
Время до первого токена и токены в секунду прогон берёт из ответа движка по каждому запросу и усредняет по вопросам набора — это среднее по разным вопросам, а не по повторам одного. Слова «медиана» на странице нет: один прогон на вопрос медианы не даёт, и обещать устойчивость, которой замер не мерил, нельзя.
Оценку верности ставит судья по рубрике дней 22 и 28: 2 — верно, 1 — частично, 0 — неверно. Судья — модель, читающая вопрос, ответ и найденные фрагменты, а не код со сравнением строк. Средняя по рубрике на десяти вопросах статистикой не является: доверительного интервала у неё нет, и порог шума поэтому считается как два вопроса из набора.
Неизменным во всех прогонах оставалось всё, кроме оси: индекс, число фрагментов на вопрос, срез фрагмента, набор вопросов, рубрика судьи и машина. Сводки «все параметры движка одним списком» на странице нет: прогон кладёт в файл значения только тех ручек, которые менялись, а дописывать остальные значило бы показать число, которого в прогоне не было.
Как мерена память
Метод тот же, что в ADR 2026-09-30-0957: размер загруженной модели движок сообщает сам, а пик расхода снимается частой выборкой процессов движка на время прогона.
У метода две честные границы. Выборка видит пик только в моменты опроса, и короткий всплеск между ними пропустит. А служб движка на ноутбуке две — замеры и сайт, — поэтому сумма по процессам включает и вторую; разбивка по процессам лежит рядом с числом в каталоге замеров.
В этом прогоне память снята на весь прогон, а не на каждую ось, поэтому по осям и по конфигурациям «до» и «после» в таблицах стоит «нет данных».
Что уже было закрыто
-
Сжатие весов уже мерилось — но для эмбеддера поиска и в виде обучения с учётом квантования, а не сжатия готовых весов генеративной модели.
Закрыто раньше30.09.2026
-
Как мерить память и чему верить: замер на macOS занижает расход, а срабатывание потолка читается по журналу, а не по признакам.
Закрыто раньше02.10.2026
-
Потолок токенов на ответ сделан громким: обрыв на потолке виден как обрыв, а не как законченный ответ.
Закрыто раньше01.10.2026
Пробел, который закрывает эта страница: для генеративной модели не мерено ничего — ни параметров движка, ни промпт-шаблона, ни сжатия весов. Было известно, как мерить память и как не обмануться потолком; чего стоит каждая ручка у локальной модели на реальной задаче — нет.
Оси: по одной за раз
Каждая строка — отдельный прогон на тех же десяти вопросах, в котором от базы отличалась ровно одна вещь. У промпта в ячейках слово, а не текст: оба шаблона целиком — в раскрывающемся блоке ниже.
| Ось | До | После | Оценка | Ток/с |
|---|
Таблица прокручивается вбок.
Читаю результаты прогона…
Как выбрано «после»
Правило записано заранее, чтобы «после» не было вкусом: берутся оси, у которых оценка не упала, а время выросло в пользу ответа. Сборка без отказов в «после» не входит ни при каких числах — «после» это конфигурация той модели, что стоит в проде.
Промпт до и после
Только для базовой модели: шаблоны сборки без отказов не публикуются.
Промпт реестра («полный»)
Читаю результаты прогона…
Компактный шаблон («компактный»)
Читаю результаты прогона…
Сжатие весов: Q4_K_M против Q6_K
Q6_K-сборка дообучена снятием отказов — разница между ней и Q4_K_M не только в сжатии. Скорость и память сравнимы честно, верность — нет. Её ответы на странице не показываются, поэтому вердикт по этой оси проверить нельзя: это единственное место недели, где читатель вынужден поверить на слово, и молчать об этом было бы нечестно.
Чистой оси сжатия здесь нет и по второй причине: чистого Q6_K у этой модели в библиотеке движка не существует, а качать восьмибитную сборку ради чистой оси владелец не выбрал. Это решение, а не упущение.
| Метрика | Q4_K_M | Q6_K | Разница |
|---|
Читаю результаты прогона…
Разбора по запросам у этой оси нет вовсе: наполнить его можно было бы только текстами её ответов, а они не публикуются — вето по ADR 2026-10-07-1349. Сборка без отказов в «после» не входит ни при каких числах.
Что такое сжатие весов
Весы модели можно хранить грубее: вместо точного значения каждого числа — его приближение по общей шкале. Модель от этого занимает меньше памяти и быстрее читается, а отвечает чуть иначе — где-то незаметно, где-то хуже. Обозначения вида Q4 и Q6 и есть степень огрубления: чем число меньше, тем грубее.
Считать биты здесь незачем: на задаче важно не то, сколько их осталось, а изменились ли ответы и насколько быстрее стало. Ровно это и стоит в таблице выше.
Стабильность: что здесь не мерено
Обрыв ответа или недоступность локальной модели — результат замера, а не пропуск в нём. Но повторов в этом прогоне нет, и секция говорит это словом, а не пустой таблицей.
Разброс на трёх вопросах мерен на той же базовой конфигурации в дне 28; сюда его числа не переносятся — это другой прогон.
Задание дня
День 29 «Оптимизация локальной LLM»: параметры (temperature, max tokens, context window), квантование, prompt-шаблон под кейс; сравнить качество до/после, скорость и потребление ресурсов.