Что такое токен простыми словами

Текст, прежде чем попасть в языковую модель, разбивается на токены, небольшие кусочки, и каждый может оказаться целым словом, обрывком слова или просто знаком препинания. Как именно текст режут на токены, определяет токенизатор — отдельная программа со своим словарём. Она разбивает текст на фрагменты и каждому фрагменту, то есть токену, присваивает число — идентификатор из этого словаря.

Этот словарь работает примерно как поварская книга, только наоборот: рецепт показывает, из каких ингредиентов собрано блюдо, а словарь токенизатора, позволяет разбирать уже готовый текст на такие же кусочки-ингредиенты и каждому присваивать свой номер. Так суп из слов и знаков препинания превращается в строку чисел, где каждое число обозначает пронумерованный кусочек текста той или иной длины. Как именно происходит такое разбиение на токены и их нумерация, показано в курсе Hugging Face.

Представьте, что вы измеряете длину комнаты шагами. При широком шаге получится одно число, при коротком — другое. Само число шагов ещё не говорит, сколько метров вы прошли. С токенами похожая история: сто токенов нельзя однозначно перевести в сто слов или фиксированное число символов.

У этой аналогии есть дополнительное условие: внутри одного текста длина «шага» тоже меняется. Один токен захватывает слово целиком, соседний — лишь несколько букв. Границы задаёт токенизатор по своим правилам, а не модель: на вход она получает уже готовую последовательность токенов.

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

Почему один токен не равен одному слову

В документации Hugging Face есть пример для токенизатора модели BERT с идентификатором google-bert/bert-base-uncased. Он разбивает фразу из пяти слов так:

I have a new GPU!
["i", "have", "a", "new", "gp", "##u", "!"]

Получилось семь токенов. Слова I, have, a и new заняли по одному. Сокращение GPU распалось на два, а восклицательный знак стал отдельным токеном. Обозначение ## показывает, что фрагмент продолжает предыдущее слово. Этот токенизатор также переводит буквы в нижний регистр.

Это конкретный пример разбиения, а не универсальное правило для всех нейросетей. У другой модели может быть иной словарь, поэтому та же фраза даст другую последовательность. В некоторых схемах токенизации пробел входит в токен вместе с соседним текстом; отдельный символ, например эмодзи, тоже может потребовать нескольких токенов.

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

Язык тоже влияет на разбиение. Исследователи сравнили токенизацию текстов на разных языках и показали, что одинаковое содержание может требовать разного числа токенов. Однако правило вроде «русский всегда вдвое дороже английского» из этого не следует — результат зависит от конкретной модели и текста.

Какие токены попадают в запрос и ответ

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

К входу относится гораздо больше, чем последняя реплика пользователя. Например, документация Gemini включает в подсчёт системные инструкции, историю разговора и описание доступных инструментов. В приложении запрос может содержать такие данные:

Поэтому короткая реплика «А теперь исправь» может сопровождаться большим входом: приложение снова передаёт код, переписку и инструкции. Предыдущий ответ модели, включённый в следующий запрос, уже относится к входным токенам этого запроса.

У моделей с режимом рассуждений расход может включать токены, которые не совпадают с видимым пользователю ответом. Например, Anthropic учитывает токены рассуждений в выходном бюджете и тарификации. Поэтому длина текста на экране не всегда объясняет весь расход.

Как токены ограничивают размер контекста

Контекстное окно — это объём текста, с которым модель работает одновременно, пока готовит ответ. В стандартном случае в него входят переданный запрос и генерируемое продолжение. Это ограничение описано в документации Claude. Оно относится к текущему обращению, а не ко всем знаниям, которые модель получила при обучении.

Для наглядности возьмём условную модель с общим окном в 32 000 токенов. Если инструкции, переписка и документы уже заняли 28 000, в пределах этого окна остаётся максимум 4 000 на генерацию. Дополнительно у модели может быть собственный предел длины ответа. Большое контекстное окно само по себе не обещает ответ такого же размера.

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

Если вы отправляете большой документ, сначала оцените весь вход и оставьте место для ответа. Для бота с длинными диалогами определите, какие сообщения он передаёт дальше, какие заменяет кратким резюме и какие детали обязан сохранять дословно. Anthropic предупреждает о потере важных деталей при слишком сильном сжатии истории. Например, резюме обсуждения может сохранить решение команды, но потерять строку ошибки, без которой модель не воспроизведёт проблему.

Как посчитать стоимость запроса

В тарифах API обычно отдельно указаны цены входных и выходных токенов, часто за миллион. Число «1 млн» здесь обозначает единицу расчёта. Оно не означает, что для одного короткого запроса нужно израсходовать миллион токенов.

Для обычного текстового запроса без кэширования и дополнительных платных операций расчёт выглядит так:

Стоимость запроса =
    входные токены / 1 000 000 × цена входа
  + выходные токены / 1 000 000 × цена выхода

Посмотрим на конкретный тариф. На 28 сентября 2026 года в карточке deepseek/deepseek-v4-pro-0813 на RouterAI для провайдера Ionstream указаны 34 ₽ за миллион входных и 300 ₽ за миллион выходных токенов. У других провайдеров этой же модели цены могут отличаться, а рублёвые значения меняются вместе с курсом валют.

Допустим, запрос использовал 2 000 входных и 500 оплачиваемых выходных токенов. Это учебный объём для расчёта, а не результат тестирования модели. Без кэширования получится:

При этих условиях короткий ответ стоит больше, чем вчетверо более длинный вход. Поэтому для сравнения моделей нужны обе ставки и характерная для вашей задачи длина ответа. Сравнение только по цене входа может привести к неверному выбору.

Кэширование промпта позволяет провайдеру повторно использовать уже обработанную общую часть запросов. Это меняет расчёт стоимости: например, Anthropic применяет разные ставки к записи и чтению кэша. Повторённый текст при этом продолжает занимать место в контекстном окне. Поддержку и условия кэширования нужно проверять у выбранной модели и провайдера.

Для практического сравнения можно использовать RouterAI: сервис даёт доступ к моделям разных разработчиков через единый API-ключ, работает без VPN и принимает оплату в рублях российскими картами. В каталоге моделей можно посмотреть ставки на вход и выход и сравнить расход на одинаковых задачах — токенизация и тарифы при этом остаются собственными у каждой модели.

Как проверить, что кэш действительно работает

Пометить запрос как кэшируемый мало. Провайдер применит кэш, только если повторяющаяся часть образует одинаковое начало запроса: кэш привязан к префиксу и хранит внутреннее состояние модели для конкретного начала текста, а не для содержимого в целом — это устройство кэша описано на RouterAI.

Отсюда частая ошибка компоновки запроса. Если статические инструкции лежат в системном блоке, а большой неизменный документ — в сообщении пользователя после переменных данных, кэш формально настроен, но фактически не срабатывает: перед неизменным текстом каждый раз оказывается разное начало.

Проверяется это не по настройкам, а по ответу API — в статистике должно расти поле чтения кэша. У Claude это cache_read_input_tokens и cache_creation_input_tokens в объекте usage, как описано в документации Anthropic; у других провайдеров поля называются иначе, но смысл тот же. Если это поле стабильно нулевое при повторяющихся запросах, кэш не работает, и вы платите полную цену за один и тот же текст на каждом вызове.

Отдельная ловушка — дописывать что-либо к системной части между вызовами. Одна добавленная фраза меняет начало запроса, и кэш промахивается. Особенно чувствительно это в автоматизированных циклах переделок, где один и тот же запрос уходит по несколько раз подряд: там промах по кэшу не просто снижает экономию, а умножает полную стоимость на число повторов.

Как узнать расход своего запроса

До отправки используйте токенизатор выбранной модели или официальный метод подсчёта, если он доступен. Считать нужно полный запрос с инструкциями и историей. Например, метод подсчёта токенов Claude принимает структурированные сообщения и возвращает оценку входа. Документация отдельно предупреждает: оценка может немного отличаться от фактического расхода.

После ответа проверяйте статистику API. В примере формата ответа RouterAI для этого используется объект usage. Для учебного объёма из расчёта выше его базовые поля выглядели бы так:

Поле prompt_tokens показывает вход, completion_tokens — выход, total_tokens — их сумму. Для кэширования и рассуждений проверяйте дополнительную детализацию, которую возвращает конкретный провайдер. Умножать total_tokens на одну ставку нельзя, если вход и выход стоят по-разному.

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

У систем, где ИИ работает автоматически, есть источник роста расходов, не связанный с самой моделью, — обвязка вокруг неё. Значимый патч CRM, воркфлоу или промпта может незаметно сломать защиту от лишних вызовов: настройку кэша, лимит на число повторов, дедупликацию похожих запросов. Тесты при этом пройдут — патч не ломает функциональность, он ломает экономику. Поэтому после каждого крупного изменения в такой системе стоит прогнать её типовой сценарий и сверить счётчики usage с тем, что было до патча, а не считать расход токенов побочным эффектом, который не требует отдельной проверки.

Как сократить расход без потери нужного контекста

Начните с того, что приложение отправляет и что просит вернуть. Обычно именно здесь можно найти данные, которые не помогают решить текущую задачу.

• Передавайте нужный фрагмент материала. Для объяснения одной ошибки приложите связанный с ней код и достаточное окружение. Весь репозиторий может содержать много файлов, которые не влияют на проблему.
• Управляйте историей диалога. Не передавайте её целиком в каждый новый запрос — резюмируйте закрытые темы и оставляйте дословно только то, что ещё понадобится.
• Задавайте формат результата. Если приложению нужны название ошибки и способ исправления, перечислите эти поля. Тогда у модели будет меньше причин добавлять длинное вступление и общий обзор темы.
• Ограничивайте генерацию параметром API. В RouterAI для этого описаны max_tokens и max_completion_tokens. Выбирайте параметр, который поддерживает ваша модель. Слишком низкий предел может оборвать полезный ответ; сам предел не обязывает модель заполнить его целиком.
• Проверяйте результат сокращений. Прогоните изменённый запрос на характерных задачах и сравните расход вместе с качеством ответа. Если после удаления контекста приходится повторять запрос с уточнениями, экономия может исчезнуть.
• Проверяйте кэш по факту, а не по настройке. Включённый в коде кэш ничего не гарантирует — ориентируйтесь на поле чтения кэша в статистике запроса.

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

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

Первым делом уменьшайте размер в пикселях, а не качество: фотография 6000×4000 в карточке шириной 1200 пикселей это чистые потери. Один этот шаг убрал 77% веса тестового снимка.

Формат выбирается под тип картинки: фотографиям WebP или AVIF, скриншотам и интерфейсам сжатие без потерь, логотипам SVG, анимациям анимированный WebP вместо GIF.

AVIF при равном качестве весит вдвое меньше JPEG, но кодируется примерно в пятнадцать раз дольше, поэтому генерировать его нужно на этапе сборки.

Метаданные съёмки занимают от 10 до 30 КБ на файл и в вебе не нужны ни для чего.

Сжатие с потерями на тексте и резких границах даёт видимые артефакты: скриншоты и логотипы жмутся только без потерь, зато на 20–60%.

Шаг, который экономит больше всех остальных

Прежде чем подбирать кодек и качество, посмотрите на фактические размеры. Фотография 6000×4000 в карточке шириной 1200 CSS-пикселей отдаёт браузеру в двадцать пять раз больше пикселей, чем нужно обычному экрану, и вшестеро больше, чем нужно экрану с двойной плотностью.

В замерах автора чеклиста одно только уменьшение до реально отображаемого размера ужало тестовое изображение с 4,7 МБ до 1,1 МБ. Это минус 77% при нулевой потере качества: пиксели, которых не видно, просто перестали передаваться.

Как определить нужный размер:
Отправная точка это ширина контейнера в CSS-пикселях. На обычном экране она же и есть нужная ширина в физических пикселях, на плотных экранах нужно кратно больше: у части ноутбуков это двойка, у большинства современных смартфонов тройка. Поэтому правильный инструмент здесь не фиксированный множитель, а атрибут srcset с несколькими вариантами файла: браузер сам возьмёт тот, что соответствует плотности экрана посетителя.

Формат под тип изображения, а не один на всё

Самая частая ошибка — выбрать один формат и применять его ко всему подряд. Между фотографией с плавными градиентами и скриншотом с текстом и резкими границами разница принципиальная, и сжимаются они противоположными способами.

• Фотографии — WebP (на 30–50% меньше JPEG) или AVIF (ещё примерно на 30% меньше WebP).
• Скриншоты и элементы интерфейса — PNG или WebP без потерь.
• Логотипы и иконки — SVG: вектор весит копейки и масштабируется без предела.
• Анимации — анимированный WebP вместо GIF, это экономит 60–80% веса.

Отдельно про текст. Сжатие с потерями на буквах и резких границах создаёт заметные ореолы вокруг символов, поэтому скриншоты и логотипы обрабатываются только алгоритмами без потерь. Инструменты вроде oxipng ужимают такие файлы на 20–60%, не меняя при этом ни одного пикселя.

Конвертация и сжатие — это два разных действия

Перевод PNG в JPEG экономит место. Сжатие получившегося JPEG экономит ещё столько же, и про этот второй проход регулярно забывают. Для фотографий рабочий диапазон качества это 75–82%: от стопроцентного такая картинка визуально неотличима, а весит заметно меньше.

Метаданные, которые вы отдаёте бесплатно

В файле с камеры или из редактора лежат EXIF, координаты GPS, модель камеры и метки программы обработки. Для показа в браузере это бесполезный груз весом от 10 до 30 КБ на файл, за одним исключением: тег ориентации. Часть снимков с телефона хранит пиксели неповёрнутыми и полагается на него, поэтому поворот нужно применить к самим пикселям до того, как метаданные срежутся, иначе фотографии лягут набок. На каталоге из тысячи товарных снимков набегает до 30 МБ трафика ни за что, а координаты съёмки вдобавок могут оказаться данными, которые вы не собирались публиковать.

AVIF: что это и почему его нельзя кодировать на лету

AVIF (AV1 Image File Format) выпущен Alliance for Open Media в 2019 году и построен на внутрикадровом кодировании видеокодека AV1. По сути это инструменты сжатия одного кадра AV1, упакованные в самостоятельный контейнер для картинок.

Перед WebP у него два практических преимущества: выше степень сжатия при равном качестве и глубина цвета до 12 бит с поддержкой расширенного динамического диапазона, тогда как WebP ограничен восемью битами и обычным диапазоном. Достигается это за счёт заметно более богатого набора инструментов предсказания, унаследованного от видеокодека.

Сколько это в килобайтах

В сравнительном тесте брали пейзажный кадр 1920×1080 с градиентами неба, текстурой листвы и границами зданий, исходник в BMP весил 5,93 МБ. Целевое качество задавали по метрике структурного сходства: она сравнивает сжатую картинку с исходной, где единица означает полное совпадение, а 0,92 примерно соответствует порогу, за которым разницу перестают замечать глазом. Результаты:

На листве и градиентах неба разница видна и глазом: JPEG на низком битрейте показывает цветовые блоки, у AVIF артефактов практически нет. Отвечают за это многоуровневые фильтры внутри цикла кодирования, которые заглаживают границы блоков и восстанавливают детали текстур.

Плата за это — время. Кодирование AVIF примерно в пятнадцать раз дольше JPEG и вчетверо дольше WebP, потому что выбор разбиения и типа преобразования требует перебора с оптимизацией. Зато декодирование медленнее JPEG всего вдвое, и на просмотр это почти не влияет. Практический вывод прямой: генерируйте AVIF заранее, на этапе сборки. Сервисы доставки изображений кодируют его и по запросу, но только с кешированием результата, чтобы платить за кодирование один раз на вариант, а не на каждого посетителя. Чего делать нельзя, так это кодировать заново при каждом обращении.

Как отдавать современный формат и не потерять старые браузеры

Поддержка AVIF в браузерах составляет примерно 96%, но подстраховка всё равно нужна. Делается она тегом <picture>: браузер берёт первый формат, который понимает, и до остальных не доходит.

Атрибуты width и height здесь не декоративные: без них браузер не знает пропорций до загрузки файла и подвёрстывает страницу заново, когда картинка приходит. Это тот самый прыжок содержимого, который портит метрику визуальной стабильности. Атрибут loading=lazy убирает изображения за пределами первого экрана из очереди, конкурирующей за отрисовку главного элемента.

Именно за пределами: на картинку первого экрана его ставить нельзя. Отложенная загрузка задержит ровно тот элемент, скорость появления которого и меряет метрика отрисовки основного содержимого. Там уместен противоположный по смыслу fetchpriority=high.

Сжатие в браузере: почему это вообще возможно

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

Речь здесь уже не про ассеты вашего сайта, которые готовятся на сборке. Речь про картинки, которые в браузер приносит сам пользователь: форма загрузки в личном кабинете, объявление на маркетплейсе, вложение в заявку. Сжать их до отправки на сервер можно прямо во вкладке, и это снимает и трафик, и вопрос о том, где полежит оригинал.

Автор одного из таких инструментов разобрал устройство своего конвейера, и его опыт пригодится всем, кто выносит тяжёлые вычисления во фронтенд.

Вся тяжёлая работа уходит из главного потока

Перекодирование снимка 4000×4000 нагружает процессор настолько, что в главном потоке интерфейс замирает, а браузер показывает предупреждение о зависшей странице. Поэтому весь конвейер живёт в Web Worker: главный поток отвечает за выбор файлов, превью и состояние, а рабочий поток декодирует через createImageBitmap, применяет преобразования и кодирует через OffscreenCanvas. Именно через него, а не через canvas.toBlob: последний это метод DOM-элемента, а DOM в рабочем потоке отсутствует, и нужный метод там называется convertToBlob.

Важная деталь производительности: передавать данные между потоками нужно как ArrayBuffer через механизм передачи владения, а не структурным клонированием. На пачке из тридцати изображений это разница между мгновенным откликом и лишними полусекундами нагрузки на сборщик мусора для каждого файла.

Три ошибки, которые ищутся дольше всего

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

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

Асинхронный обработчик сообщений перепутал порядок. Обработчик стал ждать преобразование уже после кодирования, а асинхронные обработчики порядок не сохраняют: состояние поворота разъехалось с готовым изображением. Полностью синхронным такой обработчик не сделать, декодирование и кодирование асинхронны по своей природе. Работает другое: обрабатывать сообщения строго по одному, не начиная следующее до завершения предыдущего, и хранить состояние вроде угла поворота рядом с данными конкретного сообщения, а не в общей переменной.

Заголовки безопасности ломают рабочие потоки молча:
Блокирует загрузку скрипта заголовок Cross-Origin-Embedder-Policy: он требует, чтобы каждый сторонний ресурс отдавал разрешающий заголовок, иначе браузер молча его отбрасывает. Cross-Origin-Opener-Policy на это не влияет, но включают их обычно парой, поэтому и ломается всё в одном релизе. Любое изменение заголовков безопасности проверяйте на настоящем развёрнутом стенде, а не только на машине разработчика.

Что это даёт в цифрах

Скриншот 1920×1080 проходит такой путь: исходный PNG весит 2,1 МБ, после уменьшения и перевода в WebP с качеством 75% — 186 КБ, то есть минус 91%. Тот же кадр в AVIF занимает 102 КБ, минус 95% от исходного.

Именно эти проценты и отделяют страницу, которая грузится четыре секунды, от страницы, которая укладывается в одну.

Что забрать с собой

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

Материалы разбора: чеклист оптимизации с замерами, техническое устройство AVIF и сравнительный тест форматов и разбор браузерного конвейера сжатия.

Откройте свою главную страницу с открытой панелью сети и отсортируйте запросы по размеру. Первые три строки почти наверняка окажутся картинками, и это ваша ближайшая оптимизация изображений: уменьшить их вдвое реально за один вечер.

Если вы пишете агентов с накапливаемой историей (append-only), вы знаете эту боль: чем дольше сессия, тем дороже каждый следующий шаг, потому что модель заново перечитывает всё, что было. Работа интересна тем, что предлагает не сжимать историю, а заменить её структурой, и показывает на цифрах, что структура работает лучше сжатия. Оговорка сразу: результат сильно зависит от модели, а публичного кода авторы не выложили.

• Работа arXiv:2608.26263, авторы Санкет Бадхе, Приянка Тивари и Чонхён Чон из Google LLC и Purdue University; по пометке авторов на arXiv, принята на EMNLP.
• На каждом шаге модель видит только инструкцию навыка, текущее JSON-состояние и последнее наблюдение; патч состояния проверяется, рассуждение после шага отбрасывается.
• SkillExecBench (среда Warehouse Management) на Gemini 3 Flash: при 100 шагах 65 тысяч токенов против 1,25 млн у ReAct при точности 94% против 84%; при 200 шагах 122 тысячи против 6,2 млн у агента с памятью-сводкой.
• При равном бюджете около 1 800 токенов на запрос простое усечение даёт точность 18%, LLMLingua 22%, SKILL.state 94%.
• Ограничения: схема состояния задаётся заранее; задачи, где нужна сама история (аудит, объяснение действий), методу не подходят; один агент; публичного репозитория нет; на Gemma-4-31B и Qwen-3-8B при 100 шагах точность 42% и 34% против 94% у Gemini 3 Flash.

Как это устроено

Обычный агент в стиле ReAct на шаге t получает весь журнал: системный промпт, все прошлые команды, все ответы инструментов и свои рассуждения. Суммарно за T шагов это O(T²) токенов, потому что каждый шаг перечитывает всё предыдущее. В SKILL.state промпт шага состоит из трёх частей, размер которых не зависит от номера шага при условии, что состояние и наблюдение ограничены по объёму: спецификация навыка P (что агент умеет и как должен себя вести), структурированное состояние Σ (JSON с тем, что важно для задачи) и последнее наблюдение O. Модель отвечает рассуждением, JSON-патчем к состоянию и действием; патч детерминированно проверяется и применяется, рассуждение после этого выбрасывается, действие исполняется.

Патч применяется операцией слияния: новые ключи добавляются, существующие перезаписываются, значение null удаляет ключ. Итог — суммарные затраты O(T) по токенам, а размер одного промпта почти не растёт: в экспериментах он держался в диапазоне 1 736–1 905 токенов при горизонте от 10 до 200 шагов. Схема состояния пишется один раз на домен, а не на задачу: для всех 100 задач InterCode CTF агент использовал одну статическую схему из пяти полей — найденные флаги, проверенные гипотезы, активные файлы, рабочий каталог, сводка команд.

Цифры из работы

Основной эксперимент — SkillExecBench, среда Warehouse Management: симуляция склада с длинными последовательностями действий, модель Gemini 3 Flash, пять случайных сидов, температура 0. При 100 шагах ReAct потратил 1 245 413 токенов при точности 0,84, baseline с явным состоянием в стиле LangGraph — 1 062 387 токенов и 0,91, SKILL.state — 65 408 токенов и 0,94. При 200 шагах агент с памятью-сводкой (Memory) ушёл в 6 175 509 токенов при точности 0,84, а SKILL.state уложился в 122 384 токена при 0,94. Именно отсюда «в 50 раз меньше» из пересказов; в дополнительном эксперименте с репозиторием кода при 100 шагах разница составила 1 848 500 против 90 200 токенов.

Авторы связывают выигрыш в точности не с сокращением текста, а с тем, что состояние сохраняет отношения между сущностями: какой шаг уже выполнен, что заблокировано, что кому должно. Два результата важнее заголовочных. Первый: при одинаковом бюджете около 1 800 токенов на промпт обычное усечение истории дало точность 0,18, сжатие через LLMLingua — 0,22, а SKILL.state — 0,94. Второй: в тесте с 50 нерелевантными событиями на каждом шаге обычный агент упал до 0,53, а SKILL.state удержал 0,98, потому что шум не попадает в состояние. После внешнего изменения среды и корректирующего уведомления SKILL.state в трёх сценариях из четырёх восстанавливался за 0 шагов, остальные подходы ошибались ещё 5–8 шагов; со сценарием отменённого заказа не справился никто.

На более привычных бенчмарках выигрыш скромнее, но есть: на InterCode CTF 54,2% Pass@1 против 43,2% у ReAct и 41,8% у Stateful, на τ-Bench Retail 58,3% и Airline 32,4% при снижении токенов до 3,47 млн и 2,88 млн соответственно.

Чего в работе нет

Ограничения авторы называют сами. Метод предполагает, что всё важное для будущих шагов можно вовремя записать в заранее заданную схему состояния: если структура задачи заранее неизвестна, если значимость детали осознаётся позже или если нужна сама история (аудит, происхождение данных, объяснение действий), подход не подходит. Второе: реализация рассчитана на одного агента, для нескольких понадобится разрешение конфликтов при одновременных записях в состояние. Третье: архитектура не привязана к Gemini, но качество сильно зависит от модели: при 100 шагах Gemini 3 Flash дала точность 0,94, Gemma-4-31B-it — 0,42, Qwen-3-8B-it — 0,34. Четвёртое, практическое: публичного репозитория авторы на 1 сентября не указали, хотя в статье есть промпты, псевдокод рантайма и детали реализации.

Что можно повторить у себя

• Опишите для своей задачи схему состояния из полей, которые реально нужны для следующего шага, и просите модель возвращать патч к ней, а не свободный текст; авторам для CTF хватило пяти полей.
• Отбрасывайте рассуждения модели после шага: они нужны для выбора действия, а не для памяти.
• Передавайте только последнее наблюдение целиком; всё, что из прошлых наблюдений имеет значение, должно уже лежать в состоянии.
• Заведите тест на шум: подмешивайте в наблюдения нерелевантные события и смотрите, не тащит ли агент их в состояние.
• Не ждите тех же 50 раз: в статье это симуляция склада на Gemini 3 Flash; на τ-Bench экономия заметно меньше, и ваш случай ближе ко второму.

Контекст

Идея держать в контексте состояние вместо истории не нова: похожие приёмы есть в LangGraph и в собственных рантаймах команд, которые строят агентов в проде. Вклад работы в том, что она измеряет разницу на длинных горизонтах и сравнивает с методами сжатия при равном бюджете. Обсуждения на Hacker News и в блоге Google Research на момент публикации нет; следующий сигнал — появится ли код или воспроизведение на других моделях.

Источники: SKILL.state: Scalable Long-Horizon Agent Skills (arXiv:2608.26263), Пересказ vc.ru

Изображение на обложке: Google

В статье разбираем, почему React.memo сравнивает пропсы по ссылке, как inline-объекты и inline-функции обнуляют эту оптимизацию, и какие два простых приёма действительно возвращают производительность.

React.memo пропускает рендер только тогда, когда все пропсы равны по Object.is. Для объектов и функций это проверка по ссылке.

Inline-объекты и inline-колбэки в JSX создают новую ссылку на каждый рендер родителя, поэтому memo видит «новые» пропсы и снова рисует дочерний компонент.

В эксперименте со 200 memoизированными строками это дало 243,9 мс на один keystroke; после стабилизации ссылок — 6 мс.

Сначала выносите статические объекты за пределы компонента, а useCallback применяйте только там, где колбэк действительно пересекается с memoизированным потомком.

Оптимизировать всё подряд не нужно: измеряйте в Profiler, а не добавляйте хуки «на всякий случай».

Как React решает, рендерить компонент заново или нет

Когда родитель перерисовывается, React не делает послаблений дочерним элементам только потому, что они обёрнуты в React.memo. Он сравнивает новые пропсы со старыми. Если каждый проп проходит проверку Object.is, React может «отказаться» от рендера — bailout. Если хотя бы один проп не равен, компонент рисуется заново.

Для примитивов Object.is работает очевидно: 1 === 1 и 'hello' === 'hello'. А вот для объектов и функций сравнение идёт по ссылке.

Два объекта с одинаковым содержимым — это разные объекты в памяти. То же самое с функциями. Поэтому, когда вы пишете style=\{\{ padding: 16 \}\}, React получает новую ссылку на каждом рендере и считает проп изменившимся.

Почему inline-пропсы — это не микрооптимизация, а поломка контракта

Сам по себе объект в JSX не вреден. Если компонент дешёвый, редко перерисовывается и не обёрнут в memo, inline-пропсы почти не влияют на скорость. Проблема появляется, когда три условия накладываются друг на друга:

• родитель перерисовывается часто — поиск, скролл, фильтры, live-данные;
• дочерний компонент или поддерево достаточно тяжёлые, чтобы лишний рендер был заметен;
• вы уже добавили React.memo и ожидаете, что React будет пропускать работу.

В такой ситуации нестабильные ссылки не просто добавляют накладных расходов — они полностью отменяют ту оптимизацию, ради которой вы взяли React.memo. UI продолжает работать, но лагает ввод, тормозят списки, а в Profiler видно, что дерево горит жёлтым при каждом чихе.

Классический опасный пример

Представьте список товаров из 200 строк. Каждая строка обёрнута в memo, но в месте вызова передаются inline-пропсы:

Здесь style и onAddToCart создаются заново при каждом рендере ProductList. Для memo это сигнал, что у каждой строки изменились пропсы, и все 200 компонентов рисуются снова.

Эксперимент: от 243,9 мс до 6 мс на один keystroke

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

В React DevTools Profiler один keystroke дал коммит длительностью 243,9 мс, в котором подсветились все 200 волокон строк. Инструмент @welldone-software/why-did-you-render прямо указал причину: props.style — «different objects that are equal by value», props.onAddToCart — «different functions with the same name».

Почему 14 рендеров?
Каждый ввод в поиск меняет searchTerm, родитель перерисовывается, и inline-пропсы дают строкам новые ссылки. Счётчик рендеров растёт на каждый keystroke, даже если отфильтрованные товары не изменились.

Как починить: два приёма вместо дюжины хуков

Чтобы восстановить bailout, нужно сделать так, чтобы неизменяющиеся значения не получали новую ссылку на каждом рендере. Правило простое: сначала вынести, потом закешировать.

1. Статические объекты — за пределы компонента

Если объект не зависит от пропсов и состояния, создайте его один раз на уровне модуля. Это дешевле любого хука и не требует dependency-массива.

2. Динамические колбэки — useCallback

Если функция передаётся в memoизированный компонент и не должна меняться без причины, оберните её в useCallback со стабильным массивом зависимостей.

После этих двух изменений в эксперименте время рендера упало с 243,9 мс до 6 мс, счётчики строк застыли на 2, а Why Did You Render замолчал — avoidable re-renders исчезли.

Когда не нужно ничего стабилизировать

Главная ошибка — оборачивать в useCallback каждую функцию и выносить каждый объект за компонент. React сам по себе быстрый, а мемоизация — это контракт, а не стиль кодирования.

• Компонент дёшев и редко перерисовывается — не тратьте когнитивный бюджет команды.
• Дочерний элемент не обёрнут в React.memo — тогда стабильные ссылки ничего не экономят.
• Значение зависит от часто меняющегося состояния — useCallback с нестабильным массивом зависимостей всё равно будет пересоздаваться.
• Вы ещё не замерили в Profiler — оптимизация без измерений почти всегда лишняя работа.

React Compiler, который сейчас выходит в стабильное состояние, автоматически мемоизирует многое из того, что раньше делали вручную. Но и он не отменяет понимания ссылочной стабильности: useMemo и useCallback остаются полезными, когда нужен точный контроль, например для зависимостей эффектов.

Часто задаваемые вопросы

Выводы

Inline-объекты и inline-колбэки в JSX — не антипаттерн сами по себе. Они становятся проблемой только на границе memoизации, где React ожидает стабильные ссылки. Как только вы понимаете это правило, многие «таинственные» лишние рендеры перестают быть таинственными.

1. Профилируйте до оптимизации, а не после.
2. Вынесите статические объекты за компонент — это самый дешёвый способ стабилизации.
3. Применяйте useCallback только для колбэков, которые уходят в memoизированные потомки.
4. Проверяйте себя через React DevTools Profiler и Why Did You Render.
5. Не забывайте про React Compiler, но не полагайтесь на него как на волшебную палочку.

Мемоизация — это контракт. Если потомок рассчитывает на стабильные ссылки, родитель должен их обеспечить. Нарушение этого контракта стоит намного дороже, чем отсутствие мемоизации вовсе.

Источник: LogRocket — The React pattern everyone uses that kills performance.

Проверьте свой текущий проект: откройте React DevTools Profiler, введите что-нибудь в поиск и посмотрите, сколько компонентов подсветится жёлтым только из-за новой ссылки в пропсах.

Звучит красиво.

Особенно если вы когда-нибудь вручную переносили сценарии из заметок в Confluence, сверяли шаги с макетами, оформляли вкладки с HTTP-запросами, проверяли коды ошибок и пытались не забыть все вопросы, которые «надо потом уточнить».

Пролог

Всем привет! Я Золотарёва Виктория, ведущий системный аналитик в команде Financial Transaction Service или просто FinService. В марте 2026 года активно обсуждалось внедрение ИИ в рабочие процессы. Аналитиков это тоже коснулось.

Моя первая реакция была скептической: зачем мне агент, если свою работу я могу сделать быстрее сама?

Первые эксперименты этот скепсис только подтвердили. К примеру, я могла за рабочий день самостоятельно подготовить User Story и полноценный Use Case с контрактами, эндпоинтами, диаграммой и макетами. С агентом та же задача растягивалась на 3-4 дня: нужно было передать контекст, объяснить формат результата, постоянно направлять агента, а затем ещё и внимательно проверять, что он успел придумать по дороге.

Однажды в начале исследования агент предложил неверный контракт. Я явно указала на ошибку и передала актуальное решение. Но в финальной документации снова увидела неправильный контракт с неймингом, похожим на первоначальный. Агент вернулся к собственному старому решению и представил его как подтверждённое мной (а вот это уже опасно).

Проблема AI в аналитике не всегда в том, что он пишет очевидную чушь. Иногда он очень убедительно пишет неправильные вещи.

Также основную аналитическую документацию мы описывали в Confluence, а разработчики работали с кодом и агентами в GitLab. Чтобы агент разработчика мог начать работу, документацию из Confluence приходилось передавать ему как контекст. Затем он заново анализировал требования, формировал Markdown-спецификацию в GitLab и только после этого переходил к реализации.

Получалось, что один и тот же контекст фактически описывается дважды.

В какой-то момент мы с разработчиком задались вопросом: а зачем дважды описывать один и тот же сценарий сначала в Confluence, а потом GitLab?

«Что, если аналитик сразу подготовит спецификацию, которую агент разработчика сможет использовать почти без дополнительной переработки?»

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

• research-фазы для подготовки Use Case;
• подготовка аналитических артефактов: user story, use case, API-спецификаций, PlantUML-диаграмм и Confluence-структуры;
• публикация в Confluence (здесь мы использовали агентов и, что примечательно, выявили важные технические ограничения, связанные с авторизацией, storage-разметкой, вложениями, кодировкой и передачей больших данных (но об этом в статье);
• работа с Figma: настройка токена, обращение к API, чтение нод и экспорт экранов в PNG.

В статье расскажу, где AI действительно помог, где уверенно начал придумывать лишнее, почему Confluence оказался сложнее, чем ожидалось, и какие правила я бы теперь закладывала в любой агентный сценарий для аналитика.

Спойлер: до магической кнопки далеко. Но мы получили отличный (и довольно болезненный) опыт того, как ИИ может помочь в аналитике, а где он пока просто спотыкается и обламывается.

Для самых внимательных в конце оставлю ссылку на диск со всеми style guide и результатом генерации, чтобы вы могли самостоятельно проверить подход в своей работе —>

Четыре гипотезы

Исследование было направлено на проверку нескольких практических гипотез.

• Первая гипотеза заключалась в том, что AI может ускорить подготовку аналитических артефактов: user story, use case, acceptance criteria, API-спецификаций и описаний бизнес-процессов.
• Вторая была связана с качеством требований: проверялось, может ли AI не только писать текст, но и выявлять пропуски, противоречия, неоднозначные формулировки и открытые вопросы.
• Третья гипотеза касалась агентных сценариев — можно ли использовать AI-агента как участника рабочего процесса: чтобы он читал макеты, работал с файлами, формировал спецификации, готовил Confluence-разметку и помогал публиковать результат.
• Четвертая гипотеза касалась ограничений. Было важно не только зафиксировать успешные кейсы, но и понять, где агентный подход становится нестабильным: в авторизации, публикации, работе с вложениями, передаче изображений, кодировке или сетевых ограничениях.

В результате исследование охватило не только «полезные сценарии», но и реальные технические сбои, которые важно учитывать при внедрении AI в аналитическую работу.

Использовать ИИ, чтобы написать требования — сразу нет

В списке выше нет гипотез «Может ли ИИ написать требования с нуля», потому что первый же эксперимент показал, что для аналитической работы недостаточно просто попросить AI «написать требования». Такая формулировка может дать быстрый черновик, но не гарантирует корректность.

К примеру:

• если во входных данных отсутствует endpoint, AI может предложить его по аналогии;
• если не описаны ошибки, он может добавить типовые коды;
• если в макете не виден текст кнопки, AI может восстановить его по смыслу.

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

Поэтому в исследовании был использован более строгий принцип: AI не должен закрывать пробелы самостоятельно. Если данных недостаточно, он должен фиксировать неопределенность и задавать уточняющие вопросы.

Для этого был применен целевой уровень неопределенности — 0,1. Это означает, что перед подготовкой финального артефакта все ключевые вопросы должны быть закрыты или явно вынесены в список открытых вопросов. Если неопределенность выше, агент не должен формировать финальный use case, domain-spec или диаграмму.

Такой подход позволил изменить роль AI. Он перестал быть просто генератором текста и стал инструментом предварительного анализа: помогает собрать вводные, найти недостающие данные и подготовить основу для дальнейшей спецификации.

Spec Driven Development

Следующая идея появилась после разговора с разработчиком, — чтобы ИИ не ушел в свободный полет, мы приручили его методологией Spec Driven Development. В контексте системного анализа он был применен не как подход к автоматической генерации кода, а как способ выстроить управляемую цепочку аналитических артефактов.

Суть подхода в том, что спецификация становится центральным рабочим артефактом. Работа начинается не с написания итогового документа, а с последовательного уточнения того, что должно быть реализовано, какие сценарии должны поддерживаться, какие данные нужны, какие ограничения существуют и какие вопросы остаются открытыми.

В исследовании этот подход был адаптирован следующим образом:

Исследование → Открытые вопросы → Зафиксированные факты → Domain-spec → OpenAPI → Confluence UC

На первом этапе собираются вводные и фиксируются неопределенности. На втором этапе подтвержденные факты переносятся в findings. После этого формируется domain-spec, который становится основой для API-спецификации, диаграммы взаимодействия и страницы use case в Confluence.

Такой процесс снижает риск того, что AI перенесет ошибку из раннего этапа в финальный документ.

• Если вопрос не закрыт, он остается в research-фазе.
• Если поле API не подтверждено, оно не должно появляться в спецификации.
• Если сценарий не согласован, он не должен попадать в Confluence как финальное требование.

Spec Driven Development в этом контексте оказался полезен не как модная методология, а как практический способ дисциплинировать работу с AI.

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

Дальше вас ждут несколько кейсов. Один кейс может проверять несколько гипотез.

Кейс №1. Подготовить Use Case? Да, но с нюансами

Задача research-фазы — собрать все данные, необходимые для будущего UC: цель сценария, точки входа, пользовательские действия, данные для отображения, API-вызовы, успешные и ошибочные ответы, предусловия, постусловия, бизнес-правила, ограничения и исключения из scope. Решили проверить, как с этим справится агент и «скинули» ему задачи анализировать вводные, фиксировать подтвержденные факты и выявлять недостающую информацию, при этом агент не должен писать финальный UC.

Для этого были определены рабочие файлы:

• README.md — общий контекст и статус (в т.ч. та самая неопределенность).
• open-questions.md — журнал вопросов, зависимостей и допущений.
• findings.md — только подтвержденные факты.

Такой формат оказался удобен для работы с неполными вводными. Он помогает не терять вопросы, отделять факты от предположений и не переносить спорные решения в финальную документацию.

Основной вывод из этого кейса: до применения такого подхода AI мог сразу предлагать готовый use case, даже если часть информации отсутствовала. После введения research-фазы процесс стал более контролируемым: сначала фиксируются пробелы, затем уточняются данные и только после этого формируется спецификация.

Кейс №2: Подготовка аналитических артефактов

Следующим направлением стала подготовка style guide и промтов для разных типов аналитических документов. Style guide был сделан с помощью модели LLM на основе ранее составленных user story.

Сначала я пыталась описать все правила работы агента одной большой инструкцией, но затем агент начал смешивать требования разных артефактов: правила User Story переносились в Use Case, подход к UC влиял на API-спецификацию. Поэтому каждый тип артефакта получил собственный style guide.

Первые правила я описывала с нуля на основе своего опыта и уже выстроенного формата документации.

• Были отдельно оформлены правила для user story, research-фазы, REST API-спецификации и Confluence use case. Это оказалось важным, потому что AI существенно лучше работает, когда ему задан не только контекст задачи, но и точный формат результата.
• Для user story были определены правила формулировки пользовательской цели, результата и критериев приемки. Отдельно было зафиксировано, что одна story должна описывать одну пользовательскую цель, а критерии приемки должны быть проверяемыми.
• Для API-спецификации были определены правила описания сценария, endpoint, параметров, тела запроса, успешных ответов, типовых ошибок и PlantUML-диаграммы. Отдельно было зафиксировано, что агент не должен придумывать поля или коды ошибок, если они отсутствуют в источнике.
• Для Confluence use case были заданы более строгие правила, так как это уже не просто текстовый документ, а страница с конкретной структурой и макросами. В нее должны входить разделы основной информации, истории изменений, предусловий, сценария использования и схемы работы. HTTP-детали должны оформляться во вкладках, запросы и ответы — в code-блоках, бизнес-правила — в info-блоках, а диаграмма — в PlantUML.

Основной вывод из этого кейса: AI может ускорить подготовку артефактов, если для него заранее определены правила качества. Без style guide результат будет зависеть от интерпретации модели. Со style guide результат становится более повторяемым и пригодным для командной работы.

Кейс №3: Публикация UC в Confluence (или почему здесь начался ад)

Наиболее сложным и показательным стал кейс подготовки и публикации use case в Confluence.

На первый взгляд задача простая: сформировать страницу в формате команды и опубликовать её. Страница должна была содержать оглавление, историю изменений, вкладки, code- и info-блоки, PlantUML. Обычного Markdown здесь недостаточно. Нельзя было и просто взять HTML-выгрузку существующей страницы и отправить её обратно как body.storage. Если так делать, то мы получали некорректную страницу, битые изображения и ссылки на attachments исходного документа (а ещё море слёз).

Как оказалось, генерация текста и публикация в корпоративную вики — это два совершенно разных уровня сложности. И вот почему:

1. Проблема авторизации. В Figma был PAT, и агент работал сам по себе. В нашем корпоративном Confluence отдельного технического токена не было. В итоге агент работал от лица пользователя, используя куки активной вкладки браузера (credentials: 'same-origin'). То есть, если вы не залогинены в Confluence, агент видит страницу входа.

2. Проблема формата (Storage XML). Нельзя просто взять HTML-выгрузку страницы и отправить её как body storage. Confluence это съест, но картинка сломается, а ссылки превратятся в мусор. Нам пришлось писать Python-скрипт, который генерировал чистую Confluence storage-разметку.

3. Проблема версий. Confluence требует актуальный номер версии (version.number + 1 при PUT-запросе). Если кто-то зашёл и поправил страницу пока ИИ думал — конфликт обеспечен. Приходилось перед публикацией запрашивать status=current с отключением кэша.

4. Боль с кодировкой. Классическая засада. Передавали storage через base64, использовали стандартный atob(b64) для декодирования — и вся кириллица превратилась в кракозябры. Пришлось переписывать на new TextDecoder('utf-8').decode(raw).

5. Ограничения CDP. Confluence storage весит десятки килобайт, а если добавить картинки — мегабайты. Прогонять такие объёмы данных через последовательные вызовы Runtime.evaluate (Chrome DevTools Protocol) оказалось нестабильным — связь рвалась.

В итоге мы пришли к такому пайплайну: Python-генератор → Storage XML → Локальная валидация → Локальный CORS-сервер → Browser REST (с куки) → TextDecoder → Выполнение сниппета в DevTools.

Как раз тогда и появилась идея фиксировать все проблемы и итоговые рабочие решения в отдельный документ в confluence-generation-retrospective.md. Это позволило агенту не зацикливаться на одних и тех же предложенных вариантах решения, а полноценно и автономно решать вопросы по уже зафиксированным рабочим решениям.

Кейс №4: Работа с Figma

Отдельным направлением исследования стала работа с Figma, так как макеты пользовательских сценариев хранятся именно там.

Для доступа к Figma был настроен Personal Access Token. Токен был сохранен в переменную окружения FIGMA_TOKEN, после чего агент мог обращаться к Figma API через заголовок X-Figma-Token.

Проверка подключения выполнялась через endpoint /v1/me. После подтверждения токена агент мог получать данные о файле, читать структуру нод и экспортировать отдельные экраны в PNG.

Пример проверки:

curl -s -H “X-Figma-Token: $FIGMA_TOKEN” https://api.figma.com/v1/me | python3 -m json.tool

Для работы с конкретными экранами использовались file key и node id. При этом была зафиксирована важная техническая особенность: node id из ссылки Figma может отображаться через дефис, но в API передаётся через двоеточие. Например, 4888-28266 в URL передается как 4888:28266 в API-запросе.

В результате агент смог получать макеты, экспортировать экраны в PNG, читать изображения с диска и использовать их для описания сценариев.

Отдельно было выявлено, что работа токена в обычном терминале не гарантирует работу агента в Cursor. Для доступа агента к api.figma.com может потребоваться разрешение сетевого доступа в sandbox-настройках.

Промежуточный вывод

После первых кейсов стало понятно: я постепенно перешла от разовых экспериментов с AI к оформленному рабочему подходу.

Агент уже не был отдельным чатиком, которому я каждый раз заново объясняю задачу. У него появились правила, область ответственности, рабочие файлы, критерии остановки research-фазы и понятный формат результата. Но вместе с этим появился новый риск.

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

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

А этого было недостаточно.

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

Бонусная глава, где я экспериментирую на чужой документации

Все эксперименты я проводила на собственной работе, в знакомой предметной области и на документации, формат которой хорошо знала. Задачи, которые раньше оценивались примерно в пять story points, теперь укладывались в один-два с учётом проверки. И к этому моменту оставался один вопрос: «Действительно ли у меня получилось построить воспроизводимый процесс или я просто научила агента работать «как я»?»

Чтобы подтвердить или опровергнуть свою догадку, я предложила коллеге из другого отдела провести эксперимент на другой документации. Мы взяли реальную задачу по актуализации middle-документации сервиса. Она звучала так: «Разработчик уже добавил новую функциональность, OpenAPI и тесты. Базовый каркас документации существовал, но полноценного раздела по новой функциональности ещё не было».

При ручной работе сначала потребовалось бы изучить существующую документацию, затем собрать детали реализации у разработчика, написать и полдня отшлифовать описание и отдельно дождаться сниппетов.

Мы начали не с команды «Внеси в документацию все изменения разработчика», а согласно уже проложенному сценарию (который описала выше).

На первой фазе агент должен был исследовать изменения feature-ветки относительно основной и определить:

• Что изменилось?
• Что действительно реализовано?
• Что из этого нужно переносить в документацию?

В качестве источника истины он использовал код, OpenAPI и уже существующую документацию из Confluence для получения полного контекста. Согласно правилам все подтверждённые факты фиксировались в findings.md, а неясности в open-questions.md.

Research-фаза выявила методы, которые уже появились в коде, но отсутствовали в документации, а также расхождения между контрактом и фактической реализацией.

Эти расхождения не скрывались, а фиксировались через NOTE.

Параллельно мы сравнивали результат с другой документационной веткой, но не использовали её как безусловный источник истины.

Также мы четко разграничили правилами:

- Если в документации был метод, которого нет в нашем API, мы его не переносили.

- Если описание обещало больше, чем делал код, фиксировали расхождение.

Получился двухфазный процесс: исследование изменений с минимальной неопределенностью → перенос подтвержденных фактов в техническую документацию.

Полное описание со сниппетами заняло примерно полдня. Часть времени при этом ушла на первую настройку среды и плагина (не все плагины так легко настраиваются или просто мне с idea не везет).

Но главное — эксперимент шёл параллельно с ручной работой другого аналитика над той же задачей.

После завершения мы сравнили результаты. Существенных расхождений в сценариях и технических фактах не оказалось, различались в основном формулировки.

Например, ручное описание начиналось примерно так:

> В сервисе реализованы эндпоинты для управления пакетами поставок. Пакеты используются для группировки изменений сущностей с целью последующего выполнения действий: отправки на ревью, развертывания и других операций.

Агент сформулировал вводный текст немного иначе:

> В сервисе реализованы эндпоинты для админки по работе с поставками. Поставки используются для группировки изменений сущностей перед согласованием и последующей выкаткой. Доступ к данным эндпоинтам извне ограничивается шлюзом доступа.

Смысл в обоих вариантах совпадал: речь шла о новой функциональности для группировки изменений и управления их жизненным циклом. Но агент, следуя style guide, сделал вводный текст более структурным: сначала указал, для кого предназначено API, затем объяснил назначение поставок, а отдельно вынес ограничение доступа.

При этом детали реализации не попадали в intro. Они оставались в описании конкретных методов, чтобы вводный раздел не превращался в техническую свалку.

Для меня это стало одним из главных результатов исследования.

Агент справился с другой предметной областью и другим форматом документации не потому, что «умеет писать middle-документацию», а потому что сработал процесс.

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

Здесь легко сделать неправильный вывод.

Раз агент смог работать с технической документацией, значит аналитик может заходить на территорию разработки и самому покрывать код тестами вместо разработчика

Нет.

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

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

В эксперименте с middle-документацией источником истины были код, OpenAPI и тесты. Результат дополнительно сравнивался с работой другого аналитика.

Но без достаточной экспертизы в разработке я не могу утверждать, что сгенерированный AI сниппет жизнеспособен. Я могу проверить, соответствует ли он описываемому сценарию и выполняет ли функцию примера в документации.

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

Аналитик может сэкономить два часа на генерации сниппетов, а разработчик затем потратить четыре на review, конфликты и исправление неработающего кода.

Это не оптимизация. Это перенос работы на следующего участника процесса.

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

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

Зоны ответственности остаются прежними: аналитик отвечает за требования и спецификацию, разработчик — за реализацию, тестировщик — за качество проверок. AI лишь помогает каждой роли работать быстрее со своим контекстом.

Что изменилось в процессе команды

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

Стало понятно, что основной эффект — не только в экономии времени аналитика.

Раньше один и тот же контекст фактически описывался на двух платформах:

Аналитик готовил основной документ в Confluence, а затем требования повторно переносились и интерпретировались в GitLab для разработки и агентов.

После эксперимента мы решили сосредоточиться на одном полноценном артефакте. и процессе:

- Аналитик формирует подтверждённый контекст.

- Агент разработчика использует спецификацию как вход для реализации.

- Тестировщик на основе спецификации подготавливает тест-кейсы.

Мы не убрали документацию из Confluence полностью, а убрали повторный перенос и интерпретацию одного и того же контекста.

Заключение

В марте я начинала с простого вопроса: «Зачем мне агент, если сама я сделаю быстрее?»

Первые эксперименты давали однозначный ответ: не нужен.

Задача «на день» растягивалась на три-четыре. Агент требовал постоянного контроля, придумывал данные и возвращал собственные решения в финальный документ как мои, а после запрета на додумывание начинал бесконечно задавать вопросы.

Постепенно стало понятно: мы давали агенту задачу, но не давали процесс. В итоге полезным оказался не «идеальный промт», а система ограничений: research → open questions → findings → domain-spec → API → документация.

А также:

- Отдельные style guide.

- Явные источники истины.

- Контроль неопределённости.

- Чёткие границы ответственности.

И к концу исследования вопрос изменился на «Можно ли один раз подготовить качественную спецификацию и перестать пересобирать один и тот же контекст отдельно для аналитика, разработчика и тестировщика?»

В нашем случае — да.

При этом мой главный вывод за квартал остаётся довольно жёстким — ИИ эффективен в аналитике только тогда, когда заперт в управляемый процесс. Без процесса он ускоряет не только создание документации, но и распространение ошибок. А с процессом, style guide, контролем неопределённости и ручной проверкой он становится полезным ассистентом.

AI ускоряет, он не заменяет вашу экспертизу. Если вы не способны проверить результат, вы не контролируете агента. Вы просто надеетесь, что он угадал. А на требованиях, API, коде и архитектурных решениях я бы на удачу пока не рассчитывала.

____________

Чтобы статья не осталась только рассказом о моем опыте, я собрала отдельную папку с материалами эксперимента.

[Ссылка на материалы]

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

В своей колонке Daily Drivers редактор Hackaday Дженни Лист скачала ISO-образ, запустила KolibriOS на современном ThinkPad и удивилась: система выглядит зрелой, стабильной и по-настоящему быстрой. Разбираем, что это за проект, откуда он взялся и кому пригодится сегодня.

Что такое KolibriOS

KolibriOS — российский форк MenuetOS, созданный в 2004 году. В то время как автор оригинального MenuetOS Вилле Турьянмаа переключился на закрытую 64-битную версию, сообщество вокруг русскоязычного порта сохранило код открытым и продолжило развивать 32-битную ветку. Название «Колибри» выбрано неслучайно: система маленькая и быстрая, как птица-колибри.

Проект поддерживается преимущественно разработчиками из России, Казахстана, Украины и Германии. Код распространяется под открытой лицензией, а сборки регулярно публикуются на официальном сайте и зеркалах сообщества.

Версия 0.7.7

Версия 0.7.7 продолжает философию предельного минимализма. Минимальные системные требования смехотворны по нынешним меркам: 1 МБ места на диске, 8 МБ оперативной памяти и процессор класса i586. При этом система выдаёт графический интерфейс, многозадачность и набор встроенных программ.

Дженни Лист отмечает, что на ThinkPad 2020-х годов KolibriOS загружается «в мгновение ока» и сразу показывает рабочий стол. Интерфейс выглядит пиксельным, как в 1990-х: нет сглаживания, есть ощущение ретро. Но при этом всё работает — без синих экранов и зависаний.

• KolibriOS 0.7.7 — 32-битная ОС с ядром на ассемблере, базовый образ весит около 1 МБ.
• Минимальные требования: i586, 8 МБ ОЗУ, 1 МБ на диске.
• В комплекте браузеры, игры, эмуляторы, графические редакторы и среда разработки.
• Главное ограничение для повседневного использования — отсутствие поддержки HTTPS.
• Лучше всего подходит для старого железа, тонких клиентов, обучения и ретрокомпьютинга.

Как устроена система

Ядро на ассемблере

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

Важная оговорка: несмотря на миф «всё на ассемблере», часть приложений и драйверов портирована или написана на C, Free Pascal, Oberon и даже Python. Но ядро, графическая подсистема и системные вызовы остаются ассемблерными.

Файловые системы и загрузка

KolibriOS умеет загружаться с CD/DVD, USB, жёстких дисков и даже с классической дискеты 1,44 МБ. Поддерживаются файловые системы FAT12/16/32, exFAT, NTFS и ext2/3/4. Есть варианты для Coreboot и загрузка прямо из Windows.

Что внутри: программы и игры

Несмотря на размер, KolibriOS поставляется с обширным набором софта. По данным сообщества, в образ входят более 250 программ, включая текстовый процессор, просмотрщик изображений, графический редактор, музыкальный плеер, IRC-клиент и веб-браузеры.

Из игр и развлечений — порты эмуляторов, DOSBox, а также shareware-версии классики вроде DOOM и Wolfenstein 3D на полноценном CD-образе. Есть поддержка SDL, что позволяет переносить проекты с «больших» систем.

Something this polished deserves a while to play around.

Главное ограничение: интернет без HTTPS

Дженни Лист называет именно этот момент решающим: встроенные браузеры KolibriOS, включая Netsurf и Webview, не поддерживают HTTPS. Без этого современный веб практически закрыт: большинство сайтов, включая сам Hackaday, просто не откроются.

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

Почему HTTPS сложно:
Современный TLS требует большой криптографической библиотеки, регулярных обновлений корневых сертификатов и поддержки множества алгоритмов. В условиях ОС размером в мегабайт это серьёзный архитектурный вызов, который сообщество пока не взяло в штатный комплект.

Кому и где пригодится KolibriOS

С учётом ограничений у KolibriOS остаётся несколько чётких сценариев применения. В России и соседних странах это особенно актуально: парки старого офисного и школьного оборудования часто содержат машины, которые официально «не тянут» современные ОС.

• Воскрешение старого железа. Pentium- и ранние Core-машины получают рабочий стол, браузер для локальных страниц и офисные утилиты.
• Тонкие клиенты. Низкие требования к RAM и CPU делают KolibriOS кандидатом для терминалов с удалённым рабочим столом.
• Обучение. Ядро на ассемблере, простые системные вызовы и небольшой кодовой базы — отличная площадка для изучения устройства ОС.
• Ретрокомпьютинг. Запуск DOS-игр через эмулятор, классические 2D-игры и ностальгический интерфейс 1990-х.
• Встроенные системы. Сборка Kolibri-A ориентирована на специализированное железо и железные проекты.

Как попробовать KolibriOS

Попробовать систему проще всего в виртуальной машине. Скачайте ISO-образ с официального сайта, создайте VM с 64 МБ ОЗУ и загрузитесь с образа. Для реального железа подойдёт запись образа на USB-флешку или CD.

• Скачайте ISO или образ дискеты с официального сайта KolibriOS.
• Для VM: создайте 32-битную машину с 64 МБ RAM и VESA-видео.
• Для железа: запишите ISO на CD или USB через обычную утилиту.
• Загрузитесь и выберите разрешение экрана из меню загрузчика.
• Исследуйте меню «Пуск»: игры, утилиты, терминал и браузер.

Если планируете использовать сетевые функции, проверьте совместимость сетевой карты по списку оборудования. Поддерживаются многие чипы Realtek, Intel и 3Com.

Выводы

KolibriOS 0.7.7 — это не замена Windows или Linux, а демонстрация того, какой отклик может давать компьютер, когда софт пишут под железо, а не под абстракции. В эпоху, когда операционки растут гигабайтами, проект напоминает: минимализм ещё жив.

Для российского читателя у KolibriOS есть дополнительный смысл: это открытый проект с русскоязычным сообществом, который можно изучать, дополнять и применять для решения практических задач — от перевода старого классного компьютера в рабочее состояние до обучения низкоуровневому программированию.

Главный вопрос — нужна ли вам такая система прямо сейчас. Если у вас есть старый 32-битный ноутбук, интерес к ассемблеру или просто ностальгия по быстрым ОС — попробуйте. А для повседневной работы с интернетом пока придётся держать под рукой что-то посовременнее.

Источники:

• Jenny’s Daily Drivers: KolibriOS 0.7.7 — Hackaday
• KolibriOS на DistroWatch
• Официальная вики KolibriOS

Тема получила новый импульс после серии публикаций Диона Доктера (Dion Dokter) из голландской компании Tweede golf. Во второй части он заглядывает внутрь rustc и утверждает: async Rust так и не вышел из состояния MVP. Я не буду дословно переводить его рассуждения, а переосмыслю их с упором на практику: как понять, платите ли вы за async-удобство лишними байтами, и как снизить налог, пока компилятор не научился делать это сам.

• Асинхронный Rust компилируется в state machine: на каждую await-точку приходится отдельное состояние плюс служебные Unresumed, Returned и Panicked.
• Простая функция с двумя await-точками даёт 360 строк MIR против 23 у синхронного кода. Часть излишков LLVM убирает, но не все, особенно при оптимизации по размеру.
• Компилятор не схлопывает идентичные состояния, не инлайнит futures через await, генерирует state machine даже для async-блоков без await и оставляет panic-путь в состоянии Returned.
• В release-сборках замена panic в Returned на возврат Pending может сократить прошивку на 2–5%. Убирание state machine у пустых async-блоков — ещё около 0,2%.
• Пока rustc не исправлен, можно вручную: возвращать impl Future из «прозрачных» функций, использовать std::future::ready, схлопывать await-точки через match и передавать большие данные по ссылке.

Почему async-функция — это всегда state machine

Когда вы пишете async fn, компилятор не просто оборачивает тело в callback. Он строит конечный автомат: enum, где каждый вариант — состояние между await-точками. Это называется coroutine desugaring и происходит на уровне MIR (Mid-level IR) — до того, как код попадает в LLVM.

Рассмотрим минимальный пример. Есть две функции, каждая из которых просто возвращает число, и третья складывает результаты:

У bar две await-точки, поэтому минимум два пользовательских состояния. Но если сдампить MIR после прохода coroutine_resume, картина шире:

Три служебных состояния добавляются всегда. Они нужны, чтобы соблюсти контракт Future::poll: опрос завершённой future не должен приводить к неопределённому поведению. Поэтому после первого Ready future переходит в Returned, а повторный poll паникует. Аналогично Panicked блокирует future после пойманного panic — похоже на poisoning мьютекса.

Логика корректная, но цена высокая: bar порождает 360 строк MIR, а эквивалентный синхронный код — 23. В 15 с лишним раз больше. LLVM часть этого выбросит, но на opt-level = "z" или в толстых async-графах вызовов он быстро сдаётся.

Четыре места, где компилятор работает вхолостую

1. Panic в состоянии Returned

Контракт future требует только отсутствия UB. Паниковать при повторном poll — не обязательно. Можно просто вернуть Pending снова: ничего опасного не произойдёт, а ветка panic — это лишний побочный эффект, который плохо оптимизируется.

Дион сделал экспериментальный патч rustc: в release-режиме Returned больше не паникует. На embedded-прошивках это дало 2–5% экономии бинарного размера. В debug-сборках панику можно оставить, чтобы быстро ловить ошибочный повторный poll, — по аналогии с overflow-checks.

2. State machine без await

Взгляните на функцию без единой await-точки:

Идеальная реализация — всегда возвращать Poll::Ready(5) безо всякого enum. А rustc генерирует полноценный CoroutineLayout с тремя служебными состояниями и switch по дискриминанту. Такие функции часто появляются в трейтах, где один интерфейс должен быть async, но конкретная реализация ничего не ждёт. Патч, убирающий state machine у async-блоков без await, даёт ещё 0,2% размера — мало, но правка тривиальная.

3. Futures не инлайнятся через await

Классический шаблон: адаптер просто пересылает вызов вниз.

Сейчас bar получает собственный state machine, который вызывает state machine foo. Вручную мы бы написали fn bar(blah) -> impl Future { foo(blah) } и избавились бы от лишнего enum. Аналогично с преамбулой и постамбулой: их можно перенести на FutureExt::map из крейта futures.

4. Одинаковые состояния не схлопываются

Если в async-функции несколько веток match ведут к одинаковому await, компилятор создаёт отдельное состояние на каждую ветку:

Здесь send_response вызывается с разными аргументами, но структура состояний дублируется. Если вынести выбор аргумента за await, получится одно состояние вместо двух:

В одном примере из статьи MIR сокращается с 456 до 302 строк, а ассемблер — примерно на 11%. Оптимизации stack, поэтому выигрыш в реальном коде может быть заметнее.

Что делать сегодня, не дожидаясь rustc

Всё перечисленное выше — это работа для команды компилятора. Но релиз с этими патчами может занять месяцы, а то и годы. Пока он не вышел, можно снизить async-bloat в своём коде.

Главный принцип: каждый лишний async fn — это лишний state machine. Если функция не содержит await, не делайте её async.

Заменяйте async-пустышки на impl Future

Типичный случай — трейт, где одна реализация реально ждёт ввода-вывода, а другая просто возвращает значение.

Вместо полноценного state machine получается готовая future, которая сразу возвращает Ready. Это особенно полезно в embedded-HAL, где трейты часто async, но конкретный драйвер может делать только прямой доступ к регистрам.

Прозрачные обёртки без await

Если функция только пересылает await вниз, уберите await:

Схлопывайте await-точки

Если несколько веток match заканчиваются одним и тем же await, вынесите выбор аргументов наружу. Это уменьшает число состояний state machine и облегчает жизнь LLVM.

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

Async-функция захватывает в state machine всё, что живёт через await. Если передать массив по значению, он окажется внутри future целиком:

Разница в 52 раза по размеру future — и это без учёта memcpy, который компилятор вынужден вставлять при перемещении больших значений.

Перспективы: Project Goal и финансирование

Дион оформил эти идеи как Rust Project Goal — формальный механизм, через который команды заявляют цели на полугодие. По его оценке, работа требует порядка €30 000 финансирования. Для компиляторного проекта это скромная сумма: речь идёт о 2–5% размера прошивки практически в любом async-проекте.

Есть и другой подход к той же проблеме: не убирать state machine на входе, а научить LLVM лучше их оптимизировать на выходе. Дион считает, что оба направления дополняют друг друга. Чем проще state machine попадает в LLVM, тем эффективнее её можно проинлайнить и упростить на поздних проходах.

Выводы

Async Rust never left the MVP state. The compiler generates state machines with a lot of unnecessary baggage. With a few targeted optimizations in rustc we can get smaller binaries and better performance for everyone.

Утверждение «async Rust так и не вышел из MVP» звучит резко, но поясняет, почему наши «zero-cost» абстракции иногда всё-таки стоят дорого. Компилятор делает корректный, но не оптимальный код: лишние panic-ветки, неинлайненные futures, дублирующиеся состояния и state machine там, где они не нужны.

Для embedded и WASM это не абстрактная проблема, а конкретные килобайты прошивки. Пока rustc учится, разработчик может снизить налог вручную: убирать async у функций без await, возвращать impl Future из прозрачных обёрток, схлопывать await-точки и не передавать большие структуры по значению.

Если ваш проект на Rust бьётся о лимит flash, имеет смысл посмотреть на async-граф вызовов свежим взглядом. Часто проще убрать одну лишнюю async-обёртку, чем месяцами ждать патч в компиляторе.

Источники:
— Dion Dokter, «Async Rust never left the MVP state»;
— Dion Dokter, «Debloat your async Rust»;
— Rust Project Goal: Async state machine optimisation.

Что такое NixOS

NixOS — это дистрибутив Linux, в котором всё системное окружение описывается декларативно на языке Nix и воспроизводится из одного конфигурационного файла. Каждая сборка помещает зависимости в /nix/store, что даёт атомарные откаты и воспроизводимость, но при этом легко разрастается размер.

Одна из удобных фич — команда nixos-rebuild build-vm: она превращает конфигурацию в виртуальную машину. Но иногда нужен не «тонкий» образ, привязанный к хосту, а самодостаточный ISO, который можно записать на флешку или загрузить в облаке.

• Базовый NixOS ISO занимает 458 МБ: 416 МБ — squashfs с пользовательским окружением, 26 МБ — initrd, 13 МБ — ядро.
• Главные «тяжеловесы» внутри образа: модули ядра (144 МБ), Python 3 (128 МБ), systemd (60 МБ), Perl (56 МБ), GRUB (около 62 МБ).
• Отключение Nix, документации, SSH, firewall и лишних зависимостей сокращает ISO до 197 МБ.
• Замена Perl-активации на экспериментальные system.etc.overlay и services.userborn даёт финальный размер около 183 МБ.
• Это игрушечный эксперимент: для десктопа и сервера такие отсечения небезопасны, но полезны как источник идей.

От VM к ISO за несколько строк

Минимальная виртуальная машина на NixOS собирается из файла примерно такого вида:

Запуск: $(nix-build basic-vm.nix --attr vm --no-out-link)/bin/run-nixos-vm. При этом /nix/store монтируется с хоста, поэтому VM «тонкая». Для независимого ISO импортируем модуль iso-image.nix и собираем атрибут isoImage:

ISO собирается, загружается в QEMU, но размер сразу бросается в глаза.

458 МБ — из чего они сложились

Автор примонтировал полученный ISO и посмотрел распределение места. Вот ключевые цифры:

• 416 МБ — сжатый nix-store.squashfs с пользовательским окружением.
• 26 МБ — начальная загрузочная среда initrd.
• 13 МБ — ядро Linux.
• 3 МБ — загрузчик isolinux.

При распаковке squashfs картина ещё интереснее:

• 144 МБ — модули ядра (linux-6.18.35-modules).
• 128 МБ — Python 3.13.
• 60 МБ — systemd.
• 56 МБ — Perl.
• ~62 МБ суммарно — две копии GRUB (UEFI + BIOS).

Поскольку ISO собирается локально, все пакеты из него есть и в хостовом /nix/store. Это позволяет использовать nix why-depends, чтобы найти, кто тащит каждую зависимость.

Отключаем Nix, документацию и лишние сервисы

Первый очевидный шаг — отказаться от демона Nix внутри ISO, ведь мы строим автономный образ, а не полноценную NixOS для работы с пакетами. Достаточно двух опций:

Результат: 384 МБ. Экономия скромная, потому что часть зависимостей Nix всё ещё тянется через сервис register-nix-paths. Он регистрирует содержимое хранилища ISO при загрузке — но Nix-то мы уже убрали. Отключаем и его:

Теперь ISO уменьшился до 360 МБ, а зависимость от Boost исчезла полностью.

SSH: модуль без выключателя

Следующий кандидат на удаление — OpenSSH-клиент. Проблема в том, что модуль programs/ssh.nix добавляет его в environment.corePackages, а отдельного переключателя programs.ssh.enable нет.

Попытка полностью исключить модуль через disabledModules ломает другие модули, например Plasma 6, которые ожидают существования опций programs.ssh. Выход — подменить опцию «пустышкой», не затрагивающей реальную конфигурацию:

Параллельно автор убрал firewall, documentation.man.enable и принудительно очистил environment.defaultPackages.

GRUB: зачем две копии загрузчика

ISO-пресет NixOS включает сразу и UEFI-, и BIOS-версии GRUB — отсюда около 62 МБ. Чёткого флага для отключения одной из них нет, поэтому автор пошёл грубым путём: сбросил system.extraDependencies и environment.systemPackages, оставив только environment.corePackages, чтобы shell хотя бы стартовал.

Ядерные модули: четверть образа

Модули ядра весили 144 МБ — больше, чем весь Alpine ISO. NixOS не предоставляет удобного способа ограничить их набор для runtime, поэтому автор просто удалил папку модулей из системы после сборки:

Это полностью отключает динамическую загрузку модулей. Если что-то нужно — оно должно оказаться в boot.initrd.kernelModules или availableKernelModules. После этого образ уменьшился до 197 МБ.

Perl: заменяем активацию системы

Perl в образе нужен только для скриптов активации: настройки /etc и создания пользователей. В nixpkgs уже есть экспериментальные замены — system.etc.overlay и нативный менеджер пользователей userborn.

Оба механизма помечены как экспериментальные, но в контексте «самодельного минимального ISO» это уже не самая безумная идея. Финальный размер: 183 МБ.

Что получилось и стоит ли повторять

За несколько итераций образ сократился с 458 МБ до 183 МБ — почти в 2,5 раза. При этом система всё ещё загружается, автор смог залогиниться под root, правда разрешение экрана перестало переключаться.

Важно: конфигурация выше — это не рецепт для продакшена. Отсутствие Nix, SSH, модулей ядра и Perl-активации ломает массу сценариев. Результат интересен скорее как демонстрация границ NixOS, чем как готовый шаблон.

Автор сама отмечает: для рабочего десктопа или сервера так делать не стоит. Но если вам нужен крошечный live-образ под единичный эксперимент — здесь много идей, с которых можно начать.

Выводы

Эксперимент показывает, что NixOS позволяет не только собирать сложные системы, но и жёстко урезать их — иногда в ущерб удобству. Главный инструмент здесь не волшебная опция, а последовательный анализ: смотреть, что занимает место, находить виновника через nix why-depends и решать, готовы ли вы от него отказаться.

«At some point I just kept going because I got curious.»

Если захотите повторить — начните с отключения Nix и документации, а дальше решайте, какие модули и пакеты действительно нужны в вашем live-образе. Исходный материал — в блоге автора: I can haz smoller NixOS ISOs?.

EROFS (Enhanced Read-Only File System) — это доступная с Linux 4.19 файловая система только для чтения, заточенная под производительность и компактное хранение образов контейнеров, систем Android и, всё чаще, AI-моделей.

• Linux 7.2 получил два ключевых улучшения EROFS: разреженные pcluster и оптимизированное отображение chunk-based inode.
• Поддержка sparse-данных помогает экономить место при копировании в overlayfs и корректно работать с SEEK_HOLE.
• Удалён устаревший бэкенд FSCACHE — его функциональность заменяют файловые монтирования и fanotify.
• Патчи подготовил мейнтейнер EROFS Гао Сян из Alibaba.

Зачем нужна поддержка разреженных данных

Разреженные (sparse) файлы содержат пустые участки, которые не занимают место на диске. EROFS уже умеет прозрачно сжимать нули, но для AI-датасетов важно именно сохранять дыры: иначе overlayfs при копировании «вверх» распределит под них реальное пространство, а системный вызов SEEK_HOLE не найдёт ни одной «дыры».

Мейнтейнер EROFS Гао Сян из Alibaba пояснил в патчах, что новый код отмечает целые pcluster как «дыры» двумя разными способами. Это особенно полезно для огромных AI-датасетов, где нулевые или неинициализированные фрагменты встречаются часто.

Оптимизация ввода-вывода и удаление FSCACHE

Помимо sparse-поддержки, EROFS в Linux 7.2 получила оптимизированное отображение запросов для inode на основе чанков. Разработчики сообщают, что новый код erofs_map_chunks() делает ввод-вывод более эффективным, хотя точных бенчмарков в анонсе не приводится.

Также из ядра окончательно удалили бэкенд FSCACHE для EROFS. Он раньше использовался для ленивой подгрузки образов, но после того как FSCACHE сделал NETFS обязательной зависимостью, функцию признали устаревшей. Похожее поведение теперь реализуют через монтирование файлов и хуки fanotify.

Итог

Обновления EROFS в Linux 7.2 делают эту файловую систему более удобной для больших AI-датасетов: разреженные данные теперь не превращаются в лишние мегабайты при копировании, а ввод-вывод для chunk-based inode стал эффективнее. Для разработчиков, которые используют EROFS в контейнерных и ML-окружениях, это повод проверить свои сборки ядра.

Источник: Phoronix.

Почему инфраструктура начинает привлекать больше, чем фичи

С фичами всё прозрачно: написал код — увидел результат на экране. Быстрая и понятная обратная связь. Но со временем замечаешь, что проблемы повторяются. Приложение тормозит не из-за плохого кода, а потому что на один экран уходит пять-шесть сетевых вызовов. Логика на клиенте. Хочешь что-то изменить — готовь релиз, проходи App Store Review и жди недели, пока обновление дойдёт до всех.

Я перешёл в Android-инфраструктуру — начал делать инструменты для других мобильных разработчиков. Это помогло увидеть: главные проблемы не в фичах, а в слое между приложением и бэкендом.

Возвращаться к фичам стало неинтересно. В инфраструктуре задачи сложнее, результат измеряется метриками — latency, error rate, скорость релизов, — а влияние на всю систему, а не на один экран.

Что Android даёт для инфраструктуры — а чему учиться с нуля

Мобильный бэкграунд оказался не балластом, а преимуществом. Я понимал ограничения изнутри. Backend-инженер может прочитать, что мобильные сети ненадёжны, память ограничена, а батарея — критичный ресурс. Но прочитать и прочувствовать — разное. Я годами наблюдал, как приложение “захлёбывается” на устройствах среднего сегмента. Знал, что 60% пользователей сидят именно на таких. Видел, как баг, который мы починили за день, продолжает висеть у людей неделями — просто потому, что они не успели обновиться.

Когда я проектировал gateway, я точно знал, что почувствуют мобильные разработчики, если ошибусь. Добавить ещё один сетевой вызов — это будет не бесплатно. Оставить логику в приложении — значит отдать её на устройство, которое я не контролирую.

Чего именно не хватало? Я неплохо понимал мобильную сторону, но совершенно не ориентировался в распределенных системах. Знал, например, что такое таймаут, но не представлял, как выставить его в цепочке из пяти сервисов так, чтобы одно медленное звено не обрушило весь экран пользователя. Понимал, что сети падают, но не умел проектировать систему, способную оставаться на плаву в таких условиях.

Чему пришлось учиться с нуля? Операционному мышлению. В Android ты выпускаешь релиз — и он либо работает, либо нет. Если крашится, починишь в следующей версии. В инфраструктуре нет «следующей версии». Если gateway падает, всё приложение ложится для миллионов пользователей прямо сейчас.

Пришлось учиться думать в терминах деградации, частичных отказов, плавного падения.

Что делать, если один из пяти сервисов не ответил? Как понять, что мы катимся к инциденту, до того, как пользователи начнут жаловаться?

Этому в мобильной разработке не учат.

Как я учился: пробелы, сроки и смена мышления

Формального плана у меня не было — учился на практике. Это лучший, хотя и самый стрессовый способ. Пробелы выявляла практика. Столкнулся с нерешаемой задачей — понял, чего не знаю. Пошёл разбираться.

Учился итеративно, не пытаясь объять необъятное сразу. Gateway начинался как простой прокси. Затем добавили агрегацию ответов, потом — конфигурационные определения экранов. Каждый такой шаг вынуждал осваивать следующий уровень: circuit breakers, стратегии повторов, observability, планирование мощностей.

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

Что означает «выдающийся уровень» в инфраструктуре

Когда говорят «спроектировать gateway с нуля и перевести на него живую платформу», за этими словами стоит не один навык, а целых три, и каждый требует совершенно разной подготовки.

Проектирование с нуля — это не рисование квадратиков на доске и не выбор модного стека. Это в первую очередь определение границ: что система будет делать, а что — категорически нет, и как с ней станут взаимодействовать десятки команд. Настоящая сложность здесь в том, чтобы предвидеть, что именно сломается, и заложить защиту от этого ещё до того, как написан хоть один файл с кодом.

Затем — миграция живой системы, где права на ошибку практически нет. Приложение нельзя выключить или отрепетировать в реальном масштабе. Остаётся только постепенный перевод трафика: shadow mode → 1% → 5% → 25% → 50% → 100%, с автоматическим откатом при любом росте ошибок. И всё это — пока миллионы пользователей активно работают с продуктом, не подозревая, что под капотом идёт замена двигателя на ходу. Такой уровень дисциплины и инструментации приходит только с практикой.

Наконец, владение надёжностью. Gateway — единая точка отказа: упал он, упало всё. Годы уходят на то, чтобы сделать его скучным и предсказуемым: резервирование, автомасштабирование, circuit breakers, режимы деградации, еженедельный пересмотр мощностей. Высший пилотаж — когда о системе просто не думаешь, потому что она работает.

Почему путь в инфраструктуру доступнее, чем кажется?

Карьерные траектории в инфраструктуре редко бывают чётко описаны. Здесь нет готового чек-листа в духе «диплом по Computer Science, пять лет в бэкенде, обязательное знание Kafka и Kubernetes». С одной стороны, такая неопределённость пугает. С другой — именно она и делает этот путь более доступным, чем принято думать.

Когда перед тобой лежит жёсткий список формальных требований, люди часто отсеивают себя сами, даже не попробовав. А в инфраструктуре по-настоящему важно только одно: можешь ли ты решать задачи. Я пришёл сюда без профильного диплома и учился ровно тому, что требовалось в моменте, потому что задачи сами подталкивали к этому.

Индустрия, к слову, до сих пор не слишком хорошо умеет проверять те навыки, которые на этом уровне оказываются решающими: умение видеть ограничения на стыке систем, предвидеть сценарии отказов, двигать людей к соглашению. Всему этому учатся не до начала работы, а непосредственно в процессе.

Поэтому если вы мобильный инженер и размышляете, можно ли перейти в инфраструктуру, — вопрос не в том, правильный ли у вас бэкграунд. Вопрос в другом: готовы ли вы учиться тому, чего пока не знаете, и способны ли обратить то, что уже понимаете, в собственное преимущество. Если ответ «да» — путь для вас открыт. Просто указателей на нём пока не расставили.

Мобильный бэкграунд как преимущество архитектора

Считаю ли я, что мобильный опыт сделал меня лучшим архитектором для mobile-first продуктов? Безоговорочно, да.

Я помнил, как ощущается медленный экран на устройстве среднего сегмента. Помнил, что случается, когда API возвращает слегка неправильные данные и приложение падает при парсинге. Помнил то чувство, когда баг уже в проде, а ты ждёшь App Store Review и ничего не можешь исправить.

Поэтому когда я проектировал gateway, я не занимался абстрактной «оптимизацией перформанса». Я опирался на совершенно конкретный опыт. Знал, что убрать один сетевой round trip — это подарок каждому мобильному разработчику. Знал, что перенос логики на сервер означает перенос в место, где я могу починить всё за минуты, а не за недели.

Лучшая инфраструктура для мобильных продуктов строится теми, кто сам их создавал и знает все узкие места не понаслышке. Этот опыт даёт верное направление: ты чувствуешь, где настоящие проблемы, потому что сталкивался с ними лично. Такому не учат по книгам.

Коротко: что делать, если думаете о переходе

• Найдите промежуточный шаг. Не прыгайте сразу в бэкенд. Начните с задач на стыке: оптимизация API, инструменты для мобильных разработчиков, улучшение сетевого слоя.
• Используйте мобильный контекст как рычаг. Вы понимаете то, о чём бэкенд-инженеры только догадываются. Говорите об этом вслух.
• Учитесь измерять невидимое. В инфраструктуре результат — это метрики: latency, error rate, скорость релизов. Учитесь рассказывать историю через цифры.
• Проектируйте под отказ, а не тушите пожары. Senior-уровень — это определить, что сломается и кто за это отвечает, до того, как оно сломается.
• Не ждите разрешения. Путь не размечен, но он открыт. Начните с малого — и двигайтесь туда, где задачи становятся интереснее.

Git worktrees позволяют держать несколько рабочих копий одного репозитория на разных ветках — и сейчас эта возможность в тренде. Забавно, что в Git она появилась ещё в 2015 году. Но worktrees действительно удобны, и в этой статье разберёмся, зачем они нужны, чем отличаются от обычных веток и почему внезапно стали популярны.

worktree — это дополнительная рабочая копия репозитория на другой ветке, привязанная к тому же .git.

С их помощью можно переключаться между задачами, не прерывая текущую работу и не используя stash.

Они особенно полезны при параллельной работе с ИИ-агентами и в приложении GitHub Copilot.

У worktrees есть ограничения: раздувание зависимостей, необходимость убирать папки, правила .gitignore и запрет на одновременный checkout одной ветки в нескольких worktrees.

Переключение контекста через ветки и stash

Представьте: вы работаете над задачей и вдруг получаете срочный баг. Нужно срочно переключить контекст.

Сначала, скорее всего, спрячете текущие изменения в stash:

Потом перейдёте на main и обновите её:

Затем создадите ветку с хотфиксом:

Пофиксите, закоммитите и запушите ветку:

После слияния pull request вы вернётесь к компьютеру, подтянете main и удалите ветку с багфиксом:

А потом сможете вернуться к задаче, над которой работали:

Фух. На чём мы остановились?

Переключение туда-сюда, перезагрузка файлов, переустановка node_modules в зависимости от того, что изменилось, — всё это отнимает много сил. Нагрузка от смены контекста серьёзная.

Это базовый пример, но иногда разработчики справлялись с таким хаосом сложными командами git stash или даже несколькими клонами одного репозитория (я сама грешила этим).

А потом появились… worktrees!

Переключение контекста через worktrees

С worktrees вы никогда не покидаете свою ветку и не используете stash, а редактор с вашей текущей фичей остаётся нетронутым.

Эта команда мгновенно создаёт соседнюю папку hotfix-workspace, базирует её на main и создаёт новую ветку hotfix-bug.

Теперь можно открыть эту папку в новом окне редактора (или перейти в неё через cd) и чинить баг. Исходное окно редактора остаётся в том же состоянии, в котором вы его оставили.

Pull request сливаете онлайн, как обычно, а после слияния можно просто удалить временную папку.

Гораздо плавнее! Нет риска конфликтов stash, редактор не перезагружается, и вы действительно можете работать параллельно.

Так почему же сейчас?

Долгое время worktrees были относительно неизвестны. Большинство разработчиков никогда о них не слышали, потому что либо Git GUI не поддерживали их (или относились как к второсортной функции), либо все привыкли к знакомой схеме: feature-ветка, работа, PR, merge и повтор.

Сейчас наша работа изменилась. ИИ заставляет нас работать параллельно больше, чем когда-либо в истории разработки ПО. Разработчики запускают множество сессий одновременно, а «культура код-ревью» растёт быстрее, чем «культура написания кода».

Агенты и люди могут делать больше параллельно с помощью worktrees. Это режим по умолчанию в приложении GitHub Copilot и во многих других современных инструментах.

Агенты и люди могут делать больше параллельно с помощью worktrees.

В чём подвох?

Worktrees решают кучу проблем, но есть нюансы, на которые стоит обращать внимание.

• Раздувание зависимостей: каждая папка worktree требует собственную копию зависимостей проекта. Если запускать npm install или pip install в нескольких worktrees, диск может быстро закончиться.
• Управление папками: нужно удалять папки worktree, чтобы со временем не засорять родительский каталог. Приложение GitHub Copilot часто делает это за вас, но если вы работаете в терминале, придётся следить самостоятельно.
• Требования к глобальному .gitignore: если создавать worktree внутри основного репозитория, их нужно вручную добавить в .gitignore, чтобы случайно не закоммитить. Можно создавать worktree за пределами основного репозитория (GitHub Copilot делает это по умолчанию), но это стоит учитывать.
• Ограничение «одна ветка»: Git не позволяет одновременно checkout’ить одну и ту же ветку в двух разных worktrees, чтобы избежать повреждения данных.

Как использовать git worktrees в приложении GitHub Copilot?

Отличный вопрос! Здорово, что там всё работает «из коробки». Когда вы открываете приложение, на главном экране есть выпадающий список, который спрашивает, где запускать новую сессию. По умолчанию выбран новый worktree.

Когда вы запускаете новую сессию, можно нажать на имя сессии вверху приложения и увидеть (забавное!) сгенерированное имя вашего worktree, а также путь, где он находится, проект, для которого он создан, и сведения о внесённых изменениях.

Проще простого!

Стоит ли использовать worktrees?

Я дам вам самый senior-ответ, который только можно: зависит от ситуации! Вам может быть удобнее работать по-другому. Возможно, вы не так много работаете параллельно и привыкли к ментальной модели веток и stash. Возможно, теперь вы будете использовать только worktrees. А может, захотите и то, и другое!

Мир у ваших ног, и попробовать всё это можно уже сегодня в приложении GitHub Copilot.

Об авторе. Cassidy Williams — старший директор по адвокации разработчиков в GitHub. Она создаёт ПО, консультирует стартапы и учит разработчиков строить лучше. Подписаться на её еженедельную рассылку можно на cassidoo.co/newsletter.

Выводы

Git worktrees — способ работать с несколькими ветками одновременно, не прерывая текущую задачу и не рискуя запутаться в stash. Они особенно удобны при параллельной работе с ИИ-агентами и встроены в приложение GitHub Copilot по умолчанию. Попробуйте — возможно, именно они упростят ваш рабочий процесс.

Что такое протокол передачи данных

Под протоколом передачи данных здесь понимается формат пакетов (кадров), которые строятся поверх физического уровня. Физический уровень — это уже выбранный интерфейс: RS-232, RS-485, инфракрасный канал, радиомодуль или оптоволокно. От него мы получаем две базовые операции: отправить один байт и принять один байт. Всё остальное — наша задача.

Данные передаются пакетами — кадрами. Хороший кадр позволяет приёмнику понять: где начало сообщения, кому оно адресовано, сколько в нём полезных данных и не повредились ли они по дороге.

Кадр состоит из заголовка, адресов, типа данных, длины, полезной нагрузки, контрольной суммы и концевика.

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

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

На хосте данные почти всегда буферизуются; на простых МК часто выгоднее передавать напрямую, чтобы сэкономить ОЗУ.

Структура кадра: из чего собирать пакет

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

Заголовок и концевик

Заголовок (frame header) и концевик (frame tail) отмечают границы кадра. Главное требование — минимизировать вероятность случайного совпадения этих байтов в потоке данных. Есть два подхода:

• Подбор характерных байтов. Если данные предсказуемы (например, только ASCII-текст), можно выбрать заголовок из диапазона непечатаемых символов.
• Увеличение длины. Для случайных данных лучше сделать заголовок многобайтовым — например, 0x55 0xAA 0x7E. Вероятность случайного совпадения трёх конкретных байтов подряд падает экспоненциально. Даже если совпадение произойдёт, его отловит контрольная сумма.

Адресация

Адрес назначения нужен в системах типа «один к многим» — например, когда один хост управляет несколькими датчиками по общей шине RS-485. В сложных сетях добавляют ещё и адрес источника, чтобы получатель знал, от кого пришёл пакет.

Тип, длина и данные

Тип данных (data type) говорит, что дальше идёт команда или полезная нагрузка. Длина (data length) указывает число значащих байтов в блоке данных. Вместе они образуют «тело» кадра — ту часть, которую мы действительно хотим доставить.

Контрольная сумма

Контрольная сумма проверяет целостность кадра. Простейший вариант — арифметическая сумма всех байтов тела. Для более серьёзной защиты применяют CRC (циклический избыточный код): он ловит пакетные ошибки и перестановки битов, которые простая сумма пропустит. Выбор алгоритма — компромисс между скоростью вычисления на МК и требуемой надёжностью.

Передача: хост и микроконтроллер

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

Передача с микроконтроллера

На простых контроллерах вроде семейства 8051 часто используют прямую передачу: процессор загружает байт в буфер UART и ждёт флага готовности. Плюс — данные моментально оказываются на линии. Минус — процессор занят на всё время отправки.

Альтернатива — передача по прерыванию: байты складываются в кольцевой буфер, а прерывание UART отправляет их фоном. Экономит процессорное время, но требует ОЗУ под буфер. На 8051 с его скудной памятью прямая передача часто выигрывает.

Передача с хоста

На ПК данные почти всегда буферизуются операционной системой. Программист работает с тремя уровнями абстракции:

1. Контролы ОС. В Windows — компоненты вроде MSComm (устаревший 32-bit ActiveX, не рекомендуется для новых проектов). Просто, но нужно следить за блокировками при приёме и многопоточностью.
2. Системные API. В Windows и Linux последовательный порт — это файл. Открываем через CreateFile или open(), но перед чтением и записью требуется настройка параметров порта (в Linux — termios со скоростью, чётностью и размером слова).
3. Класс-обёртка. Например, CSerialPort для Windows: он инкапсулирует инициализацию, поток приёма и отправку. После открытия порта вызов WriteToPort отправляет массив байтов, а внутренний поток следит за входящими данными и шлёт сообщения родительскому окну.

Приём и парсинг на конечном автомате

Приём данных на стороне микроконтроллера тоже бывает двух видов: опрос (поллинг) и прерывание. Опрос проще, но отнимает процессорное время. Прерывание эффективнее: байт пришёл — сработала процедура обработки прерывания (ISR, Interrupt Service Routine), процессор отвлёкся на доли миллисекунды и вернулся к задаче.

Где размещать парсер протокола? Если протокол простой, его можно держать прямо в обработчике прерывания: приняли корректный кадр — установили флаг, основной цикл реагирует. Для сложных протоколов лучше писать байты в буфер и разбирать их в главном цикле. Гибридный подход тоже возможен: в прерывании ищем только «команду подключения», а остальное парсим фоном.

Пример: разбор кадра по состояниям

Рассмотрим конкретный формат кадра:

Парсер реализуем через переменную state_machine. Каждое состояние соответствует ожидаемому байту. Если пришёл не тот байт — автомат сбрасывается в ноль. Это защищает от «залипания» в промежуточном состоянии при обрыве связи или помехах.

Совет по стабильности:
Сброс автомата при несовпадении заголовка, адресов, длины, checksum или концевика — ключевая техника. Без неё при обрыве кадра парсер застрянет в промежуточном состоянии, и следующие кадры будут отвергнуты.

Приём на стороне хоста

На ПК приём организуется проще: операционная система уже буферизует входящие байты. Для неблокирующего чтения запускают отдельный поток, который ждёт данных из порта и передаёт их в основной процесс через сообщения или обратный вызов. Класс CSerialPort, например, отправляет родительскому окну сообщение WM_COMM_RXCHAR с каждым новым байтом. Обработчик этого сообщения просто вызывает тот же парсер, что и на микроконтроллере.

Таким образом, логика разбора протокола единая для обеих сторон. Различается только способ доставки байтов в парсер: прерывание ISR на МК и поток ОС на хосте.

Выводы

Проектирование протокола связи для микроконтроллера — это не ракетостроение, но требует дисциплины. Хороший кадр защищает границы (заголовок + концевик), адресует получателя, указывает длину и проверяет целостность. Парсинг на конечном автомате делает код предсказуемым и устойчивым к сбоям.

Главный принцип — сбрасывать автомат при любом нарушении ожидаемого шаблона. Это предотвращает «залипание» и позволяет системе быстро восстановиться после помехи. На основе этой базы можно наращивать надёжность: добавлять повторные передачи, порядковые номера, шифрование — в зависимости от требований проекта.

Хороший протокол — это не тот, который передаёт быстрее всех, а тот, который не ломается при помехах.

Источник: оригинальная статья Leo Liu — Microcontroller Communication Protocol Design (DEV Community).

Индекс в базе данных — это вспомогательная структура (чаще всего B-дерево; хеш-индексы, GiST, GIN и другие типы применяются в узких специфических сценариях), которая ускоряет выборку строк по заданным колонкам. По аналогии с оглавлением книги: вместо перелистывания всех страниц СУБД сразу переходит к нужной главе. Но если оглавление построено плохо, пользы от него нет — а вот накладные расходы на поддержку остаются.

В этой статье разберём семь самых разрушительных ошибок индексации в production-SaaS: от параноидального создания индексов «на всякий случай» до игнорирования раздутия и особенностей мультитенантных схем. Каждая ошибка — с примерами SQL, метриками и конкретным фиксом.

Индексы — это налог на запись: каждый INSERT, UPDATE и DELETE обновляет все индексы таблицы.

Индекс на колонке с низкой селективностью (boolean, статус) почти бесполезен — используйте частичные (partial) индексы.

В составном индексе порядок колонок критичен: PostgreSQL может использовать (a, b, c) только если условие начинается с a.

Раздутые индексы на высокоизменяемых таблицах могут занимать в 8 раз больше места, чем нужно — планируйте REINDEX CONCURRENTLY.

В мультитенантных системах индекс по tenant_id один часто недостаточен: добавляйте диапазон времени или тип события.

Внешние ключи в PostgreSQL не индексируются автоматически — после каждого FOREIGN KEY создавайте индекс вручную.

Без EXPLAIN ANALYZE индексы создаются вслепую. Проверяйте реальный план выполнения перед деплоем.

Ошибка 1. Индексировать всё подряд «на всякий случай»

Самая распространённая ошибка — не недостаток индексов, а их избыток из тревожности. Особенно часто в неё попадают junior-разработчики: добавляют индекс на каждую колонку, которая встречается в WHERE, «на всякий случай». Кажется ответственным, но на самом деле вредно.

Каждый индекс — это налог на запись. При INSERT, UPDATE и DELETE PostgreSQL (или MySQL) вынуждена обновлять все индексы таблицы. На таблице с 8 индексами каждая запись трогает 8 структур данных. При низкой нагрузке это невидимо, но при 10 000 записей в минуту это становится узким местом.

Аудит неиспользуемых индексов в PostgreSQL:
Запрос к pg_stat_user_indexes покажет, сколько раз каждый индекс применялся с момента сброса статистики. Если idx_scan = 0 — индекс кандидат на удаление.

Не удаляйте индекс сразу — сначала убедитесь, что он не нужен для редких, но критичных отчётов. Но если он месяцами не используется, смело избавляйтесь.

Ошибка 2. Не понимать селективность

Индекс на булеву колонку — почти всегда бесполезен. Селективность измеряет, сколько различных значений содержится относительно общего числа строк. У boolean всего два значения. Если 95% строк имеют is_active = true, планировщик запросов проигнорирует индекс и сделает Seq Scan — и будет прав.

Правило большого пальца: если у колонки меньше 10–20 уникальных значений относительно размера таблицы, простой индекс по ней один не справится. Используйте частичные или составные индексы.

Ошибка 3. Неверный порядок колонок в составном индексе

Составные индексы мощны, но часто неправильно понимаются. PostgreSQL может использовать индекс (a, b, c) для фильтрации по a, a и b, a, b и c. Но не может эффективно использовать его, если запрос фильтрует только по b или c — ведущая колонка пропущена.

Решение: первыми ставьте колонки с equality-условиями, затем — по селективности, и проектируйте индексы вокруг реальных паттернов запросов, а не вокруг схемы таблицы. Также учитывайте ORDER BY и необходимость покрывающего индекса. Перед созданием обязательно запускайте EXPLAIN ANALYZE.

Ошибка 4. Игнорировать раздутие индексов

Индексы деградируют со временем. Многие инженеры воспринимают их как «поставил и забыл», но это заблуждение. В PostgreSQL при обновлении или удалении строки старые записи в индексе устаревают и накапливаются как раздутие (bloat); их физическое удаление происходит при выполнении VACUUM. На высокоизменяемых таблицах (заказы, события, логи, сессии) раздутие накапливается стремительно.

Таблица с 1 млн живых строк может иметь индекс, раздутый до размеров 8 млн записей. Каждый запрос через такой индекс делает в 8 раз больше работы, чем должен.

REINDEX CONCURRENTLY — ключевое слово. Обычный REINDEX блокирует таблицу, а в production-SaaS это прямой путь к инциденту. CONCURRENTLY перестраивает индекс без блокировок, хотя и медленнее.

Также убедитесь, что autovacuum настроен под вашу реальную нагрузку на запись. Значения по умолчанию в PostgreSQL консервативны и часто недостаточны для SaaS с высокой интенсивностью записи.

Ошибка 5. Индексы на колонках с малым числом уникальных значений в мультитенантных системах

В мультитенантной архитектуре почти каждый запрос фильтрует по tenant_id. Естественное желание — проиндексировать эту колонку. Но для крупных тенантов индекс по tenant_id вернёт слишком много строк, и планировщик предпочтёт Seq Scan. Для маленьких тенантов отдельный индекс по tenant_id может быть полезен.

На серьёзном масштабе правильное решение — партиционирование таблиц по tenant_id, но это архитектурное решение. Практический первый шаг — составные индексы с временными диапазонами.

Ошибка 6. Не индексировать внешние ключи

В PostgreSQL внешние ключи не индексируются автоматически. При удалении родительской строки СУБД должна проверить все дочерние таблицы на наличие ссылающихся записей — и без индекса на внешнем ключе это Seq Scan по каждой дочерней таблице. На таблице orders с 50 млн строк удаление пользователя вызывает полное сканирование.

Сделайте это командным соглашением: в чек-листе миграций обязательный пункт «после каждого FOREIGN KEY — CREATE INDEX».

Ошибка 7. Не использовать EXPLAIN ANALYZE перед деплоем

Большинство решений об индексах принимаются интуитивно. Интуиция ошибается достаточно часто, чтобы это стало проблемой. EXPLAIN ANALYZE показывает, что именно делает планировщик: какие индексы использует, какие игнорирует, сколько строк реально прочитал против оценки, где тратится время.

На что обращать внимание:
• Seq Scan на большой таблице при выборке малой доли строк — возможно, пропущен индекс или планировщик не может использовать существующий индекс.
• Rows Removed by Filter в десятки тысяч — индекс есть, но неправильные колонки или низкая селективность.
• Buffers: shared hit=0 read=45000 — данные не закэшированы (cold cache), страницы читаются с диска. Для диагностики раздутия смотрите общее число буферов и сравнивайте размер индекса с ожидаемым.
• Высокое actual time — проверьте раздутие, актуальность статистики, количество буферов, дисковую подсистему и наличие блокировок. Запустите ANALYZE tablename, чтобы обновить статистику планировщика.

Чек-лист индексации для SaaS

• У каждой колонки внешнего ключа есть индекс?
• Составные индексы упорядочены по селективности, а не по удобству?
• Булевы и низкокардинальные фильтры используют частичные индексы вместо полных?
• Вы запускали EXPLAIN ANALYZE на 10 самых медленных запросов за неделю?
• Есть процесс поиска и удаления неиспользуемых индексов?
• Высокоизменяемые таблицы регулярно проходят REINDEX CONCURRENTLY?
• Autovacuum настроен под реальный объём записи, а не под значения по умолчанию PostgreSQL?
• В мультитенантных таблицах индексы начинаются с tenant_id и включают диапазон времени?

Выводы

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

База данных, которая быстра на 10 000 строках и быстра на 50 миллионах, — не случайность. Это результат того, что кто-то считал планирование запросов первоклассной инженерной задачей, а не рутинным дополнением.

Проверьте свои самые медленные запросы этой недели — возможно, одна из этих семи ошибок уже сидит в вашей production-базе.

Источник и материалы:
• Database Indexing Mistakes That Kill SaaS Performance at Scale — оригинальная статья OutworkTech
• PostgreSQL Index Types — официальная документация
• REINDEX — документация по перестроению индексов

Разбираем, почему бидирекционный денойзинг оказался эффективнее привычного лево-направо декодирования, и что это значит для разработчиков интеллектуальных агентов.

Маскированные диффузионные языковые модели (MDLM) превосходят авторегрессионные LLM как модели мира (world models) для текстовых сред благодаря бидирекционному денойзингу и учёту якорей (anchors).

8-миллиардная SDAR обходит 35-миллиардную Qwen-3.5-35B-A3B по метрике MAUVE (0,982 против 0,932) и порождает состояния большего разнообразия.

GRPO-обучение на траекториях от MDLM даёт прирост до +47% на отложенных (held-out) средах (ALFWorld, ScienceWorld, AppWorld).

Экспертная оценка подтверждает высокий реализм (4,75/5) и корректность (4,25/5) сгенерированных состояний.

Ограничения: хрупкая генерация API-ключей, pagination drift и блоковые повторы при высокой temperature.

В контексте обучения с подкреплением (RL) world model — это генеративная модель, которая предсказывает следующее состояние среды на основе текущего состояния и действия агента. Вместо того чтобы взаимодействовать с реальным API или базой данных на каждом шаге обучения, агент может «играть» в симуляции, созданной world model. Это дешевле, быстрее и позволяет порождать редкие или опасные сценарии, которые сложно воспроизвести в реальной системе.

Ранее для текстовых сред чаще всего использовали обычные автрегрессионные LLM: подали префикс — модель дописала продолжение. Но у этого подхода есть фундаментальное ограничение: состояния среды часто содержат якоря (anchors) — фиксированные поля, которые должны оставаться неизменными (например, user_id или status: "error"). Авторегрессионная модель, генерирующая текст строго слева направо, не видит эти якоря до тех пор, пока не дойдёт до них, и рискует сгенерировать противоречивое состояние.

Почему автрегрессионные LLM плохо справляются

Представьте, что модели нужно сгенерировать ответ API о возврате платежа. В схеме зафиксированы поля ticket_id и user_id, а также конечный статус "error". Авторегрессионная модель начинает декодирование с первого поля и не видит финальный статус до самого конца. В результате она может сгенерировать refund_processed: true, хотя статус требует ошибки — получается глобально некорректное состояние.

Этот эффект называется left-to-right bias: causal attention маскирует будущие токены, и модель вынуждена принимать решения без учёта глобальных ограничений. При масштабировании длины траекторий ошибки накапливаются, что приводит к mode collapse — агент видит всё меньше разнообразных ситуаций и переобучается.

Проблема в цифрах:
Исследователи показали, что даже 35-миллиардная авторегрессионная модель (Qwen-3.5-35B-A3B) уступает 8-миллиардной диффузионной по метрике MAUVE, измеряющей согласованность распределений сгенерированных и реальных состояний.

Как работают маскированные диффузионные модели

Маскированные диффузионные языковые модели (MDLM) обучаются итеративно восстанавливать замаскированные токены в последовательности. В отличие от авторегрессионных моделей, они используют бидирекциональное внимание: при подавлении шума каждой позиции модель видит все уже известные и все ещё замаскированные токены одновременно. Это позволяет учитывать якоря с обеих сторон последовательности.

Ключевое преимущество для world modeling — any-order generation. MDLM может заполнять поля состояния в произвольном порядке: сначала зафиксировать статус ошибки, потом подобрать под него корректный код ошибки, а уже затем заполнить остальные поля. Такой подход естественным образом поддерживает глобальную согласованность состояния и снижает накопление ошибок.

Ещё одно отличие — стохастичность самого порядка генерации. В авторегрессионной модели temperature влияет только на выбор токена; в MDLM она влияет ещё и на то, какую позицию раскрывать следующей. Это даёт дополнительную ось разнообразия и помогает избежать коллапса моды (mode collapse) на высоковероятных префиксах.

Результаты: 8B против 35B и zero-shot transfer

Авторы исследования собрали крупный датасет из сотен тысяч траекторий из девяти открытых сред (SWE-bench, CoderForge, TauBench, Gorilla, Toolathlon и других), сгенерированных передовыми моделями. На этих данных они дообучили несколько MDLM (SDAR-8B, SDAR-30B-A3B, WeDLM-8B, LLaDA-2.1-mini) и сравнили с авторегрессионными базовыми линиями (Qwen-3.5-27B, GPT-OSS-20B, GLM-4.7-Flash, Nemotron-3-Nano-30B, Qwen-3.5-35B-A3B).

Генерация состояний

На in-domain тесте SDAR-8B достиг MAUVE = 0,982, тогда как сильнейшая AR-модель (Qwen-3.5-35B-A3B) — всего 0,932. На out-of-domain наборах (API-Bank, OccuBench, Intercode-SQL) разрыв сохраняется: SDAR-8B показывает MAUVE 0,979 против 0,960 у 35-миллиардного конкурента. При этом Self-BLEU у SDAR-8B ниже (0,601 против 0,690), а Distinct-N выше (0,385 против 0,253) — это означает, что диффузионная модель порождает состояния большего разнообразия.

Обучение агентов без дообучения среды

Главный практический тест — можно ли использовать траектории от MDLM для обучения агентов в совершенно новых средах? Авторы применили GRPO (Group Relative Policy Optimization) с траекториями от SDAR-8B и Qwen-3.5-27B на трёх отложенных (held-out) средах: AppWorld, ScienceWorld и ALFWorld. Результаты впечатляют:

• LFM2.5-1.2B на ALFWorld: с 5,7% (база) до 53,6% с SDAR-WM — прирост +47,9% абсолютных пунктов.
• Mistral-7B на ScienceWorld: с 3,3% до 48,4% — прирост +45,1%.
• Qwen3-4B на AppWorld: с 33,3% до 62,0% — прирост +28,7%.
• Во всех девяти пара модель-среда SDAR-WM превосходит Qwen-WM в среднем на +5,3 пункта.

Критически важно: это zero-shot transfer — агенты не видели целевые среды во время обучения world model. Ранее подобные результаты требовали специфической адаптации под каждую среду.

Оценка людьми

Четыре независимых эксперта с опытом работы с LLM-агентами оценили 100 сгенерированных состояний по шкале Лайкера 1–5. Средние оценки SDAR: 4,75 (реализм), 4,25 (корректность исхода), 4,50 (польза для обучения). Коэффициент согласия Криппендорфа α ≥ 0,89 на всех метриках говорит о высокой межаннотаторной надёжности.

Ограничения и подводные камни

Несмотря на впечатляющие цифры, у MDLM как world models есть свои слабые места. Во-первых, модели испытывают трудности с генерацией структурированных полей вроде API-ключей: комбинация safety-alignment базовой Qwen и малого block size при диффузии приводит к искажённым строкам. Во-вторых, при работе с постраничным выводом (pagination) MDLM иногда теряет нумерацию страниц — эффект, который авторы назвали pagination drift.

Также при высоких температурах модель может зацикливаться на блоковом уровне, повторяя одни и те же фрагменты состояния. Авторы отмечают, что все три ограничения, скорее всего, ослабнут с ростом размера модели и специализированным дообучением на задачи работы с инструментами.

Что это значит для разработчиков

Для инженеров, строящих агентных систем, исследование открывает сразу несколько перспектив:

1. Синтетические данные для RL. Если у вас нет доступа к реальному контуру заказчика, MDLM-модель может сгенерировать вполне реалистичные траектории для предварительного обучения агента, прежде чем вы перейдёте к дорогим реальным вызовам.
2. Аугментация редких сценариев. Диффузионная природа MDLM даёт естественный способ порождать редкие ошибки и пограничные случаи, которые плохо представлены в логах production.
3. Эффективность по параметрам. 8-миллиардная диффузионная модель может заменить 30-миллиардную автрегрессионную в задаче симуляции — это снижает требования к инфраструктуре вывода.
4. Управляемость. Возможность задавать якоря и направлять генерацию через маскирование упрощает создание отобранных обучающих выборок под конкретные домены.

Если тема RL и агентов вам близка, загляните в наши материалы: как работает Reinforcement Learning, ускорение Qwen3.6 в llama.cpp и локальный запуск Mistral.

Важно понимать, что MDLM не заменяют полностью реальные среды: они скорее служат мостом между supervised fine-tuning и дорогим RL в production, позволяя дешево итерировать политику агента.

Выводы

Исследование Patronus AI демонстрирует, что архитектурный выбор важнее сырого количества параметров: 8-миллиардная маскированная диффузионная модель превосходит 35-миллиардную авторегрессионную в задаче world modeling благодаря бидирекционному денойзингу и способности учитывать якоря состояния. Для разработчиков агентных систем это открывает путь к дешёвым и разнообразным синтетическим средам для обучения.

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

Если вы планируете внедрять RL в агентные пайплайны, стоит следить за развитием MDLM: с ростом масштаба и специализации эта архитектура может стать стандартом де-факто для симуляции текстовых сред.

Источник: Deshpande D. Masked Diffusion Language Models are Strong and Steerable Text-Based World Models for Agentic RL. Zenodo, 2026. DOI: 10.5281/zenodo.20219105. Исследование пока доступно только в виде препринта, его выводы стоит воспринимать с осторожностью.

Flatten — операция приведения вложенной структуры к одномерной. Самый распространённый кейс: матрица представлена как список списков, а вам нужен плоский список всех значений, чтобы передать в алгоритм или ML-модель. В отличие от других языков, в Python нет встроенного .flatten() у списков — поэтому стандартное «как это сделать?» имеет несколько ответов разной степени читаемости и эффективности.

Пусть у нас есть матрица 4×4:

Цель — получить:

• Быстрее всего работает обычный цикл с in-place мутацией: += или .extend(). Время — около 5–7 мс.
• itertools.chain() — около 16 мс, но в 3 раза экономнее по памяти; подходит, когда финальный список не нужен полностью.
• List comprehension — около 24 мс. Читаемо и без побочных эффектов, но создаёт промежуточные объекты.
• functools.reduce() + lambda и sum() — от 2,6 секунд. Это в 400–500 раз медленнее за счёт постоянного создания новых промежуточных списков.
• Для произвольной вложенности — рекурсия или итеративный обход со стеком.
• В data-science для NumPy-массивов используйте np.ndarray.flatten() — он быстрее любого варианта на чистых списках.

Способ 1. Цикл for + .extend()

Самый прямолинейный и читаемый вариант: проходим по каждой подсписку и добавляем её элементы к итоговому списку через .extend().

.extend() принимает любой iterable и поэлементно добавляет его в конец списка. Альтернативно можно использовать augmented-concatenation +=:

Обе функции делают одно и то же. Real Python отмечает: flatten_extend читается чуть лучше, потому что метод named — намекает на смысл операции. По скорости варианты идут в первой тройке.

Способ 2. List comprehension

Pythonic-альтернатива однострочнику. Двойной for внутри comprehension перебирает сначала строки, потом элементы строк:

Подход компактнее цикла и не плодит промежуточных переменных. Скорость — заметно медленнее .extend() из-за двух вложенных циклов на уровне comprehension, но всё ещё в диапазоне десятков миллисекунд.

Способ 3. itertools.chain() — экономно по памяти

chain() возвращает итератор, а не список. Это значит, что вы можете обходить элементы потокового, не материализуя весь массив в памяти — полезно, когда матрица большая и хранить полный flat-список нерационально.

На большой матрице chain.from_iterable примерно в три раза медленнее цикла .extend(): накладные расходы на материализацию через list(). Но если итоговый список как таковой не нужен — можно отдать сам итератор потребителю и сэкономить и время, и память.

Способ 4. functools.reduce() и sum() — почему так медленно

Эти варианты часто появляются в туториалах для красоты, но на практике плохо масштабируются. Причина одна: каждая итерация создаёт новый промежуточный список вместо мутации существующего.

iconcat мутирует аккумулятор и держится в топ-3 по скорости. А вот вариант с lambda и оператором + на каждом шаге копирует обе стороны — отсюда и взрывной рост времени на больших данных.

С sum() ситуация ровно такая же:

sum() работает на любых сложениях, но для списков это О(n²) по аллокациям. На матрице 1000×1000 он в ~500 раз медленнее цикла с .extend().

Способ 5. Произвольная вложенность — рекурсия и стек

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

Рекурсия удобна, пока глубина не упирается в sys.getrecursionlimit() (по умолчанию 1000). Для очень глубоких структур стоит переписать через итеративный обход со стеком:

Способ 6. NumPy для data-science

Если вы работаете с матрицами в data-science, у numpy.ndarray есть готовый метод .flatten(). Он быстрее любого варианта на чистых Python-списках, потому что под капотом работает с непрерывным блоком памяти.

Замер производительности

Real Python прогнали все варианты на матрице 1000×1000 через timeit. Результаты, отсортированные по времени:

Между первыми тремя и последними четырьмя — пропасть в 400–500 раз. Причина: топовые функции мутируют существующий список, а reduce(+), reduce(operator.add), reduce(lambda x, y: x + y) и sum() на каждой итерации создают копии.

FAQ

Выводы

Если вам нужен один-в-один поведенческий рецепт: for row in matrix: flat.extend(row). Этот код понятен любому, кто знает Python, и упирается в производительность только когда матрица переваливает за миллионы элементов. Если объёмы такие, что нужна потоковая обработка — переключитесь на itertools.chain. Если данные numerical — используйте NumPy.

Главное, чего стоит избегать — sum(matrix, []) и reduce с + или lambda. Они смотрятся изящно в туториалах, но превращают O(n) в O(n²) и ставят вас в первую же боттлнек-историю на проде.

Оригинальный туториал с пошаговыми объяснениями и сравнением — на Real Python, автор — Leodanis Pozo Ramos.

Это вторая часть серии. В первой — обходные приёмы для async-кода прямо в пользовательском коде. Во второй — автор копает в MIR (Mid-level Intermediate Representation — внутреннее представление rustc между исходником и LLVM IR) и формулирует, что должен научиться делать сам компилятор. Цель — не лечить симптомы, а добраться до корня и улучшить генерацию futures.

• Async-функция в Rust разворачивается в state machine: компилятор генерирует enum с одним состоянием на каждую точку await плюс три служебных — Unresumed (старт), Returned (после завершения) и Panicked (после пойманного catch_unwind).
• Функция с двумя await-точками у автора разворачивается в 360 строк MIR против 23 у синхронного аналога — больше чем в 15 раз. Часть этого LLVM срежет, но не всё.
• Замена panic! в состоянии Returned на возврат Pending в release-сборках даёт 2–5% экономии размера прошивки на embedded.
• Ещё четыре оптимизации: убрать state machine у async-блоков без await-точек, заинлайнить futures с одним await, схлопнуть одинаковые состояния из ветвей match, под panic=abort вообще убрать состояние Panicked.
• Автор подал Rust Project Goal и оценил работу примерно в €30 000 финансирования.

Что компилятор делает с async-блоком

Возьмём простой пример из статьи:

У bar два await-points — значит, в state machine минимум два состояния. Просим компилятор сдампить MIR на этапе coroutine_resume (последний async-специфичный pass) и видим:

Returned и Panicked — служебные. Future::poll — безопасная функция, и опросить уже завершённую future нельзя так, чтобы получить undefined behaviour. Поэтому компилятор после первого Ready переключает future в Returned, и при повторном poll она паникует. Похожая логика для Panicked: после пойманного unwind future блокируется от повторного poll, иначе можно дёрнуть её в неконсистентном состоянии — автор сам отмечает, что точная документация по этому состоянию ему не нашлась, и сравнивает механизм с mutex poisoning.

Логично, но автор замечает: bar генерирует 360 строк MIR, а синхронный аналог — 23 строки. То есть в 15+ раз больше. Часть этого добавления LLVM оптимизирует позже, но не всё — и на embedded остаток ощутимо влияет на размер прошивки.

Оптимизация 1: вместо panic — снова Pending

Future в состоянии Returned обязана не вызывать UB. А не обязана паниковать. Можно вместо panic! просто возвращать Pending: контракт Future не нарушается, ничего опасного не происходит.

Panic — относительно дорого: добавляется ветка с побочным эффектом, которая плохо оптимизируется. Автор пропатчил компилятор и измерил: 2–5% сокращение размера бинарника для async-прошивок на embedded.

Идеальное место — флаг по аналогии с overflow-checks = false: в debug-сборке оставляем panic, чтобы быстро ловить ошибочный повторный poll, в release — экономим. Аналогично, при panic = abort состояние Panicked потенциально можно убрать целиком — автор хочет это отдельно исследовать.

Оптимизация 2: лишняя state machine у пустого async-блока

Возвращаемся к foo: там нет ни одного await-point, future просто возвращает число. Логично было бы реализовать вручную как:

Никакого состояния не нужно — просто вернуть 5. На деле компилятор генерирует CoroutineLayout с тремя вариантами (Unresumed, Returned, Panicked) и честный switch по дискриминанту перед каждым возвратом — даже там, где без него можно было обойтись. Когда await-точек ноль, state machine можно убирать целиком — это около 0,2% размера бинарника. Поведение чуть меняется только для неконформных executor-ов: future всегда возвращает Ready без переходов между состояниями.

Ещё две оптимизации в плане работ

• Inlining futures с одним await-point. В таких future внутреннее состояние сводится к Suspend0 + Returned + Panicked, а ветка управления при правильной работе компилятора схлопывается в обычный вызов с одним переключением.
• Схлопывание идентичных состояний из ветвей match. Если в функции несколько await-точек попадают в одинаковые по смыслу варианты (одни и те же сохранённые поля), их можно объединить в одно состояние state machine — без потери семантики.

Каждый из этих кейсов даёт меньше, чем замена panic на Pending, но вместе с ней образуют связный набор патчей в компилятор. Автор формулирует план так: вынести проблему из «каждая embedded-команда со своими обходными приёмами» в «исправление в rustc раз и навсегда».

Project Goal и финансирование

Изменения требуют времени на проектирование, обсуждение в Rust-проекте и собственно правки. Автор оформил это как Project Goal по async state machine optimisation и оценил необходимое финансирование примерно в €30 000 — в основном на работу embedded-инженера над патчами компилятора. Платит обычно либо сам Tweede golf, либо Rust Foundation через программу грантов, либо отдельный спонсор; Project Goal — публичный механизм, чтобы заявить цель и собрать поддержку, в том числе финансовую. По меркам компиляторных проектов это недорого: типичная цена «уберём 2–5% размера прошивки в любом async-проекте» — десятки тысяч евро.

Это вторая часть серии. В первой я показывал, что вы можете сделать в своём async-коде, чтобы избежать части bloat. Во второй мы лезем во внутренности и переводим методы из первой части в оптимизации для компилятора.

Выводы

Async в Rust — давно главный болевой пункт у embedded-сообщества: обещания zero cost не подтверждаются, а обходные приёмы на уровне пользовательского кода сильно ограничены. Tweede golf формулирует разговор иначе: показывает, какие именно паттерны генерации виноваты, и предлагает их закрывать в компиляторе.

Для практика это значит две вещи. Первое — писать async-код можно не оглядываясь на «не сделать ли я ещё одно состояние»; bloat лежит в компиляторе, и просьба к нему — править генерацию, а не ваши async fn. Второе — следить за статусом Project Goal: если его подхватят, размер async-кода в release-сборках уменьшится у всех пользователей сразу, без правок в их репозиториях.

Оригинал — на tweedegolf.nl/en/blog/237/async-rust-never-left-the-mvp-state. Первая часть серии — «Debloat your async Rust». Project Goal лежит на rust-project-goals/2026/async-statemachine-optimisation.

В материале на блоге LogRocket разобран один из самых частых React-паттернов, который в неподходящем контексте оказывается одним из самых дорогих, — передача inline-объектов, массивов и колбэков прямо в месте вызова компонента. Контролируемый эксперимент с 200 memoized строк показывает, как это превращает один keystroke в коммит на 243,9 мс — и как простой рефактор возвращает время до 6 мс.

React.memo сравнивает по ссылке. Внутри React работает Object.is: {padding:16} и {padding:16} — это разные ссылки, значит «изменилось».

Inline-объекты в JSX обнуляют memo. Каждый рендер родителя создаёт новый объект/функцию, мемоизированный дочерний компонент видит «новые пропсы» и перерисовывается заново. Оптимизация, которую вы планировали, не срабатывает.

Цена в живом коде. Эксперимент: 200 memoized строк, поиск, inline style и onAddToCart. После 6 нажатий — счётчик рендеров каждой строки = 14, на keystroke коммит 243,9 мс.

Фикс простой. Статичный объект — в module scope. Динамический колбэк — в useCallback с пустыми зависимостями. После: коммит 6 мс, счётчик рендеров = 2, Why Did You Render молчит.

React Compiler не отменяет понимания. Он автоматизирует много memoization, но useMemo/useCallback остаются escape hatch для случаев, когда нужен точный контроль (например, dependency для Effect).

Как работает bailout у React

React.memo оборачивает компонент в memoization-границу. Когда родитель ререндерится, React не пропускает дочерний автоматически только потому, что он мемоизирован. Вместо этого сравниваются новые пропсы со старыми. Если каждый пропс считается равным — bail out, переиспользуем предыдущий результат. Если хотя бы один не равен — рендер. По умолчанию React сравнивает попропсово через Object.is.

Эта деталь критична, потому что для объектов и функций Object.is — это, по сути, проверка по ссылке:

Содержимое выглядит идентичным, но ссылки разные. React поэтому считает их изменёнными. Именно по этой причине inline-объекты и колбэки оказываются скрытой причиной того, что мемоизированный дочерний компонент продолжает ререндериться.

Та же логика объясняет, зачем нужны useCallback и useMemo. По документации React, useCallback кеширует определение функции между рендерами, а useMemo — результат вычисления. Оба помогают только тогда, когда зависимости остаются достаточно стабильными, чтобы React переиспользовал предыдущее значение. Если положить в массив зависимостей нестабильный объект, React видит новую зависимость на каждом рендере и пересчитывает заново.

Это и объясняет, почему баг ощущается запутанным в реальном приложении. Значения «выглядят» неизменными для человека: у style-объекта те же ключи, тело колбэка идентично, config всё ещё говорит то же самое. Но React не сравнивает намерение или структуру — он сравнивает идентичность.

Когда inline-пропсы реально становятся проблемой

Стоит провести границу между теоретической и практической ценой. Inline-колбэк сам по себе — не баг производительности. Если ребёнок дешёвый, частота рендера низкая и memoization-границы вокруг нет, измеримого отрицательного эффекта может вообще не быть. И в документации React, и в гайдах LogRocket по производительности — общее место: оптимизация работает там, где есть реальные узкие места, а не гипотетические.

Проблема начинается, когда сходятся три условия одновременно:

• Родитель ререндерится часто (поиск, скролл, фильтры, анимация, live data).
• Дочерний компонент или поддерево большое — лишняя работа заметна.
• Вы уже добавили memoization и ждёте, что React пропустит работу, когда «ничего важного не изменилось».

В такой связке нестабильные inline-ссылки не просто добавляют немного оверхеда — они обнуляют ту оптимизацию, которую вы намеренно ввели. И этот паттерн коварен в продакшене: он не объявляет себя багом. UI работает, исключений нет, предупреждений нет, и без профилировщика часто нет очевидного запаха. Цена проявляется иначе: тормозящая фильтрация списков, лаг ввода, шумные flame-графы и компонентные деревья, которые продолжают перерисовываться, даже когда осмысленные данные не менялись.

Контролируемый эксперимент: 200 memoized строк

Чтобы не спорить «плохо или нормально», автор поста собрал контролируемый тест: поисковый список товаров с 200 memoized строками, где каждая строка получает одинаковые логические значения, но новые ссылки на объект и функцию на каждом рендере родителя. Это позволяет напрямую увидеть, делает ли React.memo bail out или всё поддерево ререндерится на каждое нажатие клавиши.

Представьте storefront UI с 200 memoized ProductRow. Родитель — ProductList — хранит searchTerm в state. Каждое нажатие апдейтит state, ререндерит ProductList и снова прогоняет JSX, который мапает отфильтрованные товары. В эксперименте каждая ProductRow обёрнута в memo и помечена whyDidYouRender = true, но получает два inline-пропса в месте вызова:

Это ровно тот случай, о котором React предупреждает при передаче функций в memoized-компоненты: свежая функция или объект, созданные во время рендера, не пройдут сравнение пропсов, если ссылку не стабилизировать.

В эксперименте эффект становится виден почти мгновенно. Объект style и колбэк onAddToCart пересоздаются каждый раз, когда ререндерится ProductList, поэтому memo-обёртка видит изменённые пропсы для каждой строки на каждом нажатии. Счётчик рендеров делает это конкретным: после шести нажатий каждая видимая строка показывает Renders: 14. React Profiler затем показывает рантайм-цену ошибки: одно нажатие порождает коммит, в котором ProductList занимает 243,9 мс и все 200 row-fibers светятся в flame-графе.

Здесь React Developer Tools отрабатывают по полной. По официальной документации, React DevTools позволяют инспектировать компоненты, редактировать пропсы и state, а также находить проблемы производительности. Профайлер также доступен программно через <Profiler>, но интерактивный вид DevTools обычно используется командами для отладки.

Why Did You Render делает корневую причину ещё нагляднее. Пакет модифицирует React и сообщает о потенциально избегаемых ререндерах. В этом примере он рапортует props.style как «different objects that are equal by value» и props.onAddToCart как «different functions with the same name» — ровно тот референциальный мисматч, который мы и ожидаем. Это диагностический инструмент только для разработки, не для прода, но крайне эффективный для выявления этого класса багов.

Рефакторинг, который реально решает проблему

Чтобы остановить каскад рендеров, нужны стабильные ссылки. Концептуально фикс прост: значения, которые не меняются, не должны пересоздаваться во время рендера; колбэки, которым нужно жить через рендеры, должны быть memoized, когда ребёнок зависит от референциальной стабильности.

Вынос ROW_STYLE в module scope решает проблему на самом дешёвом уровне: React никогда не видит новую ссылку на объект, потому что он создаётся один раз вне компонента. Использование useCallback для handleAddToCart даёт ребёнку стабильную ссылку на функцию между рендерами, пока массив зависимостей не меняется. Это и есть тот случай, для которого React документирует useCallback при передаче функций в мемоизированных детей.

В эксперименте стабилизация ссылок восстанавливает bail-out. Измеренный результат впечатляет: ProductList падает с 243,9 мс до 6 мс, бейджи рендеров остаются на 2 сколько ни печатай, и Why Did You Render замолкает — избегаемых референциальных мисматчей больше нет.

Когда стабилизировать ссылки, а когда — нет

Это часть, которая часто теряется в дискуссиях про производительность. Урок не «никогда не используй inline-объекты» и не «оборачивай всё в useCallback». Урок: memoization — это контракт. Если ребёнок полагается на референциальное равенство, чтобы пропустить работу, родитель обязан этот контракт уважать и передавать стабильные ссылки.

Но это не значит, что каждому компоненту нужна агрессивная мемоизация. Современные рекомендации React всё ещё трактуют memoization как точечную оптимизацию, а не дефолтный стиль. Если рендер дешёвый, поддерево маленькое или ребёнок не memoized, стабилизация ссылок может добавить сложности без реальной выгоды. Поэтому большинство гайдов по React performance, включая обзоры LogRocket, акцентируют профилировку прежде, чем механически оптимизировать.

Полезное правило большого пальца: сначала перенеси, потом мемоизируй. Если значение статично — вынеси его за пределы тела компонента, прежде чем тянуться к хукам. Это даёт референциальную стабильность почти без когнитивной или рантайм-нагрузки. useCallback и useMemo — только когда значение реально динамическое и ребёнок выигрывает от стабильной идентичности.

Меняет ли это React Compiler

Один актуальный нюанс — React Compiler. Документация описывает его как стабильный билд-тайм инструмент, который автоматически оптимизирует React-приложения и по умолчанию мемоизирует код на основе анализа и эвристик. Это уменьшает потребность в ручных useMemo, useCallback и React.memo, особенно в новом коде.

Но это не делает референциальную стабильность нерелевантной. Документация также отмечает, что useMemo и useCallback остаются полезными как escape hatch для случаев, когда разработчику нужен точный контроль — например, чтобы держать memoized-значение стабильным как зависимость для Effect. Так что даже в кодовых базах, переходящих на React Compiler, всё равно полезно понимать, как нестабильные ссылки влияют на ререндеры, результаты профайлера и кейсы, где ручной контроль ещё нужен.

Итог

Inline-объекты и inline-колбэки — не плохой React-код по умолчанию. Чаще всего это просто обычные JavaScript-выражения внутри JSX. Проблема появляется, когда они пересекают memoization-границу и вы ждёте, что React воспримет «то же значение» как «тот же пропс». По умолчанию React сравнивает пропсы и зависимости хуков через Object.is, поэтому для объектов и функций новой ссылки достаточно, чтобы React счёл значение изменившимся.

Этот паттерн заслуживает большего внимания, чем обычно получает. Это не пустяковая микрооптимизация. Это один из самых простых способов случайно обнулить React.memo — особенно в фильтруемых списках, дашбордах, search-heavy UI и компонентных деревьях с дорогими потомками. Код выглядит чистым, приложение работает, но оптимизация, на которую вы рассчитывали, исчезает.

Практический вывод для команд, строящих быстрые React-интерфейсы: профилируй сначала. Если memoized поддерево всё ещё ререндерится слишком часто — проверь пропсы прежде, чем винить React. Перенеси статичные объекты из render-пути. Мемоизируйте колбэки только тогда, когда ребёнок реально выигрывает. Используй React DevTools и Why Did You Render, чтобы подтвердить, что именно изменилось и почему. Делай это последовательно — и React.memo перестанет быть декоративным куском кода и начнёт делать свою работу.

Источник: The React pattern everyone uses that quietly kills performance — LogRocket Blog.

Главная идея: в Rust поле типа Option<BigStruct> занимает столько же, сколько BigStruct — даже когда оно None. Чтобы пустое поле «весило одно слово», нужно обернуть значение в Box. Компилятор тогда применяет niche-оптимизацию (использует нулевой указатель как маркер None) — Option<Box<T>> весит ровно как один указатель. На задачах с массой опциональных полей это даёт двукратное сокращение памяти.

• Кейс: десериализация всех JSON-моделей AWS SDK (Smithy Shapes) через serde в Rust
• Было: 895 МБ. Стало: 420 МБ. Экономия 475 МБ (-53%)
• Изменения: только layout структур + кастомный Deserializer для пустых полей
• Ключевая мысль: Option<Big> ≠ Option<Box<Big>> по памяти
• Niche-оптимизация компилятора: Option<Box<T>> весит как один указатель
• Verification: jemalloc через feature-флаг profile, замер до/после загрузки
• Цена: десериализация чуть дороже по CPU (значение всё равно создаётся, потом отбрасывается)

Реальный кейс

Программа автора десериализует все JSON-файлы из репозитория awslabs/aws-sdk-rust/aws-models в структуры «Smithy Shape». Эти файлы содержат тысячи объявлений вроде такого:

Как принято в Rust-коде, для разбора используется serde. Соответствующие структуры выглядят естественно — это обычная вложенность структур со множеством опциональных полей и serde-атрибутов. Не нужно вчитываться в код: обратите внимание только на сами имена полей и на россыпь Option<...>:

Это типичный для Rust код. Но именно такой layout приводит к тому, что после десериализации структуры занимают 895 МБ. При этом анализ показывает: большинство опциональных строк отсутствуют — это и стало рычагом для радикального сокращения объёма. Чтобы понять механизм, нужен короткий теоретический отступ.

Как устроены структуры в памяти Rust

На 64-битной платформе одно «слово» — это 8 байт. Например, столько занимает usize.

Тип String занимает 3 слова: указатель на буфер, длину и ёмкость (capacity). Это 24 байта на сам тип String (проверить можно через dbg!(std::mem::size_of::<String>())) — не считая место под содержимое строки на heap. Подробности в документации Rust.

Существует niche-оптимизация компилятора: Option<String> весит столько же, сколько String. Дополнительный байт под пометку «это None» не нужен — пустое значение определяется по нулевому указателю.

Поэтому такая структура, когда все строки None, занимает ровно 120 байт (5 × 24):

Композиция структур

Дальше — самое важное. Что будет, если такая структура встроена в другую? Пусть это будет Container1, у которой одно поле Option<String> и одно — SmithyServiceTrait:

Размер Container1 — 24 + 120 = 144 байта: 24 под Option<String> и 120 под SmithyServiceTrait. А что, если поле trait сделать опциональным — на случай, когда trait отсутствует?

Сколько занимает Container2, когда оба поля None? Те же 144 байта. Опциональность ничего не сэкономила: место под структуру уже зарезервировано в layout родителя, и компилятор всё равно держит его готовым. Везёт ещё, что внутри SmithyServiceTrait только поля Option<String> — это позволяет компилятору не добавлять дополнительный байт-discriminant для внешнего Option.

Применив эту арифметику к SmithyTraits, видно, почему наивная реализация так разбухает в памяти.

Почему в Java и других языках с GC такой проблемы нет

В языках с reference-семантикой полей композиция работает иначе. Когда у класса Container есть поле-объект, это поле — указатель на heap. Если поле null, оно занимает только одно слово.

Чтобы добиться того же поведения в Rust — то есть чтобы пустое поле занимало одно слово, — нужно явно вынести содержимое на heap, обернув в Box:

Теперь, когда оба поля None, Container3 занимает всего 32 байта: 3 слова под Option<String> и одно слово под Option<Box<...>>. Та же niche-оптимизация работает и здесь: Option<Box<...>> весит столько же, сколько голый Box<...>.

Что именно поменялось

Изменение свелось к трём шагам:

1. Найти структуры, которые часто оказываются «пустыми» (все поля — None).
2. Сделать их опциональными в родительской структуре, переместив на heap через Box.
3. Написать кастомный Deserializer, чтобы пустые структуры вообще не попадали в результат.

Было:

Стало:

Аналогично, в SmithyShape все поля Option<SmithyReference> заменены на Option<Box<SmithyReference>>. Местами пришлось поправить акцессоры, потому что путь к данным удлинился на одну разыменовку. И всё — память на хранение десериализованных AWS-shape снизилась вдвое, экономия 475 МБ.

Подводные камни

• CPU чуть дороже. Десериализация полного объекта всё равно происходит — а потом он отбрасывается, если оказался пустым. Парадокс: суммарно задача стала быстрее, потому что меньше памяти = меньше работы аллокатора, меньше TLB-промахов, лучше попадания в L2/L3-кеш. На больших объёмах эти эффекты перевешивают накладные расходы на лишний разбор.
• Фрагментация heap. Много мелких Box ведёт к фрагментированной куче. В авторском случае это не было проблемой, но в долгоживущих сервисах — стоит держать в уме.

Как проверить, что экономия реальная

Чутьё подсказывает, где можно сэкономить и сколько примерно. Но без замеров — не работа. В Rust нет простого способа узнать, сколько весит композитный объект со всеми полями и аллокациями за указателями. Решение автора — использовать аллокатор, умеющий отдавать статистику. В стандартной поставке такие данные ограничены, поэтому подключается jemalloc:

В Cargo.toml объявляется feature-флаг profile, чтобы не таскать jemalloc в обычные сборки:

В main.rs аллокатор подключается под этим же флагом:

И в самой функции загрузки структур делается замер: до и после.

Совет автора: tikv_jemalloc_ctl отдаёт ещё кучу деталей, которые полезно мониторить в серверных приложениях.

Что запомнить из статьи

• Применяйте Option<Box<T>> только там, где поле пусто в большинстве случаев — иначе heap-fragmentation и разыменовка перевесят выигрыш.
• Размер типа узнать просто: std::mem::size_of::<T>(). Реальное потребление с heap — только через jemalloc-ctl, dhat-rs или heaptrack.
• Niche-оптимизация работает не для всего: String, Box, Vec, &T — да; кастомный enum без явных #[repr] — обычно нет.
• При desered-через-serde: голая замена типа на Option<Box> не даёт выигрыша — нужен кастомный Deserializer, который вернёт None для «пустых» структур.
• Перед оптимизацией — всегда замер. После оптимизации — снова замер. Без цифр это карго-культ.

От редакции

Один практический совет от редакции: чтобы быстро найти кандидатов на оптимизацию в большом проекте, прогоните код через dhat-rs — это профайлер аллокаций от автора «Rust Performance Book». Он покажет, какие типы съедают больше всего heap. Альтернатива Option<Box<T>> — arena-аллокаторы вроде bumpalo: если вся группа объектов живёт один пакетный жизненный цикл, разовый bump-аллокатор может оказаться эффективнее множества мелких Box.

Если интересна тема Rust в крупных продакшенах, у Tproger есть свежий материал про то, как WhatsApp переписал медиадвижок на Rust и выкинул 160 тысяч строк C++ — там тоже про экономию памяти и скорость, только в другом масштабе.

Источник: «Box to save memory» — dystroy.org/blog. Автор оригинала — Дени «Canop» де Майе, разработчик файлового менеджера broot и других open-source утилит на Rust.

Пизло — человек, от которого обычно ждут постов про «как мы выкрутили очередной трюк в JIT JavaScriptCore». Его прошлые тексты — это FTL JIT, B3, Riptide GC и другие вещи, которые требуют двух лет опыта в компиляторах. Но этот текст — принципиально другой. Он показывает ровно то, о чём обычно не пишут: что делать, когда у вас ещё нет JIT, а GC ещё не является главной болью.

Стартовая версия интерпретатора Zef была в 35 раз медленнее CPython 3.10, в 80 раз медленнее Lua 5.4.7 и в 23 раза медленнее QuickJS-ng 0.14.0. После 21 оптимизации (ни одной из которых не требует SSA-преобразований (static single assignment), переделки сборщика мусора, байткода или машинного кода) тот же интерпретатор проигрывает CPython всего в 2,1 раза, Lua — в 4,8 раза, QuickJS — в 1,35 раза. Если же собрать тем же обычным C++ без Fil-C — Zef становится быстрее CPython в 1,9 раза и быстрее QuickJS в 3 раза.

Представление значений: tagged 64-битные значения с NaN-boxing (упаковка целых и указателей в неиспользуемые биты double) позволяют держать числа на стеке и отличать их от указателей по битам.

Symbols вместо строк: один раз интернировать все имена методов и переменных в Symbol*, потом сравнивать указатели — даёт +18%.

Object Model + Inline Caches + Watchpoints: самый большой прирост (+355%, 4,55x) — одна мегакоммит-оптимизация, без которой остальное не работает.

Специализация мелочей: выделенный AST-узел для a + b вместо строкового a.add(b), Getter/Setter-инференс, специализированные ZeroArguments/OneArgument/TwoArguments.

Штраф Fil-C — 4x: memory-safe C, в котором автор пишет, даёт GC бесплатно, но накладывает штраф; итоговый буст после перехода на обычный C++ — 67x.

О каком интерпретаторе речь

Zef — это учебный динамический язык, который Пизло написал для удовольствия. В нём есть классы с наследованием, приватные поля (по умолчанию), замыкания, кастомные операторы, getter'ы и setter'ы. На уровне идиом он похож на Ruby и тихую версию JavaScript. Исходный интерпретатор — наивный AST-walker, в котором каждая нода — это C++-объект с виртуальным методом Node::evaluate, а все переменные живут в std::unordered_map<std::string, Value>.

Весь исходный код интерпретатора, diff-просмотрщики для каждой оптимизации и бенчмарки выложены на zef-lang.dev/implementation. Бенчмарки — набор ScriptBench1: Richards (OS scheduler), DeltaBlue (constraint solver), N-Body (физика) и Splay (самобалансирующееся двоичное дерево). Все портированы на Zef, Lua, Python и JavaScript.

Одна деталь про измерения: Пизло собирает свой интерпретатор компилятором Fil-C++ — это его собственный memory-safe C, который даёт сборщик мусора из коробки, но платит за это примерно 4x производительности. То есть когда в тексте написано «в 35 раз медленнее CPython», держите в голове, что 4x из этого — стоимость безопасности памяти, а остальные ~9x — это то, что будем выжимать.

Исходная точка: в 35 раз медленнее Python

В базовом варианте Пизло сделал два единственных осознанных про производительность выбора:

• 64-битное tagged-представление значений. Значение может быть int32, double или Object*. Double'ы сдвигаются на 0x1000000000000 — техника из JavaScriptCore, которую в литературе зовут NaN-boxing. Целые и указатели лежат как есть. Это позволяет определить тип значения битовой проверкой и не выделять int'ы в куче.
• Язык — C++. Пизло обосновывает: «Java — потолок низкоуровневых оптимизаций слишком низкий, Rust — сборщик мусора требует глобального изменяемого состояния и циклических ссылок, с этим придётся драться или писать много unsafe».

Всё остальное — сознательные «плохие» решения ради скорости разработки:

• Fil-C++ — штраф 4x, но GC бесплатно.
• Рекурсивный AST-интерпретатор через виртуальные вызовы.
• std::string везде — для имён переменных, методов, полей.
• std::unordered_map везде — на каждый Get переменной идёт хеш-лукап по строке.
• Цепочки рекурсивных вызовов по scope chain: класс внутри функции внутри класса внутри функции — каждый доступ проходит через несколько уровней вызовов.

Результат — 35x медленнее CPython, 80x медленнее Lua, 23x медленнее QuickJS. Дальше — что с этим можно сделать, не переписывая интерпретатор на JIT.

#1–2: Прямой вызов операторов и RMW

В Zef выражение a + b эквивалентно a.add(b). Наивный парсер делает одну и ту же AST-ноду для обоих случаев — DotCall(a, "add", [b]). Каждый плюс превращается в лукап строки "add" в Value::callMethod, который каскадом сравнивает её со всеми возможными именами операторов.

Первая оптимизация — парсер генерирует отдельные ноды Binary<> и Unary<>, каждая со своим виртуальным evaluate, который сразу зовёт Value::add, Value::sub и так далее. Без строковых сравнений на каждый плюс.

+17,5%. Вторая оптимизация делает то же самое для += и аналогов — отдельные ноды SetRMW, DotSetRMW, SubscriptRMW. +3,7%. Итог: 1,22x быстрее старта.

#3: Убрать проверку IntObject из быстрого пути

В базовой версии Value различал четыре случая: tagged int32, tagged double, IntObject (для int64, не влезающих в 32 бита) и всё остальное. Фастпас вызывал isInt(), который через виртуальный вызов спрашивал Object::isInt() — на случай, если под обложкой лежит IntObject.

Правка — пусть Value работает только с int32 и double, а весь int64-код уезжает внутрь IntObject. +1%. Мелочь, но копеечка.

#4: Symbols вместо std::string

Это первый по-настоящему большой прирост. В исходном интерпретаторе std::string — это ключ везде, где есть хеш-лукап: локальные переменные, dot-доступ, имена операторов, имена методов. То есть на каждый x + 1 идут хеширование строки "x", strcmp на каждой коллизии, ещё раз для "+".

Оптимизация — классический interning. Новый класс Symbol. Строки превращаются в Symbol* через глобальный hash-consing — одна строка = один указатель. Равенство Symbol* теперь проверяется сравнением указателей, а хеш-таблицы ключуются по Symbol*, а не по std::string.

Правка большая по количеству затронутых файлов, но по сути тривиальная — меняются сигнатуры функций с const std::string& на Symbol*. +18%. Суммарно: 1,46x быстрее старта.

#5: Value Inline

Простая техника: вынести часть методов Value в отдельный заголовочник valueinlines.h, чтобы они видели типы, которые нельзя было включить в value.h из-за циркулярных зависимостей. Компилятор теперь может их инлайнить в горячих местах. +2,8%.

#6: Объектная модель + inline caches + watchpoints — 4,55x одним махом

Самая большая оптимизация в статье, и единственная, которую Пизло специально защищает:

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

Патч объединяет три независимо бесполезных вещи:

Новая объектная модель: Storage + Offsets

В исходной версии каждый lexical scope выделял объект Context, а внутри Context жил hashmap с «полями» — локальными переменными. Объекты пользовательских классов были хуже: каждый объект содержал hashmap «класс → Context», потому что если Bar наследует Foo, поля у них приватные и могут иметь одинаковые имена — нужно различать, к какому классу относится поле.

Новая идея — Storage, который держит данные по Offsets, вычисленным на этапе resolve AST. Context всё ещё существует, но создаётся заранее, а объекты на рантайме просто выделяют Storage размера, который Context уже посчитал. Доступ к полю становится индексом по offset'у, а не лукапом в хеш-таблице.

Inline caches

Классическая техника — обычно её описывают в контексте JIT-компиляторов. Но здесь Пизло применяет её в интерпретаторе: для каждой AST-ноды типа expr.name запоминается тип, который expr имел в прошлый раз, и offset, куда резолвилось name. Запоминание — через placement-new на месте старой ноды: под той же памятью лежит новая специализированная нода, которая умеет быстрый путь.

Специализация может быть: «прямой load из Storage» (для локальной переменной), «проверка класса + direct call в функцию, которую видели в прошлый раз» (для метода). Плюс chain steps и watchpoints, если access требовал обхода scope chain.

Watchpoints

Представим: класс Foo внутри lexical scope, в котором есть переменная x. Метод Foo обращается к x. Внутри Foo имени x нет. Казалось бы, можно делать доступ без проверок. Но кто-то может унаследовать Foo и добавить геттер с именем x — тогда доступ должен пойти в геттер.

Watchpoint — это пассивный охранник: «если кто-то переопределил имя x в подклассе, инвалидируй мой inline cache». Пока имя не переопределяли, доступ работает на минимальных циклах.

Почему всё вместе

Пизло объясняет, почему эти три вещи не разделить:

• Новая объектная модель без inline caches не даёт никакого прироста.
• Inline caches без watchpoints не могут кешировать большинство интересных случаев — слишком много условий.
• И объектная модель, и watchpoints должны работать вместе с самого начала.

+355% — 4,55x быстрее. После этого Zef в 5,2 раза медленнее CPython, в 11,7 раза медленнее Lua, в 3,3 раза медленнее QuickJS. То есть накладные расходы Fil-C++ (примерно 4x) — это уже почти вся разница. Суммарно: 6,8x быстрее старта.

#7: Arguments — свой тип вместо std::vector

Раньше аргументы функций передавались как const std::optional<std::vector<Value>>&. optional нужен, чтобы отличать геттер-вызов o.getter от функции без аргументов o.function() — в Zef это разные вещи для некоторых типов. То есть каждый вызов аллоцировал std::vector, копировал его, и ещё раз копировал в scope функции.

Правка — новый тип Arguments, физически совпадающий с layout scope, который callee создаст. Caller выделяет его напрямую, callee не копирует. Плюс в Fil-C++ std::optional всегда живёт в куче из-за специфики invisicaps — это отдельный штраф. +33%.

#8–10: Специализация геттеров, сеттеров и callMethod

Много методов в Zef устроены тривиально:

Это запись readable f. Метод fn f f — просто чтение переменной. Гонять это через полноценный eval AST'а расточительно. Оптимизация #8 — инференс: если тело функции — это просто Get, заменяем UserFunction на специализированный GetterFunction, делающий load по известному offset'у. +5,6%.

Оптимизация #9 — то же самое для сеттеров (fn set_x(v) x = v). Инференс сложнее — нужно матчить параметр сеттера как источник присваивания. +3,4%. Оптимизация #10 — тривиальная однострочная: inline-инг callMethod в заголовочник. +3,2%. Суммарно: 10,2x быстрее старта.

#11: Глобальная hashtable для method dispatch

Когда inline cache промахивается, старый путь лез через ClassObject::tryCallMethod и tryCallMethodDirect, которые делают два хеш-лукапа на каждый уровень иерархии наследования: «есть ли метод в этом классе» и «есть ли вложенный класс с этим именем». O(depth × 2).

Правка — глобальный hashmap (ClassObject*, Symbol*) → callee, который запоминает все успешные резолвы. Промах по IC теперь — один лукап в эту таблицу, и только если её нет — полный медленный путь. +15%. Суммарно: 11,8x.

#12: Избавиться от std::optional на горячем пути

В Fil-C++ std::optional почти всегда аллоцируется в куче — из-за особенностей union-типов и invisicaps. LLVM может непредсказуемо потерять capabilities указателей внутри union'ов; Fil-C++ компилятор страхуется и вставляет интринсики, которые заставляют всё, что выглядит как union, аллоцировать на heap.

Правка — обход кода, ведущего к std::optional на горячем пути. +1,7%. Важный сайд-эффект для тех, кто пишет на Fil-C++: избегайте union-типов в горячем коде.

#13: ZeroArguments, OneArgument, TwoArguments

Большинство встроенных функций Zef берут 0, 1 или 2 аргумента. Им не нужен полноценный Arguments-объект — он просто занимает память. Три новых типа: ZeroArguments, OneArgument, TwoArguments. Функции шаблонизируются и инстанцируются отдельно для каждого.

ZeroArguments нужен отдельно, потому что (Arguments*)nullptr уже используется для геттер-вызова. Теперь ZeroArguments означает «функция без аргументов». +3,8%.

#14: Slow paths Value через static + by value

Раньше медленные пути Value были member-функциями и принимали неявный const Value*. Значит, caller должен был stack-аллоцировать Value. В Fil-C++ любая stack-аллокация это heap-аллокация.

Правка — сделать эти методы static и принимать Value по значению. Аллокации не нужны. +10%. Суммарно: 13,6x. Это ещё одна «специфичная для Fil-C++» оптимизация, которая в Yolo-C++ (обычный C++) была бы бесплатной по умолчанию.

#15–17: Дедупликация, быстрый sqrt и toString

#15 — «оптимизация» в кавычках: убрать дублированный код в DotSetRMW. Пизло надеялся на прирост от уменьшения кода. Прироста нет — но код чище.

#16 — специализация Dot-ноды для value.sqrt. Inline caches хороши для объектов, но для числовых примитивов они не работают — там фастпас другой, через Binary<>/Unary<>. sqrt в базовом варианте летел через общий путь. Теперь — свой специализированный код. +1,6%.

#17 — то же самое для toString. Плюс чуть меньше аллокаций при конвертации int → string. +2,7%. Суммарно: 14,2x.

#18: Специализация литералов массивов

Код вроде my whatever = [1, 2, 3] по-старому каждый раз спускался в AST и вычислял 1, 2, 3. Но если литерал константный — результат известен на парсинге.

Оптимизация — специализированная ArrayLiteral-нода, которая при вычислении просто копирует заготовленный массив значений. +8,1%. Суммарно: 15,35x.

#19: Value::callOperator по значению

Та же идея, что в #14 — не передавать Value по ссылке в медленный путь callOperator, а принимать его по значению. Ещё одна Fil-C++-специфичная аллокация убирается. +6,5%. Суммарно: 16,3x.

#20–21: Настройки компилятора и отключение ассертов

#20 — билд-система: отключить RTTI и libc++ hardening, потому что Fil-C++ их всё равно перекрывает. Ни одного изменения в C++-коде, только флаги сборки. +1,8%.

#21 — отключить по умолчанию ассерты. Код использовал макрос ZASSERT (всегда проверяет). Замена на ASSERT (только если ASSERTS_ENABLED) должна была дать прирост, но — не дала. Зато готовит код к сборке в обычном C++.

После 21 оптимизации: 16,6x быстрее старта. Zef в 2,1x медленнее CPython, в 4,8x медленнее Lua, в 1,35x медленнее QuickJS. Стартовали с 35x, 80x и 23x разрывов — оказались в окрестностях конкурентов, без строчки JIT.

Переход на обычный C++ — ещё 4x

Финальный эксперимент — собрать тот же код обычным C++ (GCC 11.4.0) вместо Fil-C++. Пизло называет это Yolo-C++ — без гарантий безопасности памяти. Получается ещё 4x. Суммарно: 67x быстрее базовой версии. Zef в 1,9x быстрее CPython 3.10, в 1,2x медленнее Lua и в 3x быстрее QuickJS.

Сборка неидеальна: вместо Fil-C++ GC там calloc, память не освобождается — интерпретатор течёт, просто ScriptBench1 слишком короткий, чтобы это заметить. С реальным GC Yolo-C++-версия была бы ещё быстрее.

В этот момент Zef в 1,9 раза быстрее CPython 3.10, в 1,2 раза медленнее Lua 5.4.7 и в 3 раза быстрее QuickJS-ng 0.14.0. Мы стали в 67 раз быстрее, чем там, где начали.

Итоговая таблица всех оптимизаций

Что получается по ходу работы — в одной таблице (геосреднее по четырём бенчмаркам, чем быстрее, тем лучше):

Выводы

Главное в этом тексте Пизло — не сами оптимизации, а то, что они все простые. SSA здесь нет. GC переделывать не надо. Байткода нет. Машинного кода нет. Есть базовые вещи: не хешировать строки (Symbols), не аллоцировать лишнее (Value by value, специализированные Arguments), не ходить по hashmap'ам (Offsets + IC), запомнить то, что уже видели (inline caches), инвалидировать кеш только когда реально что-то поменялось (watchpoints).

Для тех, кто пишет интерпретатор с нуля — список в статье Пизло работает как чеклист. Первые оптимизации (#1–#5) дают суммарные 1,5x — они дешёвые. #6 даёт 4,55x — это день работы, но переворачивает игру. Всё остальное — серия из 3–8% приростов, которые в сумме добирают разницу.

Для тех, кто хочет потом написать JIT — эта статья объясняет, как выглядит база, на которую JIT потом ложится без сюрпризов. NaN-boxing, новая объектная модель, IC и watchpoints — это ровно то, что должно быть у интерпретатора до того, как вы начнёте генерировать машинный код.

Оригинал: How To Make a Fast Dynamic Language Interpreter, Filip Pizlo, 21 апреля 2026 года. Автор — один из ключевых инженеров WebKit JavaScriptCore, автор FTL JIT, B3, Riptide GC.

RAG (Retrieval-Augmented Generation) — стандартный подход к построению ИИ-ассистентов: нарезать документацию на чанки, сохранить эмбеддинги в векторную базу, искать top-K релевантных фрагментов по запросу. Но у него есть фундаментальное ограничение: агент видит только те фрагменты, которые совпали с запросом. Если ответ распределён по нескольким страницам или пользователю нужен точный синтаксис — RAG буксует.

• Mintlify заменила RAG на ChromaFs — виртуальную ФС поверх Chroma DB
• Время создания сессии: 46 сек → 100 мс (460x быстрее)
• Стоимость на диалог: $0,0137 → $0 (используется существующая инфраструктура)
• Агент работает через grep, cat, ls, find — как с обычной файловой системой
• Встроенный RBAC: контроль доступа без Linux-прав и chmod
• 30 000+ диалогов в день на существующей инфраструктуре

Проблема: песочницы медленные и дорогие

Очевидный способ дать агенту файловую систему — развернуть контейнер и склонировать репозиторий. Mintlify так и делала для фоновых задач, но для фронтенд-ассистента, где пользователь смотрит на спиннер, подход не работал:

• P90 время создания сессии: ~46 секунд (включая клонирование с GitHub)
• Стоимость: при 850 000 диалогов в месяц даже минимальная конфигурация (1 vCPU, 2 ГБ RAM, 5-минутный TTL) обошлась бы в $70 000+/год
• Каждому пользователю нужен отдельный контейнер, иначе агенты видят чужие данные

Решение: ChromaFs — виртуальная ФС поверх Chroma

Агенту не нужна настоящая файловая система — ему нужна иллюзия файловой системы. Документация Mintlify уже была индексирована и хранилась в Chroma DB для поиска. Команда построила ChromaFs — виртуальную ФС, которая перехватывает UNIX-команды и транслирует их в запросы к Chroma.

ChromaFs построена на just-bash от Vercel Labs — TypeScript-реализации bash, которая поддерживает grep, cat, ls, find и cd. just-bash предоставляет интерфейс IFileSystem — ChromaFs реализует его, транслируя каждый вызов файловой системы в запрос к Chroma.

Как это работает

Дерево файлов из базы данных

При инициализации ChromaFs загружает сжатый JSON-документ с деревом путей из Chroma-коллекции и разворачивает его в две структуры в памяти: множество путей файлов и маппинг директорий на дочерние элементы. После этого ls, cd и find работают из памяти без сетевых запросов.

Сборка страниц из чанков

Страницы в Chroma разбиты на чанки для эмбеддингов. Когда агент выполняет cat /auth/oauth.mdx, ChromaFs находит все чанки с подходящим slug, сортирует по индексу и склеивает в полную страницу. Результаты кешируются — повторные чтения не обращаются к базе.

Оптимизация grep

Рекурсивный grep -r по всем файлам через сеть был бы слишком медленным. ChromaFs перехватывает команду, парсит флаги и транслирует поиск в запрос к Chroma ($contains для фиксированных строк, $regex для паттернов). Chroma выступает грубым фильтром — определяет, в каких файлах может быть совпадение. Эти чанки загружаются в Redis-кеш, и уже из него just-bash выполняет точный поиск в памяти.

Контроль доступа (RBAC)

Каждый путь в дереве файлов имеет флаги доступа: isPublic и groups. Перед построением дерева ChromaFs фильтрует пути по токену сессии пользователя. Если у пользователя нет доступа к файлу — файл полностью исключается из дерева. Агент не может даже узнать о его существовании.

В настоящей песочнице такой контроль потребовал бы управления Linux-группами, chmod-правами или отдельных контейнеров для каждого тарифа. В ChromaFs — это несколько строк фильтрации.

Результаты

• P90 время создания сессии: ~46 секунд → ~100 мс (460x быстрее)
• Стоимость на диалог: ~$0,0137 → ~$0
• Масштаб: 30 000+ диалогов в день на существующей инфраструктуре
• Запись заблокирована: все операции записи возвращают EROFS — агент не может модифицировать документацию, система полностью stateless

Когда это работает, а когда нет

Подход Mintlify работает для структурированной документации, где каждая страница — файл, а каждый раздел — директория. Агент использует привычные UNIX-примитивы (grep, cat, find), и ему не нужно учиться новому API.

Ограничения:

• Нужна уже индексированная и чанкованная документация в векторной базе
• Не подходит для задач, где агенту нужно модифицировать файлы (виртуальная ФС read-only)
• Для неструктурированных данных (чаты, тикеты, логи) RAG может быть эффективнее
• Зависимость от качества чанкирования — плохое разбиение = плохие результаты cat

Выводы

Подход Mintlify показывает важный тренд: для структурированных данных агентам не нужны сложные RAG-пайплайны — достаточно привычного интерфейса файловой системы. Когда ваши данные уже в базе, виртуальная ФС может быть быстрее, дешевле и понятнее для агента, чем векторный поиск. Особенно если агент уже умеет работать с grep и cat.

Источник: Mintlify — How we built a virtual filesystem for our Assistant

Плагин Caveman решает эту проблему радикально: он заставляет ИИ-ассистента отвечать как пещерный человек — только самое необходимое. Никакого «The reason your component is re-rendering is likely because...» — только «New object ref each render. Wrap in useMemo.» По данным автора, в среднем экономия составляет 75% output-токенов. На Hacker News проект набрал 797 очков, на GitHub — 2,8K звёзд за несколько дней.

• Caveman сокращает output-токены в среднем на 65–75%, не затрагивая «мышление» модели
• Работает как плагин для Claude Code и OpenAI Codex через одну команду установки
• Три уровня сжатия: Lite, Full и Ultra — под разные задачи
• Научное исследование марта 2026 года подтвердило, что краткость ответов повышает точность моделей на 26 п.п.

До и после: как выглядят ответы

Вот реальный пример ответа на вопрос о повторном рендеринге React-компонента. Обычный режим — 69 токенов:

Тот же вопрос с Caveman — 19 токенов:

Смысл тот же, шум убран. Девиз проекта: «Why use many token when few do trick.»

Бенчмарки на реальных задачах

Автор замерил расход токенов на десяти типичных задачах через Claude API. Результаты:

• Объяснить баг с повторным рендером React: 1180 → 159 токенов (−87%)
• Исправить middleware для токена авторизации: 704 → 121 (−83%)
• Настроить пул соединений PostgreSQL: 2347 → 380 (−84%)
• Объяснить git rebase vs merge: 702 → 292 (−58%)
• Рефакторинг callback → async/await: 387 → 301 (−22%)
• Архитектура: микросервисы vs монолит: 446 → 310 (−30%)
• Ревью PR на безопасность: 678 → 398 (−41%)
• Docker multi-stage build: 1042 → 290 (−72%)
• Отладка race condition в PostgreSQL: 1200 → 232 (−81%)
• Реализовать React error boundary: 3454 → 456 (−87%)
• Среднее: 1214 → 294 токена (−65%)

Наибольший эффект там, где модель обычно «разогревается» перед ответом: объяснения, отладка, архитектурные обсуждения. На задачах с конкретным кодом (рефакторинг, ревью) выигрыш скромнее — модель и так пишет по делу.

Три уровня сжатия

Caveman предлагает три режима работы — в зависимости от задачи и допустимого уровня «дикости» ответов:

• Lite — убирает вводные фразы и повторения, сохраняет связный текст. Подходит для объяснений и документации.
• Full — сокращает до ключевых утверждений, телеграфный стиль. Оптимален для отладки и код-ревью.
• Ultra — максимальная экономия, ответы из 2–5 слов на пункт. Для быстрых уточнений и одностроковых подсказок.

Наука подтверждает: меньше слов — лучше ответ

В марте 2026 года вышла статья «Brevity Constraints Reverse Performance Hierarchies in Language Models», в которой исследователи проверили, как ограничения длины ответа влияют на качество. Вывод неожиданный: принудительное сокращение ответов улучшило точность моделей на 26 процентных пунктов. Авторы объясняют это тем, что при жёстком лимите модель вынуждена сразу формулировать суть, а не «думать вслух» в ответе.

Важно понимать: Caveman влияет только на output-токены — то, что модель пишет вам в ответ. Thinking-токены (внутренние рассуждения Claude) плагин не трогает. Как говорит сам проект: «Caveman no make brain smaller. Caveman make mouth smaller.»

Как установить

Плагин устанавливается одной командой через npx skills:

После установки плагин подключается к Claude Code или Codex и начинает работать автоматически. Уровень сжатия можно переключать в настройках или через аргументы команды.

Caveman — редкий случай, когда оптимизация расходов не требует компромисса по качеству. Если вы платите за API Claude или GPT-4 и используете ИИ-ассистента для рутинных задач разработки, плагин окупится быстро. Средняя экономия 65% означает, что при счёте $100/месяц вы начнёте тратить $35. А пещерный стиль ответов — это просто побочный эффект, к которому привыкаешь за час работы.

Одним из поводов для разочарования в области аппаратных форматов изображений всегда было медленное развитие. Разработчики обычно не решались поставлять текстуры в новом формате, пока он не становился повсеместно доступным — поддерживался большинством целевого железа и всеми вендорами без исключения. Сегодня три вендора предлагают собственные форматы аппаратного сжатия текстур на лету: ARM AFRC, ImgTec PVRIC4 и Apple Metal Lossy. Игнасио Кастаньо исследовал все три и сравнил их с программным сжатием реального времени Spark от NVIDIA.

— ARM AFRC (Pixel 8, Mali-G715) — явный победитель: по метрике RMSE значительно обходит Spark и других конкурентов во всех форматах.

— Apple Metal Lossy (A15/M2+) — коэффициент сжатия 1:2, API минималистичен: один флаг в дескрипторе текстуры.

— ImgTec PVRIC4 (Pixel 10) разочаровал: драйвер игнорирует запрошенный bitrate, качество хуже Spark для R и RG форматов.

— Vulkan-расширение VK_EXT_image_compression_control унифицирует доступ к аппаратному сжатию через параметр BPC (bits per component).

— Аппаратное сжатие — перспективная альтернатива программному, но пока ограничено современными топовыми устройствами.

Контекст: почему это важно

Разработчики обычно не решались поставлять текстуры в новом формате, пока он не становился широко доступным — то есть поддерживался большинством целевого железа и всеми вендорами. Например, хотя ATI представила форматы 3Dc в 2004 году вместе с Radeon X800 (R420) и открыла их через расширения D3D9, их использование не стало распространённым, когда Direct3D 10 стандартизировал их как BC4 и BC5 в 2007 году. Массовое применение началось лишь тогда, когда Direct3D 10 стал минимальным требованием к железу.

Crysis стала первой крупной игрой, поставляемой с BC5-текстурами, но большинство игр ещё долгие годы не решались устанавливать такое жёсткое требование к железу. Чтобы избежать задержек с принятием, форматы BC6 и BC7 разрабатывались совместно ATI и NVIDIA для Direct3D 11.

Именно поэтому сжатие текстур в реальном времени так интересно: когда кодировщик работает в реальном времени, внедрять новые аппаратные форматы значительно проще — не нужно ждать, пока будет подготовлен контент, целенаправленно созданный под них. Аппаратное сжатие устраняет эту проблему принятия: детали форматов не документируются, их использование абсолютно прозрачно — приложению не нужно явно указывать эти форматы, драйвер сжимает текстуры динамически в процессе рендеринга и загрузки изображений.

Apple Metal: Lossy-сжатие

Apple представила сжатие текстур с потерями в чипах A15 и M2 (оба используют одно поколение GPU). Оно обеспечивает коэффициент сжатия 1:2. Включить его на удивление просто — API минималистичен. Свойство compressionType дескриптора MTLTextureDescriptor принимает значение из перечисления MTLTextureCompressionType, и установка MTLTextureCompressionTypeLossy зачастую является единственным необходимым изменением:

Согласно таблицам возможностей Metal Feature Set Tables, все обычные пиксельные форматы поддерживают сжатие с потерями — включая 10-битные и форматы с плавающей точкой. Тестирование это подтвердило, однако основное внимание сосредоточено на форматах R8, RG8 и RGBA8.

Внутренний алгоритм Apple не задокументирован. По результатам реверс-инжиниринга lossy-форматов используется размер блока 8×4 пикселя — и они напоминают некоторые особенности форматов ETC и EAC. Несмотря на заявленное сжатие 1:2, на практике для каждого блока выделяется один байт метаданных, так что реальное потребление памяти чуть выше заявленного.

Качество на M4 Pro

Для форматов R и RG Metal Lossy показывает результаты лучше кодеков Spark EAC, но хуже BC4 и BC5. Результаты RMSE (Root Mean Square Error — среднеквадратичная ошибка; меньше = лучше):

Формат R:

Формат RG:

Прямое сравнение lossy RGBA8 с форматами Spark некорректно из-за разных коэффициентов сжатия: Metal Lossy поддерживает только 1:2, тогда как форматы Spark RGB(A) — 1:4. Тем не менее, для полноты картины:

Формат RGBA:

Производительность на M4 Pro

С точки зрения производительности lossy-форматы показывают себя отлично и при достаточно большом размере текстуры упираются в пропускную способность памяти. Результаты на M4 Pro (16 ядер GPU) в МПикс/сек:

Обратите внимание, что пропускная способность стандартных блитов остаётся достаточно стабильной вне зависимости от размера текстуры. Кодеки Spark, напротив, имеют фиксированные накладные расходы, которые становятся заметнее при уменьшении размеров текстур. Интересен скачок скорости блитов при 512×512 — у него пока нет объяснения. Также стоит учесть, что кодеки Spark требуют дополнительного копирования из буфера вывода кодека в финальную сжатую текстуру — это дополнительные накладные расходы, которых можно было бы избежать, если бы Metal поддерживал запись в блочно-сжатые текстуры, как это делает Vulkan.

Vulkan: расширение VK_EXT_image_compression_control

В Vulkan расширение VK_EXT_image_compression_control даёт приложениям возможность запрашивать сжатие изображений с фиксированной скоростью. Расширение уже доступно на флагманских устройствах от ARM и Imagination. Включение потерявого сжатия в Vulkan несколько многословнее, чем в Metal, но на практике ненамного сложнее: нужно лишь расширить структуру VkImageCreateInfo, добавив в цепочку VkImageCompressionControlEXT.

Можно использовать флаг VK_IMAGE_COMPRESSION_FIXED_RATE_DEFAULT_EXT, чтобы позволить реализации самой выбрать параметры сжатия:

Альтернативно можно явно указать флаги фиксированной скорости для управления допустимыми коэффициентами сжатия:

BPC (bits per component — бит на компонент) — несколько нестандартная единица, но она позволяет задавать коэффициент сжатия единообразно вне зависимости от количества каналов. Для справки, BPC существующих форматов блочного сжатия GPU:

Расширение VK_EXT_image_compression_control также присутствует в некоторых драйверах AMD и Qualcomm, однако, насколько известно, ни один из этих вендоров не поддерживает аппаратное сжатие изображений с фиксированной скоростью. В случае AMD расширение присутствует в драйвере RADV, чтобы Proton мог отключать потерявое сжатие фреймбуфера в некоторых играх, где оно вызывало проблемы с корректностью — через флаг VK_IMAGE_COMPRESSION_DISABLED_EXT.

ARM AFRC: лучший результат среди всех

ARM Fixed Rate Compression (AFRC) было анонсировано в 2021 году и впервые появилось в Mali-G510 в 2022-м, однако широкого распространения этот дизайн не получил. По-настоящему массовым AFRC стало с выпуском Mali-G715 и Mali-G615 в том же году. Тестирование проводилось на Pixel 8 с GPU Mali-G715.

Устройство сообщило поддержку следующих форматов сжатия с фиксированной скоростью (возможности значительно шире Metal Lossy):

В отличие от Metal Lossy, AFRC не использует дополнительных байт метаданных — все управляющие биты находятся внутри самого блока. Изображение делится на блоки 8×8 пикселей, в ряде случаев разбиваемые на подблоки меньшего размера. Размер каждого блока 8×8 в байтах:

По результатам реверс-инжиниринга удалось установить: AFRC представляет цвета с использованием преобразования YCoCg, а представление пикселей напоминает вейвлет Хаара. Для каждого подблока 4×4 используется 16 коэффициентов, квантование которых зависит от режима. Форматы RGB и RGBA принципиально одинаковы — флаг в заголовке просто указывает, присутствует ли альфа-канал или блок полностью непрозрачен.

Качество AFRC

Качество AFRC впечатляет. В отличие от Metal, здесь можно сделать прямое сравнение с ASTC в реальном времени, поскольку Mali поддерживает сжатие 1:4:

Формат R:

Формат RG:

Формат RGBA:

Во всех случаях RMSE значительно ниже, то есть AFRC превосходит Spark ASTC при нацеливании на ASTC с кодировщиком реального времени. Тем не менее есть несколько случаев, когда Spark даёт более высокое качество: на очень гладких изображениях сжатие AFRC приводит к заметным паттернам дизеринга, раскрывающим границы блоков. Это особенно заметно при использовании AFRC в качестве текстуры с увеличением, тогда как для сжатия фреймбуфера — основного сценария применения — такие паттерны практически незаметны.

Производительность AFRC (Pixel 8)

Включение AFRC не вызывает значительных накладных расходов по сравнению с несжатыми загрузками текстур, за исключением некоторых размеров. Результаты на Pixel 8 в МПикс/сек:

Пропускная способность здесь масштабируется с размером текстуры, а не остаётся стабильной. Накладные расходы одинаково влияют на блиты и compute-шейдеры Spark. В отличие от секции Metal, где lossy-блиты явно доминировали над Spark на малых размерах, здесь картина смешанная: Spark вплотную приближается к AFRC или превосходит его. Это показывает, что кодирование текстур в реальном времени вполне конкурентоспособно с аппаратным сжатием. Абсолютные числа здесь значительно ниже, чем на M4 Pro, — это принципиально разные классы устройств.

ImgTec PVRIC4: разочарование от Pixel 10

ImgTec впервые анонсировала поддержку PVRIC4 ещё в 2018 году для GPU серии Series 6, однако протестировать её удалось только с выходом Pixel 10 на чипе Series D. Первоначальное объявление намекало на то, что, как и Metal Lossy, PVRIC4 поддерживает только 50%-е сжатие, но расширение декларирует более широкий спектр опций:

К большому удивлению, качество вывода оказалось одинаковым вне зависимости от BPC. Дальнейшее расследование показало: драйвер игнорирует запрошенный BPC и всегда использует 4 bpc (сжатие 1:2). Формат блоков PVRIC4 — наиболее сложный из всех трёх вендоров: размер блоков составляет 16×16 пикселей, и, как в Metal Lossy, присутствует один байт метаданных на блок. Сделать реверс-инжиниринг практически не удалось.

Качество PVRIC4

Качество оказалось разочаровывающим. Для форматов R и RG Spark фактически превосходит PVRIC4 при нацеливании на стандартные форматы блочного сжатия, поддерживаемые этим железом:

Формат R:

Формат RG:

Для RGBA прямое сравнение невозможно из-за разных коэффициентов сжатия, но качество также значительно хуже других вендоров:

Формат RGBA:

Производительность PVRIC4 (Pixel 10)

Кривая пропускной способности на этом устройстве существенно отличается от Pixel 8: пик приходится на размеры 1024–2048, а не монотонно возрастает с размером. На больших размерах пропускная способность Spark фактически выше, чем у несжатых загрузок текстур. Это характерно для устройств, ограниченных пропускной способностью памяти: обычный блит должен прочитать всё входное изображение и записать обратно тот же объём данных, тогда как Spark записывает лишь 1/4 входных данных. Экономия на записи зачастую перекрывает вычислительные затраты кодирования.

Комментарий PowerVR Dev (ImgTec)
PVRIC4 поддерживает только сжатие 1:2. TFBC (доступен исключительно в чипах Rogue XE) поддерживал соотношения 1:2, 1:4 и 1:3. Дизайн расширения был спорным — многим не нравилась многословность выбора BPC, поэтому было решено экспонировать все BPC в рамках поддерживаемых соотношений и повышать их до поддерживаемого ratio. Это считалось допустимым, поскольку качество не деградирует относительно запроса приложения, а приложение всё равно обязано запрашивать реальный размер изображения, который не гарантирует уменьшения.

Spark: программная точка отсчёта

Spark — библиотека NVIDIA для программного сжатия текстур в реальном времени. Работает на GPU как compute shader, поддерживает форматы BC1–BC7 и ASTC. В тесте выступает базовой точкой сравнения как лучшее доступное программное сжатие без специализированного железа.

Spark показывает стабильные результаты по форматам, но требует явного вызова compute-прохода — это дополнительный этап в пайплайне. Аппаратное сжатие, напротив, встроено в рендеринг и не требует дополнительного кода. Отдельный плюс Spark — предсказуемое и согласованное поведение на всех устройствах, что важно, если унифицированный вывод критичен для вашего сценария. Ни один из форматов аппаратного сжатия пока не доступен через WebGPU — если это изменится, расширить spark.js для их поддержки будет несложно.

Итоги: кто победил

ARM AFRC — явный победитель. Это не только превосходит программные реализации вроде Spark, но и обходит все остальные форматы по всем метрикам. Итоговая таблица RMSE по всем протестированным форматам:

Стоит оговориться: результаты PVRIC4 могут не отражать полного потенциала железа — драйвер игнорирует запрошенный коэффициент сжатия и всегда использует 1:2. Возможно, эти результаты удастся пересмотреть после исправления проблемы.

Аппаратное сжатие — убедительная альтернатива программному. Главная оговорка — оно сейчас ограничено современными топовыми устройствами, которые как раз и располагают наибольшим объёмом памяти и пропускной способностью.

Даже когда нативное аппаратное сжатие доступно, есть веские причины продолжать использовать Spark. Вывод аппаратного сжатия различается у разных вендоров, и в некоторых случаях — как мы видели с PVRIC4 — качество уступает кодировщику реального времени. Если для вашего сценария критичен единообразный и предсказуемый вывод на всех вендорах, Spark остаётся правильным выбором.

Ключевые выводы
- SIMD-инструкции (SSE2, AVX2) позволяют обрабатывать 16-32 байта за одну операцию
- В UTF-8 все управляющие символы CSV (запятая, кавычка, перенос строки) занимают ровно один байт и совпадают с ASCII
- Минималистичный код (16 КБ) побеждает оптимизированный, но раздутый (163 КБ) за счёт давления на L1-кэш процессора
- Компилятор и рантайм умеют оптимизировать лучше, если им не мешать микрооптимизациями

Наивная реализация — считаем запятые

Прежде чем строить парсер, поставим простую задачу: как быстрее всего подсчитать, сколько раз символ , встречается в большом UTF-8-файле? Тестируем на CSV-файле размером 500 МБ.

Базовая реализация: 135,305 мс

Простейший вариант: перебираем каждый байт и сравниваем с искомым. Можно ли лучше?

Unsafe-указатели: 128,683 мс

Каждый раз, когда вы обращаетесь к массиву через data[i], рантайм .NET выполняет проверку границ (bounds checking) — убеждается, что индекс не выходит за пределы массива. Если вместо этого использовать unsafe-указатели, мы обещаем рантайму, что не выйдем за границы. Экономия — 7 мс.

Развёртка цикла (unrolling 4x): 105,320 мс

Механика цикла for обманчиво дорога: на каждой итерации нужно проверить условие выхода и выполнить переход в начало. Если обрабатывать по 4 элемента за итерацию, накладные расходы снижаются в четыре раза. «Хвост» данных, не кратный четырём, обрабатывается обычным побайтовым циклом.

Проблема — UTF-8 и Unicode ломают всё

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

Наименьшая единица данных — байт (числа 0-255). Но человечество использует гораздо больше 256 символов. Ранние системы решали это через кодовые страницы — у каждого региона была своя таблица. Японские системы использовали Shift-JIS, в Китае по закону обязателен GB 18030. Если открыть файл в неправильной кодировке, вы увидите «крокозябры» (mojibake) — бессмысленный набор символов.

Unicode решил эту проблему в 90-х: каждому символу присваивается номер (codepoint), а разные кодировки (UTF-8, UTF-16, UTF-32) определяют, как эти номера записываются в байты.

Вот как UTF-8 кодирует символы в зависимости от количества байтов:

Ключевой факт: байты 0x00-0x7F в UTF-8 полностью совпадают с ASCII. Это значит, что управляющие символы CSV — запятая (,), кавычка ("), перевод строки (\n) — всегда занимают ровно один байт, независимо от того, какие Unicode-символы находятся в данных. И это можно использовать для невероятно быстрого сканирования.

SIMD — ускорение через параллельные инструкции

До сих пор мы обрабатывали по одному байту за раз. Представьте сложение двух массивов по 8 элементов — нужно 8 отдельных операций сложения. Можно распараллелить это по потокам, но управление потоками создаёт накладные расходы и не добавляет эффективности.

SIMD (Single Instruction, Multiple Data) — это набор процессорных инструкций, которые выполняют одну операцию сразу над несколькими элементами данных. Вся магия происходит в железе, поэтому результат приходит за то же время, что и обычная операция над одним элементом.

Аналогия: сложить два однозначных числа (8 + 2) — просто. Сложить два семизначных — нужно перебирать разряды. А теперь представьте, что вы можете «увидеть» сумму двух семизначных чисел мгновенно, с той же лёгкостью, что и однозначных. Это и есть SIMD.

Вот как выглядит SIMD-сложение 4 элементов за одну операцию:

Мы делаем в 4 раза больше работы за то же усилие.

SSE2: 46,663 мс

SSE2 (появился в x86-процессорах в 2000 году) работает с 128-битными регистрами — 16 байтов за раз. Алгоритм такой:

1. Загрузить 16 байтов данных в SIMD-вектор
2. Сравнить каждый байт с искомым (Sse2.CompareEqual) — на позициях совпадений появятся байты 255, на остальных — 0
3. Извлечь старшие биты из каждого байта (Sse2.MoveMask) — получаем 16-битное число, где каждый установленный бит означает совпадение
4. Подсчитать установленные биты

Для строки "Hello, I, like, commas." это выглядит так:

AVX2: 42,220 мс

AVX2 (с 2011 года) расширяет регистры до 256 битов — 32 байта за итерацию. Код аналогичен SSE2, но с Vector256 вместо Vector128.

Прирост скромный — значит, узкое место сместилось на цикл обработки маски. Нужно ускорить подсчёт битов.

AVX2 + TZCNT: 16,630 мс

BitOperations.TrailingZeroCount — аппаратная инструкция TZCNT, которая мгновенно находит позицию младшего установленного бита. Вместо того чтобы перебирать биты маски по одному, мы прыгаем сразу к следующему совпадению и сбрасываем его.

AVX2 + POPCNT: 13,673 мс

А есть ещё лучше. BitOperations.PopCount — аппаратная инструкция POPCNT, которая за одну операцию считает количество установленных битов в числе. Именно то, что нам нужно:

Мы достигли потолка производительности для подсчёта символов. Ускорение в 10 раз по сравнению с наивной реализацией — отличный результат. Пора применить это к парсингу CSV.

Поиск разделителей через SIMD

При парсинге CSV нас интересуют три управляющих символа: запятая (,), кавычка (") и перевод строки (\n). Правила обработки:

• Запятая — конец текущего поля
• Перевод строки — конец текущей строки
• Кавычка — начало или конец экранированного блока (внутри которого запятые и переносы игнорируются). Две кавычки подряд — это экранированная кавычка в значении

Парсинг разбивается на два этапа. Первый — определение позиций и длин полей через SIMD (функция DetermineFields). Второй — фактическое извлечение и дeкодирование значений, только когда пользователь их запрашивает.

Вот упрощённый код первого этапа (без обработки краевых случаев):

Несколько важных деталей:

• Здесь используется TrailingZeroCount вместо PopCount, потому что нам важна позиция каждого найденного символа, а не только их количество
• Одна и та же схема CompareEqual + MoveMask применяется для каждого управляющего символа, а затем маски объединяются через OR. Отдельные маски сохраняются, чтобы потом определить тип найденного символа
• Мы не касаемся содержимого полей — если пользователю нужен только один столбец, незачем декодировать остальные

Обработка кавычек и экранирования

Когда поле содержит кавычки, нужно выполнить декодирование вручную — убрать обрамляющие кавычки и заменить двойные кавычки на одинарные. Кроме того, C# внутри использует UTF-16 для всех строк (char — это 16-битная единица кода), поэтому при чтении UTF-8 приходится конвертировать.

Если кавычек в поле нет, используется быстрая встроенная конвертация Encoding.UTF8.GetChars. Но если кавычки есть, быстрее выполнить конвертацию и удаление кавычек за один проход:

Хитрость здесь в том, что 2- и 3-байтовые UTF-8-последовательности всегда дают одну единицу кода UTF-16, поэтому кодпоинт можно просто привести к char. Четырёхбайтовые символы (эмодзи и редкие иероглифы) требуют суррогатных пар.

Для UTF-16-строк (внутренний формат C#) парсер использует трюк с Avx2.PackUnsignedSaturate: два 256-битных вектора 16-битных символов «сжимаются» в один 256-битный вектор 8-битных байтов. ASCII-символы сохраняются как есть, а все не-ASCII насыщаются до 255 (или 0 для отрицательных при знаковой интерпретации). После перестановки блоков через Avx2.Permute4x64 можно применять ту же маску, что и для UTF-8.

Бенчмарки — результаты

Существующие бенчмарки CSV-парсеров на C# тестируют только один файл — по сути, они измеряют не парсинг CSV, а производительность на одном конкретном сценарии. Поэтому автор создал собственный набор тестов с разными типами данных:

• Реальные данные Reddit — широкий датасет с разными типами данных и большим количеством текста (из Reddit ArcticShift)
• Международный текст — CSV с названиями предметов из Pokemon на множестве языков (кириллица, японский, корейский)
• Финансовые данные — числа с минимумом текста
• Синтетические тесты — числовые поля, короткие файлы (50 строк), файлы с обязательным экранированием, «стресс-тест» с массой кавычек

Полные результаты опубликованы на bepis.io/csv-benchmark.

Итог: FourLambda.Csv оказался самым быстрым в 41 из 70 тестов. Не абсолютная победа, но убедительное лидерство.

Для сравнения, вот как менялась скорость подсчёта символов на файле 500 МБ по мере оптимизации:

Почему FourLambda.Csv быстрее Sep

До этого самым быстрым CSV-парсером на C# считалась библиотека Sep. Вот несколько причин, почему FourLambda.Csv выигрывает:

UTF-8 без промежуточной конвертации. Sep внутри конвертирует UTF-8 в UTF-16 даже если данные не нужны пользователю. FourLambda.Csv работает напрямую с UTF-8.

Давление на кэш. L1-кэш процессора — около 32-64 КБ, и он хранит не только данные, но и исполняемый код. FourLambda.Csv весит ~16 КБ, а Sep — ~163 КБ. Разница в 10 раз означает, что Sep может вытеснять данные из L1-кэша, вызывая медленные обращения к памяти.

Переоптимизация. Sep тщательно контролирует, как данные перемещаются между регистрами. Теоретически это быстрее, но на практике может мешать оптимизациям рантайма. Компилятор и процессор умеют оптимизировать код, если им не указывают точный способ выполнения. Чрезмерная микрооптимизация «связывает руки» и мешает автоматическим улучшениям в новых версиях .NET.

Зависимость от оборудования. Результаты могут отличаться на разных машинах. Например, Sse.Prefetch0 (предзагрузка данных в L1) давала +10-20% на ноутбуке с DDR3, но почти нулевой эффект на десктопе с DDR5. На системах с AVX-512 и ARM у Sep есть аппаратные оптимизации, которых пока нет в FourLambda.Csv.

Выводы

История этого проекта — хороший пример того, как глубокое понимание низкоуровневых деталей (кодировки, устройство кэша, SIMD-инструкции) может привести к результатам, которые превосходят годы целенаправленных оптимизаций в существующих библиотеках.

Главные уроки:

• SIMD — не магия для избранных. В C# интринсики доступны из коробки и дают кратный прирост на задачах поиска и сравнения
• UTF-8-совместимость ASCII — мощное свойство, которое можно эксплуатировать для быстрого парсинга
• Минимализм побеждает сложность: меньше кода — меньше давления на кэш — быстрее выполнение
• Не мешайте компилятору: иногда лучшая оптимизация — не оптимизировать вручную

Библиотека доступна на GitHub: bbepis/FourLambda.Csv.

Перевод и адаптация статьи How I accidentally made the fastest C# CSV parser с разрешения автора.

В Go для этого есть Bleve — файловая библиотека полнотекстового индексирования. Она умеет индексировать любые Go-структуры с разумными настройками по умолчанию, поддерживает встроенный язык запросов в стиле Google, работает с миллионами записей и не требует отдельного сервера.

В этой статье — практический гайд: от простого индекса до кастомных анализаторов, мультиязычного поиска, пагинации курсором и тонкой настройки производительности.

Ключевые выводы

- Bleve — встраиваемый полнотекстовый движок для Go: не нужен отдельный сервер, достаточно одной зависимости
- Кастомные маппинги позволяют настроить анализатор, стемминг и стоп-слова для каждого поля отдельно
- IndexAlias объединяет несколько индексов (например, по языкам) в один виртуальный — с единым интерфейсом поиска
- Курсорная пагинация через SearchAfter / SearchBefore работает стабильно даже при обновлении индекса между запросами
- Scorch-настройки (воркеры, размер сегментов, порог мёржа) критичны для производительности под нагрузкой

Создаём простой индекс

Начнём с минимального примера. Два базовых действия — индексирование (сохранение документа для последующего поиска) и запрос (извлечение документов, отсортированных по релевантности).

Несколько важных деталей:

• bleve.New vs bleve.Open — New создаёт новый индекс по указанному пути, Open открывает существующий. Паттерн из примера (сначала New, при ошибке — Open) — идиоматический способ обработки первого и повторных запусков.
• NewIndexMapping() — возвращает маппинг по умолчанию: текстовые поля токенизируются, приводятся к нижнему регистру и фильтруются через список стоп-слов английского языка.
• Автоматическое обнаружение полей — Bleve использует рефлексию для анализа структуры. Все экспортируемые поля автоматически токенизируются и становятся доступными для поиска.
• Уникальные ID документов — строковый идентификатор, передаваемый в Index, используется для обновлений и удалений. Повторный вызов Index с тем же ID заменяет документ.
• SearchRequest.Fields — по умолчанию Bleve возвращает только ID и релевантность. Укажите имена нужных полей или []string{"*"}, чтобы получить все.
• hit.Score — каждый результат содержит числовой показатель релевантности на основе BM25. Чем выше — тем точнее совпадение.

Кастомные маппинги полей

Маппинг по умолчанию подходит для быстрого старта, но в реальных проектах нужен контроль над тем, как Bleve анализирует и хранит каждое поле. Маппинг определяет тип поля, анализатор для токенизации, необходимость хранения оригинального значения и включение в индекс.

Маппинги позволяют:

• Управлять токенизацией — разбивать текст на термы по пробелам, языковым правилам, edge n-граммам и другим стратегиям
• Фильтровать входные данные — приводить к нижнему регистру, удалять HTML, применять стоп-слова и стемминг (чтобы «running» и «runs» находились по запросу «run»)
• Исключать поля из индекса — пропускать чувствительные или нерелевантные данные для экономии дискового пространства
• Создавать кастомные анализаторы — комбинировать любой токенизатор с произвольной цепочкой фильтров

Пример ниже применяет стемминг английского языка к полям Text и Title, а поле с сырым HTML исключает из индексирования:

Результат buildIndexMapping() передаётся в bleve.New или bleve.NewUsing при создании индекса. Маппинги закрепляются за индексом на этапе создания и не могут быть изменены позже. Чтобы применить новый маппинг, нужно создать свежий индекс и переиндексировать все документы.

Мультиязычный поиск

Bleve умеет прозрачно работать с несколькими индексами одновременно через IndexAlias. Алиас — это виртуальный индекс, который отправляет запрос во все реальные индексы и объединяет результаты в единый ранжированный список.

Это особенно полезно, когда у каждого языка свой индекс с собственным анализатором (английский стемминг, французские стоп-слова, кастомная токенизация), а искать нужно по всем сразу:

Алиасы также упрощают горячую замену (hot-swap). Когда нужно перестроить индекс (например, применить новый маппинг), можно собрать новый индекс в фоне, а затем атомарно подменить его вызовом alias.Swap(newIndexes, oldIndexes). Текущие запросы завершатся на старом индексе, новые сразу пойдут на свежий — без даунтайма.

Пагинация с курсором

У SearchRequest в Bleve есть поле From для офсетной пагинации: 0 для первой страницы, 20 для второй и так далее. Это работает, но имеет серьёзную проблему: Bleve вынужден оценивать и сортировать все совпавшие документы вплоть до From + Size на каждый запрос. Глубокие страницы становятся всё дороже по памяти и CPU.

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

Правильный подход — курсорная пагинация через SearchAfter и SearchBefore. Эти методы продолжают выдачу с известной позиции, а не пересканируют результаты с начала:

На что обратить внимание:

• Стабильная сортировка обязательна. SearchAfter использует ключ сортировки последнего результата в качестве курсора. Если ключ нестабилен, курсор станет невалидным.
• Sort — всегда []string. Даже при сортировке по числовому полю Bleve сериализует ключ в строку. Читайте курсор из hit.Sort и передавайте напрямую в SetSearchAfter.
• SearchBefore работает аналогично, но в обратном направлении — полезно для кнопки «предыдущая страница».

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

Настройки производительности Bleve не слишком хорошо документированы, но существенно влияют на работу под нагрузкой. Конфигурация передаётся как map[string]any в NewUsing или OpenUsing вместо обычных New / Open.

Эти параметры относятся к Scorch — дефолтному бэкенду хранения Bleve. Полный список доступных опций и значений по умолчанию можно найти в исходном коде персистера.

Пакетная индексация

Если нужно проиндексировать большой объём данных, используйте Batch вместо одиночных вызовов Index. Пакетная запись группирует операции в одну транзакцию, что значительно снижает нагрузку на диск:

Оптимальный размер пакета зависит от объёма документов и доступной памяти. Как правило, пакеты по 100-1000 документов дают хороший баланс между скоростью и потреблением ресурсов.

Выводы

Bleve — одна из недооценённых жемчужин экосистемы Go. Библиотека позволяет добавить полнотекстовый поиск в приложение без сложной инфраструктуры. Настройки по умолчанию дают рабочий результат за минуты, а кастомные маппинги, композитные запросы и тонкая настройка Scorch — инструменты для решения специфических задач оптимально.

Официальная документация местами неполна, но issues на GitHub и реальные open-source-проекты отлично её дополняют. Рабочий пример всех описанных концепций можно найти в пакете indexer проекта Hister.

Адаптированный перевод статьи Data Indexing in Golang из блога Hister.

Независимый разработчик Tom Turney опубликовал метод sparse V dequantization — оптимизацию для инференса LLM с квантизированным KV-кешем. Вместо того чтобы ускорять деквантизацию каждого значения, он предложил пропускать деквантизацию целиком для позиций, где вес внимания пренебрежимо мал. На Apple M5 Max с моделью Qwen 3.5 35B (MoE) метод дал прирост +22,8% к скорости декодирования на контексте 32K токенов. Перплексия осталась неизменной, а точность поиска needle-in-a-haystack выросла с 7/9 до 9/9.

Ключевые выводы

— Узкое место квантизированного KV-кеша — не то, как вы деквантизуете, а то, сколько значений вы деквантизуете.
— При длинном контексте (32K+) более 90% весов внимания пренебрежимо малы — их деквантизацию можно пропустить.
— Метод работает с любой схемой квантизации KV-кеша: TurboQuant, q8_0, q4_0, NVFP4.
— Реализация — 3 строки в ядре flash attention. Не нужно ни переобучение, ни калибровочные данные.
— NIAH-тест улучшился: 9/9 вместо 7/9. Пропуск деквантизации убирает квантизационный шум от позиций, которые ничего не вносят в результат.

Проблема — узкое место деквантизации

Чтобы понять суть открытия, нужно разобраться в контексте. Современные LLM при генерации текста хранят промежуточные вычисления в так называемом KV-кеше (key-value cache). Это массив ключей (K) и значений (V), которые модель использует в механизме внимания — чтобы при генерации каждого нового токена не пересчитывать всю историю диалога.

Проблема: KV-кеш растёт линейно с длиной контекста и при 32K токенов занимает гигабайты памяти. Решение — квантизация: сжатие значений из 16-битного формата в 3-4 бита. TurboQuant от Google (ICLR 2026) сжимает KV-кеш в 4,6 раза с потерей перплексии всего ~1%. Но при декодировании каждый сжатый блок нужно деквантизовать — преобразовать обратно в числа с плавающей точкой. И на длинных контекстах это становится узким местом.

На Apple M5 Max деквантизация TurboQuant занимает 14-34% времени декодирования. На контексте 32K токенов скорость декодирования падает с 78,3 tok/s (потолок без деквантизации) до 47,0 tok/s — штраф в 40%.

14 попыток, которые провалились

Прежде чем найти решение, Turney перебрал 14 альтернативных реализаций деквантизации на Apple Silicon: регистровые массивы, битовую арифметику, SIMD-шаффлы, FMA без ветвлений, слитые блочные операции. Ни одна не обогнала базовую таблицу подстановки (LUT) в константной памяти GPU.

Вывод оказался фундаментальным: на Apple Silicon 4 дивергентных чтения из константной памяти быстрее любой арифметики, которая даёт тот же результат. Это аппаратный пол — ниже него не опуститься. Единственный оставшийся рычаг — уменьшить количество позиций, которые нужно деквантизовать.

Решение — не ускорять, а пропускать

Ключевое наблюдение: в flash attention ядре веса внимания (softmax) вычисляются из ключей (K) до того, как начинается работа со значениями (V). То есть на момент деквантизации V мы уже знаем, какие позиции контекста получили значимый вес внимания, а какие — нет.

Что такое разреженность внимания? Когда модель генерирует следующий токен, механизм внимания (softmax) распределяет вероятность по всем предыдущим позициям контекста. При коротком контексте внимание распределено относительно равномерно. Но чем длиннее контекст, тем более концентрированным оно становится: модель «смотрит» на несколько десятков ключевых позиций, а 90%+ получают веса ниже 10-6 — они практически ничего не вносят в итоговый результат.

Sparse V dequantization использует этот факт: если вес внимания для позиции ниже порога (10-6), её деквантизация и аккумуляция пропускаются целиком.

Вся реализация — три строки в Metal-ядре:

Это экономит чтения из константной памяти (обращения к LUT), ALU-операции (извлечение индексов, применение знака, умножение на норму) и чтения из глобальной памяти устройства.

Принципиальное отличие от 14 провалившихся подходов: они пытались сделать каждую из N операций быстрее (ограничено аппаратным полом). Sparse V убирает (1-p) x N операций целиком — и выигрыш растёт с длиной контекста, потому что разреженность внимания растёт.

Результаты

Скорость декодирования (M5 Max, Qwen 3.5 35B MoE)

Эффект sparse V масштабируется с длиной контекста — чем длиннее контекст, тем больше позиций пропускается:

• Короткий контекст: +1,4% (внимание плотное, мало что пропускать)
• 4K: +4,0%
• 8K: +7,2%
• 16K: +12,9%
• 32K: +22,8% (с 47,0 до 57,7 tok/s)

При 32K токенов отношение к несжатому q8_0 улучшилось с 0,76x до 0,93x — почти паритет.

Качество: перплексия и retrieval

Перплексия при включении sparse V остаётся численно идентичной варианту без него. На корпусе wikitext-103 (50 чанков, контекст 32K, CI +/-0.021) дельта составила ровно 0,0000. Это подтверждено на всех протестированных длинах контекста: 8K, 16K, 32K.

Ещё более неожиданный результат — в тесте needle-in-a-haystack (NIAH). Этот тест проверяет, может ли модель найти конкретный факт, спрятанный в длинном контексте:

• Без sparse V: 7/9 (q8_0 тоже 7/9)
• С sparse V: 9/9 (100%)

Гипотеза автора: позиции с пренебрежимо малым весом внимания вносят практически нулевой полезный сигнал, но при деквантизации добавляют квантизационный шум. Sparse V убирает этот шум — и соотношение сигнал/шум улучшается.

Почему это работает для любой квантизации

Sparse V работает не на уровне конкретного формата квантизации, а на уровне механизма внимания. Метод использует веса softmax как сигнал для пропуска вычислений — а softmax одинаков вне зависимости от того, как именно сжаты K и V.

Автор валидировал метод на трёх форматах KV-кеша с разной стоимостью деквантизации:

• turbo3 (3,5 бита, TurboQuant) — +22,8% на 32K, перплексия без изменений
• q8_0 (8 бит) — +5% к декодированию, перплексия идентична
• q4_0 (4 бита) — перплексия идентична, скорость в пределах шума

Закономерность: чем дороже деквантизация, тем больше выигрыш. turbo3 использует Walsh-Hadamard-преобразование и полярную декомпозицию — тяжёлые операции, поэтому выигрыш максимален. q4_0 использует простое масштабирование — пропуск дешёвой операции даёт мало. Но в обоих случаях метод не ухудшает ни перплексию, ни retrieval.

Это означает, что sparse V можно включить по умолчанию для любого формата квантизации KV-кеша в llama.cpp — как безусловную оптимизацию, которая ничего не стоит на коротком контексте и даёт ощутимый выигрыш на длинном.

FAQ

Не сломает ли пропуск позиций качество генерации?

Нет. Порог 10-6 выбран консервативно. При контексте 32K с 32 головами внимания вклад пропущенной позиции в итоговый вектор — менее одной миллионной от максимума. Перплексия во всех экспериментах осталась численно идентичной — дельта 0,0000 на 50 чанках wikitext-103.

Почему нельзя пропускать и K-деквантизацию?

Потому что K нужен для вычисления весов внимания. Чтобы узнать, какие позиции имеют пренебрежимо малый вес, нужно сначала деквантизовать все ключи и посчитать softmax. Автор отмечает это как направление будущей работы: двухпроходный механизм, где первый проход вычисляет приблизительные веса для фильтрации K-позиций.

Работает ли это на NVIDIA GPU?

Эксперименты проводились на Apple Silicon (M5 Max, M2 Pro). Реализация — Metal-ядро для llama.cpp. На CUDA профиль узкого места другой (NVIDIA использует тензорные ядра и HBM вместо unified memory), но сам принцип — пропуск работы для позиций с малым весом внимания — универсален. Портирование на CUDA и ROCm автор указывает как следующий шаг.

Выводы

Sparse V dequantization — элегантное решение, которое меняет вопрос с «как деквантизовать быстрее?» на «нужно ли деквантизовать вообще?». Метод использует информацию, которая уже есть в ядре flash attention — веса softmax — как бесплатный сигнал для пропуска вычислений.

Главная ценность подхода — не конкретный прирост в 22,8%, а более широкая идея attention-aware computation: использование собственных паттернов разреженности модели для оптимизации ядер инференса. Чем длиннее контекст, тем сильнее разреженность — и тем больше выигрыш. Именно при тех длинах контекста, где узкое место деквантизации наиболее болезненно.

Код и бенчмарки: TheTom/turboquant_plus (бенчмарки и диагностика), TheTom/llama-cpp-turboquant (реализация, ветка experimental_decode_speed_tests).

Обсуждение на r/LocalLLaMA.

Источник: Sparse V Dequantization — документация turboquant_plus.

Он опубликовал 113 уроков, которые вынес из этого опыта. Мы отобрали самые ценные, сгруппировали по темам и адаптировали для русскоязычной аудитории. Каждый урок — практический: его можно взять и применить в своём проекте уже сегодня.

Ключевые выводы

— Кэширование — последняя мера. Сначала исправьте модель данных, индексы и N+1-запросы.
— E2E-тесты на happy path дают в 10 раз больше отдачи, чем юнит-тесты на отдельные методы.
— Доведите Sentry до inbox zero — это единственный самый мощный шаг для качества продукта.
— Не обвиняйте конкретного разработчика за баг в проде: это всегда каскад из 3+ ошибок системы.
— Деплой за 2 минуты вместо 28 — достижимо, и это меняет культуру принятия решений.

Про архитектуру и масштабирование

Используйте сервисные объекты вместо раздувания моделей

В фреймворках, где модели строятся вокруг существительных (Product, User, Auction), логика неизбежно скапливается в этих классах. Со временем каждый из них превращается в монстра на тысячи строк. Решение — выносить процессы в отдельные сервисные объекты: PlaceAuctionBidService, ProductBillingService. Суть — перестать мыслить существительными и начать мыслить глаголами.

Одна и та же вещь, реализованная дважды — провал технического лидерства

Если в кодовой базе есть два разных клиента к одному платёжному провайдеру, три файла с функциями для работы с датами или дублирующиеся UI-компоненты — это симптом отсутствия ответственного за архитектуру. Создавайте очевидные, легко находимые места для общего кода (common/datetime.py, common/geo.py) и отмечайте переиспользуемый код на ревью.

Полиморфные связи в БД — почти всегда ошибка

ORM-код для полиморфных отношений становится крайне запутанным, и вы теряете защиту через foreign key constraints. Проще добавить nullable FK для каждой связанной модели и написать абстракции на уровне запросов.

Дефолтные фильтры и сортировки в ORM — всегда ошибка

Скрытые дефолты вроде order_by('-id') или filter(is_deleted=False) становятся миной замедленного действия, когда в команде 20+ человек. Новый разработчик не знает про неявное поведение — и получает баг. А скрытый ORDER BY портит аналитические запросы, потому что ORM добавляет ключ сортировки в SELECT.

Вся инфраструктура — в коде

Когда Джек пришёл в MorphMarket, все 27 крон-задач были настроены вручную на продакшн-сервере. Большинство отсутствовали на staging. Перенос в код (а затем конфигурация AWS/Heroku/CloudFlare/Sentry через Terraform) сделал все окружения похожими друг на друга — и, что важно, сделал инфраструктуру доступной для чтения AI-агентам.

Про тестирование

E2E > интеграционные > юнит-тесты

Пользователям важно, чтобы система работала целиком. Один E2E-тест на happy path каждой ключевой фичи (регистрация, покупка, создание листинга) даёт на порядок больше уверенности, чем десятки юнит-тестов. Детали дорабатывайте интеграционными и юнит-тестами — они быстрее и проще в поддержке.

Автоматические тесты для шаблонных фич

В MorphMarket написали систему, которая автоматически тестирует около 300 админ-страниц: парсит имя страницы, находит фабрику, создаёт запись в БД и проверяет, что страница открывается. Тот же подход можно применить к любому CRUD-эндпоинту без выделенного теста.

Изолируйте тесты полностью

Хрупкость тестов убивает мотивацию команды. Основные ловушки:

• Всё, что связано со временем — замораживайте или мокайте
• Фиксируйте seed для всех источников случайности — в каждой библиотеке
• Запретите реальные HTTP-запросы в не-E2E тестах (используйте VCR-подобные библиотеки)
• Отдельный Redis для тестов с автоочисткой перед каждым тестом
• Тестовая среда не должна читать ни одной переменной из вашего .env

Мокайте только внешние объекты

Мок — полезный инструмент, но только для внешних зависимостей. Мокать внутренние методы тестируемого класса — антипаттерн. Если можно переписать тест без мока без потери скорости — так и сделайте.

CI должен проверять не только ошибки, но и раздражающие мелочи

В MorphMarket CI также ловит новые warning-и в тестах, рассинхронизацию SDK с бэкендом и забытые миграции в Django. Чем раньше замечена мелочь, тем дешевле её исправить.

Про отладку и мониторинг

Sentry до inbox zero — самый мощный шаг к качеству

Когда Джек пришёл в компанию, Sentry показывал 1 000 ошибок в час. После агрессивной фильтрации (игнор старых браузеров, расширений, пометка JavaScript-ошибок уникальным идентификатором) и починки реальных багов — меньше 1 ошибки в час. Результат: каждая новая ошибка стала событием, на которое команда реагирует немедленно.

Dead Man Switch — мониторьте то, что должно происходить

Исключения шумят и легко ловятся. А вот отсутствие события — нет. Если крон-система перестала работать или бэкапы БД не снимаются — вы узнаете об этом только через heartbeat-мониторы. Настройте их.

Username в каждой строке лога

По умолчанию в логах — только IP-адрес. Но IP ротируется, создаёт лишнее перенаправление при дебаге и не показывает картину при использовании нескольких устройств. Поместите текущий запрос в thread-local и добавьте username в каждую запись.

Трипвайр-алерты на 20 самых важных эндпоинтов

Деградация производительности подкрадывается незаметно — инкрементальные фичи постепенно ломают индексы и кэши. Установите порог в несколько стандартных отклонений от нормы на ключевых эндпоинтах. Команда узнает о проблеме в течение часов после деплоя, а не через неделю жалоб.

Громко падайте при ошибках

Не глушите исключения except: pass. Паттерн от Джека: крашиться локально, мягко отказывать в проде — но всегда отправлять ошибку в Sentry/логи. Чем раньше заметили — тем меньше ущерб.

Про работу в команде

Не обвиняйте одного человека за баг в проде

Любой инцидент — это каскад минимум трёх провалов: автор не заметил, ревьюер пропустил, QA не покрыло, тесты не проверили, архитектура допустила класс ошибки. Обвинение одного человека мешает команде видеть системные причины.

Все разработчики должны быть немного фулстек

В MorphMarket убрали строгое деление на фронтенд/бэкенд/ops. Переобучение заняло год, но окупилось: фронтендер добавляет поле в БД сам, а не ждёт бэкендера — это сокращает время доставки фич.

Пятницы технического долга

Разумный компромисс между CEO, который хочет фичи, и инженерами, которым нужна чистота кода: с понедельника по четверг приоритеты задаёт продукт, а по пятницам — CTO. Бонус: инженеры отдыхают на глубоких задачах перед выходными.

Запретите длинные PR

В MorphMarket был период, когда PR висели по 3 месяца и накапливали тысячи изменений. Их невозможно ревьюить, они конфликтуют с master и создают огромный деплой-риск. Новое правило: мерж в master каждые 1–2 дня, максимум — раз в неделю. Побочный эффект: старшие разработчики дают фидбэк раньше, и драматические переписывания случаются реже.

Поощряйте общение в удалённых командах

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

Про производительность

N+1-запросы — враг номер один в ORM

Проблема проявляется на крупных эндпоинтах, которые постепенно расширяют разные авторы: новые фильтры и параметры создают спорадические N+1, которые возникают только при определённом сочетании фильтров и объёме данных. Настройте APM (например, New Relic) для автоматического обнаружения N+1 и обучите команду ловить их на ревью.

Кэширование — последняя мера

Код кэширования чудовищно сложен в поддержке. Сначала исправьте модель данных, допишите индексы, уберите N+1, оптимизируйте алгоритмы. И только после этого — кэш. Джек рассказывает о случаях, когда наивный кэш работал на малых объёмах, но убивал Redis (он однопоточный!) при росте данных на два порядка.

Таймауты на всех уровнях — иммунная система сервиса

Веб-запрос должен завершиться за 25 секунд — иначе убивается. Да, для длинных задач придётся использовать фоновые задачи, но без таймаутов одна тормозящая внешняя API может съесть все потоки сервера и уронить всё.

Выгружайте работу в фоновые задачи

Отправка email, push-уведомления, обработка вебхуков от платёжных систем — всё это должно уходить в очередь. Веб-процесс обязан оставаться быстрым.

ORDER BY id вместо ORDER BY created

Если поле created неизменяемо и совпадает по порядку с id — сортируйте по id. Индекс на id уже есть бесплатно в каждой таблице.

Удаляйте ненужные данные

В MorphMarket некоторые таблицы копили 10 лет данных — логи IP-адресов, записи push-уведомлений, сообщения девятилетней давности. Скрипт очистки делает эти таблицы компактнее и быстрее.

Про безопасность и надёжность

Начните с модели угроз: что может получить атакующий?

Для MorphMarket основные вектора: захват аккаунтов (фикс — обязательный 2FA), спам-фишинг (капча на регистрации + фильтры сообщений), DDoS (Cloudflare + rate limit на nginx + кэш ключевых эндпоинтов). Универсального подхода нет — каждый сервис должен понимать свою специфику.

CHECK-ограничения в БД — лучше предотвратить, чем чинить

Раньше в MorphMarket крон-задача раз в сутки проверяла целостность данных и слала алерты. Всё заменили на CHECK constraints на уровне БД — некоторые проверяют до 16 операций над разными колонками. Невалидные данные просто не могут быть записаны.

Вебхуки — рассадник race conditions

Действие в коде может вызвать вебхук, который прилетит быстрее, чем данные запишутся в БД. Получатель вебхука прочитает устаревшее состояние и может затереть свежие данные. Решение: откладывайте действия, вызывающие вебхуки, до on_commit в БД.

Логируйте намерение перед побочным эффектом — особенно для платежей

Перед списанием с карты или возвратом пишите в лог: "bill user XYZ $100 for Y". Простой Write-Ahead Log спасал MorphMarket в нескольких инцидентах.

Про деплой

Деплой должен быть быстрым — действительно быстрым

MorphMarket сократил деплой с 28 минут до 2. Как: разделили фронтенд и бэкенд, распараллелили, перешли на Rust-based компиляцию JS, вынесли сборку на мощные машины (MacBook M-series вместо commodity Heroku), убрали из слага всё ненужное, почистили старые ассеты из S3.

Smoke-тест после каждого деплоя в прод

Автоматическая проверка ключевых страниц через Playwright после каждого деплоя. Если последние 150 деплоев были скучными — соблазн перестать проверять вручную огромен. Автоматический smoke-тест не устаёт и не теряет бдительность.

Не деплойте ничего рискованного в пятницу

Баг может проявиться вечером или в субботу, когда никого нет. Мелкие хотфиксы и изменения в админке — можно. Всё остальное — до четверга.

Плейбук для инцидентов при деплое

Короткие инструкции: как убить залипшие соединения к БД, точечно почистить кэш (без flush, который разлогинит всех), форсировать обновление ассетов. Обученная команда сокращает даунтайм в разы.

Про карьерный рост — от тимлида до CTO

Научитесь говорить о производительности сотрудников

Джек признаётся, что панически боялся этих разговоров, потому что не любит конфликты. Но реальность проста: лучше открыто сказать человеку, где он не дотягивает, чем копить раздражение и уволить неожиданно. Большинство людей способны расти под менторингом — Джек это недооценивал.

Документ ожиданий от сотрудника

Если написать "мы ценим, когда вы решаете проблемы в #bug-discussion до того, как они дойдут до CTO", люди действительно начнут так делать. Мотивированный сотрудник хочет ясности. Он не может прочитать ваши мысли.

Одно крупное изменение за раз

Внедряете E2E-тесты? Доведите до стабильности, прежде чем браться за линтеры. Если система сделана плохо — команда не будет ей доверять и не будет использовать. Плюс есть предел того, сколько изменений люди могут усвоить одновременно.

CLI-инструменты + AI = максимальный рычаг

AI отлично работает с текстом. CLI-инструменты тоже. Дайте AI доступ к продакшн-логам, отчётам об ошибках, read-only реплике БД, CI-результатам и REPL — и получите огромный множитель продуктивности. Джек называет это "наблюдаемость через CLI — ваш главный усилитель для AI".

FAQ

Почему монолит, а не микросервисы?

Монолит на миллион строк с 20 разработчиками — рабочая модель, если соблюдать дисциплину. Микросервисы добавляют сетевую сложность, и для команды такого размера overhead координации перевешивает выгоды. Джек не утверждает, что микросервисы плохи — он утверждает, что переход оправдан только при конкретной боли, а не как дефолтный выбор.

С чего начать, если в проекте уже бардак?

С Sentry до inbox zero и таймаутов на веб-запросы. Первое даёт видимость реальных проблем, второе предотвращает каскадные отказы. Дальше — по статье: N+1, изоляция тестов, сервисные объекты.

Насколько эти уроки применимы за пределами Django?

Джек 17 лет работал с Rails, Laravel, Express и другими фреймворками — и подчёркивает, что большинство уроков переносимы. N+1, дефолтные сортировки, race conditions в вебхуках, инфраструктура как код — всё это не привязано к конкретному стеку.

Правда ли, что E2E-тесты лучше юнит-тестов?

Не лучше, а дают больше отдачи на первом этапе. Один E2E-тест на happy path покрывает весь стек. Юнит-тесты нужны для деталей и граничных случаев, но начинать покрытие лучше сверху вниз.

Выводы

113 уроков Джека Кинселлы — это не теория из книг, а выжимка из 7 лет ежедневной работы над монолитом, который обслуживает реальных пользователей. Главные принципы:

• Предотвращайте, а не чините — CHECK constraints, таймауты, линтеры
• Делайте невидимое видимым — логи, мониторинг, Sentry до inbox zero
• Инвестируйте в скорость обратной связи — быстрый деплой, быстрый CI, короткие PR
• Доверяйте людям и системе, а не контролю — fullstack-навыки, плейбуки, документ ожиданий

Оригинальная статья: Scaling a Monolith to 1M LOC: 113 Pragmatic Lessons from Tech Lead to CTO (Semicolon & Sons, Jack Kinsella).

Если знаете коллегу, который борется с растущим монолитом — отправьте ему эту статью. А в комментариях расскажите, какой урок оказался самым неожиданным для вас.

Это не абстрактный кейс из маркетингового блога. Это реальная история от Reco — SaaS-платформы безопасности, которая обрабатывает миллиарды событий в день. Их инженер Нир Барак взял подход, описанный Cloudflare в статье о переписывании Next.js с помощью ИИ, и применил его к собственной инфраструктуре. Получилась библиотека gnata — полная реализация JSONata 2.x на чистом Go с ускорением до 1000x на типовых выражениях.

JSONata — это язык запросов и трансформации JSON-данных. Его можно представить как jq, но с поддержкой лямбда-функций и более выразительным синтаксисом. JSONata позволяет писать сложные правила обработки данных без необходимости лезть в код основного приложения. Это делает его популярным в системах, где бизнес-аналитики или исследователи пишут правила детекции, а инженеры обеспечивают инфраструктуру.

Главное из статьи:

- JSONata-выражения через RPC обходились в $300 000/год на инфраструктуру
- ИИ-ассистированная перезапись на Go заняла 7 часов и стоила $400 в токенах
- Результат: 13 000 строк Go-кода, 1 778 пройденных тестов из официального набора
- Ускорение до 1000x на простых выражениях за счёт устранения RPC и JSON-парсинга
- Суммарная экономия после оптимизации пайплайна — $500 000/год

Проблема — JSONata как узкое место

У Reco есть policy engine, который проверяет JSONata-выражения на каждом событии в потоке данных. Миллиарды событий, тысячи различных выражений. Исследователи безопасности пишут правила детекции на JSONata, а инженеры обеспечивают их выполнение в реальном времени.

Загвоздка: референсная реализация JSONata написана на JavaScript, а весь пайплайн Reco — на Go. Годами компания держала в Kubernetes отдельный флот Node.js-подов (jsonata-js), к которым Go-сервисы обращались через RPC.

Для каждого события и каждого выражения это означало:

1. Сериализовать данные на стороне Go
2. Отправить по сети в Node.js-под
3. Выполнить JSONata-выражение
4. Сериализовать результат
5. Отправить обратно в Go-сервис

Во что это обходилось

Прямые затраты на инфраструктуру jsonata-js составляли около $300 000 в год, и сумма росла с каждым новым клиентом и правилом детекции. На одном из крупных кластеров количество реплик jsonata-js перевалило за 200 — и команда столкнулась с лимитом IP-адресов в Kubernetes.

Но денежные затраты были даже не главной проблемой. RPC round-trip занимает ~150 микросекунд ещё до начала вычисления. Для простого выражения вроде user.email = "admin@co.com", которое должно выполняться за наносекунды, основная цена — пересечение языковой границы. На масштабе Reco эти микросекунды складываются в ощутимые задержки.

Команда пробовала разные подходы: оптимизировала выражения, кэшировала результаты, даже встраивала V8 прямо в Go-процесс. Всё это давало инкрементальные улучшения, но не решало корневую проблему — данные всё равно пересекали языковую границу.

Решение — переписать на Go с помощью ИИ

Толчком стала статья Cloudflare о том, как один инженер за неделю переписал API Next.js на Vite, потратив $1 100 на токены. Нир Барак прочитал её и понял: у Reco та же самая ситуация — есть спецификация, есть тестовый набор, нужна реализация на другом языке.

Подход: спецификация + тесты = контракт

Метод прямолинейный:

1. Портировать официальный тестовый набор jsonata-js на Go
2. Направить ИИ на реализацию, пока все тесты не пройдут
3. Добавить оптимизации, специфичные для Go и задачи Reco

В выходные Нир составил план, разбитый на «волны» (с помощью ИИ). На следующий день нажал «старт».

Инструменты и затраты

Конкретные модели и инструменты автор не раскрывает, но ключевые цифры говорят сами за себя:

• Время работы: 7 часов (один инженер)
• Стоимость токенов: $400
• Результат: 13 000 строк Go-кода
• Тесты: 1 778 пройденных тест-кейсов из официального набора jsonata-js

Библиотека получила название gnata — полная реализация спецификации JSONata 2.x на чистом Go.

Технические результаты

Двухуровневая архитектура вычислений

gnata использует двухуровневую архитектуру оценки выражений. На этапе компиляции каждое выражение анализируется и классифицируется.

Быстрый путь (fast path) обрабатывает простые выражения: поиск по полям, сравнения и 21 встроенную функцию на чистых путях (например, $exists(a.b) или $lowercase(name)). Эти выражения вычисляются прямо по сырым JSON-байтам, без полного парсинга документа. Для выражения вроде account.status = "active" результат — ноль аллокаций в куче.

Полный путь (full path) — полноценный парсер и вычислитель с полной семантикой JSONata 2.x. Он парсит JSON, но только нужные поддеревья, а не весь документ целиком.

Потоковая обработка

Поверх двухуровневой оценки работает потоковый слой (StreamEvaluator), спроектированный под конкретную задачу Reco: применить N скомпилированных выражений к каждому событию, где события структурно похожи.

• Все пути из всех выражений объединяются в один проход по данным — количество выражений не влияет на скорость чтения
• После прогрева горячий путь работает без блокировок (lock-free)
• Планы вычислений создаются один раз на схему событий и кэшируются неизменяемо — чтение через один атомарный load без синхронизации
• Память ограничена: кэш с настраиваемой ёмкостью, вытесняющий старые записи

Бенчмарки

Ускорение на простых выражениях — в основном за счёт полного устранения RPC: gnata вычисляет прямо по сырым байтам без парсинга JSON. На сложных выражениях, где нужен полный парсинг и AST-вычисление, разрыв сужается, но они всё равно в 25–90 раз быстрее, чем через RPC.

На простых lookups ускорение достигает 1000x.

Пример использования

Экономический эффект

Этап 1: устранение RPC-флота

Первый и самый очевидный эффект — полное устранение jsonata-js подов в Kubernetes:

• До: ~$25 000/мес на compute для jsonata-js (200+ реплик Node.js)
• После: $0 — gnata работает как библиотека внутри существующих Go-сервисов
• Экономия: ~$300 000/год

Этап 2: рефакторинг rule engine

Но на этом история не закончилась. Старый JSONata через RPC мог обрабатывать только одно выражение за раз, и вся инфраструктура вокруг него была вынуждена подстраиваться. Rule engine запускал десятки тысяч горутин для максимизации параллелизма — со всеми вытекающими: избыточное потребление памяти и высокая конкуренция за CPU.

gnata не имеет таких ограничений. Команда заменила внутренности rule engine на более простую и эффективную реализацию с just-in-time батчингом (паттерн request coalescing), короткоживущими кэшами и групповыми запросами обогащения данных.

Результат: ещё ~$18 000/мес, или ~$200 000/год экономии.

Итого

$500 000/год снято с пайплайна за две недели работы. Из них 7 часов — создание gnata, остальное — тестирование, code review и раскатка.

Как внедряли — от shadow mode до продакшена

Создать библиотеку — половина дела. Вторая половина — убедиться, что она выдаёт ровно те же результаты, что и оригинал, на миллиардах реальных событий.

У Reco уже была инфраструктура для shadow-тестирования: feature flags, параллельное вычисление, логирование расхождений. Подключить gnata к ней было несложно.

Хронология раскатки:

• День 1: gnata готова, PR открыт
• Дни 2–6: code review, QA на реальных продакшен-выражениях, деплой в preprod в shadow mode. gnata вычисляет всё, но результаты jsonata-js остаются основными. Расхождения логируются и алертятся. Найденные edge-кейсы исправляются
• День 7: три дня подряд ноль расхождений. gnata переведена в primary

К моменту перевода gnata уже обработала миллиарды событий и выдала идентичные результаты. Более того, в процессе обнаружились баги в самом jsonata-js — случаи, где референсная реализация не соответствует собственной спецификации.

Побочный эффект: gnata стала одним из первых крупных PR в Reco, где ИИ-агенты ревьюили ИИ-сгенерированный код. Агенты помечали всё подряд — и реальные проблемы с конкурентностью, и косметические замечания. Команде пришлось научить их отличать одно от другого, и этот опыт теперь используется шире.

Уроки — когда ИИ-переписывание работает

gnata — удачный кейс. Но не каждая задача подходит для ИИ-переписывания. Вот что сделало этот проект идеальным кандидатом:

1. Чёткая спецификация. JSONata имеет формальную спецификацию и обширный тестовый набор. ИИ не нужно придумывать поведение — нужно реализовать заданное
2. Детерминированная проверка. Каждое выражение имеет однозначный правильный ответ. Можно автоматически проверить корректность — не нужен человек для оценки каждого результата
3. Глубокая экспертиза инженера. Нир не просто «нажимал кнопку». Он спроектировал двухуровневую архитектуру, потоковую обработку и стратегию кэширования. ИИ генерировал код, но архитектурные решения принимал человек
4. Существующая инфраструктура тестирования. Shadow mode, feature flags, сравнение результатов — всё это было готово до gnata. Без этого раскатить ИИ-сгенерированный код в продакшен было бы рискованно
5. Ограниченная область. JSONata — это чётко ограниченная задача. Не «перепишите весь бэкенд», а «реализуйте этот конкретный язык на другом стеке»

Как отметил Андрей Карпати: программирование становится неузнаваемым, и на верхних уровнях глубокая техническая экспертиза — «ещё больший мультипликатор, чем раньше, из-за увеличенного рычага». gnata — хорошая иллюстрация этой мысли.

FAQ

Что такое JSONata и зачем он нужен?

JSONata — это язык запросов и трансформации для JSON-данных. Он позволяет писать выражения для фильтрации, преобразования и агрегации JSON без написания кода на языке общего назначения. Используется в IoT-платформах, ETL-пайплайнах и системах обработки событий.

Почему нельзя было просто оптимизировать существующий подход?

Reco пробовали: оптимизация выражений, кэширование, встраивание V8 в Go. Всё это давало инкрементальные улучшения, но корневая проблема — пересечение языковой границы через RPC — оставалась. Единственное радикальное решение — нативная реализация на Go.

Насколько gnata совместима с оригинальной JSONata?

gnata проходит 1 778 тест-кейсов из официального набора jsonata-js и 2 107 интеграционных тестов в продакшен-обёртке Reco. В процессе тестирования были обнаружены баги в самом jsonata-js, где референсная реализация не соответствует собственной спецификации.

Можно ли повторить этот подход в другом проекте?

Да, если есть формальная спецификация и тестовый набор. Подход Cloudflare (vinext) и Reco (gnata) одинаков: берём спеку + тесты, направляем ИИ на реализацию до прохождения всех тестов. Ключевое требование — детерминированная проверка результата.

Выводы

История gnata — это не про то, что ИИ «волшебным образом» пишет продакшен-код. Это про то, как опытный инженер с глубоким пониманием задачи использует ИИ как мультипликатор своей экспертизы.

Ключевые выводы:

• ИИ-переписывание работает, когда есть чёткая спецификация и автоматизированная проверка
• Экономический эффект может быть огромным: $400 на токены превратились в $500 000/год экономии
• Архитектура важнее генерации кода: двухуровневая оценка, потоковая обработка и батчинг — решения инженера, не ИИ
• Shadow mode обязателен: ИИ-сгенерированный код нельзя просто «выкатить» — нужна параллельная проверка на реальных данных
• ROI считается просто: если задача имеет спеку и тесты, стоимость ИИ-переписывания предсказуема

gnata доступна как open-source библиотека: github.com/RecoLabs/gnata.

Источник: We Rewrote JSONata with AI — блог Reco.

Разбираемся, как инженеры Cloudflare нашли проблему и решили её буквально одной строчкой конфигурации.

Ключевые выводы:
— fsGroup в Kubernetes рекурсивно меняет владельца всех файлов на PersistentVolume при каждом монтировании — это безопасный дефолт, который становится проблемой на больших томах.
— Параметр fsGroupChangePolicy: OnRootMismatch (доступен с K8s 1.20) проверяет только корневую директорию вместо обхода всех файлов.
— Одна строчка в манифесте сократила время рестарта Atlantis с 30 минут до 30 секунд — экономия ~600 инженерных часов в год.
— Безопасные дефолты Kubernetes рассчитаны на небольшие рабочие нагрузки. При масштабировании их стоит пересматривать.

Проблема — 30 минут на рестарт

Atlantis — это инструмент для автоматизации Terraform через pull/merge request'ы. В Cloudflare он управляет десятками проектов и работает как singleton StatefulSet в Kubernetes. Для хранения состояния репозиториев Atlantis использует PersistentVolume (PV).

Перезапуски нужны регулярно: ротация секретов, onboarding новых проектов, обновления конфигурации. С учётом примерно 100 рестартов в месяц каждый 30-минутный простой складывался в 50+ часов заблокированного инженерного времени ежемесячно. Плюс каждый рестарт триггерил алерт и будил дежурного.

Ситуация обострилась, когда на PV закончились inode'ы. Inode — это запись о файле или директории в файловой системе, и их количество фиксируется при создании ФС. Единственный способ получить больше inode'ов в их конфигурации — увеличить размер тома, а для этого нужен рестарт пода.

Расследование

Первые зацепки

После kubectl rollout restart statefulset atlantis новый под появлялся практически мгновенно, но зависал на стадии инициализации:

События пода выглядели нормально — Kubernetes успешно распределил под на ноду, скачал образ init-контейнера за доли секунды. Но между назначением на ноду и началом скачивания образа был необъяснимый промежуток в 30 минут.

Копаем глубже — логи kubelet

Событий Kubernetes было недостаточно. Инженеры обратились к логам kubelet — компонента, который на каждой ноде координирует создание подов, монтирование томов и другие операции. Поскольку kubelet работает как systemd-сервис, его логи доступны через централизованную систему (в данном случае Kibana).

В логах kubelet было видно, что PersistentVolume монтируется сразу после назначения пода. Секреты тоже монтируются без проблем. Но затем — снова провал, и в логах появляется ошибка:

Kubelet считал, что под готов к запуску, но что-то блокировало монтирование тома и вызывало таймаут.

Разгадка — fsGroup

Последней зацепкой стало имя PV. Инженеры использовали его как поисковый запрос в Kibana — и сразу нашли ключевое сообщение:

Вот в чём было дело. В spec.securityContext пода было указано fsGroup: 1. Это нужно, чтобы процессы Atlantis (запущенные не от root) имели доступ к файлам на томе. Но способ, которым Kubernetes это обеспечивает, оказался проблемой: при каждом монтировании kubelet выполняет рекурсивный chgrp по всем файлам и директориям на PersistentVolume.

А файлов к тому моменту были миллионы — команда недавно столкнулась с нехваткой inode'ов, что прямо указывало на огромное количество файлов. Рекурсивный обход миллионов записей на каждом рестарте — вот что съедало 30 минут.

Решение — одна строчка

Начиная с версии 1.20, Kubernetes поддерживает поле fsGroupChangePolicy в pod.spec.securityContext. По умолчанию оно установлено в Always — рекурсивный обход при каждом монтировании. Альтернативное значение OnRootMismatch проверяет только корневую директорию тома: если у неё уже правильная группа, рекурсивный обход не запускается.

Фикс целиком:

Важно: устанавливать OnRootMismatch стоит только если вы уверены, что ничто не меняет группу файлов на PersistentVolume извне. В случае Cloudflare инженеры проверили, что никакие процессы не модифицируют права на файлы в томе, и только после этого применили настройку.

Почему это работает

Параметр fsGroup в Kubernetes решает конкретную задачу: контейнеры, запущенные от непривилегированного пользователя, должны иметь доступ к файлам на примонтированном томе. Kubernetes обеспечивает это, выполняя chgrp -R по всему содержимому PV при каждом монтировании.

Для небольших томов с сотнями или тысячами файлов это работает незаметно. Но по мере роста данных время обхода растёт линейно. На миллионах файлов — даже на быстрых NVMe-дисках — операция занимает десятки минут.

Политика OnRootMismatch меняет логику: kubelet проверяет только корневую директорию тома. Если её группа совпадает с fsGroup, рекурсивный обход пропускается. Поскольку Atlantis сам создаёт файлы с правильной группой (она наследуется от корневой директории), проверять миллионы файлов при каждом рестарте нет необходимости.

Результат

• Время рестарта: 30 минут → 30 секунд (ускорение в 60 раз)
• Экономия: ~50 часов заблокированного инженерного времени в месяц
• В годовом исчислении: ~600 часов продуктивной работы, возвращённых команде
• Ложные алерты: дежурный инженер больше не получает пейджер на каждый рестарт
• Время на фикс: одна строчка в YAML-манифесте

Как отметили в Cloudflare: диагностика заняла больше времени, чем само исправление.

Уроки для разработчиков

1. Проверяйте дефолты при масштабировании. Безопасные настройки по умолчанию в Kubernetes рассчитаны на простые рабочие нагрузки. Когда данные растут, дефолты могут незаметно стать бутылочным горлышком.
2. Ищите не только в событиях Kubernetes. Pod events показывают не всё. Логи kubelet, метрики нод, журналы CSI-драйверов — полезные источники информации при отладке проблем с монтированием.
3. Считайте стоимость «мелких» проблем. 30 минут простоя кажутся терпимыми. 30 минут x 100 раз в месяц = 50 часов. Масштаб меняет приоритеты.
4. Аудит securityContext. Поля fsGroup, runAsUser, runAsGroup и fsGroupChangePolicy напрямую влияют на время старта подов с PersistentVolume. Если у вас большие тома — проверьте эти настройки.
5. Не всякий фикс должен быть сложным. Самые ценные исправления часто оказываются самыми простыми — но требуют глубокого понимания того, как система работает под капотом.

Частые вопросы

Что делает fsGroupChangePolicy в Kubernetes?

Параметр fsGroupChangePolicy определяет, когда Kubernetes рекурсивно обновляет группу-владельца файлов на PersistentVolume. Значение Always (по умолчанию) запускает рекурсивный chgrp при каждом монтировании. Значение OnRootMismatch выполняет обновление только если группа корневой директории не совпадает с fsGroup. Поддерживается с Kubernetes 1.20.

Безопасно ли использовать OnRootMismatch?

Если файлы на PersistentVolume создаются только процессами внутри пода (и наследуют правильную группу от корневой директории), OnRootMismatch безопасен. Но если внешние процессы или другие поды могут менять группу файлов на томе, лучше оставить значение Always и искать другие способы оптимизации.

Как узнать, влияет ли fsGroup на время старта моих подов?

Проверьте логи kubelet на ноде, где запускается под. Если в них есть сообщение "Setting volume ownership... If the volume has a lot of files then setting volume ownership could be slow", значит рекурсивный обход выполняется. Также можно сравнить время между событиями Scheduled и Started для пода — большой разрыв при наличии PV с fsGroup указывает на эту проблему.

Выводы

История Cloudflare — отличный пример того, как безопасный дефолт может превратиться в серьёзную проблему на масштабе. fsGroupChangePolicy: Always — разумная настройка для небольших томов, но на миллионах файлов она съедает минуты при каждом рестарте.

Главный урок: если что-то в вашем кластере работает медленнее, чем должно — не расширяйте окно алертов, а копайте глубже. Иногда ответ — это одна строчка YAML.

По материалам блога Cloudflare.

Мы разобрались. Объясняем так, чтобы было понятно всем — и тем, кто пишет нейросети, и тем, кто просто хочет запустить ChatGPT-подобную модель на своём ноутбуке.

TurboQuant — алгоритм квантизации KV-кеша для больших языковых моделей (LLM), разработанный Google Research. Сжимает KV-кеш с 16 до 3 бит на значение, уменьшая потребление памяти при инференсе в 5–6 раз без переобучения модели и без потери качества. Представлен на ICLR 2026 (arXiv:2504.19874).

KV-кеш: почему нейросетям нужно столько памяти

Когда вы общаетесь с ChatGPT, Gemini или любой другой LLM, модель должна «помнить» весь ваш диалог. Для этого она использует KV-кеш (Key-Value cache) — специальный буфер в памяти видеокарты, где хранятся промежуточные вычисления механизма внимания (attention).

Представьте: вы читаете книгу и делаете заметки на полях. KV-кеш — это те самые заметки. Без них модели пришлось бы каждый раз перечитывать весь текст с начала, чтобы ответить на ваш вопрос.

Проблема в масштабе:

• Модель Llama 3.1 70B при контексте 128K токенов тратит ~40 ГБ только на KV-кеш — это больше, чем весит сама модель в квантизированном виде
• Чем длиннее контекст (переписка, документ, код) — тем больше памяти нужно, и это растёт линейно
• Именно KV-кеш — главный ограничитель того, сколько текста модель может «видеть» одновременно

И именно KV-кеш сжимает TurboQuant.

Что такое TurboQuant

TurboQuant — это алгоритм сжатия KV-кеша, разработанный Google Research. Статья принята на ICLR 2026 — одну из топовых конференций по машинному обучению. Авторы — Amir Zandieh, Vahab Mirrokni (VP Google, известный исследователь в области алгоритмов) и коллеги.

• Сжимает KV-кеш до 3 бит на значение (с обычных 16) — уменьшение в ~5 раз
• Не требует дообучения модели — работает с любой LLM «из коробки»
• Не теряет качество на стандартных бенчмарках (LongBench, Needle in a Haystack, RULER)
• Ускоряет вычисления attention до 8 раз на NVIDIA H100
• Работает «на лету» — не нужно заранее обрабатывать данные

Важно: TurboQuant сжимает только KV-кеш при инференсе. Он НЕ сжимает веса модели (это делают GPTQ, AWQ, GGUF) и НЕ влияет на обучение. Это принципиально другая задача.

Как работает TurboQuant: PolarQuant и QJL простыми словами

TurboQuant работает в два этапа. Если упрощать — это как сжатие фотографии в JPEG, только для математических векторов в памяти нейросети.

Шаг 1: PolarQuant — умное сжатие основных данных

Обычно данные в нейросети хранятся в декартовых координатах — как «иди 3 блока на восток и 4 блока на север». PolarQuant переводит их в полярные координаты — «иди 5 блоков под углом 37 градусов». Перед конвертацией вектор случайным образом поворачивается — это делает распределение координат более однородным.

В полярных координатах данные распределены более предсказуемо. Это позволяет применить оптимальный квантизатор (Lloyd-Max) к каждой координате независимо, без дополнительных битов на хранение параметров квантизации. В обычных методах эти «служебные» биты съедают 1–2 бита на число — при 3-битной квантизации это колоссальные накладные расходы.

Шаг 2: QJL — коррекция ошибок за 1 бит

После PolarQuant остаётся небольшая ошибка. QJL (Quantized Johnson-Lindenstrauss) — алгоритм, который использует математическое преобразование Джонсона–Линденштрауса для сведения остаточной ошибки к нулевому смещению, тратя на это всего 1 дополнительный бит.

Если PolarQuant — это основной «сжиматель», то QJL — это математический «корректор», который гарантирует, что attention-скоры модели остаются точными. Вместе они дают 3-битное представление, которое математически доказано как близкое к теоретическому пределу сжатия (с точностью до константы ~2,7).

Чем TurboQuant отличается от обычной квантизации

Если вы запускаете модели через llama.cpp, Ollama или LM Studio, вы уже используете квантизацию — те самые Q4, Q5, Q8 в названиях файлов. Но это квантизация весов модели. TurboQuant работает с совершенно другой сущностью.

Квантизация весов (GPTQ, AWQ, GGUF) — сжимает параметры модели один раз перед запуском. Чем меньше бит — тем хуже качество. Иногда требует калибровки или дообучения.

TurboQuant — сжимает KV-кеш (промежуточные вычисления) на лету во время работы. При 3,5 битах — нулевая потеря качества. Не требует дообучения вообще.

Эти подходы комплементарны. Вы можете использовать Q4-квантизированную модель И TurboQuant-сжатый KV-кеш одновременно. Одно не заменяет другое — они сжимают разные части системы.

TurboQuant на практике: MacBook, видеокарты и облако

Если у вас MacBook или обычный ПК

Энтузиасты уже запустили Qwen 3.5 9B на обычном MacBook Air M4 (16 ГБ) с контекстом 20 000 токенов — раньше на таком железе длинные контексты были невозможны. Не MacBook Pro, не Mac Studio — обычный Air, самая дешёвая конфигурация. В Reddit-треде есть видео-демо.

Это значит: локальная нейросеть на вашем ноутбуке сможет «видеть» в 5 раз больше текста за раз. Длинные документы, полноценные кодовые базы, многостраничные переписки — всё это становится доступнее без покупки нового железа.

Если у вас мощная видеокарта

Один из разработчиков рассчитал для модели 70B Q4_K_M с 34 ГБ свободной VRAM под KV-кеш:

• Без TurboQuant (FP16 KV-кеш): ~109K токенов контекста
• С Q8 KV-кешем: ~218K токенов
• С TurboQuant TQ3 (3 бита): ~536K токенов
• Полное окно контекста 262K легко помещается на 3× RTX 3090

Если вы разрабатываете ИИ-продукты

• В 5–6 раз меньше GPU-памяти на инференс при длинных контекстах
• До 8× ускорение attention на H100
• Снижение стоимости обслуживания каждого запроса к LLM

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

TurboQuant в llama.cpp, MLX и PyTorch: кто уже пробует

Прошло всего несколько дней с публикации, но Open Source сообщество уже на коне:

• llama.cpp — минимум 3 независимых реализации, обсуждение интеграции в основную ветку. Одна уже работает на Apple Silicon через Metal
• MLX (Apple Silicon) — разработчики адаптируют алгоритм для маков
• PyTorch + Triton — появились reference-реализации для CUDA-видеокарт
• C/CUDA — рабочая реализация с 18 из 18 пройденных тестов, MSE совпадает с бумагой

Пока реализации не оптимизированы. Бенчмарки показывают падение скорости генерации в 3–8 раз по сравнению с обычным Q8 KV-кешем. Причина — неоптимизированная операция поворота вектора. Разработчики уже работают над оптимизацией через преобразование Адамара.

Как попробовать TurboQuant прямо сейчас

Официального кода от Google нет, но сообщество уже сделало несколько рабочих реализаций. Вот как запустить TurboQuant на своём железе — три варианта в зависимости от платформы.

На Mac (Apple Silicon M1–M5)

Форк llama-cpp-turboquant от TheTom — самая зрелая реализация с Metal-ядрами для Apple Silicon. Работает на M1, M2, M3, M4, M5.

Флаг turbo3 включает 3,5-битную квантизацию KV-кеша (сжатие 4,6× vs FP16). На M5 Max 128 ГБ модель Qwen3.5-35B показывает 2747 tok/s на prefill — на уровне стандартного q8_0, при этом KV-кеш занимает в 4,6 раза меньше памяти.

На PC с видеокартой NVIDIA или AMD

Форк llama-turboquant поддерживает CUDA и ROCm. Тип кеша здесь называется tq3_0 (вместо turbo3).

Python (для исследований и экспериментов)

turboquant-pytorch — reference-реализация на PyTorch. Подойдёт для изучения алгоритма и проверки сжатия на своих моделях.

Ollama и LM Studio пока не поддерживают TurboQuant — они используют свои сборки llama.cpp, в которые метод ещё не влит. Но можно поднять llama-server из форка выше и подключиться к нему как к OpenAI-совместимому API.

Бенчмарки TurboQuant: результаты из бумаги и от сообщества

Из бумаги Google (тестировалось на Gemma и Mistral):

• LongBench, Needle in a Haystack, ZeroSCROLLS, RULER, L-Eval — при 3,5 битах «абсолютная нейтральность качества»
• При 2,5 битах — «маргинальная деградация»
• 4-bit TurboQuant: ускорение attention до 8× на H100 по сравнению с 32-bit baseline
• Сжатие KV-кеша минимум в 6 раз

Из независимых реализаций:

• TQ3 (3 бита): MSE = 0,034, сжатие 4,9× vs FP16
• TQ4 (4 бита): MSE = 0,009, сжатие 3,8× vs FP16
• Размер блока: 52 байта на 128 значений (для TQ3)

Почему TurboQuant обвалил акции Micron — и стоит ли переживать

Рынок отреагировал панически: Micron −25%, Samsung −4,7%, SK Hynix −6,2%. Но аналитики Morgan Stanley, JPMorgan, Citigroup и Goldman Sachs единодушны — реакция чрезмерна. Вот почему:

1. TurboQuant не трогает обучение. HBM-память, основной драйвер прибыли чипмейкеров, нужна для обучения моделей. TurboQuant сжимает только инференс
2. Это исследование, не продукт. Официального кода от Google нет, эксперименты на моделях ~8B параметров
3. Прецедент DeepSeek. В январе 2025 тоже обвалили чипмейкеров — затем спрос только вырос
4. Фиксация прибыли. Micron был +300% за год, Samsung +200%. Инвесторы искали повод зафиксировать прибыль

Если TurboQuant снизит операционные расходы на ИИ до одной шестой от текущего уровня, компании, которые до сих пор не внедряли ИИ из-за высокой стоимости, войдут в ИИ-экосистему.

Подробнее о реакции рынка — в нашей новости.

Часто задаваемые вопросы

Чем TurboQuant отличается от GGUF/GPTQ/AWQ?
GGUF, GPTQ и AWQ сжимают веса модели (параметры). TurboQuant сжимает KV-кеш — временную рабочую память, которая используется во время инференса. Эти подходы дополняют друг друга.

Можно ли уже использовать TurboQuant?
Экспериментально — да. Несколько независимых реализаций для llama.cpp и MLX уже работают. Но в основную ветку llama.cpp и в Ollama/LM Studio метод пока не интегрирован. Ожидается в ближайшие недели–месяцы.

Нужно ли переобучать модель для TurboQuant?
Нет. TurboQuant — data-oblivious метод, который применяется к любой существующей LLM без дообучения и без калибровочных данных.

TurboQuant: итоги и выводы

• TurboQuant — прорыв в сжатии KV-кеша, но не «убийца GPU» и не «конец эпохи дорогого железа»
• Работает вместе с обычной квантизацией весов, а не вместо неё
• Реально позволяет запускать более длинные контексты на том же железе — в 5 раз длиннее
• Сообщество уже пишет реализации для llama.cpp и MLX
• До полноценного внедрения в популярные инструменты — недели или месяцы
• Обвал акций — чрезмерная реакция, аналитики рекомендуют покупать на падении

Следите за GitHub-дискуссией в llama.cpp — именно там появится рабочая реализация для повседневного использования. А блог Google Research и бумага на arXiv — для тех, кто хочет погрузиться в математику.

Но паника оказалась преждевременной. Разбираемся, что на самом деле делает TurboQuant и почему аналитики советуют покупать на падении.

Главное: TurboQuant сжимает только KV-кеш при инференсе, не веса модели и не данные обучения. HBM-память, основной драйвер прибыли чипмейкеров, нужна для обучения — а TurboQuant на обучение не влияет вообще. Аналитики Morgan Stanley, JPMorgan и Citigroup называют обвал «возможностью для покупки».

Что такое TurboQuant

TurboQuant — алгоритм сжатия KV-кеша (Key-Value cache) при инференсе больших языковых моделей. KV-кеш — это «рабочая память» модели: промежуточные вычисления механизма внимания, которые хранятся в VRAM GPU. Чем длиннее контекст, тем больше KV-кеш занимает места.

Алгоритм работает в два этапа:

1. PolarQuant — переводит векторы из декартовых координат в полярные после случайного вращения, экономя 1–2 бита на число
2. QJL (Quantized Johnson-Lindenstrauss) — коррекция ошибок: сводит остаточную ошибку к одному биту, обеспечивая нулевое смещение attention scores

Результат: сжатие KV-кеша до 3 бит на значение (с 16 стандартных), ускорение до 8x на H100, нулевая потеря качества на бенчмарках. Не требует дообучения. Статья принята на ICLR 2026.

Как отреагировал рынок

• Micron (MU) — с $471 до $345, падение ~25% за неделю
• SK Hynix — -6,2% за день
• Samsung — -4,7%, 4 дня падения подряд
• Kioxia — -6% в Токио
• Western Digital, SanDisk — -7%+
• KOSPI -3,2%, NASDAQ -2,4%

Почему паника преждевременна

Аналитики Morgan Stanley, JPMorgan, Citigroup и Goldman Sachs единодушны: реакция чрезмерна. Почему:

1. TurboQuant сжимает только KV-кеш, не веса и не данные обучения. HBM нужна для обучения — TurboQuant на обучение не влияет
2. Парадокс Джевонса. Дешевле инференс = больше компаний используют ИИ = спрос растёт
3. Прецедент DeepSeek. В январе 2025 тоже обвалили чипмейкеров — затем спрос только вырос
4. Исследование, не продукт. Нет кода, эксперименты на ~8B моделях
5. Фиксация прибыли. Micron +300%, Samsung +200%, Kioxia +700% за год

If TurboQuant cuts AI operating costs to one-sixth of current levels, companies that have hesitated to adopt AI due to cost burdens will enter the AI ecosystem.

Sell-off stemmed from an interpretation error caused by confusing the roles of memory capacity and memory bandwidth.

FAQ

TurboQuant убьёт спрос на память?

Нет. Алгоритм сжимает только KV-кеш при инференсе. HBM для обучения не затронута. Глава SK Group заявил, что дефицит чипов памяти сохранится до 2030 года.

Можно ли уже использовать TurboQuant?

Официального кода от Google нет, но уже появились независимые реализации на PyTorch+Triton, MLX и C/CUDA для llama.cpp.

Чем это отличается от обычной квантизации?

GPTQ/AWQ сжимают веса модели с потерей качества. TurboQuant сжимает KV-кеш (временные вычисления) с математически доказанным нулевым смещением. Подходы комплементарны.

Источники: Google Research, CNBC, Seoul Economic Daily

WordPress часто не любят backend-разработчики, и у каждого на это есть свои причины. Кому-то не нравится функциональный стиль разработки, кто-то критикует form-builder и экосистему плагинов. У других WordPress как CMS и PHP как язык программирования до сих пор ассоциируются со стереотипами 10–15-летней давности - будто они устарели и уступают современным технологиям.

При этом реальность такова, что и PHP, и WordPress - отличные и современные инструменты, которые очень хорошо выполняют свои задачи. Опустим PHP - статья не об этом. Что же можно сказать про WordPress как про продукт и как CMS?

WordPress по‑прежнему остаётся самой популярной системой управления контентом. Согласно данным команды WordPress, платформа обслуживает более 43% всех веб-сайтов и занимает долю в 61% на рынке CMS. Также статистика показывает, что WordPress используется примерно на 59% сайтов, где известна CMS (это около 42% всего веба).

Данные были взяты из официального блога WordPress и сайта w3techs.com:

• https://wordpress.com/blog/2025/04/17/wordpress-market-share/
• https://w3techs.com/technologies/overview/content_management
• https://w3techs.com/technologies/details/cm-wordpress

При этом, традиционный WordPress объединяет CMS, шаблоны на PHP и монолитные темы. Такая связка усложняет разработку с использованием современных JS фреймворков, а также затрудняет независимое масштабирование фронтенда и бэкенда, и оптимизацию производительности и безопасности. Жёсткая связка страниц, устаревшие PHP‑функции и не самый удобный девелоперский опыт часто заставляют команды искать альтернативы.

Headless WordPress решает эти проблемы: CMS становится админ-панелью для управления контентом, а отдельный фронтенд отвечает за UI. Такое разделение обязанностей даёт несколько преимуществ: четкое разделение ответственности, независимое масштабирование интерфейса и CMS, упрощенную локальную разработку и CI/CD. CMS превращается в API‑ориентированное хранилище, а современные фреймворки вроде Next.js берут на себя маршрутизацию и рендеринг.

Headless WordPress с использованием WPGraphQL

Чтобы использовать WordPress как headless‑CMS, нужен API. Также есть интересный пост про headless wordpress в их официальном блоге.

В WordPress из коробки есть REST API, но для frontend и mobile приложений часто удобнее использовать GraphQL. WPGraphQL - это open source плагин, который добавляет GraphQL API в WordPress. Используя WPGraphQL, мы получаем:

• Гибкие запросы к таким сущностям, как посты, страницы, произвольным типам постов, таксономиям и пользователям.
• Систему расширений которая позволяет расширять функционал GraphQL бекенда и таким образом поддерживать популярные плагины, тем самым позволяя возвращать дополнительные поля которые не относятся к стандартным полям Wordpress.
• GraphQL API, который даёт очень удобный формат для интеграции фронтенд фреймворков таких как Next.js, Astro и SvelteKit.
• Оптимизацию производительности, поскольку клиент запрашивает только нужные поля и данные делая один запрос вместо группы REST запросов + отдельный фронтенд забирает на себя часть запросов.

В дополнение к доступному функционалу WPGraphQL можно добавлять дополнительные плагины-расширения, такие как WPGraphQL Yoast SEO и WooGraphQL (WPGraphQL для WooCommerce). Таким образом добавив несколько плагинов в базовую инсталляцию CMS можно из коробки получить полностью функциональный GraphQL бекенд, который может покрыть запросы для блога, сео функционал, онлайн-магазин и тд.

Важно отметить, что изначальная идея использовать WPGraphQL пришла из статьи в блоге Vercel.

Фронтенд на Next.js

Next.js - production-ready React-фреймворк, который разрабатывается компанией Vercel. Многие используют его по умолчанию для разных headless‑проектов. Наш пример headless-wordpress не исключение. Фреймворк предлагает удобную маршрутизацию на базе файловой системы, где любой файл в папке pages автоматически становится маршрутом и поддерживает несколько стратегий рендеринга:

• Server‑side rendering (SSR) позволяет генерировать HTML при каждом запросе.
• Статическая генерация (включая [Incremental Static Regeneration])
• React Server Components, стратегия которая дает гибкость в балансировании производительности и кэширования.

Это делает Next.js хорошей платформой для работы с GraphQL API и рендеринга страниц React‑компонентами. Если у вас нет опыта с Next.js и React, то это не повод не попробовать набросать POC в свободное время. Современные Next.js и React templates + хороший AI agent помогут адаптировать UI под GraphQL для вас.

Почему Cloudflare?

Vercel очень часто является платформой по умолчанию для Next.js‑приложений. Более того Next.js адаптирован для запуска из коробки на серверах Vercel. При этом нужно добавить, что идея этой статьи не в том чтобы как-то компрометировать Vercel. Что же нужно знать про Cloudflare чтобы обратить внимание на этот сервис с точки зрения альтернативы для хостинга Next.js?

Согласно статистике, реверс-прокси сервисы Cloudflare используются примерно на 21,9% всех сайтов в интернете, а это более 82% сайтов, где используется прокси‑сервисы в принципе. Такая распространённость говорит о масштабе, надежности и глобальном охвате сервиса. Но Cloudflare - это не только reverse-proxy. Компания разрабатывает целую группу облачных сервисов, включая такие сервисы, как Cloudflare Pages - альтернатива Github Pages, Workers - Serverless functions (по аналогии с AWS Lambda), Контейнеры, Очереди, AI сервисы, R2 Object Storage, и другие. В дополнение ко всему, компания предоставляет такие сервисы, как защита сайта (site-protection), VPN и капча (human-detection captcha). Такое разнообразие сервисов делает сервис очень распространенным.

Лимиты бесплатного тарифа Cloudflare

Одним из самых интересных аргументов в пользу Cloudflare можно считать их бесплатный тариф. Защита от DDoS, Universal SSL и глобальную CDN доступны бесплатно. Также бесплатный тариф включает большинство из вышеперечисленных облачных сервисов. Например, Cloudflare Workers, который можно использовать для хостинга Next.js-проектов, бесплатно даёт 100,000 запросов в день. Или R2 object storage - альтернатива S3 по умолчанию дает 10GB пространства, которое можно использовать для хранения статики или других данных. Этого более чем достаточно чтобы поэкспериментировать на выходных с новым стеком и вполне достаточно для того, чтобы бесплатно хостить ваш проект до тех пор пока у вас не пойдет серьезный трафик. Ниже приведена таблица с некоторыми из Cloudflare сервисов и что включено в бесплатный тариф.

Запуск Serverless функций на edge-серверах

Cloudflare Workers позволяют запускать серверлесс‑код по всей сети Cloudflare. Ниже приведено изображение показывающее как работает Edge CDN, когда например статика продублирована на все доступные сервера и таким образом пользователь получает ресурсы с самого близлежащего сервера.

Эта картинка хороша тем, что аналогично CDN статике на этих же серверах можно запускать и Workers (Lambda) функции, тем самым ускоряя вашу инфраструктуру еще больше.

Одной из интересных особенностей Workers-функций является отсутствие cold-starts. Любой cloud provider обычно подымает docker container или виртуализированное окружение в момент первого запуска программы, а это всегда задержка. Минусом Workers-функций является тот факт что их Runtime API требует чтобы код мог использовать их Web platform APIs. А это в свою очередь ограничивает выбор языка программирования: Javascript, Typescript и WebAssembly. Но благодаря такому подходу Workers используют изолированную модель запуска и могут быть прогреты еще до момента запуска кода этого воркера. Прогрев начинается еще на этапе TLS-соединения между клиентом и серверами Cloudflare. Полный текст статьи можно почитать в их блоге.

Воркеры выполняются на edge-серверах, которые находятся ближе всего к пользователям, тем самым уменьшая задержку и разгружая origin‑сервер (в нашем случае WordPress backend). По аналогии с другими cloud-провайдерами, код внутри Workers Runtime может использовать другие сервисы Cloudflare, такие как:

• Cache API - позволяет читать и записывать данные в глобальный edge‑кэш через caches.default, что удобно для кэширования GraphQL‑ответов или страниц Next.js.
• Workers KV - распределенное key‑value‑хранилище для конфигурации и небольших наборов данных; можно хранить и получать данные глобально с низкой задержкой.
• Cron Triggers - можно сопоставить cron‑выражение с обработчиком scheduled(), чтобы запускать периодические задачи, например, уборку кэша или обновление данных. Триггеры выполняются на малоиспользуемых машинах, максимизируя эффективность.

Наличие доступа к дополнительным сервисам, таким как базы данных (D1), объектное хранилище (R2), очереди и AI даёт свободу строить более сложные и гибкие архитектуры, что очень полезно в дальнейшем на больших масштабах.

OpenNext: мост между Next.js и Cloudflare

Самостоятельный деплой Next.js на разные платформы непрост, поскольку среда исполнения Vercel отличается от других. Можно поднять Next.js на Node‑сервере, но его работа отличается от edge‑режима Vercel. OpenNext - это проект с открытым исходным кодом, который адаптирует Next.js для разных серверлесс‑платформ. Важно сказать что у Next.js нет нативного способа само разворачивания на других платформах, кроме Vercel; существующие отдельные адаптеры разрознены и сложны в поддержке. OpenNext объединяет усилия в одном адаптере, переводя выход сборки Next.js в формат, совместимый с основными облачными платформами. Проект поддерживают сообщество SST (AWS), команда Cloudflare и Netlify. Соответственно, с помощью OpenNext можно развернуть Next.js на Cloudflare Workers, сохраняя SSR, статическую генерацию и API‑маршруты.

Cloudflare‑адаптер устанавливается через @opennextjs/cloudflare. Далее следует установить Wrangler, настроить wrangler.toml с вашим Account ID и создать open-next.config.ts для управления кэшем и ассетами. Адаптер собирает приложение Next.js под среду Cloudflare, создает edge‑воркер и конфигурирует кэш для статики и ISR‑страниц (например, используя R2). После публикации Git‑интеграция Cloudflare автоматически разворачивает приложение при каждом пуше в GitHub или GitLab, а для pull‑request создает превью.

Кэширование и уровни производительности

Архитектура headless WordPress + Next.js + Cloudflare обычно включает несколько уровней кэша:

1. Кэш браузера - стандартный HTTP‑кэш на стороне клиента.
2. Кэш edge‑рантайма - Cache API Cloudflare Workers сохраняет HTML‑страницы или GraphQL‑ответы рядом с пользователем; при попадании в кэш контент отдаётся мгновенно, а промахи идут к воркеру или origin.
3. Кэш ISR Next.js - технология Incremental Static Regeneration сохраняет отрендеренные страницы на сервере и обновляет их по запросу, снижая нагрузку на WordPress API.
4. Кэш GraphQL - API WPGraphQL может реализовывать кэширование по времени или тегам (например, через WPGraphQL Smart Cache), чтобы управлять сроком жизни ответов.

Эта многоуровневая иерархия кэша обеспечивает, что большинство запросов вообще не доходят до вашего WordPress‑сервера, повышая производительность и снижая нагрузку.

Пример конечной архитектуры показан на изображении ниже.

Автоматизация периодических задач

Headless‑сайтам часто требуются периодические действия - например, обновление кэша ISR или синхронизация данных. Cron Triggers Cloudflare позволяют планировать запуск воркера по cron‑выражению. Обработчик scheduled() срабатывает по расписанию и подходит для обслуживания и получения сторонних данных. Триггеры выполняются на малоиспользуемых машинах по всему миру и легко управляются через Wrangler или панель Cloudflare.

Модернизация PHP‑стека с Roots toolkit

Хотя headless WordPress переносит рендеринг на JavaScript, CMS всё ещё нужно поддерживать. В качестве бонуса хочется порекомендовать экосистему Roots, которая предлагает современный инструментарий для разработки на WordPress:

• Bedrock - шаблон WordPress, которая устанавливает ядро, плагины и темы через Composer. Таким образом Bedrock дает современную для PHP проектов структуру проекта, улучшает структуру папок, использует концепты Двенадцать факторов для конфигурации приложения с помощью .env‑файлы и тд. Более того, управление зависимостями через Composer повышает надежность и позволяет делать деплой приложения на разные сервера без страха что-то забыть или упустить.
• Sage - стартовая тема WordPress, использующая Blade от Laravel для шаблонов и интегрирующая Tailwind CSS. Sage автоматически генерирует theme.json из конфигурации Tailwind, поддерживает live preview блокового редактора с Vite и позволяет создавать компоненты на Blade. Это помогает фронтенд‑разработчикам отойти от устаревших подходов для разработки тем Wordpress с нуля.
• Trellis - DevOps‑инструмент на базе Ansible, который поднимает серверы и автоматизирует деплой. Trellis предоставляет LEMP‑стек (Ubuntu 24.04, Nginx, PHP 8.3, MariaDB), выполняет деплой без downtimes и из коробки поддерживает SSL‑сертификаты. CLI помогает создавать и настраивать серверы, а также разворачивать проекты с атомарными релизами и откатами.
• Acorn - интеграция, позволяющая использовать функционал Laravel в WordPress. С Acorn становятся доступны такие инструменты как Blade‑шаблоны, миграции, роутинг, кэширование и Artisan‑подобный CLI внутри WordPress. Это позволяет разработчикам строить плагины и фичи WordPress с использованием современных PHP‑подходов и современного фреймворка .

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

Собираем всё вместе

Архитектура приложения headless WordPress + Next.js + Cloudflare выглядит приблизительно так:

1. WordPress (headless) - работает на традиционном сервере или в контейнере. Редакторы управляют контентом в админке. WPGraphQL и его расширения предоставляют GraphQL‑endpoint с данными, SEO и другой информацией, например данными о магазине.
2. Next.js фронтенд - React‑приложение, которое получает данные через GraphQL, рендерит страницы на сервере (SSR) или статически (ISR/SSG) и обрабатывает маршрутизацию и взаимодействие с клиентом. Код хранится в Git и автоматически разворачивается благодаря Git‑интеграции Cloudflare.
3. Cloudflare Workers - размещают приложение Next.js на edge через OpenNext. Workers исключают cold-starts и работают по аналогии с CDN как можно ближе к пользователю. Они также выполняют кэширование, обрабатывают API‑маршруты и запускают cron‑задачи.
4. Кэш на edge и в браузере - несколько уровней кэша гарантируют быструю отдачу статики и отрендеренных страниц. KV, R2 или D1 могут хранить дополнительные данные вроде сессий или объектов.

Заключение

Headless‑архитектура объединяет универсальность WordPress и гибкость современных JavaScript‑фреймворков. Экспонируя контент через WPGraphQL и потребляя его в Next.js, можно получить больше контроля над рендерингом и тем самым улучшить производительность. Размещение фронтенда на Cloudflare Workers через OpenNext позволяет приблизить фронтенд код к пользователям, устраняет cold-starts, позволяет использовать free-tier и продвинутые уровни кэширования. Инструменты вроде Bedrock, Sage, Trellis и Acorn модернизируют PHP/Wordpress‑сторону и делают CMS такой же удобной в работе, как и современный Next.js/React-фронтенд. Вместе эти технологии создают мощный стек для создания быстрых, масштабируемых и безопасных сайтов, будь то хакатон, pet‑проект или серьёзный продакшн.

Новые фичи, интеграции, поддержка Kubernetes и облаков сделали продукт мощнее... и заметно тяжелее. Это стало проблемой для serverless, IoT и контейнеров.

Вместо того чтобы урезать функциональность, команда решила «переломить кривую роста». За полгода (v7.60.0 → v7.68.0) им удалось сократить размер Go-бинарников до 77%.

Аудит зависимостей: минус 36 МБ одной правкой

Первый шаг — полный разбор зависимостей. С помощью go list, goda и go-size-analyzer разработчики искали пакеты, которые подтягиваются в бинарник случайно.

В одном случае trace-agent тащил 526 пакетов Kubernetes из-за одной функции, которая фактически не использовала k8s-код. Перенос ее в отдельный пакет позволил компилятору выбросить все лишнее — минус 36 МБ.

И таких случаев нашли десятки.

Разблокировка «скрытой» оптимизации линкера

Вторая находка дала еще ~20% выигрыша. В Go есть оптимизация method dead code elimination, но она отключается, если используется reflect.MethodByName с динамическими именами (например, в text/template).

Команда нашла проблемные вызовы через -dumpdep и утилиту whydeadcode, пропатчила зависимости и даже форкнула text/template, чтобы отключить динамические вызовы методов. Результат — еще минус около 100 МБ.

Удаление plugin = минус 245 МБ

Самый неожиданный эффект дал пакет plugin. Его импорт заставлял линкер сохранять все методы типов, отключая оптимизацию.

Выяснилось, что зависимость приходила через containerd, хотя агент ее не использовал. После добавления build-тега и обновления зависимостей, основной Linux amd64-бинарник «похудел» на 245 МБ.

Итог

• Security Agent: −77%
• Process Agent: −74%
• Trace Agent: −74%
• Общий .deb: 1,22 ГБ → 688 МБ

И главное — все это без удаления функций. Только системная чистка зависимостей, грамотные build-теги и возвращение оптимизаций линкера.

Мы собрали пять инструментов, которые решают конкретные задачи: от генерации презентаций до работы с кодом и аналитикой. Их стоит протестировать, если вы ещё этого не сделали. Давайте разбираться, что каждый из них умеет делать и для кого они вообще созданы.

1. Сократик — генерация презентаций через нейросеть

Сократик — веб-сервис, который собирает презентации автоматически. Вы загружаете текст, документ или таблицу, задаёте тему и параметры — ИИ формирует структуру, пишет текст для слайдов, подбирает изображения и оформляет всё в выбранном стиле.

Под капотом работают LLM-модели для текста и диффузионные модели для генерации графики. Сервис умеет анализировать загруженные данные: парсит таблицы, вытаскивает ключевые тезисы из документов, даже подтягивает информацию из других презентаций.

Для кого и какие сценарии

Изначально Сократик ориентировался на образование — студентов, школьников, преподавателей, которым нужно быстро структурировать материал и упаковать его в визуал. Но на практике сервис зашёл и в корпоративный сегмент.

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

Как это работает

Процесс состоит из трёх этапов: настройка параметров, редактирование структуры и генерация финальной презентации.

На первом этапе вы выбираете количество слайдов, язык (русский, английский, немецкий, французский, испанский, польский, казахский, узбекский), аудиторию и тональность. Можно загрузить исходники — текстовые документы, PDF, таблицы, картинки или другие презентации в PPTX. Сервис их распарсит и использует как базу для контента.

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

Третий этап — генерация. Занимает 1–2 минуты. Сервис создаёт не только текст и картинки, но и таблицы, графики, инфографику. Всё автоматически подстраивается под выбранный дизайн.

После генерации открывается встроенный редактор, где можно вручную доработать слайды: поменять текст, переместить блоки, заменить изображения. Редактор сочетает привычные функции презентационных инструментов с ИИ-правками — например, можно попросить переписать текст слайда или добавить визуал.

По наблюдениям, весь процесс от настройки до готовой презентации занимает 8–10 минут, если вы проверяете структуру и дорабатываете детали. Если генерировать на автомате без правок — уложитесь в 3 минуты.

Что отличает от аналогов

Главное отличие — возможность редактировать структуру до генерации. В большинстве подобных сервисов вы получаете готовый результат и начинаете его переделывать. Здесь вы видите план, корректируете его и только потом запускаете генерацию.

Второй момент — автоматическая генерация таблиц и графиков. Загружаешь данные из Excel, указываешь, что нужно визуализировать, — Сократик строит диаграммы и вставляет их на слайды.

Третья особенность — текст для выступления. Сервис генерирует спикерские заметки на основе готовой презентации.

Технические детали

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

Сервис поддерживает импорт разных форматов: текстовые файлы, PDF, PPTX, таблицы (XLS, XLSX), изображения. Экспорт — в PDF или PPTX. Водяной знак на бесплатном тарифе, но его можно убрать за 149 рублей за презентацию.

Интеграций с внешними платформами нет — Сократик работает автономно. API пока не предоставляется, только веб-интерфейс.

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

Тарифы и как начать

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

Есть два варианта: разовая покупка за 149 рублей (скачиваете одну презентацию) или подписка «Безлимит» — 469 рублей в месяц или 2490 рублей в год. Подписка снимает лимиты на скачивания и убирает водяной знак.

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

Поддержка доступна через чат и почту, документация есть на сайте. В Telegram-канале публикуют разборы функций, подсказки и примеры использования.

2. Войси — транскрибация аудио и видео в Telegram-боте

Войси — Telegram-бот для транскрибации речи из аудио и видео в текст. Загружаете файл, выбираете функцию — бот за пару минут выдаёт расшифровку с метками времени и подписями спикеров. Включён в реестр российского ПО, работает на локальных серверах, данные не уходят за рубеж.

Сервис разбирает разговоры с несколькими голосами, даже если они накладываются друг на друга или есть акценты. Умеет в мультиязычность — если в записи говорят на разных языках, текст сохраняет эти языки. Модели недавно обновили: лучше разбивают абзацы по смыслу, распознают голоса на коротких записях.

Основные сценарии для разработчиков и команд

В разработке Войси заходит как инструмент для фиксации всех разговоров и переботки видео в текст. Записали созвон с клиентом, загрузили в бота — получили точный протокол с таймкодами. Дальше можно выбрать формат текста для анализа или доработки.

В блогинге и подкастинге Войси превращает голосовые заметки в готовые посты или статьи. Короткая запись — короткий пост для соцсетей. Длинное интервью — развёрнутая статья для сайта с автоматическим форматированием.

Полный набор функций на практике

Транскрибация

Базовая расшифровка с разделением по спикерам и таймкодами. Поддерживает 55 языков.

Краткое содержание

ИИ находит главное в записи, структурирует в список тезисов. Полезно для встреч, где полчаса болтовни, а суть в трёх пунктах.

Субтитры

Генерирует SRT-файлы с переводом на 55 языков. Вставляете в видеоредактор — субтитры готовы. Есть LRC для аудиокниг и подкастов с синхронизацией текста по времени.

Книжный стиль

Очищает текст от "эээ", повторов, разговорных оборотов. Получается текст, готовый к публикации.

Перевод

С 54 языков на русский в литературном формате. Не дословно, а с сохранением смысла.

Пост для блога

Из аудио делает короткий пост или полную статью. Короткие голосовые — для Telegram, длинные подкасты — для Tproger или VC.

Викторина

Генерирует тесты по содержимому записи. Из лекции — квиз для студентов, из фильма — развлекательная викторина.

После обработки бот предлагает интерактивную веб-версию: синхронный плеер с текстом, редактор, эмоциональная окраска речи. Можно подписать спикеров вручную, убрать таймкоды, скачать чистый текст в PDF/DOCX/TXT. Редактирование сохраняется, доступно по паролю.

Технические детали и ограничения

Работает только через Telegram-бот, веб-версии для редактирования хватает. Файлы до нескольких часов обрабатываются за минуты (10 часов быстрой обработки в месяц на тарифе). Поддерживает все популярные форматы аудио/видео.

Интеграции: есть API для транскрибации, саммаризации и перевода — документация на voicee.ru/api-transkribacii. Плюс готовые связки с amoCRM для анализа звонков. Разработчики могут встраивать в свои пайплайны.

Тарифы и как начать

Оплата по балансу по времени обработки. Пополняете — используете, бот сам считает, сколько нужно.

• Войси Лайт: 990 ₽/мес — 10 часов быстрой обработки + безлимит в очереди.
• Полная версия: почасовая, скидки для студентов/пенсионеров (250 ₽/час), бонусы за рефералов.

Баланс не сгорает. Есть YouTube-канал с примерами (@voicee_ru) и Telegram-канал (@voice_of_voicee) с разборками. Поддержка через @Voicee_Buddy.

3. GigaCode — ИИ-ассистент разработчика с агентным режимом

GigaCode — российский ИИ-ассистент для разработчиков, который работает прямо в IDE. Поддерживает GigaIDE Desktop, JetBrains IDE и другие инструменты. Работает на собственной серверной инфраструктуре без зависимости от сторонних решений.​

Основное отличие от классических code completion инструментов — агентный режим. Ассистент не просто дописывает код, а понимает контекст проекта и выполняет задачи от анализа до готового решения. Находит и открывает нужные файлы, вносит изменения, запускает тесты, собирает проекты и оформляет коммиты в Git.​

Режимы работы

Line completion — однострочные подсказки для быстрого дописывания кода. Работает на повторяющихся и шаблонных конструкциях: импорты, стандартные паттерны, типовые операции.

Full-function completion — многострочные подсказки, которые завершают функцию целиком или её часть. Убирает эффект «чистого листа», когда сидишь и думаешь, как начать. Пишешь сигнатуру функции, ассистент предлагает реализацию на основе контекста проекта.​

Агентный режим — полноценный помощник, который выполняет задачи автономно. Даёте описание задачи — он анализирует проект, находит нужные файлы, вносит изменения, проверяет через тесты, коммитит результат.

Поддерживаемые языки

Работает с 35+ языками программирования: ABAP, C, C++, C#, Clojure, CoffeeScript, CSS, CUDA, Dart, Dockerfile, Erlang, Go, Groovy, HTML, Java, JavaScript, Julia, JSON, Kotlin, Lua, PHP, Pascal, Python, Perl, Ruby, Rust, Scala, Shell, SQL, Swift, TypeScript, TSX, VB, Vue, YAML и другие.​

Это покрывает практически весь стек современной разработки — от фронтенда на TypeScript и Vue до бэкенда на Go или Java, конфигурационные файлы вроде Dockerfile и YAML, скрипты на Shell и Python.​

Сценарии использования

• Для джунов и мидлов: снижает порог входа в новые области. Попал в незнакомый проект на Kotlin — ассистент подсказывает идиоматичные конструкции, стандартные подходы, помогает разобраться в структуре кодовой базы.​
• Для джунов и мидлов: снижает порог входа в новые области. Попал в незнакомый проект на Kotlin — ассистент подсказывает идиоматичные конструкции, стандартные подходы, помогает разобраться в структуре кодовой базы.
• Для команд: ускорение общего процесса разработки. Когда у тебя 20 микросервисов и нужно обновить версию библиотеки во всех, агентный режим проходит по репозиториям, вносит изменения, проверяет через тесты.

Интеграция с рабочим процессом

GigaCode встраивается в привычные IDE через плагины. Работает с GigaIDE Desktop (собственная IDE от GitVerse) и JetBrains IDE (IntelliJ IDEA, PyCharm, WebStorm, GoLand и другие). Поддержка других инструментов разработки тоже есть.​

Агентный режим взаимодействует с Git: оформляет коммиты с осмысленными сообщениями и создаёт ветки. Запускает тесты и собирает проекты через CI/CD.

4. Kodify 2 — ещё один ИИ-инструмент для генерации кода

Kodify — российский ИИ-инструмент для генерации и автодополнения кода от МТС AI. Существует в двух версиях: Kodify 2 — полноценный on-premise сервис для корпоративной разработки, и Kodify Nano — опенсорсная модель на 1,5 миллиарда параметров, которую можно развернуть локально.​

Kodify 2 работает как сервис, готовый к использованию сразу после установки. Интегрируется с популярными IDE, разворачивается в контуре компании. Kodify Nano — облегчённая версия для разработчиков, которым не нужна корпоративная инфраструктура: генерирует код, unit-тесты и документацию, не требует мощного железа.​

Основные возможности

• Генерация и автодополнение кода: модель создаёт код по текстовому описанию, анализирует текущие задачи, код до и после выбранного фрагмента, предлагает релевантное решение. Функции автодополнения, подсказки параметров и автоформатирования ускоряют процесс разработки.​
• Анализ и оптимизация: рефакторинг, автоматические тесты, поиск ошибок и документирование помогают быстрее находить и устранять дефекты. Можно запустить проверку кодовой базы, получить список проблемных участков с предложениями по исправлению.​
• Многоязычная поддержка: 90 языков программирования, включая Python, Java, JavaScript, C#, Go и другие. Может переводить код с одного языка на другой — полезно при миграции проектов или портировании библиотек.​

Сценарии использования

Разработка продуктов: автоматизация разработки, рефакторинг, оптимизация кода и поиск ошибок, перевод на другие языки программирования. Если у вас легаси на Java и нужно портировать модуль на Go, Kodify переведёт код с сохранением логики.​

Разработка игр: генерация кода для игровых движков, создание игровой логики. Подходит для скриптинга в Unity или Unreal, когда нужно быстро набросать механики или AI-поведение NPC.​

Веб-разработка: генерация кода для фронтенда и бэкенда сайтов и приложений. Пишешь API-эндпоинт на Python — Kodify предложит реализацию с валидацией, обработкой ошибок и документацией.​

Кибербезопасность: анализ уязвимостей, тестирование защиты данных. Можно прогнать код через модель, получить список потенциальных проблем с безопасностью — SQL-инъекции, XSS, небезопасные зависимости.​

Системное администрирование: автоматизация задач DevOps, настройка серверов с помощью генерируемого кода. Пишешь описание инфраструктуры — Kodify генерирует Ansible playbook или Terraform конфиг.​

Kodify Nano — опенсорсная версия

Kodify Nano — модель на 1,5 миллиарда параметров, доступная для локальной установки. Не предъявляет высоких требований к железу, работает на обычном ноутбуке. Генерирует код, unit-тесты и документацию.​

Доступна как плагин для JetBrains IDEs — IntelliJ IDEA, PyCharm, WebStorm, GoLand. Есть версии для macOS, Windows и Linux. Инсталляция и настройка описаны в инструкции пользователя.​

Разница между Nano и полной версией: Nano работает офлайн, не требует серверной инфраструктуры, но уступает в точности и контекстном понимании больших проектов. Kodify 2 разворачивается на серверах компании, обрабатывает более сложные сценарии, поддерживает корпоративные интеграции.​

Интеграция и развёртывание

Kodify 2 готов к использованию сразу после установки. Интегрируется с популярными средами разработки, разворачивается в контуре компании. Это снимает вопрос утечки кода — всё остаётся внутри периметра.​

Для on-premise установки доступна полная документация: руководство администратора, руководство пользователя, описание жизненного цикла, инструкция по установке и эксплуатации, описание функциональных характеристик.​

Демо и тестирование

На сайте mts.ai доступна демо-версия: можно сгенерировать код на Python или Java, протестировать функцию подсказок и автодополнения. Остальной функционал тестируется по заявке — заполняешь форму обратной связи, получаешь доступ к полной версии.​

5. APIHOST — агрегатор ИИ-сервисов для повседневных задач

APIHOST — российская платформа, которая собирает несколько ИИ-сервисов в одном месте. Работает как веб-приложение, не требует установки. Объединяет синтез речи, транскрибацию, генерацию изображений, клонирование голоса, текстовые модели и утилиты для работы с медиа.​

Всё работает через веб-интерфейс, есть Telegram-бот для генерации изображений.​

Основные сервисы

• Озвучка текста: уникальный синтез речи с выбором голосов, языка озвучки, настройкой высоты и эмоциональной окраски. Поддерживает русский, английский и другие языки. Можно загрузить текст напрямую, вставить ссылку на YouTube или записать голосом. Стоимость считается по символам — в интерфейсе видишь, сколько стоит озвучка до отправки запроса.​
• Транскрибация (звук в текст): преобразует аудио и видео в текст. Работает с файлами, ссылками на YouTube, записью с микрофона. Подходит для расшифровки интервью, лекций, подкастов.​
• Клонирование голоса: создаёт уникальный голос на основе загруженных образцов. Два режима — PRO-CLONE и FAST. PRO требует несколько аудиофайлов для качественной генерации, FAST работает быстрее, но менее точно. Перед генерацией система оценивает качество загруженных файлов — показывает оценку по окраске и прерывистости. Если средняя оценка удовлетворительная, можно начинать генерацию, но рекомендуется следовать комментариям возле каждого файла.​
• Запись голоса с микрофона прямо в браузере — максимальная длина записи 11 секунд. Это удобно для быстрого создания образца без отдельных аудиофайлов.​
• Нейросеть, пишущая тексты: текстовая модель V1 с чатом. Вводишь запрос до 4000 символов, получаешь ответ в том же окне. Стоимость запроса — 2 рубля. Есть история запросов с возможностью восстановления старых диалогов и скачивания всей истории.​
• Генератор изображений: создаёт изображения по текстовому описанию. Одна генерация включает 4 фотографии, стоимость — 9 рублей. Описание можно писать на русском. Есть Telegram-бот @MidJourney3g для генерации через мессенджер.​

Утилиты и дополнительные функции

YouTube в Mp3: конвертирует аудио из ссылок на YouTube, TikTok, Facebook, VK, Rutube. Вставляешь ссылку, получаешь аудиофайл. Работает быстро, файлы доступны для скачивания в формате WAV или MP3.​

Изменение голоса и редактор звука: обработка аудиофайлов, настройка высоты, сохранение в новом формате. Можно загрузить файл или записать через диктофон.​

Онлайн радио: встроенный плеер с радиостанциями России. Работает как фоновая функция, если нужен доступ к радио без переключения на другие сервисы.​

Анализ текста: подсчёт символов, слов и других метрик. Полезно для контент-мейкеров, которым нужно соблюдать ограничения по объёму.​

Определение IP-адреса: показывает ваш текущий IP. Простая утилита, доступная в пару кликов.​

Как работает оплата

Система работает по предоплате. Пополняешь баланс, тратишь на запросы — каждый сервис показывает стоимость до выполнения. Озвучка считается по символам (0,02 рубля за 41 символ в примере), генерация изображений — фиксированная цена за пакет из 4 фото (9 рублей), текстовые запросы — 2 рубля.​

API для разработчиков

Платформа предоставляет API для интеграции сервисов в собственные проекты. Документация доступна на сайте. Это позволяет встраивать озвучку, транскрибацию, генерацию изображений в свои приложения без развёртывания отдельной инфраструктуры.

Пять инструментов — пять разных подходов к одной задаче: сделать работу быстрее и избавить от рутины.​​​​​

Сократик помогает с созданием презентаций, когда нужно упаковать сложную информацию в слайды за минуты до созвона с фаунедром. Войси фиксирует всё, что обсуждалось на созвонах, и превращает часовую встречу в структурированный текст. GigaCode и Kodify 2 берут на себя написание кода: первый через агентный режим выполняет задачи от анализа до коммита, второй работает как мощный ассистент с поддержкой 90 языков. APIHOST собирает несколько ИИ-сервисов в одном месте — озвучка, транскрибация, генерация изображений доступны через веб-интерфейс без настройки инфраструктуры.​​​​​

Все решения работают на российских серверах, поддерживают оплату в рублях и не требуют VPN. Большинство предлагают демо-версии или бесплатные тарифы — можете протестировать на реальных задачах до покупки.

Спойлер: мы никого не уволили.

Вместо слепой веры в «волшебную таблетку» мы посчитали реальную стоимость генерации ответов, сравнили её с зарплатами и нашли точку безубыточности. Ниже – цифры, наши архитектурные ошибки и итоговая экономика проекта.

Проблема масштабирования

Специфика SERM (управления репутацией) – это потоковая обработка текста. Представьте клиента с сетью на 50 филиалов, которому ежедневно падает от 100 до 300 отзывов. На каждый нужно ответить уникально, потому что антиспам-фильтры поисковиков банят копипаст.

Раньше мы решали эту задачу линейным расширением штата. Больше отзывов – больше копирайтеров. Но это тупиковый путь: люди на рутине выгорают, Tone of Voice «гуляет», а ФОТ растет быстрее прибыли. Автоматизация через LLM казалась единственным логичным выходом.

Фаза 1. Как мы сжигали бюджет (Naive RAG)

Первая итерация была наивной: мы подключили GPT-4, написали системный промпт с инструкциями («Ты вежливый саппорт...») и начали скармливать модели отзывы.

Экономика рухнула почти сразу. Проблема оказалась в оверхеде на токенах. Для адекватного ответа модели нужен контекст: адреса филиалов, телефоны, условия возврата, скрипты вежливости. Мы передавали этот статический контекст в System Prompt при каждом запросе.

Математика получилась убийственной:

• входящий отзыв – всего 50 токенов
• сгенерированный ответ – около 100 токенов
• но инструкция с правилами компании – 1500 токенов

Мы платили за 1650 токенов, чтобы получить 100 полезных. КПД транзакции составлял ничтожные 6%. На объемах в десятки тысяч запросов ежемесячный счет за API опасно приблизился к зарплате квалифицированного разработчика.

Пример неоптимизированного промпта. Передача статического контекста в каждом запросе убивает экономику.

Вторая проблема – галлюцинации. Без жестких ограничений модель начинала фантазировать. На жалобу об отсутствии парковки AI радостно отвечал: «Приносим извинения! Мы уже строим подземный паркинг, открытие в следующем месяце». Для бизнеса это прямой риск судебного иска за введение потребителя в заблуждение.

Фаза 2. Смена архитектуры

Решение «в лоб» оказалось экономически несостоятельным. Нам пришлось перестраивать процесс и внедрять RAG (Retrieval-Augmented Generation).

Логика изменилась. Вместо того чтобы скармливать нейросети весь устав компании, мы сначала ищем в векторной базе знаний фрагмент, релевантный конкретному отзыву. Если клиент пишет про доставку, в промпт попадает только блок правил о доставке.

Архитектура RAG. Поиск релевантного контекста через Vector DB перед генерацией снижает объем входных токенов.

Переход занял две недели работы бэкенда и потребовал развертывания Vector DB (мы тестировали Pinecone и Milvus). Результат того стоил: System Prompt «похудел» с 1500 до 300 токенов, а стоимость одной транзакции упала в 4 раза.

Unit-экономика: человек vs API

Давайте сравним себестоимость одного ответа в рублях (цены усредненные, включая налоги и инфраструктуру).

1. Ручной труд (Junior-копирайтер). Если сложить зарплату, налоги, стоимость рабочего места и лицензий, один сотрудник обходится компании примерно в 80 000 руб/мес. При средней выработке 70 ответов в день, Cost per Action (CPA) одного ответа составляет ~50 рублей.

2. Гибридная схема (GPT-4o + Оператор). Стоимость токенов (Input + Output) с учетом RAG и затрат на серверы составляет около 3-4 рублей. Но выпускать ответы без проверки нельзя – риск галлюцинаций слишком высок. Поэтому мы ввели роль оператора-валидатора. Один человек с AI-помощником проверяет до 500 ответов в день. Стоимость его работы в пересчете на единицу контента – около 8 рублей. Итоговый CPA: ~12 рублей.

Сравнение стоимости обработки одного отзыва (RUB). Оптимизированный RAG с валидацией дешевле ручного труда на 70+%.

Ограничения технологии

Даже с такой экономикой есть сценарии, где мы сознательно запрещаем использование AI.

Во-первых, это сарказм и скрытая агрессия. LLM до сих пор плохо считывают контекст вроде: «Доставка – просто ракета, ждал всего три недели». Модель реагирует на слова-триггеры («ракета», «спасибо») и выдает: «Мы рады, что вы оценили скорость!». Для репутации бренда это катастрофа. Sentiment analysis помогает, но не дает 100% гарантии, поэтому такие отзывы фильтруются и уходят на ручную обработку.

Во-вторых, юридические риски. Любые досудебные претензии, угрозы жалобами в госорганы или требования компенсаций – это зона ответственности юристов. Риск автоматического ответа здесь превышает любую потенциальную экономию.

Итог

Внедрение AI в процессы агентства оказалось задачей не творческой, а сугубо математической.

Мы трансформировали роли: перестали нанимать джунов для написания текстов, а текущих сотрудников переквалифицировали в операторов-валидаторов. Их выработка выросла кратно, как и зарплата.

Главный вывод: без правильной архитектуры (RAG) и токеномики использование мощных моделей убыточно. Себестоимость производства контента у нас снизилась на 70%, но расходы на API и облачную инфраструктуру стали второй по величине статьей бюджета после ФОТ. И это тот компромисс, который выгоден бизнесу.

На российском рынке доступно несколько инструментов, которые решают эти и многие другие задачи, связанные с администрированием PostgreSQL-инфраструктуры. Каждый — со своими функциональными и архитектурными особенностями.

1. Платформа Tantor

Платформа Tantor позволяет осуществлять управление, администрирование и мониторинг множества корпоративных баз данных на PostgreSQL и любых его форках (Tantor Postgres, PostgresPro, Pangolin и других). Объединяет в одном интерфейсе инструменты для конфигурирования, обслуживания, профилирования запросов и работы с кластерами Patroni. Все функции доступны из браузера без установки дополнительного ПО на рабочее место администратора. Продвинутая система алертов (оповещений) в платформе Tantor автоматически отслеживает метрики и уведомляет администраторов о потенциальных проблемах, позволяя максимально быстро на них реагировать.

Для кого это работает

• DBA используют платформу как центр управления всеми PostgreSQL-инстансами: мониторят нагрузку, блокировки и репликацию, настраивают параметры через группы конфигураций, планируют регламентные работы.
• SRE и дежурные инженеры следят за дашбордами по доступности кластеров, работают с алертами на превышение порогов по времени ответа или лагу репликации. При инцидентах используют алерты и алгоритмический ассистент для расшифровки ошибок и базовой диагностики.​
• Разработчики заходят эпизодически — посмотреть профиль нагрузки своих сервисов, разобрать планы выполнения проблемных запросов или получить SQL-выборку по описанию на естественном языке через алгоритмический ассистент.​
• Команды безопасности настраивают маскирование конфиденциальных данных для тестовых контуров и проверяют аудит действий пользователей.

Алерты (оповещения)

• Непрерывный мониторинг: агенты платформы постоянно собирают метрики (например, загрузку процессора, состояние процессов БД) и анализируют эти данные на предмет аномалий. Можно редактировать условия срабатывания. Например, система может автоматически создать алерт, если загрузка процессора сервера БД долгое время превышает 80%, а при сбое в отказоустойчивом Patroni-кластере алерт мгновенно уведомит администратора о необходимости вмешательства. Также если запланированная задача (например, резервное копирование) не выполнилась или завершилась с ошибкой, в интерфейсе появится соответствующее уведомление.
• Классификация по критичности: алерты имеют цветовую индикацию: красный — высокая критичность, желтый — предупреждение. Все алерты отображаются в едином интерфейсе (меню «колокольчик»), где их можно фильтровать, сортировать и просматривать детали.
• Внешние уведомления: интеграции позволяют направлять алерты в Telegram, электронную почту, Mattermost. Алерты разного уровня критичности можно направлять в разные каналы.
• Анализ и история: для каждого алерта доступны детали (метрики, хост), связанные события и полный журнал изменений (Events Log).

Управление Patroni-кластерами

Платформа визуализирует топологию кластера: кто лидер, кто реплика, какой lag, статус health. Плановый switchover выполняется из интерфейса без ручных команд. Если одна из реплик отстаёт или упала, система фиксирует это на дашборде и отправляет алерт.

Профилирование и оптимизация запросов

Query Profiler на базе pg_stat_statements собирает статистику по запросам на выбранном промежутке времени. Группирует их, показывает время выполнения, количество вызовов, детализацию по каждому.

Для «тяжелых» запросов формирует визуализацию планов и рекомендации по оптимизации — добавить индекс, переписать join, изменить параметры планировщика.

Конфигурирование СУБД под разные профили нагрузки

Платформа Tantor позволяет из одной точки управлять конфигурациями кластеров и инстансов. Кроме этого, у пользователя есть возможность создать типовые профили нагрузки, например 1С или BI-платформу, автоматизированную банковскую систему или иные ресурсоемкие бизнес-приложения. Это позволяет более тонко управлять имеющимися ресурсами хранения данных и их вычисления за счет возможности сконфигурировать сразу большую группу инстансов одной конфигурацией с помощью групповых параметров.

Анонимизация данных

Модуль на основе pg_anon ищет конфиденциальную информацию в таблицах и создаёт анонимизированные дампы. Настраиваются правила маскирования для конкретных полей, после чего формируется выгрузка или копия базы для передачи разработчикам. Данные остаются репрезентативными по объёму и структуре, но без реальных значений.

Планировщик и автоматизация

Создание задач для выполнения SQL-скриптов или команд ОС по расписанию или с указанием периодичности. Подходит для регламентных работ — vacuum, analyze, проверка bloat, архивирование логов. История выполнения и результаты сохраняются в интерфейсе.​

Лог-аналитика

Платформа собирает и хранит логи СУБД с возможностью поиска по тексту, пользователям, объектам БД и кодам ошибок. При разборе инцидентов это позволяет связать проблемы на уровне приложения с реальными событиями в базе без grep по десяткам файлов.

Алгоритмический ассистент

Взаимодействует с метаданными БД, логами, оптимизатором запросов и метриками. Выполняет семантический поиск, классифицирует данные, генерирует SQL по текстовому описанию, предлагает оптимизации и помогает интерпретировать планы выполнения.

Технические детали

• Веб-интерфейс, доступный из браузера на любой ОС.
• Развёртывание on-premise через docker-compose на Linux (включая Astra Linux).
• Поддержка всех версий PostgreSQL и коммерческих форков.
• REST API для экспорта метрик и выборок данных.
• Интеграция с SIEM через syslog, с мессенджерами (Telegram, Mattermost) и почтой.
• Ролевая модель доступа, рабочие пространства, журнал событий.​

Лицензирование

Коммерческая лицензия по количеству серверных ядер обслуживаемых (наблюдаемых ) СУБД. Бесплатная полнофункциональная версия работает до 180 дней. Включена в Единый реестр российского ПО (запись 12905).

Поддержка

Документация полностью на русском языке, есть обучающие материалы на YouTube, Rutube и VK. Компания проводит вендорские курсы и сертификацию через авторизованные учебные центры. Для корпоративных клиентов доступна техподдержка 24/7 с SLA от 2 часов в зависимости от критичности запроса.

2. Platform V Kintsugi

Инструмент для мониторинга и сопровождения СУБД, основанных на PostgreSQL, который позволяет обслуживать тысячи баз данных и выполнять задачи администрирования в едином интерфейсе. Продукт зарегистрирован в Едином реестре российских программ и позиционируется как альтернатива Oracle Enterprise Manager Cloud Control.

Для кого это работает

Platform V Kintsugi также подходит для компаний, которые ищут замену инструментам мониторинга иностранных вендоров. Решение масштабируется от среднего бизнеса с небольшими объёмами баз данных до крупных компаний с высоконагруженными системами — продукт выдерживает промышленные нагрузки Сбера.

Централизованное наблюдение

Оперативный центр даёт возможность получать информацию о состоянии множества СУБД в одном окне. Предустановлены панели мониторинга с основными метриками, есть опция добавления собственных метрик мониторинга.

В оперативном центре можно отслеживать события БД практически в режиме реального времени, чтобы контролировать инциденты до их эскалации.

Работа с экземплярами БД

Обзорная панель СУБД проводит постоянный мониторинг экземпляров и отправляет важную информацию о статусе баз данных в одном месте. Функциональность решения ускоряет обслуживание инфраструктуры и автоматизирует повторяющиеся задачи по сопровождению СУБД.

SQL-интерфейс с аудитом

Безопасный терминал для выполнения запросов оснащен функцией аудита действий пользователя, что повышает уровень безопасности при работе с данными. Решение соответствует стандартам защищённости в каждой функциональной части и гарантируют безопасность при работе с критической инфраструктурой.

Анализ производительности

История активности сессий помогает оптимизировать производительность любой PostgreSQL-подобной СУБД без необходимости использования дополнительного программного обеспечения. В интерфейс продукта интегрированы отчёты pg_profile. Решение помогает анализировать и проводить диагностики без влияния на производительность СУБД.

Визуализация и оптимизация запросов

Понятная визуализация планов для подробного анализа пользовательских запросов, чтобы улучшить понимание и оптимизацию выполнения. Инструмент собирает и обрабатывает метрики баз данных и находит узкие места в работе системы.

Лицензирование

Продукт зарегистрирован в Едином реестре российских программ для ЭВМ и баз данных. Реестровая запись: №18302 от 12.07.2023.

Особенности архитектуры

Инструмент оснащен изменяемой информационной моделью и широким интеграционным слоем. Совместим с 80+ решениями Platform V. Встроена поддержка отечественной СУБД Platform V Pangolin DB для высоконагруженных систем, при этом поддерживается работа с любыми PostgreSQL-like СУБД. Документацию можно изучить здесь.

3. Postgres Pro Enterprise Manager

PPEM — графическая платформа для управления базами данных Postgres Pro через веб-интерфейс. Инструмент обеспечивает мониторинг, диагностику и управление множеством экземпляров Postgres Pro в рамках собственной инфраструктуры.​

Снижение порога входа

Понятная структура интерфейса, визуализация данных и подробная информация о статусе операций снижают порог вхождения в администрирование СУБД. Для выполнения рутинных операций не требуется знать команды SQL. Автоматизация задач, визуализация метрик и планов запросов, интеграция с pgpro_pwr и pg_probackup ускоряют работу и упрощают анализ производительности.​

Централизованный дашборд

На главном дашборде отображается основная информация о базах данных, подключённых к PPEM: общий размер, последние сообщения из журналов, статус выполнения задач. Обеспечивается постоянный контроль в режиме реального времени 24/7.​

Управление экземплярами

Раздел «Экземпляры» показывает список всех подключённых баз данных с основной информацией: версия PostgreSQL, каталог данных, порт, сервер, роль (standalone), количество баз данных, транзакций в секунду, соединений. Доступны базовые действия: остановка, запуск, резервное копирование, настройки. PPEM работает с любой редакцией Postgres Pro.​

Инструмент поддерживает автоматическое обнаружение экземпляров в сети (autodiscovery-режим), что сокращает время подключения новых баз и упрощает масштабирование.​

Мониторинг и диагностика

Для каждого экземпляра доступны графики ключевых метрик производительности, информация по сеансам БД и событиям ожидания, выполняющимся SQL-запросам. Можно просматривать и редактировать параметры экземпляра. Есть возможность добавлять собственные показатели производительности и адаптировать мониторинг под особенности инфраструктуры.​

Работа с базами данных

Список баз данных предоставляет детальную информацию: объём, количество таблиц и индексов, bloat (коэффициент распухания), wraparound (предупреждение о зацикливании счётчика транзакций). Это помогает выявлять узкие места и реагировать до появления проблем.​

Интеграция с pgpro_pwr

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

Управление табличными пространствами

Возможность создания, редактирования и удаления Tablespace. При создании табличного пространства настраиваются параметры: название, каталог, владелец, seq_page_cost, random_page_cost, effective_io_concurrency, maintenance_io_concurrency, compression.​

Резервное копирование и восстановление

Интеграция с pg_probackup позволяет настраивать резервное копирование по расписанию и восстанавливать данные за несколько кликов. В интерфейсе отображается список резервных копий с информацией: ID, размер, начало и окончание выполнения, режим (FULL), хранилище, экземпляр, статус, пользователь, статус валидации, начало и окончание валидации. Можно посмотреть детальный журнал выполнения или вызвать форму восстановления из выбранной резервной копии.​

Планирование и автоматизация

Настройка расписаний для обслуживания базы: вакуум, анализ, реиндексация и другие операции. Все процессы прозрачны — в консоли заданий видны статус, длительность и результат выполнения. Это ускоряет обслуживание инфраструктуры и автоматизирует рутинные повторяющиеся задачи.​

Журнал событий

Графический интерфейс к журналу событий экземпляра БД с возможностями выбора временнóго интервала, фильтрации и текстового поиска. Журнал показывает детали каждого события: дата, время, экземпляр, пользователь, база данных, тип, сообщение.​

Управление доступом

Система ролей и встроенная аутентификация позволяют точно настроить права доступа. Гибкое распределение ролей помогает ограничить доступ к важным данным и избежать случайных ошибок. Все действия — от задач до изменений в конфигурации — фиксируются в истории. Можно интегрировать PPEM с LDAP для централизованной аутентификации.​

Лицензирование

Postgres Pro Enterprise Manager входит в состав всех редакций Postgres Pro и не имеет ограничений на количество ядер процессора или сервера и количества пользователей. Регистрация (№104 в Едином реестре российского ПО).

Особенности развёртывания

PPEM не требует внедрения сторонних решений — всё в одном инструменте, без дополнительных затрат и рисков. Можно развернуть в изолированной среде без доступа в интернет. Интуитивно понятная структура, ролевая модель доступа, встроенная история действий и консоль заданий обеспечивают удобную и безопасную работу с БД.

В результате

Если у вас уже есть коммерческая СУБД одного из российских вендоров, то вы вместе с ней в комплекте скорее всего получили и графическую платформу управления БД. Но если текущая платформа вас не устраивает, то можете выбрать из обзора.

База VPIC от National Highway Traffic Safety Administration весила 1,5 ГБ. Для серверов это нормально, но для браузеров, edge-платформ и мобильных устройств — почти приговор.

У такой базы целый ворох проблем. От долгого скачивания и съедания чрезмерной памяти, до поломки serverless-запусков и невозможности работать с приложениями, которые должны запускаться «везде».

При этом именно VPIC считается официальным и самым полным источником данных для расшифровки VIN в США.

Анализ вместо «магической оптимизации»

Первое, что сделали разработчики — это разобрали базу по частям. С помощью SQLite-инструментов они посмотрели, какие таблицы реально занимают место.

Оказалось, что почти 850 МБ приходилось на одну таблицу, которая хранила соответствие кодов производителей и модельных годов.

Ключевой вывод: эти данные можно вычислять на лету из других таблиц. Таблицу удалили и база сразу похудела больше чем наполовину.

Дальше команда пошла по тому же пути: не сжимать, а выкидывать лишнее. Из базы убрали шаблоны и справочники, которые нужны регуляторам, но почти никогда не используются в прикладных VIN-декодерах.

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

Следующий шаг — чистка «мертвых» данных. После удаления части таблиц, в базе остались записи, на которые больше никто не ссылался. Их тоже убрали.

Затем команда пересобрала индексы. Оригинальная база оптимизирована под регулярные обновления — ведь государство ее постоянно дополняет. Corgi же использует базу только для чтения.

Это позволило удалить лишние индексы и создать новые, заточенные под самые частые запросы при декодировании VIN.

И финальный штрих — VACUUM, чтобы SQLite физически пересобрал файл без мусора.

Результат: минус гигабайты, плюс скорость

В итоге размер базы сократился с 1,5 ГБ до 64 МБ в несжатом виде. После gzip — всего 21 МБ. При этом декодирование стало даже быстрее: таблицы меньше, индексы точнее, а лишних данных нет.

Оптимизированную базу упаковали в open-source библиотеку Corgi, которая работает офлайн и одинаково подходит для сервера, браузера и edge-окружений.

Почему релиз Node.js 22 важен

30 апреля 2025 года завершился жизненный цикл версии Node.js 18. Сообщество заранее предупреждало об этом через официальный аккаунт в X. Там напомнили разработчикам о необходимости перейти на более свежие версии — Node.js 20 или 22. Восемнадцатая версия перестала получать патчи безопасности, поэтому обновление стало критичным для поддержания стабильной работы приложений.

Наиболее надёжным вариантом стала миграция на Node.js 22, которая сейчас находится в статусе долгосрочной поддержки (LTS) и гарантирует обновления безопасности и стабильность на ближайшие годы.

Хотя релиз этой версии не выглядел революционным, он существенно изменил основу платформы. Многие возможности, которые раньше требовали внешних библиотек, теперь встроены прямо в платформу: WebSocket-клиент, стабильный fetch(), работа с файлами, Blob и URL, улучшенная совместимость ESM и CommonJS. Это уменьшает количество зависимостей, снижает вероятность уязвимостей и значительно упрощает поддержку проектов.

Помимо удобства разработки, в новой версии усилились производительность и безопасность. Обновлённый движок V8 ускоряет выполнение кода, а оптимизация старта и снижение потребления памяти делают Node.js более стабильным в высоконагруженных и serverless-сценариях. Улучшенная модель разрешений, строгие настройки TLS и расширенная поддержка AbortController повышают защиту на уровне рантайма, ограничивая последствия уязвимостей в сторонних пакетах. Это даёт компаниям возможность строить более надёжные сервисы с меньшими затратами на контроль рисков и эксплуатацию.

Node.js 22 также стал удобнее для работы гибридных команд. Стабильная интеграция ESM и CommonJS облегчает миграцию старых проектов, а унификация Web-API делает код универсальным и понятным даже для сотрудников без глубокого опыта в бэкенде. Улучшенные инструменты тестирования и диагностики повышают прозрачность разработки и снижают время на нахождение ошибок.

Node.js 22 — эволюционный релиз. Он развивает ранее введённые возможности (fetch, ESM, WebSocket и др.), но не переворачивает парадигму разработки. Это укрепление уже заданного курса.

Возможности Node.js 22

Расширение JavaScript и обновление V8. Получив движок V8 12.x, Node.js подтянул все улучшения ECMAScript 2024. Код стал исполняться быстрее как за счёт оптимизаций в компиляторе, так и благодаря улучшенной работе с асинхронностью. Например, async/await теперь обрабатываются эффективнее, а создание структур данных, активно используемых в серверах, стало менее затратным.

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

Corepack включён по умолчанию. До выхода Node.js 22 разработчики сами решали, подключать ли Corepack. Теперь он активен без дополнительной настройки, и это серьёзное изменение в экосистеме. Все менеджеры пакетов контролируются единой прослойкой, что устраняет зависимость от версии, установленной глобально у разработчика или в CI.

На практике это означает, что версия менеджера пакетов становится частью проекта и перестаёт зависеть от среды. Ошибки вида «у меня работает, а у коллеги нет» заметно сокращаются. Благодаря этому процессы разработки и сборки становятся стабильнее.

Corepack, как мне кажется, сильно упростит жизнь большим командам. Исчезает вечная история “а у меня Yarn другой версии” или “Pnpm не подтянулся”. Corepack берёт на себя управление версионированием менеджеров пакетов, а значит, сборки становятся более воспроизводимыми. Для корпоративных проектов это плюс, особенно если речь идёт о распределённых командах или CI/CD-конвейерах.

WebSocket API и улучшенные Web Streams. Node.js 22 внедрил нативную поддержку WebSocket API. Теперь можно создавать WebSocket-клиенты и серверы без сторонних библиотек вроде ws. Это делает код чище и ближе к браузерному API.

Параллельно были улучшены Web Streams. Работа с потоками стала предсказуемой, а инструменты вроде CompressionStream и DecompressionStream функционируют так же, как и в современных браузерах. Поддержка универсального кода — сервер + клиент — стала проще, а объём внешних зависимостей уменьшился.

Улучшения в работе CommonJS и ESM. Node.js постепенно движется в сторону ESM, но у огромного количества проектов всё ещё используется CommonJS. В новой версии улучшена производительность смешанных проектов и сокращены ошибки при импорте модулей между двумя системами. Между ними появилось меньше «подводных камней», а значит миграция на ESM может идти постепенно, без ломки архитектуры.

Стабильный встроенный fetch(). Его реализация теперь полностью совпадает с браузерной, так что в простых кейсах можно отказаться от axios или node-fetch. Меньше зависимостей — быстрее запуск и меньше технического долга.

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

Я бы отметил более зрелую работу с Permission Model. Она уже не экспериментальная и реально помогает ограничивать доступ к файловой системе и сети. Параллельно улучшилась производительность V8, а вместе с ней и общая отзывчивость серверных приложений. Подтянули и Web-стек: стабильнее стали Web Streams, Request/Response и другие API, которые сближают Node с браузерами. Всё это не революция, но тренд на унификацию растёт.

Расширенные возможности тестирования. Node.js продолжает развивать встроенный тестовый фреймворк node:test. Теперь доступны кастомные репортеры, покрытие кода без внешних инструментов и mock timers (замена реальной работы таймеров). Это позволяет использовать встроенный тест-раннер для большинства задач, отказавшись от Jest или Vitest в простых проектах.

Обновления в безопасности. Обновление OpenSSL — одно из самых чувствительных изменений в релизе. Поддержка старых криптоалгоритмов исключена, проверка сертификатов стала строже, а взаимодействие по TLS 1.3 стабильнее.

С точки зрения безопасности рывка не произошло, но заметное движение есть: Permission Model, улучшенная работа с OpenSSL, более аккуратная валидация входящих данных. Всё это снижает риски, но полностью опасность не снимает, потому что реальная безопасность всё равно лежит в архитектуре, процессов CI/CD и культуре разработки.

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

Международные стандарты и локализация. Были обновлены Intl API на базе новой версии ICU. Преимущества: точные часовые пояса, поддержка новых календарей и систем чисел. Это критично для глобальных SaaS-платформ, аналитических сервисов и финтех-продуктов.

По словам Даниила Гоника, для разработчиков наиболее значимы такие изменения, как WebSocket-клиент, модульная система., обновление V8, улучшение JIT-компиляторов, добавление новых возможностей JS и улучшение встроенного test-раннера.

Как безопасно мигрировать на Node.js 22

Переход лучше начинать с аудита и подготовки окружения. Сначала стоит убедиться, что все зависимости поддерживают Node.js 22. Особенно это касается библиотек, которые используют нативные модули, криптографию и WebSockets. Проверка совместимости позволит избежать неожиданностей вроде ошибок компиляции или падений при запуске.

После этого нужно прогнать тесты. Даже минимальный набор позволит выявить проблемы, связанные с изменениями в ESM/CJS, WebSocket API или OpenSSL.

Само обновление среды зависит от выбранного инструмента. Через nvm или n процесс занимает секунды, а для Docker достаточно указать новый базовый образ. Если проект использует CI/CD, стоит уделить внимание Corepack: теперь он активен всегда, что может изменить поведение сборки.

После обновления полезно проверить логи и внимательно изучить предупреждения. Большинство проблем решается установкой последних версий библиотек, иногда — правкой конфигурации TLS или обновлением менеджера пакетов.

Обновление стоит внедрять поэтапно, начиная со staging или частичного продакшена, и держать готовность к откату.

Я обычно советую подход двухконтурного обновления. Сначала поднять проект на 22-ю версию в отдельной среде, включить максимальный объём логов, запустить тесты и прогнать реальные сценарии. Потом обновить линтеры, сборщики и самые старые пакеты, чтобы убрать накопленные за годы предупреждения. И только когда всё стабильно, имеет смысл переключать продакшен. По сути, обновление Node нужно делать так же аккуратно, как обновление облачных сервисов: через изоляцию, наблюдаемость и бэкап-стратегию.

В Node.js 22 удалены некоторые устаревшие, малоиспользуемые функции, поэтому при переходе может потребоваться рефакторинг мест, где они использовались. Следует проверить депрекейты: Node.js 22 помечает ряд старых возможностей как устаревшие и предлагает альтернативы. Необходимо убедиться, что все библиотеки и пакеты, используемые проектом, поддерживают новую версию Node.js.
При скачке сразу с 18/20 на 22 некоторые зависимости могут оказаться несовместимыми с обновлённым движком V8 или новыми APIs — может понадобиться их обновление до последних версий.

Кому стоит подождать с переходом

Переход на Node.js 22 подходит не всем проектам. В некоторых ситуациях разумнее подождать, чтобы избежать регрессий и поломок в продакшене. Вот кому стоит повременить с переходом:

• Тем, кто использует инструменты сборки или менеджеры пакетов, которые ещё не совместимы с Node.js 22 и могут выдавать ошибки или не работать вовсе.​
• Командам, которые работают на старых версиях ОС. Известны проблемы совместимости с macOS 10.14 и ниже, а также возможны ошибки на Windows при миграции старых приложений.​
• Тем, чьи CI/CD, контейнеры или Docker-образцы завязаны на конкретные версии Node.js и npm. Переход на 22-ю версию требует много регрессионного тестирования.​
• Проектам с критически важными C++-добавками. Смена major-версии влечёт за собой обновление бинарных интерфейсов, что может вызывать ошибки при компиляции нативных модулей.
• Пользователям определённых интеграций. Для некоторых версий MongoDB‑драйверов зафиксированы фатальные баги после перехода на конкретные промежуточные версии Node.js 22.x.​
• Если вы используете проекты, которые сами рекомендуют Node.js 18 или 20, а обновление их зависимостей под 22 только планируется.

В продакшене чаще всего проблемы возникают не из-за самих изменений в платформе, а из-за того, как эти изменения проявляются в реальных проектах. Где-то обновился V8 и стал вести себя строже, где-то повылезали deprecated-модули, а где-то просто сломались сборщики или старые зависимости. Многие команды до сих пор живут на Webpack 4, Express 4 или TypeORM старых версий: вот они первыми столкнутся со сложностями.

Что дальше

Среди будущих трендов в экосистеме Node.js Максим Захаренко выделяет следующие: «Первое — постепенное сближение Node с Web-стеком, чтобы код становился максимально универсальным. Второе — рост влияния Bun и Deno, которые будут подталкивать Node к более агрессивной оптимизации. И третье — всё более активная интеграция с AI-инструментами, особенно в DevTools и в цепочках генерации кода».

Всё больше веб-API внедряются в Node.js (fetch, WebSocket, EventTarget). Этот тренд будет продолжаться. ESM становится стандартом, поддержка будет расширяться, CommonJS постепенно уйдёт в прошлое. Расширяется WASI и поддержка WASM-модулей. Node.js движется в сторону мульти-языковой среды. Модель прав доступа и другие sandbox-механизмы также продолжат развиваться. Кроме того, в версии Node.js 22.5.0 экспериментально добавлен встроенный модуль SQLite (через –experimental-sqlite). Это важное уточнение: в релизе 22.0.0 SQLite отсутствовал.

Даниил Гоник хотел бы увидеть в будущих релизах стабильную и удобную модель разрешений, возможность require() для ESM без флагов, улучшения в DevX: поддержка TS «из коробки», больше инструментов в ядре, расширение SEA (Single Executable Apps) и встроенные механизмы верификации зависимостей (подписи, integrity).

Выводы

Node.js 22 делает приложения быстрее, безопаснее и совместимее с Web API, улучшает работу с памятью и снижает зависимость от глобальных инструментов. Хотя переход требует подготовки, он не представляет серьёзных рисков, если следовать базовой процедуре: проверить зависимости, прогнать тесты и обновить среду постепенно. Если инфраструктура современная, а стек устойчивый, переход на Node.js 22 принесёт ощутимые преимущества как в скорости работы, так и в удобстве разработки.

Метрики, KPI и дашборды – это основа деятельности любой компании, претендующей на отлаженность процессов. Особенно в разработке. Там все буквально помешаны на time-to-market и делают ради его достижения все, что только можно, лишь бы вывести продукт на рынок побыстрее. Разве что к бабке-шептунье не ходят. В связи с этим спрашивается: а почему, собственно, точно так же нельзя в облаке, где перерасходы – обычное дело и никто не стремится их устранять? Оказывается, можно.

Что такое Time-to-Optimize

Time-to-Optimize – это временной промежуток между выявлением перерасходов в облаке и их оптимизацией. Она необязательно должна быть полной. Частичная тоже подойдет: уменьшение счетов, высвобождение ресурсов под новые задачи или рост производительности при тех же расходах. Главное, чтобы эти результаты были реальными, а не сводились просто к планам.

Казалось бы, чего тут вообще считать?

Дело в том, что перерасход не фиксируется в тот момент, когда его обнаружили. Он не останавливается на месте, а продолжает нарастать как снежный ком. То есть чем выше ваш TTO, тем больше денег утекает в никуда.

Особенно негативно задержка оптимизации влияет на мультиоблачные среды, когда у каждого провайдера свои правила: свой биллинг, форматы данных, терминология. При такой разносортице попытка свести воедино картину расходов превращается в тот еще квест.

Со своим железом еще сложнее. Там вообще надо учитывать амортизацию оборудования, зарплаты администраторов, затраты на электричество и обслуживание. И все это нужно как-то аккуратно разложить по проектам и командам.

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

Формула расчета Time-to-Optimize

Для расчета Time-to-Optimize есть специальная формула:

TTO = сбор данных + нормализация + аллокация + анализ + внедрение + фиксация результата

А вот что значат эти слагаемые:

• Сбор данных — получение сырых биллинговых отчетов от всех провайдеров.
• Нормализация — приведение данных к единому формату.
• Аллокация — распределение расходов по командам, проектам, cost-центрам (кто сколько потратил и на что).
• Анализ — принятие решений о том, что оптимизировать.
• Внедрение — реализация изменений: выключение VM, смена тарифов, резервирование ресурсов.
• Фиксация результата — подтверждение первых измеримых эффектов.

Опять-таки, на бумаге все выглядит просто. Складываем временные отрезки – получаем итоговое число. Вот только на практике возможны нюансы:

Прежде всего этапы оптимизации могут идти нелинейно. Вы почти наверняка – особенно при первых попытках оптимизации – будете то останавливаться, то возвращаться к предыдущему шагу, возможно, что-то переделывать и пересчитывать. А иногда и вовсе начинать все заново.

Другой важный фактор – это длительность каждого этапа, которая зависит от зрелости процессов. Если собирать данные вручную, это займет неделю. С API-интеграциями – считанные минуты. Согласования – наоборот: в стартапе они проходят за пару часов, а корпорации с двадцатью командами могут затянуться даже на неделю.

Поэтому полезно разделить TTO на уровни:

• Макро-TTO – показывает весь цикл от осознания проблемы до результата, помогает понять общую скорость реакции.
• Микро-TTO – фиксирует длительность отдельных этапов внутри цикла, показывая, как много времени вы тратите на каждый из них.

Так будет проще выявить проблемные места.

TTO как показатель зрелости

Time-to-Optimize – штука универсальная. Он показывает не только скорость оптимизации, но и общий уровень зрелости FinOps в компании. Про сами уровни мы уже рассказывали, а вот как они коррелируют со временем оптимизации:

• Crawl (начальный уровень) – когда все делается руками, а на проблемы реагируем постфактум. TTO измеряется 3-6 неделями.
• Walk (средний уровень) – когда уже есть некая системность, частичная автоматизация и FinOps-команда, пусть даже работающая по совместительству. TTO сокращается до 3-7 дней.
• Run (высший уровень) – когда автоматизировано вообще все, используются специализированные FinOps-платформы, а аллокация достигает 100%. TTO – от нескольких часов до пары дней.

Примеры расчета Time-to-Optimize

Теория теорией, но давайте посмотрим на разницу в результатах в зависимости от уровня зрелости FinOps у одной и той же компании, скажем, с 5 облаками и 10 командами разработки.

Ручной процесс:

• Сбор данных: 5 дней (походы по консолям, скачивание файлов)
• Нормализация: 3 дня (сведение в Excel)
• Распределение: 4 дня (выяснение владельцев, согласования)
• Анализ и решения: 5 дней (встречи, споры, утверждения)
• Внедрение: 2 дня (технические изменения)
• Результаты: 1 день (новый биллинг)

Итого: 20 дней

За это время перерасход продолжает накапливаться, люди отвлекаются от основной работы, и показатели компании падают.

Автоматизированный процесс:

• Сбор данных: минуты (API все подтягивает сам)
• Нормализация: мгновенно (правила уже настроены)
• Распределение: автоматически (теги работают)
• Анализ и решения: 1 день (система выдает готовые рекомендации)
• Внедрение: 1-2 дня (часть изменений применяется сама)
• Результаты: в реальном времени (дашборды показывают изменения)

Итого: 2-3 дня

Разница в десять раз. При этом команды делают то, ради чего их наняли, а не возятся с таблицами.

Что замедляет процесс Time-to-Optimize

Основные факторы замедления TTO

Ну, вообще-то факторов, влияющих на TTO, довольно много. Но вот самые основные:

• Архитектурная сложность: мультиоблако – это в первую очередь многоформатность, с которой нужно уметь грамотно работать.
• Отсутствие автоматизации: когда вся аналитика делается руками в Excel, удивляться большому TTO не приходится.
• Бюрократия: если вы неделю тратите на то, чтобы согласовать отключение одной забытой виртуалки, вас никакие FinOps-платформы не спасут.
• Плохое тегирование ресурсов: от такой базовой вещи зависит очень многое. А с правильно настроенной системой тегов вся информация о владельцах, проектах и окружениях доступна мгновенно.

Польза быстрой оптимизации в FinOps

Зачем торопиться, спросите?

Во-первых, скорость оптимизации напрямую влияет на то, в какую сумму вам обойдется ваша облачная инфраструктура. Если команда тратит лишние 500 тысяч рублей в месяц, при TTO в три недели дополнительный перерасход составит еще 375 тысяч. При TTO в три дня — всего 50 тысяч.

Во-вторых, большой TTO реально ухудшает рабочий климат. Финдир не может сразу понять, что техническая команда работает, а не просто жжет бюджет, а техлид – не верит, что финансисты помогают развитию, а не тормозят его.

В-третьих, если оптимизация происходит быстро, это позволяет высвобождать бюджет под новые инициативы здесь и сейчас, а не на будущий месяц. Отключили по-быстрому неиспользуемые виртуалки – и вот вам средства на разработку новой фичи для приложения. Не отключили? Окно возможностей закрылось, и конкуренты выпустили похожий продукт раньше.

Вывод: в FinOps медленно = плохо.

Что тормозит Time-to-Optimize

Превращать TTO в самоцель – плохая идея. Ну, какой смысл отключать все подряд ради демонстрации короткого TTO, если через неделю половина системы ляжет, а восстановление обойдется дороже всей потенциальной экономии?

Кроме того, важно понимать контекст своих действий. Авральная оптимизация из-за двукратного увеличения месячного счета и плановая работа в рамках квартального ревью бюджетов – вообще не одно и то же. Они требуют разной скорости и подхода. Поэтому сравнивать их TTO напрямую некорректно.

Метрика требует отслеживания дат, этапов, событий. Это дополнительная нагрузка на команду, особенно если у вас параллельно идет несколько инициатив по оптимизации. Как понять, где одна закончилась, другая началась? Чем выше уровень зрелости, тем проще становится, потому что все автоматизировано. Но на начальных стадиях может реально напрягать.

И последнее. Тип изменений имеет значение. Простые действия типа выключения забытых виртуалок займут пару дней максимум. А архитектурные перестройки могут растянуться на месяцы даже при хорошей автоматизации. Сравнивать эти TTO между собой бессмысленно. Это как мерить скорость марафонца и спринтера одной линейкой.

Как использовать TTO на практике

Time-to-Optimize можно использовать несколькими способами:

1. Как основной KPI FinOps-команды. Забудьте про закрытые тикеты в Jira. Сократили TTO с 20 дней до 5? Значит, эффективность работы выросла в 4 раза. И это ясно всем – от CFO до уборщицы тети Маши.
2. Как обоснованиеч бюджетов. Руководство любит цифры, и, если показать ему десятикратную разницу между ручным подходом и автоматизацией. 20 дней против 2 – шутка ли. Вот вам и повод для использования FinOps-платформы. Причем не абстрактное, а с конкретными числами по вашей инфраструктуре.
3. Диагностика узких мест. Если разбить TTO на отдельные блоки, то можно сразу увидеть, где все тормозит. Может неожиданно выясниться, что техническая часть работает как часы, а вот согласования тянутся три недели. Тогда уже ясно, с кем надо разговаривать и какие процессы чинить.
4. Оценка зрелости процессов. Crawl – это недели, Walk – это дни, Run – это часы. Получается простой и понятный индикатор того, где вы сейчас и куда двигаться дальше.

В ближайшие годы TTO наверняка станет такой же привычной метрикой, как когда-то стал time-to-market в разработке. Так что компании, которые освоят быстрое реагирование на перерасходы, получат реальное преимущество перед конкурентами.

Главное — помнить, что TTO это просто инструмент, а не священная корова для поклонения. Его задача помочь выстроить толковую систему управления облачными тратами, где скорость не противоречит здравому смыслу. Потому что лучше потратить лишний день на анализ рисков, чем потом неделю восстанавливать систему и объяснять начальству, что вообще произошло и кто за это ответит.

Быстрая оптимизация — штука безусловно полезная и прибыльная. Но это метрика должна работать на вас, а не вы на нее.

Что такое катастрофическое забывание

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

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

Как выглядит забывание на практике

Возьмём простую ситуацию. Мы обучаем нейросеть распознавать собак (Задача A) — она показывает 95% точности, потом даём ей новую задачу — классифицировать котов (Задача B). После обучения по новой выборке сеть отлично отличает котов (92%), но если снова проверить её на собаках — точность падает с 95% (как было изначально на собаках) до 10%, то есть до уровня случайного угадывания.

Это не потому, что у сети не хватает параметров. Исследования показывают: ёмкости модели достаточно, чтобы хранить знания по обеим задачам. Проблема в другом — в том, как работает градиентный спуск.

Почему обучение стирает старое

Градиентный спуск видит только текущие ошибки и стремится минимизировать функцию потерь именно для новой задачи. То, что было важно для старой, в этот момент не учитывается.

Во время обучения сеть перемещается по пространству весов, чтобы найти минимум потерь. Для Задачи A она находит подходящее устойчивое решение. Когда приходит Задача B, алгоритм начинает с тех же весов, но дальше шаг за шагом уводит их в новое направление под новую цель. Многие параметры для старой задачи при этом переписываются.

В итоге то, что помогало распознавать собак, оказывается теперь непригодным для собак, а подходит только для котов. Алгоритм не учитывает, как теперь работает старая задача — он смотрит только на текущие задачи.

Дилемма стабильности и пластичности

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

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

Стабильность — противоположное качество: умение сохранять старые знания, не давая им разрушиться при каждом обновлении весов.

Проблема в том, что нельзя увеличить и стабильность, и пластичность одновременно. Если сеть слишком гибкая — она хорошо впитывает новое, но моментально забывает старое. Если наоборот — слишком стабильная, то перестаёт учиться и застывает на месте.

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

Потеря геометрии ландшафта: почему архитектура нужна

Чтобы понять, почему одни нейросети подвержены катастрофическому забыванию сильнее других, нужно разобраться в процессе оптимизации. Во время обучения модель корректирует миллионы параметров, минимизируя функцию потерь. Этот процесс можно визуализировать как перемещение по многомерному ландшафту потерь (loss landscape), где каждая точка представляет уникальную конфигурацию весов.

Ландшафт потерь состоит из областей с разными значениями функции потерь:

• Локальные минимумы — области с низким значением потерь, где модель показывает хорошее качество
• Высокие области — конфигурации параметров с большой ошибкой

При обучении на первой задаче (например, классификация собак) модель сходится к одному минимуму. При переходе ко второй задаче (классификация кошек) градиентный спуск направляет модель к совершенно другому минимуму, который может быть далеко от первого. Это приводит к перезаписи весов и потере знаний из предыдущей задачи.

Критический фактор — геометрия этих минимумов. В одних архитектурах минимумы узкие и острые (sharp minima) — небольшое возмущение параметров резко увеличивает функцию потерь. В других минимумы широкие и плоские (flat minima) — модель более устойчива к изменению весов.

Исследования показали, что архитектуры с skip connections, например ResNet, как раз формируют такие плоские минимумы — это делает их более устойчивыми к изменению весов, даже когда модель дообучается на новой задаче, её настройки остаются близки к старым, и забывание происходит не так сильно.

Это объясняет, почему современные архитектуры забывают меньше старых. У них принципиально другое устройство процесса обучения — более стабильное, которое труднее случайно сломать при добавлении новых задач.

Как нейроны конкурируют друг с другом

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

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

Нейронам не могут одинаково хорошо специализироваться и на собаках, и на котах. Одни и те же группы нейронов работают на разные задачи, из‑за чего старая специализация стирается.

Исследования показывают, что если две задачи активируют одну и ту же часть нейронов, эффект забывания становится сильнее — до 40–50%. Получается, сеть забывает не из‑за нехватки параметров, а потому что внутренние ресурсы перекрываются. Она просто переучивает старые нейроны на новую роль и не создает новые.

Почему повторное обучение не спасает

Можно подумать, что проблему легко решить: просто чередовать старую и новую задачу. Сначала немного обучаем сеть на собаках, потом на котах, потом снова на собаках — и так по кругу. Это действительно помогает, но не решает проблему полностью.

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

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

Как разработчики пытаются найти баланс

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

Если усилить регуляризацию — старые знания лучше сохранятся, но сеть хуже будет учиться новому. Если ослабить — сеть быстро впитает новую задачу, но забудет старую. Получается постоянный выбор: жертвовать старым или новым.

Любая точка на этом спектре — компромисс. Нет такого параметра, который позволит и запомнить всё прошлое, и учиться на будущем — на данный момент, это главное ограничение.

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

Методы борьбы с забыванием

Исследователи разработали несколько способов снизить катастрофическое забывание. Но ни один из них не решает проблему полностью — у каждого есть свои ограничения.

Elastic Weight Consolidation (EWC) — защита важных весов

Это метод, который старается определить, какие параметры критичны для предыдущей задачи, и защищает их от сильных изменений. Когда сеть дообучается на новой задаче, алгоритм смотрит: если какой-то параметр был очень важен для собак, его не надо сильно менять при обучении на котах.

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

Rehearsal — повторение старых примеров

Этот способ работает просто: сеть хранит в памяти часть примеров из старой задачи и время от времени подмешивает их при обучении на новой. Это снижает забывание, но требует хранить старые данные, что может быть невозможно из-за ограничений по памяти или приватности.

Архитектурные подходы — разные задачи, разные параметры

Самый радикальный способ — выделить разные части сети под разные задачи. Тогда обучение одной задачи вообще не трогает другую, потому что используются разные параметры. Забывания нет, но сеть становится огромной — чем больше задач, тем больше параметров.

HyperMask (2024 год) использует специальные маски, которые позволяют переиспользовать до 85% параметров между задачами, сохраняя изоляцию.

Современные гибридные методы

CURLoRA — метод, который комбинирует математическое разложение матриц с ограничениями при дообучении. Он показывает хорошие результаты на больших языковых моделях: например, для модели Mistral 7B удалось снизить ухудшение с 53 896 до 5,44 по метрике perplexity. Но такие методы заточены под конкретные модели и не всегда переносятся на другие архитектуры.

Пример на практике

Простой эксперимент на PyTorch показывает, как это выглядит. Сеть обучается на двух задачах: сначала на A, потом на B. Полный код доступен в оригинале в файле catastrophic-forgetting-demo.py.

Без защиты: точность на старой задаче падает с 93,6% до 53,6% — потеря 40%.

С методом EWC: точность падает с 91,8% до 74,4% — потеря 17,4%, что на 52% лучше. Но на новой задаче EWC тормозит обучение: вместо 95,6% получается только 73,8%.

Здесь видно главное: в каждом методе нужно выбирать чем жертвовать. Либо памятью, либо вычислением, либо производительностью на новой задаче. Вы не решаете проблему катастрофического забывания полностью, вы только управляете ею.

Как катастрофическое забывание проявляется в продакшене

В реальных системах катастрофическое забывание выглядит не как внезапный сбой, а как постепенное ухудшение работы — дрейф модели. Модель, обученная на прошлых данных, уверенно работает сегодня, но через пару месяцев начинает ошибаться. Это и есть то же самое забывание, только в замедленном виде.

Исследования показывают, что 75% компаний сталкиваются с падением качества моделей без постоянного мониторинга.

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

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

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

Например, в рекомендательных системах забывание снижает точность старых сегментов пользователей на 20–25%. В медицинском AI модели, обновленные на новых пациентах, теряют около 18% точности на старых группах — и это уже риск для качества диагностики.

Для инженеров это значит одно: катастрофическое забывание — не теоретическая проблема. Это реальный фактор, который нужно учитывать, если вы строите систему, которая учится на живых данных.

Новые подходы: не бороться, а обойти проблему

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

Сегодня развиваются три основных направления:

1. Непрерывное предобучение

Модель постоянно обновляет свои знания, когда появляются новые данные, но делает это аккуратно — чередуя новую информацию со старой из кеша. Такой подход сохраняет примерно 90–95% исходных способностей модели, при этом добавляя свежие знания.

2. Непрерывное дообучение (fine-tuning)

Здесь используется идея модульности: новая задача обучается поверх базовой модели, но сама база остаётся “замороженной”. Получается, что каждая дополнительная функция подключается как надстройка, не ломая основную логику. Это похоже на плагины, где каждая новая задача — отдельный модуль, не влияющий на предыдущие.

3. Множество моделей вместо одной

Третий подход — вообще отказаться от идеи универсальной модели, которая знает всё. Вместо этого создают ансамбли: набор специализированных моделей, которые работают вместе. Каждая отвечает за свой участок задачи, и таким образом проблема забывания просто не возникает — разные знания не мешают друг другу.

Все три подхода не устраняют забывание напрямую, но делают его несущественным. По факту вам просто нужны разные модели под разные задачи.

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

Это немного философское наблюдение: не пытаться побороть ограничение, а выстраивать архитектуру вокруг него.

Вопросы, которые остаются

Существует ли математический предел, ниже которого забывание уже невозможно снизить?

Некоторые исследования указывают на такие пределы, но точные границы пока не найдены.

Как выбирать баланс между стабильностью и пластичностью?

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

Влияет ли размер модели на забывание?

Практика показывает, что большие модели забывают меньше, но почему это происходит и как именно зависит сила забывания от размера — неясно.

Можем ли мы достичь теоретического максимума?

Даже если знать предел, можно ли разработать процедуру обучения, которая его достигает? Сейчас методы работают примерно на 70% от теоретически возможного оптимума.

Как ведут себя большие модели?

Ранние данные показывают, что большие модели забывают данные по-другому, чем маленькие сети. Но системного описания этих различий пока нет.

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

Выводы, которые можем сделать

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

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

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

Для разработчиков, которые работают с продакшен ML, это значит следующее: последовательное обучение сложнее одноразового обучения в принципе, и никакой алгоритм этого не изменит. Системы, которые хорошо справляются с меняющимися данными, не пытаются впихнуть всё в одну модель. Они признают ограничение и строятся вокруг него — с мониторингом, переобучением, специализированными моделями или ансамблями.

Введение

Мы живём в эпоху, когда мобильная связь стала критически важной инфраструктурой для бизнеса, безопасности и обслуживания клиентов. Современные проекты требуют интеграции SMS, голосовых вызовов и данных с корпоративными системами, а также удалённого управления устройствами. В этой статье мы подробно объясним, почему использование настоящих GSM-IP шлюзов предпочтительнее эмуляций, программных решений и VPN-заменителей. Вы узнаете технические, юридические и операционные аргументы, получите практические рекомендации по выбору и внедрению реальных GSM-IP решений, а также реалистичные чек-листы и готовые фреймворки для оценки поставщиков. Этот материал предназначен для инженеров, IT-директоров, руководителей проектов и архитекторов коммуникационных решений.

Основы: фундаментальные концепции

Что такое GSM-IP?

GSM-IP — это интеграция мобильной сети GSM с сетями передачи данных по протоколу IP. По сути, это устройство или система, которая подключает реальные SIM-карты в аппаратных слотах к IP-инфраструктуре: SIP, RTP, SMPP и пр. Шлюз принимает и передаёт голос, SMS и данные, используя мобильный оператор как транзитный канал.

Отличие от эмуляций и VPN-заменителей

Эмуляция GSM — это попытка воспроизвести поведение мобильной сети программно, без использования реальных операторских каналов. VPN-заменители предлагают туннелирование трафика через IP, маскируя источник, но не обеспечивая реальной мобильной идентичности SIM и IMSI. Ключевое различие: в реальных GSM-IP используются настоящие физические SIM и операторские ресурсы, тогда как эмуляции и VPN манипулируют сетевыми уровнями без участия мобильного оператора.

Ключевые термины

• SIM — модуль идентификации абонента, содержащий IMSI и ключи аутентификации.
• IMSI — уникальный идентификатор абонента в мобильной сети.
• SMPP — протокол для передачи SMS между системами.
• SIP — протокол сигнализации для установки голосовых соединений в IP-сетях.
• HLR/HSS — базы подписчиков в сетях GSM/UMTS/LTE.

Глубокое погружение: продвинутые аспекты

Аутентификация и безопасность на уровне SIM

Реальная SIM обеспечивает аппаратную аутентификацию в сети оператора посредством секретных ключей. Это означает, что наличие SIM гарантирует, что соединение прошло проверку у оператора, и вызовы или SMS идут через законный канал. Эмуляторы не имеют доступа к таким аппаратным секретам, что делает их уязвимыми к блокировке и манипуляциям со стороны операторов.

Качество связи и прогноз латентности

Прямое использование GSM-каналов обеспечивает предсказуемое качество: задержки, джиттер и потеря пакетов соответствуют мобильной сети. Эмуляции и VPN могут добавлять дополнительную латентность и непредсказуемые скачки качества из-за маршрутизации в публичных IP-сетях, что критично для голосовых сервисов и низколатентных SMS-коммуникаций.

Совместимость с IMS/VoLTE

С ростом LTE и VoLTE важна совместимость с IMS-инфраструктурой оператора. Настоящие GSM-IP шлюзы обеспечивают корректную обработку SIP и CSFB, поддерживают голос поверх LTE и корректно работают с IMS-базовой сигнатурой. Эмуляторы часто несовместимы или обходят эти механизмы, что приводит к падениям вызовов и ошибкам рутизации.

Юридические и регуляторные требования

Многие юрисдикции требуют прозрачности источника и маршрутизации телекоммуникаций. Использование реальных SIM гарантирует, что трафик проходит через зарегистрированные каналы оператора, что облегчает соответствие законам и уполномоченным запросам. Эмуляции и VPN-замены создают риски нарушения законов о хранении данных, прослушивании и противодействии мошенничеству.

Практический раздел 1: Выбор архитектуры GSM-IP

Теория: варианты архитектуры

Существует несколько базовых архитектур: локальные аппаратные шлюзы с физическими SIM, распределённые облачные точки с удалёнными SIM-банками (физическими или eSIM), гибридные модели, и решения с поддержкой IMS. Каждый подход имеет свои преимущества по масштабируемости, управлению и стоимости.

Практика: шаги выбора

1. Определите требования по объёму трафика и SLA.
2. Оцените юрисдикционные ограничения: местное размещение SIM, регистрация абонентов.
3. Решите, нужен ли вам поддержка VoLTE / SMSC / MMS.
4. Оцените риски безопасности и требования шифрования.
5. Сравните TCO для аппаратных и облачных решений.

Пример

Компания X требовала массовой рассылки SMS с высоким уровнем доставки. Мы выбрали локальные GSM-IP шлюзы с физическими SIM у трёх операторов для разнооператорного покрытия и отказоустойчивости. Это дало доставку 98.7% в первой волне и сократило жалобы клиентов на спам.

Чек-лист выбора

• Поддержка физических SIM и eSIM.
• Совместимость с вашими SIP/SMPP системами.
• Возможность локальной установки по юрисдикции.
• Мониторинг качества и SLA от поставщика.
• План аварийного переключения на резервные каналы.

Практический раздел 2: Внедрение и интеграция GSM-IP

Теория: ключевые интеграционные точки

Интеграция подразумевает соединение GSM-IP шлюза с вашими back-end системами через SIP для голоса и SMPP/HTTP для SMS, а также обеспечение аутентификации, шифрования и логирования. Необходимо также предусмотреть мониторинг на уровне сигнала, качества и использования SIM.

Практика: пошаговая инструкция внедрения

1. Подготовка инфраструктуры: выделите VLAN и брандмауэрные правила для GSM-IP.
2. Прокладка физического подключения: Ethernet, питание и защита от сбоев.
3. Установка и конфигурация шлюза: настройка SIP-профилей и SMPP-соединений.
4. Встраивание в биллинг и CRM: реалтайм-метрики и отчёты.
5. Тестирование через пилотную зону: стресс-тесты трафика и сценариев отказа.

Шаблон конфигурации

Мы рекомендуем следующую минимальную конфигурацию: VLAN 10 для управления, VLAN 20 для медийного RTP, IPSec туннель для управления, SMPP соединение с учётом аутентификации по IP и логирование на удалённый SIEM. Настроить автоматическое переключение на резервного оператора при наличии падения RTT выше 300 мс в течение 60 секунд.

Чек-лист внедрения

• Изолированные сети для сигнального и медийного трафика.
• Мониторинг качества: MOS/RTT/RTP loss.
• Логи SMPP и SIP в единой системе агрегации.
• Резервирование питания (UPS) и сетевых путей.
• Процедуры обновления прошивки с откатом.

Практический раздел 3: Операционная безопасность и управление рисками

Теория: угрозы и модели риска

Основные угрозы для GSM-IP систем включают незаконное использование SIM, SIM-cloning (при наличии уязвимости), кражу SIM, атаки на API шлюза, DDoS на SIP и компрометацию учетных данных SMPP. Управление рисками подразумевает защиту на нескольких уровнях: физическая, сетевого периметра, аутентификация и внутренняя сегментация.

Практика: стратегия безопасности

1. Физическая защита SIM: использовать защищенные SIM-кассеты и журналирование доступа.
2. Ограничение доступа: RBAC для управления шлюзом и ключами.
3. Защита сетевого уровня: IPSec/SSL для SIP, белые списки IP для SMPP.
4. Мониторинг аномалий: частые непарные вызовы, всплески отправки SMS со SIM.
5. Процедуры инцидент-реакции: быстрое блокирование SIM у оператора.

Примеры практических правил

Ограничьте ежедневный лимит SMS на одну SIM до значения, соответствующего нормальному пользовательскому поведению. Внедрите автоматическое временное замораживание SIM при превышении порога. Используйте 2FA и HSM для хранения ключей доступа к шлюзу.

Контрольный чек-лист безопасности

• Физический учёт SIM и аудит доступа.
• Автотриггеры на аномалии трафика.
• Шифрование конфигураций и секретов.
• Планы восстановления и резервирования.
• Тестирование на проникновение — ежегодно.

Практический раздел 4: Оптимизация и масштабирование

Теория: горизонтальное vs вертикальное масштабирование

Горизонтальное масштабирование добавляет больше физических шлюзов и SIM-баков, вертикальное — увеличивает мощность и пропускную способность отдельных устройств. Каждый подход имеет ограничения: количество одновременных голосовых каналов на SIM, ограничения SMPP-сессий у оператора, и инфраструктурные ограничения вашей сети.

Практика: план масштабирования

1. Оцените пиковые нагрузки и определите порог масштабирования.
2. Разработайте архитектуру с автоматическим добавлением шлюзов и балансировкой SIP/SMPP трафика.
3. Распределяйте SIM по операторам и географии для равномерного распределения риска.
4. Используйте контейнеризированные сервисы для управляемых компонентов (SMPP gateway, monit сервисы).

Методы оптимизации

Агрегация SMPP-сессий, кэширование маршрутов, использование предиктивного алгоритма распределения запросов между SIM на основе исторической нагрузки и событий. Внедрите throttling и очереди для управления всплесками.

Шаблон фреймворка масштабирования

1. Мониторинг: метрики использования SIM, очереди SMPP, MOS.
2. Триггеры: порог использования 70% ведёт к автоматической активации резервного шлюза.
3. Автоматизация: Ansible/Terraform для развёртывания новых узлов.
4. Отчётность: ежедневные отчёты по доставке и качеству.

Типичные ошибки: что НЕ нужно делать

Мы часто видим повторяющиеся ошибки в проектах:

• Переоценка возможностей эмуляции: многие команды полагают, что программный эмулятор заменит настоящую SIM. Это приводит к проблемам с доставкой и блокировками.
• Недооценка регуляторных требований: размещение SIM в другой юрисдикции без регистрации может привести к запрету услуг и штрафам.
• Отсутствие физической защиты SIM: неучёт физического доступа и отсутствие учёта приводит к кражам и несанкционированному использованию.
• Игнорирование мониторинга качества: отсутствие MOS, RTT и логов приводит к тому, что проблемы ищут слишком поздно.
• Слабая интеграция с операторами: отсутствие официальных каналов и договоров приводит к нестабильной работе и неожиданным блокировкам.

Чего не следует делать: использовать общедоступные VPN для маскировки источника мобильного трафика, применять массовое клонирование SIM в масштабных проектах, игнорировать законность обработки персональных данных и передачу метаданных.

Инструменты и ресурсы

Аппаратные и программные решения

• Аппаратные GSM-шлюзы от проверенных производителей с поддержкой SIP/SMPP и управлением SIM-банками.
• Платформы управления SIM (SIM management platforms) для инвентаризации и контроля использования.
• SMPP gateway приложения и open-source SIP PBX для интеграции.
• SIEM и мониторинговые решения (Prometheus/Grafana) для метрик качества.

Дополнительные ресурсы

Документы операторов по интеграции SMPP/SIP, регуляторные гайды по хранению телеком-данных, отраслевые отчёты по защите инфраструктуры связи. Рекомендуем изучать white papers по IMS и VoLTE, актуальные стандарты 3GPP и публикации по безопасности SIM и протоколов мобильной связи.

Кейсы и результаты: реальные примеры применения

Кейс 1: Финтех-компания и гарантия доставки OTP

Проблема: Финтех-компания испытывала низкую доставку одноразовых паролей (OTP) при массовых рассылках через виртуальные SMS-сервисы. Решение: Переход на собственную сеть GSM-IP с физическими SIM и распределение по трём операторам. Результат: уровень доставки OTP вырос до 99.3%, среднее время доставки снизилось вдвое, количество отказов клиентов уменьшилось на 84%.

Кейс 2: Служба охраны и голосовые оповещения

Проблема: Служба охраны использовала VoIP через VPN для аварийных оповещений, но при пиковых нагрузках голосовые каналы падали. Решение: Развёрнуто GSM-IP решение для критических исходящих оповещений, с локальным резервированием силовых каналов и отдельными SIM у двух разных операторов. Результат: Надёжность оповещений выросла с 78% до 99.1% в течение суток, время срабатывания сократилось на 37%.

Кейс 3: Маркетинговая кампания с высоким требованием к легитимности

Проблема: Маркетинговая команда столкнулась с массовыми блокировками из-за использования дешёвых SMS-агрегаторов и эмуляций. Решение: Запуск кампании через реальные GSM-IP шлюзы, регистрация кампаний у операторов и корректная настройка DLR/SMPP. Результат: Снижение блокировок на 92% и повышение открываемости сообщений, что привело к увеличению ROI рекламы.

FAQ: глубокие вопросы и ответы

1. Почему оператор может заблокировать эмулятор или VPN-заменитель?

Операторы блокируют источники, которые не проходят аутентификацию на уровне SIM или генерируют аномальный трафик. Эмуляции и VPN часто выявляются по несоответствию сигнатур, отсутствию корректной IMSI/IMEI и по необычным шаблонам трафика. Это приводит к автоматическим фильтрам и ручной блокировке.

2. Можно ли заменить физические SIM на eSIM?

Да, eSIM даёт гибкость и упрощает дистанционное управление, но при этом требуется поддержка операторов и корректное управление профилями. В ряде стран регуляторы строго относятся к удалённой активации SIM-профилей, поэтому важно учитывать юридические ограничения.

3. Насколько безопасно хранить ключи и доступы к GSM-IP шлюзу?

Крайне важно использовать HSM или защищённые хранилища для секретов, а также реализовать RBAC и аудит доступа. Утечка ключей может привести к компрометации всей платформы и несанкционированной отправке трафика.

4. Какие метрики качества стоит отслеживать?

Рекомендуем мониторить MOS для голоса, RTT для SIP, RTP loss, процент доставленных SMS, DLR delays и количество отказов на уровне оператора. Также важно отслеживать аномалии: всплески трафика, необычные шаблоны отправки и новые географические паттерны.

5. Как снизить риски юридической ответственности при массовых рассылках?

Регистрируйте кампании у операторов, используйте легальные opt-in базы абонентов, храните логи подтверждений и согласий, и следуйте требованиям по обработке персональных данных в вашей юрисдикции. Партнёрство с легитимным оператором снижает вероятность претензий.

6. Что делать при обнаружении компрометации SIM?

Немедленно блокировать SIM у оператора, изолировать шлюз, проигнорировать все очереди, восстановить состояние из последней безопасной копии и провести расследование. Важно иметь SLA и контакты у операторов для срочного блокирования и замены SIM.

7. Стоит ли строить собственную инфраструктуру или пользоваться провайдером GSM-IP?

Решение зависит от масштаба, требований к контролю и регуляторных условий. Собственная инфраструктура даёт полный контроль и прозрачность, но требует инвестиций. Провайдеры удобны для старта и масштабирования, но могут ограничивать доступ к деталям и вводить риски зависимости.

8. Как избежать штрафов за межоператорские рассылки?

Соблюдайте правила операторов, используйте корректные маршруты, регистрируйте номера отправителей и избегайте шаблонов, похожих на спам. Настройка обратной связи и обработка жалоб позволяет быстрее реагировать и сохранять легитимность.

9. Как влияют 5G и будущие сети на GSM-IP?

5G приносит новые возможности — более низкую задержку, большую пропускную способность и расширенные возможности ядра. Однако многие сервисы будут опираться на LTE/VoLTE и совместимость с существующими IMS. GSM-IP придётся эволюционировать для поддержки новых стандартов и обеспечения межоператорской совместимости.

10. Можно ли использовать облачные SIM-банки безопасно?

Да, при условии, что SIM-физически управляются в безопасных локациях, их доступ контролируется, а юридические аспекты соблюдены. Облачные SIM-банки удобны, но требуют строгой цепочки доверия и аудита.

Заключение: резюме и следующие шаги

Использование реальных GSM-IP шлюзов — это не только вопрос качества связи. Это вопрос легитимности, безопасности, соответствия регуляторным требованиям и устойчивости бизнеса. Мы рекомендовали архитектуры, практические шаги внедрения, фреймворки масштабирования и стратегии безопасности. Что делать дальше? Сформируйте внутреннюю рабочую группу, оцените текущие каналы связи на соответствие перечисленным критериям, разработайте пилот с реальными GSM-IP шлюзами и запланируйте тестирование на реальные сценарии нагрузки и отказов. Используйте предоставленные чек-листы для аудита поставщиков и внедрения. Вместе с вами мы можем выстроить надёжную, масштабируемую и соответствующую требованиям инфраструктуру мобильной связи.

Полезные контрольные вопросы для старта

• Какие требования к доставке SMS и голосу у нашего проекта?
• Какие регуляторные ограничения применимы в наших целевых регионах?
• Есть ли у нас ресурсы для управления собственной GSM-инфраструктурой?
• Какие KPI по качеству и SLA мы ожидаем от поставщика?

Если вы готовы, начните с малого пилота, соберите данные и примите решение на основе метрик и реальных результатов. Настоящие GSM-IP решения стоят своих усилий: они дают контроль, стабильность и юридическую прозрачность, которые невозможно обеспечить эмуляциями или VPN-заменителями.

Вместе с экспертами собрали системный подход из 12 шагов, чтобы найти узкие места и пофиксить проблемы.

Шаг 1. Проверьте CPU, память и диск

Начинаем с базы — проверяем аппаратные и системные ресурсы. Иногда проблема кроется в том, что серверу объективно тяжело. CPU перегружен, память закончилась, диск устал, и PostgreSQL просто не из чего строить производительность. База работает как сениор-разработчик в последней стадии выгорания.

На что ориентироваться:

• Если CPU постоянно упирается в предел — анализируем активность запросов или рассматриваем масштабирование.
• Если Swap активен — не хватает памяти.
• Если видите высокий iowait или высокий %util диска, то кандидаты: медленное хранилище, случайные чтения, VACUUM, большие запросы.

Шаг 2. Изучите активность в pg_stat_activity

Представляет информацию о текущей активности каждого процесса в реальном времени. Благодаря pg_stat_activity можно увидеть, какие запросы сейчас ждут запуска, какие в работе, а какие съедают больше всего ресурсов производительности. Если смотреть сюда регулярно, большинство проблем видно ещё до аварии.

На что обратить внимание

• долгие транзакции;
• wait_event_type = 'Lock';
• idle in transaction — признак некорректной работы приложения с транзакциями.

Однажды в проде столкнулись с резким ростом задержек запросов, далее — массовые ошибки canceling statement due to lock timeout. Выяснилось: в ETL начали повсеместно использовать транзакции, в том числе там, где они не нужны. Долгие этапы блокировали частые операции. Перезапуск PostgreSQL помогал до следующего запуска ETL.

Решение: идентифицировать и завершить блокирующие процессы, переработать ETL на более короткие транзакции. В дальнейшем — маркировать подобные процессы и мониторить их отдельно.

Шаг 3. Найдите медленные запросы в pg_stat_statements

Этот модуль отслеживает статистику выполнения сервером всех операторов SQL. Сюда стоит заглянуть, если зависание и торможение повторяются. Сама база может работать нормально, а один или два плохо написанных запроса — нет.

Что искать:

• запросы, потребляющие больше всего времени;
• случаи, когда чтение идёт с диска, а не из буфера (shared_blks_read >> shared_blks_hit).

Шаг 4. Выявите блокировки

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

Ищем цепочки блокировок. Частые причины:

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

Шаг 5. Проанализируйте план запроса с EXPLAIN ANALYZE

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

Шаг 6. Проверьте и оптимизируйте индексы

Индекс работает как указатель в книге, чтобы быстро искать нужную страницу. Но если поставить закладки везде, то книга станет толстой и неудобной. PostgreSQL ведёт себя так же: без индекса он перебирает строки вручную, а с перегруженной структурой дольше обновляет таблицу и тратит лишнюю память

Как оптимизировать:

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

Шаг 7. Устраните раздувание таблиц — bloat

PostgreSQL не удаляет ненужные данные сразу, а копит «мёртвые» строки. Если их становится слишком много, таблицы разрастаются. Тогда база тратит ресурсы впустую.

Диагностика:

Очистка:

Шаг 8. Настройте и проверьте autovacuum

Этот фоновый процесс нужен в PostgreSQL, чтобы автоматически обслуживать базу. Пока он работает, система в порядке. Если его выключить или не настроить, то накопится мусор, вырастут таблицы, а база замедлится.

Проверьте эффективность процессов:

Настройки должны соответствовать нагрузке и объёму данных.

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

Если n_dead_tup растёт, а autovacuum_count нет — это сигнал будущих проблем с производительностью и ростом bloat. Также важно следить за WAL: резкий рост записи может указывать на массовые обновления, проблемы с репликацией или приближающееся заполнение диска.

Шаг 9. Обновите статистику и настройте планировщик

PostgreSQL формирует план выполнения запроса на основе статистики о распределении данных в таблицах. Если статистика устарела, оптимизатор может выбрать неэффективный план.

Регулярно выполняйте команду ANALYZE, чтобы освежить статистику и корректно оценивать операции.

Учитывайте важные параметры:

• random_page_cost для SSD ≈ 1.1
• effective_cache_size ≈ 50–75% RAM

Шаг 10. Контролируйте соединения

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

Текущее состояние соединений можно просмотреть с помощью:

Чтобы решить проблему, используйте пул соединений — например, через пулер PgBouncer или аналоги. Такие программы перераспределяют нагрузку между клиентами.

Шаг 11. Проанализируйте логи

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

Рекомендуемые параметры в postgresql.conf:

Шаг 12. Оптимизируйте конфигурацию

Значения по умолчанию предназначены для минимальных нагрузок — для работы на ноутбуке. Они не дают достаточной мощности в производственной среде.

Измените ключевые параметры конфигурации:

• shared_buffers ~25% RAM
• effective_cache_size ~50–75% RAM
• work_mem 4–16 MB per operation
• checkpoint_timeout 15–30 min
• random_page_cost = 1.1 для SSD

Многие думают, что 16 мегабайт — это глобальный лимит на соединение. На самом деле это лимит на операцию. Один запрос может использовать work_mem много раз.

Качество и целостность данных: типовые проблемы и решения

Качество данных — основа устойчивой IT-системы. Проблемы с ними часто приводят к сбоям и некорректной работе приложений. В PostgreSQL есть встроенные механизмы, которые помогают поддерживать надёжность информации.

Какие ошибки встречаются чаще всего:

• дубли,
• неверные типы,
• конфликтующие или устаревшие значения,
• частичные и повреждённые записи.

Как поддерживать целостность данных:

• Проводить регулярный аудит и мониторинг качества данных.
• Внедрять автоматические проверки на дубликаты, пропуски и нарушения правил ещё на этапе загрузки данных.
• Использовать резервное копирование и инструменты восстановления после сбоев.
• Повышать осознанность пользователей и разработчиков — качество данных это часть инженерной культуры.

Контроль качества данных включает также стратегию восстановления. Даже идеально настроенная валидация не спасает от сбоя диска или человеческого фактора. Резервные копии и репликации должны стать частью общей стратегии.

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

• проверенные бэкапы возвращают к нормальному состоянию,

• репликация сохраняет доступность, если падает основной сервер.

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

Как проверять входные данные

Задавайте допустимые форматы и диапазоны. Указывайте, какие значения вы считаете корректными. Пример:

• дата рождения не может быть позже текущего дня;
• возраст — только числа ≥ 18;
• формат email должен содержать @ и домен.

Проверяйте данные на двух уровнях. Чтобы пользователь увидел ошибку сразу, смотрите на клиенте — например, в форме сбора контактов.

Чтобы защититься, если приложение пропустило проблему — на сервере.

Используйте ограничения в базе. SQL-ограничения — это тот самый встроенный механизм надёжности:

• NOT NULL — поле не может быть пустым;
• UNIQUE — значение должно быть уникальным;
• CHECK — значение должно соответствовать условию;
• FOREIGN KEY — связь с другой таблицей;
• триггеры — дополнительная логика проверки.

Давайте понятные сообщения об ошибках. Пользователь должен понимать, что он сделал не так. Например, вместо Error 400 — invalid data напишите: «Возраст должен быть от 18 лет. Введено: 15».

Актуализируйте правила проверки. Если вчера минимальная сумма заявки была 5 тысяч, а сегодня 10 — проверка должна обновиться.

Отдайте контроль машине. Используйте автоматизированные проверки:

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

Документируйте и обучайте. Опишите, какие данные нужны, в каком виде и почему. Покажите команде и пользователям. Чем понятнее правила, тем меньше ошибок.

Идеальный сценарий: регулярные тестируемые бэкапы + репликация с мониторингом лагов.

Чек-лист диагностики за 15 минут

1. pg_stat_activity — долгие транзакции, ожидания
2. pg_locks — есть ли блокировки
3. pg_stat_statements — тяжёлые запросы
4. iostat, htop, free — ресурсы железа
5. Проверка автовакуума
6. Проверка WAL и места на диске
7. Анализ логов

Ещё 4 неочевидные причины деградации производительности

Что делать, если диагностика по стандарту не помогла? Владимир Васильев рассказал нам, где ещё можно найти источник проблем:

• «Тихое» повреждение данных на диске. Дисковая подсистема не сообщала об ошибках: контроллер RAID с кэшем-бутербродом, где батарея отжила своё. Некоторые страницы данных на диске были битые. Postgres при чтении таких страниц не падал, а уходил в бесконечные ожидания I/O, которые выглядели как резкий скачок нагрузки на диск. Вылечили включением zero_damaged_pages на свой страх и риск, с последующим дампом/рестором. Потом, конечно, заменили железо.
• Конфликт расширений. Была история с pg_stat_statements и auto_explain, которые при определённой настройке (совместная загрузка и высокая частота сэмплирования) начинали сильно тормозить из-за конкуренции за локи в общей памяти. Симптом — высокий wait_event типа LWLock для простых запросов.
• Проблема на уровне файловой системы. Очень старый, но запоминающийся случай: файловая система была заполнена почти под завязку, больше 95%. Это привело к драматическому падению производительности, так как механизмам VACUUM и CREATE INDEX не хватало места для создания временных файлов. Симптомы были самые странные, пока не посмотрели на df -h.
• Субтильный баг в версии PostgreSQL. Однажды апгрейд на минорную версию в рамках одного major привёл к деградации конкретного типа запросов с JOIN. Оказалось, баг в планировщике — он неправильно оценивал стоимость при определённом условии. Помог откат или установка enable_<type>scan = off в качестве временного костыля.

Выводы

Основные источники проблем:

• долгие транзакции и блокировки
• неэффективные планы выполнения
• недостаточная память и I/O-узкие места
• неверные настройки work_mem, autovacuum, max_connections
• игнорирование метрик и логов

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

Краткий чек-лист диагностики:

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

Читайте также

• Основы PostgreSQL для начинающих: от установки до первых запросов
• PostgreSQL vs. ClickHouse vs. Duck DB: какую опенсорс базу выбрать для аналитики в 2025 году?
• Вредные советы по работе с базами данных, или как расстроить DBA
• SQL-оптимизация: 5 запросов, которые ломают базу
• PostgreSQL: что нужно знать о счётчике транзакций

Если вы пишете код и начинаете разбираться с большими данными, здесь много идей, которые можно применить прямо сейчас.

Главный месседж — зрелый ML‑инженер это не коллекционер нейронок, а разработчик, умеющий проверять гипотезы, валидировать результаты и писать поддерживаемый код.

Кем должен быть ML‑специалист — математиком или программистом

Без математики в ML далеко не уйдёшь, но и без хорошего кода модели не взлетят. Ошибка в формуле или пробел в логике тестов может стоить недели отладки. Поэтому подход должен быть инженерным: писать чисто, добавлять аннотации типов, покрывать код тестами, следить за читаемостью.

Сколько математики нужно в ML

Без линейной алгебры, матриц, теории вероятностей и дифференцирования не получится даже понимать, что именно делает модель. Эти базовые знания можно освоить за полгода‑год, но важно не просто формулы выучить, а развить интуицию.

Инженеру нужно чувствовать, как данные проходят через слои сети, что происходит с тензорами и почему параметры меняются именно так. Это не про сложную теорию — скорее про понимание механики. Когда видишь матрицы не как набор чисел, а как систему преобразований, всё становится проще, и дебаг модели перестаёт быть сложной задачей.

Как развиваться в ML и не застрять на старте

По мнению Александра, главный способ расти в машинном обучении — постоянно разбирать чужие работы. Читать статьи, пробовать воспроизводить их, собирать сети, смотреть, как устроены архитектуры. Не стоит относиться к программированию как к самоцели. Код — инструмент, но смысл в том, чтобы понимать, что делает модель внутри.

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

Развитие начинается, когда ты сам задаёшь вопросы вроде «почему слой ведёт себя так», «как меняются веса», «что даёт нормализация». Именно через эти вопросы начинается путь к инженеру, а не к пользователю фреймворков и вайбкодингу.

Что с большими языковыми моделями

Хайп вокруг больших языковых моделей уже выдохся: корпорации гонятся за размерами, а остальные используют их как библиотеку. Это не плохо — эмбеддинги и промты действительно решают прикладные задачи, от резюмирования встреч до автозаполнения CRM.

Но инженеру важно понимать, что промт не заменяет модель, это просто способ задать контекст, как преднастройка перед задачей. За ней всё тот же набор весов и вероятностных расчётов. Ошибка — считать промты заменой инженерной работы.

LLM полезны там, где есть конкретный сценарий и метрики: если видно, что саммари экономит время менеджера или классификатор улучшает отклик в CRM, тогда инструмент оправдан.

В остальных случаях стоит смотреть на ресурсы и задавать вопрос — нужна ли тяжёлая модель, если задачу решает бустинг или простая логистическая регрессия.

Какие методы сейчас реально работают

По данным Александра, для бизнес‑задач нет универсального решения, но есть набор проверенных инструментов. Если данные категориальные — лучше использовать градиентный бустинг, например CatBoost или XGBoost. Эти методы часто точнее нейросетей и требуют меньше подгонки.

Хороший результат даёт комбинация моделей. Например, можно взять LLM для генерации эмбеддингов, а дальше подать их в логистическую регрессию или тот же бустинг. Такой гибрид работает быстрее и требует меньше ресурсов, но при этом сохраняет качество.

Если данных мало или вычислительных мощностей не хватает, помогает байесовский подход. Он хорошо ведёт себя на шумных и несбалансированных выборках, где другие методы не подходят или не работают. Отдельное направление — оптимизация моделей. Уменьшение моделей через compression позволяет запускать их на обычных серверах без потери точности — актуально для компаний без GPU‑кластеров.

Когда ML действительно нужен

Не любую задачу стоит решать через машинное обучение. Александр объясняет: если алгоритм можно описать правилами, лучше начинать с классики. Но когда формулы не работают — например, при обработке изображений или машинном переводе — подходит ML. Главное, чтобы были данные: сотни или тысячи пар примеров «правильно» и «неправильно». Без них обучение просто не из чего строить.

Если данных мало, лучше брать байесовские методы или простые классификаторы — они устойчивее и не требуют много ресурсов. То же самое касается бизнес‑кейсов, где результат критичен, а точность нужно проверять.

Решение в пользу ML — это не вопрос нового стека, а вопрос наличия данных и понимания задачи. Если подход классических алгоритмов решает проблему быстрее и дешевле, значит, выбираем его.

Что делать, если данных мало

Недостаток данных — это нормальное состояние, полных и сбалансированных выборок почти не бывает. Поэтому разработчику приходится проявлять креатив. Один из способов — генерировать синтетические данные. Например, создавать дополнительные примеры с небольшими изменениями, чтобы модель видела больше разнообразия.

Полезно искать и дополнительные источники сигналов. Если пользователь бросил корзину в интернет‑магазине, это может быть прокси‑признак будущей покупки. Такие косвенные данные часто помогают вытащить модель на нужный уровень точности.

Где ML приносит реальную пользу бизнесу

Александр приводит примеры из практики Bitrix24. Один из самых ощутимых по эффекту — скоринг лидов и сделок. Там используется логистическая регрессия и градиентный бустинг. Метод простой, но позволяет заметно повысить точность прогнозов и напрямую влияет на выручку.

Вторая история — классификация запросов техподдержки. Решение построено на основе алгоритма шинглов и простой модели, оно работает стабильно и подходит для разных языков.

Алгоритм шинглов — это простой способ представить текст для последующей обработки или сравнения без участия сложных моделей.

Пример: текст "машина" при длине шингла 3 даёт набор шинглов: "маш", "аши", "шин", "ина".

Дальше можно сравнивать эти множества и вычислять похожесть, например через коэффициент Жаккара.

В Bitrix24 метод шинглов помогает системе одинаково понимать обращения пользователей на разных языках или с разными формулировками.

Как проверить, что модель действительно работает

Без тестирования и валидации никакая модель не считается готовой. Первое, с чего нужно начинать, — сравнение с базовой линией. Самый простой пример — случайный классификатор. Если ваша модель даёт результат не лучше рандома, значит, смысла в ней нет.

Дальше важно понимать метрики: precision, recall, F1 и другие. Они показывают, на сколько точно модель попадает в нужные ответы и сколько ложных срабатываний допускает. Не стоит воспринимать метрики как формальности — от них зависит, будет ли решение полезно для бизнеса.

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

Если ML‑модель не выигрывает по скорости или точности, её не стоит внедрять. Тестировать нужно на реальных данных и регулярно пересматривать результаты, особенно если бизнес‑процессы меняются.

Какие инструменты и ресурсы использовать

Основная экосистема машинного обучения сегодня крутится вокруг Python, и начинать логично с него. Хороший старт — realpython.com, где подробно объясняются основы языка и приёмы написания читаемого кода.

Но нужно развивать инженерные привычки. Александр рекомендует читать книги вроде Effective Java Джошуа Блоха, чтобы прокачивать культуру разработки и понимать многопоточность. Даже если вы работаете с Python, знания из других языков помогают писать лучше и думать о производительности.

Из библиотек стоит освоить PyTorch или TensorFlow для нейросетей и scikit‑learn для классического ML. При росте нагрузки полезно переписывать критичные части на Java или Rust — это уменьшает задержки и делает систему устойчивее.

Как набраться практики и выбрать правильную команду

Лучший способ вырасти в ML — попасть туда, где есть реальные данные и сильная инженерная культура.

Идите в крупные компании вроде Яндекса, ВК, Сбера или X5 — там есть инфраструктура, процессы и опытные коллеги. Просто читать статьи и собирать pet‑проекты недостаточно, если не сталкиваешься с настоящими продуктами и их ограничениями.

Главный признак хорошей команды — наличие тестов, QA и понятного кода. Если в отделе этого нет, нужно уходить, иначе быстро потеряешь профессиональный уровень. ML уже давно не чудо‑технология, а инструмент. И успех зависит не от того, кто первым применил нейросеть, а от того, чья команда умеет держать систему в рабочем состоянии и проверять результаты каждый день.

В конце хочется спросить: как вы сами учились или учитесь ML — через курсы, проекты или книги? Делитесь своим опытом и мыслями в комментариях — обсудим, какие подходы к обучению и работе в ML работают сегодня.

Проект опубликован на GitHub и сопровождается демонстрацией, инструкциями и, непосредственно, самим QR-изображением.

Как это работает

Это x86-код, изначально рассчитанный на DOS. Есть и вариант, который не требует BIOS, загрузчика или операционной системы.

Автор использует тонкие приемы оптимизации — минимальные инструкции, хитрые трюки с регистрами и адресацией. И все это нужно чтобы уместить игровую логику и отрисовку в крошечный набор байтов.

Зачем все это

Разумеется, это никакая не попытка заменить полноценную игру, а упражнение в минимализме: показать, как далеко можно зайти с низкоуровневыми оптимизациями.

В README автор прямо сравнивает размер в байтах с обычными программами.

Практическое значение и эстетика

Проекты вроде этого интересны двумя вещами:

1. Техническая демонстрация — они учат «компактному» мышлению и глубокому пониманию архитектуры процессора;
2. Эстетика хакерской культуры — умение поместить игру в QR-код служит чистым челленджем и поводом для обсуждений в сообществе.

Где посмотреть и запустить

Сборник кода, QR-изображение и онлайн-демо доступны на странице проекта на GitHub.

Там же — инструкции, как запустить локально (скрипты main.sh/main.bat) и как собрать свое QR-воплощение.

1. Запросы без ограничений

Запрос:

Почему он опасен

Такие запросы тянут абсолютно все данные из таблицы, даже если нужны 2–3 поля. На больших таблицах это превращается в тяжелую нагрузку на сервер: растет объём передаваемых данных, замедляется отклик, падает производительность. Если запрос используют в проде (например, при каждом открытии страницы), он легко может «задушить» базу под пиковыми нагрузками.

Как переписать правильно

или

Важно явно указывать необходимые поля и добавлять LIMIT, если не нужны все строки сразу. Это снижает нагрузку и ускоряет ответ.

2. WHERE без индексов

Запрос:

Почему он опасен

Если по полю status нет индекса, база будет проходить всю таблицу построчно (full table scan), чтобы найти нужные строки. На таблицах с миллионами записей это приводит к заметной деградации производительности, особенно при частых запросах. Если таких фильтров несколько, нагрузка на сервер растет лавинообразно.

Как переписать правильно

Добавить индекс по фильтруемому полю:

Переписать запрос, чтобы он использовал индекс:

Если поле часто используется в фильтрах или джоинах — индексировать его почти всегда оправдано. Это резко ускоряет поиск и снижает нагрузку.

3. GROUP BY и агрегаты по большим таблицам

Запрос:

Почему он опасен

GROUP BY заставляет базу данных сначала обработать все строки, а потом сгруппировать их в памяти или на диске. Если таблица содержит миллионы записей и нет подходящих индексов, такой запрос приводит к сортировке или хэшированию огромных объёмов данных. Итог — долгие выполнения, рост потребления оперативной памяти и, в худшем случае, временные таблицы на диске (disk spill). Дополнительную нагрузку дают агрегаты (COUNT, SUM, AVG и др.) без фильтров — база пересчитывает их для всех строк, даже если вам нужна малая часть.

Как переписать правильно

Ограничить выборку с помощью фильтров до агрегации:

Добавить индекс по ключу группировки:

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

GROUP BY хорошо работает на подготовленных и отфильтрованных данных. Если он упирается в «сырые» миллионы строк — это сигнал к пересмотру логики запроса.

4. Подзапросы в WHERE (особенно некоррелированные)

Запрос

Почему он опасен

Подзапрос в WHERE нередко превращается в лишний проход по таблице. Если оптимизатор не умеет эффективно преобразовать подзапрос в JOIN, он будет сначала выполнять подзапрос (часто без индексов), а потом сверять результаты с основной таблицей. При больших объёмах это означает десятки тысяч сравнений и скачки производительности. Особенно опасны некоррелированные подзапросы, которые не зависят от внешнего запроса — они могут выполняться повторно или создавать временные таблицы.

Как переписать правильно

Заменить подзапрос на JOIN:

Убедиться, что по ключам соединения и фильтрации (customer_id, country) есть индексы:

Если подзапрос всё же нужен — использовать EXISTS, а не IN, чтобы оптимизатор мог «коротко замыкать» проверку:

Подзапросы — удобный синтаксис, но не всегда эффективный. JOIN и индексы почти всегда работают быстрее, особенно на больших таблицах.

5. ORDER BY без индекса

Запрос

Почему он опасен

Когда вы используете ORDER BY по колонке без индекса, база вынуждена сортировать всю выборку в памяти или на диске. Это означает дополнительную нагрузку на CPU, а при больших объёмах данных — полную деградацию производительности. Часто такие запросы встречаются в продакшене в виде пагинации по миллионам строк. В итоге простой «листинг заказов» превращается в многосекундный или даже минутный ответ.

Как переписать правильно

Добавить индекс по полю сортировки:

Ограничить выборку с помощью LIMIT и пагинации:

Использовать составные индексы, если сортировка идёт вместе с фильтром:

А какие запросы убивают вашу базу? пишите в комментариях!

Главный итог — новая версия работает примерно на 27% быстрее, чем Python 3.13. Ключевое новшество — полноценная поддержка free-threading (многопоточности без глобальной блокировки GIL).

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

В тестах участвовали версии CPython 3.9–3.14, а также PyPy 3.11, Node.js 24 и Rust 1.9.

Проверяли производительность на двух алгоритмах: рекурсивном вычислении чисел Фибоначчи и сортировке пузырьком. В однопоточном режиме Python 3.14 показал стабильный прогресс:

• В тесте Фибоначчи ускорение на 27% — 6,4 секунды против 8,2 секунд у версии 3.13.
• В сортировке пузырьком время сократилось до 2,05 секунды против 2,8 секунд.

Революция free-threading

Главный прорыв — free-threading, который наконец снимает системное ограничение GIL и раскрывает потенциал многоядерных процессоров.

В четырехпоточном тесте Фибоначчи скорость выросла в три раза, а в сортировке — в два раза относительно стандартной сборки.

Сравнение с другими

Стоит отметить, что PyPy 3.11 остается недосягаемым лидером — он быстрее CPython 3.14 почти в пять раз в рекурсии и в 18 раз при сортировке.

Node.js приблизился к PyPy в одном тесте, а Rust ожидаемо вырвался вперед — до 70 раз быстрее Python.

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

Python 3.14 — самая быстрая версия CPython на сегодня. Для проектов с интенсивными вычислениями free-threading дает ощутимый прирост. А вот JIT-режим пока остается экспериментальным — ускорения почти нет.

Если ваша команда может обновиться — это стоит сделать. Python 3.14 не просто быстрее: он впервые по-настоящему раскрывает многопоточность.

Пора перестать смотреть на GPU как на экзотику для геймеров и IT-гигантов. Сегодня это — стратегический актив. Он существенно ускорит ключевые бизнес-процессы. Вопрос лишь в том, как грамотно подойти к вложениям и не слить бюджет.

Тревожные звоночки: пора покупать GPU?

Как понять, что ваш бизнес достиг той точки, когда мощности центральных процессоров стали тормозом? Есть несколько явных сигналов.

Если рендеринг видео или сложной 3D-графики растягивается на ночь, заставляя дизайнеров и инженеров простаивать в ожидании. Если модели машинного обучения обучаются неделями, не позволяя оперативно тестировать гипотезы и улучшать продукт. Если анализ больших данных или сложные финансовые симуляции не дают инсайтов для принятия решений. Это не просто технические неудобства — это прямые потери денег и конкурентных позиций. Компании, которые уже используют GPU-ускорение, попросту двигаются быстрее.

Где GPU приносят реальные деньги

Мощность сама по себе бессмысленна. Ценность появляется, когда она решает конкретные бизнес-задачи.

Возьмём, к примеру, искусственный интеллект. Скорость здесь — это всё. Сокращение времени обучения модели с десяти дней до одного означает не просто экономию времени. Это возможность запустить на 30% больше экспериментов и быстрее выйти на рынок с уникальным продуктом. Выгода становится очевидна.

В индустрии дизайна и медиа GPU творят чудеса. Студия, сократившая время рендера кадра с часа до пяти минут, увеличивает свою пропускную способность в разы. Это позволяет брать больше проектов без расширения штата, повышать качество картинки и соблюдать самые сжатые сроки. Здесь окупаемость считается в дополнительных контрактах и лояльности клиентов.

CAPEX или OPEX: финансовая развилка

Итак, решение принято. Но как поступить — построить собственную инфраструктуру или воспользоваться облачной арендой? Это фундаментальный выбор между двумя финансовыми моделями.

Покупать свои GPU (CAPEX). Это стратегия основателя крепости. Вы владеете всем: от процессора до системы охлаждения. Плюсы? Полная независимость и предсказуемые расходы в будущем. Минусы? Огромный первоначальный взнос, а техника имеет привычку устаревать буквально на глазах. Плюс к этому — штат инженеров для ее содержания. Выбор для тех, у кого работа кипит 24/7 и планы расписаны на годы вперед.

Арендовать в облаке (OPEX). Это стратегия мобильной команды. Нужны мощности — включил. Закончил проект — выключил и перестал платить. Главный козырь — невероятная гибкость. Сегодня тестируете модель на одной видеокарте, а завтра для нового клиента разворачиваете целый кластер за считанные минуты.

Считаем выгоду: простая формула ROI

Чтобы принять взвешенное решение, необходим хотя бы примерный расчет возврата на инвестиции. Формула выглядит пугающе только на первый взгляд.

Выгода (₽) = (Сэкономленное время сотрудников × почасовую ставку) + (Ускорение вывода продукта × потенциальный доход) + Снижение операционных издержек.

Затраты (₽) = Стоимость оборудования / аренды + Электроэнергия + Обслуживание.

ROI (%) = ((Доход – Затраты) / Затраты) × 100.

Рассмотрим гипотетический пример. Допустим, инженерная команда тратила на симуляции 200 часов в месяц. Внедрение GPU сократило это время до 20 часов. При стоимости часа работы инженера в $50 экономия на фонде оплаты труда составляет $9000 в месяц. Если аренда необходимых GPU-мощностей обходится в $4000, ежемесячная чистая выгода — $5000. Простой ROI в этом случае превышает 120%. Цифры условны, но они наглядно демонстрируют, что при правильном подходе инвестиции могут окупаться очень быстро.

Резюмируя: шаг к осознанным инвестициям

GPU давно перестали быть узкопрофильной технологией. Они превратились в мощный бизнес-инструмент и дают конкурентное преимущество через скорость. Инвестиции в них оправданы. Но важно чётко понимать, какие процессы ускорятся и как это повлияет на финансовые результаты.

Выбирайте строительство собственного кластера (CAPEX) для стабильных, непрерывных рабочих нагрузок. Аренда в облаке (OPEX) — более гибкий и менее рискованный путь для старта и тестирования идей. Начните с пилотного проекта, соберите данные и посчитайте. Возможно, ваша главная победа над конкурентами лежит не в найме еще одного сотрудника, а в покупке или аренде нескольких видеокарт.

Чек-лист для принятия решения:

• Выявлен бизнес-процесс, который тормозит развитие (AI, рендеринг, симуляции).
• Измерены текущие временные и финансовые потери.
• Оценена потенциальная выгода от ускорения.
• Проанализирован характер нагрузки (постоянная/пиковая).
• Проведено сравнение CAPEX и OPEX на основе реалистичных расчетов ROI.

Потому что SQL, несмотря на свое превосходство в работе с данными, неудобен, ограничен и рискован в роли полноценного языка программирования.

Логика не по адресу

Как отмечает Эвальд Бенс, фуллстек разработчик и авторов популярного блога об IT, он предпочитает держать как можно больше логики в приложении, а не в SQL-хранилищах, представлениях и процедурах:

Я отношусь к базе как к тупому хранилищу данных. Вся логика — в коде. SQL просто не предназначен для сложных сценариев.

И дело не в том, что SQL чего-то «не умеет». Умеет — особенно с расширениями вроде PL/pgSQL или Oracle PL/SQL.

Но выразительность этих языков — далека от Python, TypeScript, Rust или C#, особенно когда речь идет о бизнес-логике, объектной модели или сложных расчетах.

Зачем выносить логику из базы?

1. SQL невыразителен

Для манипуляций с табличками и JOIN — он король. Но как только начинается рекурсия, классы, вложенные состояния или обработка ошибок — SQL превращается в монстра с BEGIN, IF, LOOP, EXCEPTION, RAISE, CURSOR, FETCH, WHILE и т.д...

2. Развертывание — боль

Обновить приложение можно за минуту, откатить — за две. А вот миграции на проде — это:

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

3. Лочит на вендора

Логика, написанная на PL/SQL — это билет в один конец к Oracle. Переезд на PostgreSQL или SQL Server становится в 5 раз сложнее.

4. Меньше инструментов

Вокруг SQL есть утилиты, но полноценной среды с юнит-тестами, статическим анализом, форматтерами, профайлерами, линтерами и отладчиками — почти нет.

А что с производительностью?

Да, есть нюанс: иногда лучше обработать данные прямо в базе, чтобы не гонять десятки тысяч строк по сети. Это особенно актуально, если не хочется получить классическую проблему N+1-запросов.

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

Что делать?

Подход «база — хранилище, логика — в коде» стал де-факто стандартом во многих командах. Но это не догма:

• Для отчетности или простых ETL сценариев логика в SQL может быть уместной.
• Для монолитных решений без CI/CD и DevOps — процедурный SQL вполне оправдан.
• Но в современной разработке с частыми релизами, микросервисами и отказоустойчивостью бизнес-логика в приложении — просто удобнее и безопаснее.

1. 10-Страйк: Мониторинг Сети Pro

10-Страйк: Мониторинг Сети Pro — это российская программа для системных администраторов, которая позволяет контролировать состояние сетевых устройств, серверов, рабочих станций, коммутаторов, баз данных и других ресурсов инфраструктуры. Она отслеживает ключевые параметры — от свободного места на дисках и загрузки процессора до температуры оборудования — и в случае проблем отправляет уведомления по email, SMS или в мессенджеры. Система может не только сигнализировать о сбоях, но и автоматически устранять их, например, перезапуская службы или выполняя скрипты.

Технические возможности

Продукт поддерживает десятки видов сетевых проверок через ICMP, SNMP, HTTP, SQL, SSH и другие протоколы. Возможно мониторить серверы Windows и Linux, сетевые службы, видеокамеры, принтеры, СУБД и промышленное оборудование. Визуализация данных доступна на карте сети с графиками и индикаторами. В версии Pro предусмотрен распределённый мониторинг с несколькими серверами и аген­тами, а также веб-интерфейс для удалённого управления.

Сценарии использования

Для DevOps и системных администраторов 10-Страйк подходит как инструмент централизованного мониторинга с алертами и картой сети. IT-отделы предприятий используют его для контроля доступности каналов связи, серверов, баз данных и устройств. Руководители могут формировать отчёты по аптайму и SLA для анализа стабильности работы инфраструктуры.

Особенности

Программа выделяется простотой настройки проверок, наличием наглядной карты сети и гибкой системой сигнализации. Важное преимущество — возможность распределённого мониторинга в удалённых сетях и работы в круглосуточном режиме без участия администратора. Решение разработано в России и подходит под задачи импортозамещения.

Тарифы и условия

Продукт распространяется по лицензии с ограничением на число сенсоров: версия Pro на 100 сенсоров стоит 40 000 рублей, стандартная версия — 20 000 рублей. Для корпоративных лицензий действует ограничение на количество серверов мониторинга.

2. Deckhouse Prom++

Deckhouse Prom++ — это Open Source-система мониторинга на базе Prometheus, которая потребляет до 10 раз меньше памяти. Она собирает метрики приложений, сервисов и инфраструктуры в реальном времени, хранит их во встроенной TSDB и поддерживает PromQL для анализа. Deckhouse Prom++ умеет формировать алерты и легко интегрируется с Grafana, оставаясь привычным для команд, которые уже работают с Prometheus.

Технические возможности

Deckhouse Prom++ может собирать любые инфраструктурные метрики напрямую или через экспортеры: состояние серверов, контейнеров, сетей, баз данных и приложений. Главная оптимизация по сравнению с «ванильным» Prometheus — переработка Write Ahead Log — позволяет снизить потребление памяти без ущерба производительности. Продукт полностью совместим с API и настройками Prometheus: дашборды, правила алертинга и интеграции продолжают работать без изменений. Prom++ уже используется на более чем 1000 кластеров и поддерживает до 10 млн активных метрик на кластер.

Сценарии использования

DevOps-инженеры и SRE могут использовать Deckhouse Prom++ для мониторинга Kubernetes и традиционной инфраструктуры. Архитекторы и CTO получают возможность сократить расходы на RAM без отказа от привычной экосистемы. Prom++ подходит и для on-prem, и для облачных окружений, а также уже встроен в Deckhouse Kubernetes Platform.

Особенности

Ключевое преимущество Deckhouse Prom++ — низкое потребление ресурсов: до 10 раз меньше памяти, чем у Prometheus, и до 3 раз меньше, чем у VictoriaMetrics. Сервис полностью совместим с экосистемой Prometheus, не создаёт вендорлока и распространяется под лицензией Apache 2.0. Поддержка осуществляется инженерами Deckhouse и сообществом через открытый Telegram-чат.

Тарифы и условия

Deckhouse Prom++ — полностью бесплатный Open Source-продукт. Ограничений по количеству пользователей или метрик нет.

Есть инструкция по миграции, потребуется только предварительная конвертация WAL-файлов. Вы также сможете без труда вернуться с Deckhouse Prom++ на Prometheus.

Инженеры Deckhouse и сообщество помогают пользователям в Telegram-чате Prom++ User Group.

3. GMONIT

GMONIT — российская платформа класса Observability, которая собирает и анализирует метрики, логи, трассировки и бизнес-показатели в едином интерфейсе. Она даёт ИТ-командам полный обзор цифрового контура: от сетей, серверов, баз данных и контейнеров до пользовательских действий и бизнес-метрик. GMONIT помогает перейти от «реактивного» реагирования на инциденты к проактивному управлению ИТ, сокращая время диагностики и повышая стабильность сервисов.

Технические возможности

GMONIT поддерживает мониторинг сетей, серверов, виртуальных машин, баз данных, контейнеров, API, реальных пользователей в браузере или мобильном приложении и бизнес-процессов. Система строится на микросервисной архитектуре, легко масштабируется и формирует дашборды для разных ролей — от инженеров до CIO. В одном интерфейсе доступны ключевые показатели доступности, SLA, конверсии, скорость обработки заказов и другие бизнес-метрики. Платформа обеспечивает предиктивную аналитику, раннее выявление аномалий и ускоренное RCA (Root Cause Analysis — анализ первопричин): TTD (Time To Detect — время до обнаружения) — менее 10 минут, RCA — около 15 минут.

Сценарии использования

• Разработчики используют GMONIT для отладки сервисов и мониторинга CI/CD, что ускоряет релизы и сокращает время устранения ошибок.
• QA-команды применяют платформу при нагрузочных тестах и фиксации ошибок в продакшене.
• DevOps и SRE получают централизованный мониторинг с алертами, предиктивной аналитикой и интеграцией в пайплайны.
• PM и CIO работают с визуальными панелями SLA, аптайма и бизнес-метрик, чтобы видеть реальное влияние инфраструктуры на продажи и пользовательский опыт.
• Поддержка сокращает время реакции на инциденты и устраняет сбои до того, как о них сообщают пользователи.

Особенности

GMONIT строится как масштабируемая система с единым «окном наблюдения»: метрики инфраструктуры, пользовательского опыта в браузере, приложений, API; а также вызовы во внешние сервисы и бизнес-процессы отображаются на одном дашборде. Архитектура ориентирована на работу с большими объёмами данных, а визуализация адаптирована как под инженеров, так и под управленцев. Сервис интегрируется с CI/CD, мессенджерами и сторонними системами через API. Поддерживаются как on-prem, так и облачные сценарии.

Тарифы и условия

Информацию о тарифах можно найти на официальном сайте GMONIT. Ограничений по числу пользователей и метрик нет. API и SDK доступны, а интеграции гибко настраиваются под нужды заказчика.

Управление и поддержка

Управление осуществляется через веб-интерфейс и API. Поддержка организована через чат, систему тикетов, SLA и подробную документацию.

4. Zabbix

Zabbix — это платформа мониторинга корпоративного уровня, которая обеспечивает полную наблюдаемость IT- и OT-инфраструктуры. Решение ориентировано на крупные компании и поставщиков управляемых услуг, отличается низкой совокупной стоимостью владения и предсказуемой моделью поддержки без лицензионных сборов. Zabbix создан для долгосрочного использования: он масштабируем, безопасен «по конструкции» и подходит для критически важных систем.

Технические возможности

Платформа поддерживает мониторинг серверов, приложений, облачных сервисов, сетевых устройств и IoT, включая многоуровневые среды. Важной функцией выступает вложенное низкоуровневое обнаружение, позволяющее автоматически создавать иерархические правила для хостов и сервисов. Zabbix предлагает мастер создания хостов, встроенную проверку форм для сокращения ошибок, расширенные сетевые карты и новый виджет карточки товара для детальной визуализации метрик. Платформа может быть развернута локально, в облаке Zabbix или в сторонних облаках (AWS, Azure, Google Cloud).

Сценарии использования

Zabbix применяют IT-отделы и DevOps-команды для централизованного мониторинга инфраструктуры и соответствия требованиям безопасности. Поставщики управляемых услуг используют его как MSP-дружественное решение с многопользовательским доступом и возможностью масштабирования под клиентов. Платформа востребована в высокозащищённых и регулируемых отраслях, где важны автономность и полный контроль над данными.

Особенности

Ключевые преимущества Zabbix — это открытый исходный код и отсутствие лицензионных ограничений. Архитектура платформы масштабируется «под будущее» и интегрируется с системами управления конфигурацией. Пользователи получают полное владение данными, гибкость в развертывании (on-premise, облако, гибрид) и широкие возможности кастомизации визуализации.

Тарифы и условия

Zabbix распространяется как решение с открытым исходным кодом и не требует лицензионных платежей. Стоимость формируется только за счет технической поддержки, которая предоставляется по фиксированным тарифам в зависимости от уровня сервиса.

5. LibreNMS

LibreNMS — это система мониторинга сетевой инфраструктуры с автоматическим обнаружением устройств и сервисов. Она ориентирована прежде всего на мониторинг сетей по SNMP, но также поддерживает серверы на Windows, Linux и FreeBSD через собственные агенты. Решение работает на базе PHP и MySQL, имеет удобный веб-интерфейс, мобильные приложения и широкий набор встроенных метрик, которые не требуют ручной настройки.

Технические возможности

Система автоматически обнаруживает топологию сети с помощью протоколов CDP, FDP, LLDP, OSPF, BGP, SNMP и ARP. Поддерживается интеграция с NfSen, collectd, SmokePing, RANCID и Oxidized. Встроенный API позволяет управлять установкой, строить графики и выгружать данные. Реализована гибкая система оповещений с поддержкой email, IRC, Slack и других сервисов, а также встроенная биллинговая система для учета использования полосы пропускания. LibreNMS поддерживает различные методы аутентификации, включая LDAP, Radius и Active Directory, и обновляется автоматически.

Сценарии использования

LibreNMS выбирают компании, которым важно быстрое развертывание мониторинга сети без сложной ручной настройки. Решение подходит интернет-провайдерам и корпоративным IT-отделам для учета трафика и выставления счетов, а также администраторам, которым нужен автоматический контроль устройств и серверов с оповещениями в удобных каналах. Благодаря мобильным приложениям и демо-версии система подходит для тестирования и удаленной работы.

Особенности

Ключевыми преимуществами LibreNMS выступают простота запуска и поддержка практически всех популярных сетевых устройств «из коробки». Автоматическое обнаружение и распределенный опрос упрощают масштабирование, а встроенный биллинг и интеграции делают систему полезной не только для мониторинга, но и для коммерческих задач.

Тарифы и условия

LibreNMS распространяется как проект с открытым исходным кодом и бесплатен для использования. Доступна онлайн-демонстрация (https://demo.librenms.org, логин: demo, пароль: demouser).

Участникам предоставляется доступ к менторской поддержке и отраслевой экспертизе, возможность сотрудничества с компаниями из инвестиционного портфеля Газпромбанка. В этом году программа включает три трека: Финтех, Диптех и Наука, каждый из которых ориентирован на разный уровень зрелости проектов — от стадии идеи до готового продукта с подтвержденным рыночным спросом.

Запуская эту акселерационную программу, мы делаем целенаправленные инвестиции в развитие российских технологий . Наша цель — создать инфраструктуру для трансфера перспективных разработок в реальную экономику. Программа открыта для проектов самого разного уровня — от смелой научной идеи до готового продукта с подтвержденным спросом. Мы уверены, что лучшие команды получат именно то, что нужно для роста: не просто финансирование, но также экспертизу, пилотные внедрения и прямой диалог с бизнес-заказчиками.

Финтех трек акселератора направлен на технологические решения, которые можно внедрить внутри банка. В фокусе:

• Маркетинг и новые каналы продаж, развитие клиентского сервиса и оптимизация клиентского пути;
• Кибербезопасность, управление рисками, антифрод (внутренний, пользовательский, внешний, транзакционный);
• Моделирование и скоринг, управление и работа с данными;
• Удобные и безопасные транзакции;
• Управление человеческим капиталом.

В этот трек принимаются проекты от стадии MVP с подтвержденной работоспособностью прототипа.

Технологический конкурс DeepTech-проектов ориентирован на привлечение инвестиций компаниями, разрабатывающими передовые решения по направлениям:

• Новые технологии сбережения здоровья;
• Экономика данных и цифровая трансформация государства;
• Космические технологии;
• Новые атомные и энергетические технологии;
• Новые материалы и химия;
• Средства производства и автоматизации;
• Технологическое обеспечение биоэкономики.

К участию приглашаются проекты, которые уже прошли стадию пилота или демонстрации в реальной среде и готовы к масштабированию.

Трек акселератора «Наука» открыт для ранних проектов, основанных на научных разработках. Участие возможно даже на стадии идеи — при наличии потенциала для технологического роста и будущей коммерциализации. В трек «Наука» приглашаются университеты - участники программы стратегического академического лидерства «Приоритет-2030» и проекта «Передовые инженерные школы».

Технологические направления проектов:

• Новые материалы и химия (катализаторы, малотоннажная химия, нефтехимия, моделирование и синтез катализаторов;
• Новые технологии сбережения здоровья (биомедтех, агротех,бионика, медицинские изделия);
• Средства производства и автоматизации (производственные технологии, станкостроение;
• Новые атомные и энергетические технологии (системы накопления энергии, электрохимия);
• Развитие многоспутниковой орбитальной группировки (космические технологии, плазменные двигатели, лазерная связь);
• Экономика данных и цифровая трансформация (микроэлектроника, квантовые технологии).

Полный список направлений и критериев отбора представлен на официальном сайте программы. Участие — бесплатное и открыто для юридических лиц и индивидуальных предпринимателей, зарегистрированных в России.

Программа реализуется в гибридном формате: ключевые активности проходят как в очном, так и онлайн форматах, а финальные презентации — на Демо-дне в очной форме.

При запуске акселератора организаторы опирались на успешный опыт предыдущего сезона и вывели его на новый уровень с расширенной программой и углубленной экспертизой. В прошлом году в программу подали заявки более 280 проектов по 14 направлениям. Эксперты Газпромбанка отобрали 20 финалистов, шесть из которых стали победителями. Все финалисты получили рекомендации по развитию продукта и провели встречи с профильными бизнес-заказчиками. По итогам акселератора два проекта уже запустили пилотные внедрения, еще пять находятся на стадии структурирования.

Смотреть видео о прошлогоднем акселераторе

Заявки принимаются до 10 октября 2025 г. в треки «финтех» и «диптех» и до в трек «наука» до 30 сентября через официальный сайт программы.

По вопросам участия: accelerator@twinscom.ru

Сайт: www.gazprombank.ru/business/accelerator-gpbtech-2025/

Реклама. Рекламодатель АО БАНК ГПБ, ИНН 7744001497, erid 2W5zFGRVg6c

BeeCR: автоматический помощник для ревью в GitLab

BeeCR — сервис, который автоматически просматривает изменения в запросах на слияние (Merge Requests) в проектах GitLab и добавляет к ним комментарии. Каждый файл, который вы меняете, получает свой набор комментариев.

Сервис пригодится всем, кто пишет код на популярных языках программирования, и понимает, зачем нужно код-ревью. BeeCR работает с кодом на Python, JavaScript, Java, Kotlin, Swift, C#, C++, Ruby, PHP, Go, Bash/Shell, TypeScript и др.

Этого помощника можно добавить в команды, где процессы уже работают с живыми специалистами, или внедрить код-ревью с нуля без лишних затрат по времени и деньгам.

Что именно проверяет?

BeeCR — это не замена линтерам или инструментам для строгой проверки кода по конкретным гайдам. Он действует скорее как человек-ревьюер. Сервис способен обнаружить:

• Нарушения логики в алгоритме.
• Лишний код, который случайно остался после отладки.
• Ошибочность информации в логах.
• Неудачное именование сущностей. Его задача — помочь найти неочевидные проблемы и дать рекомендации.

Как он встраивается в процесс разработки?

BeeCR бесшовно интегрируется с GitLab. Результаты автоматического ревью отображаются прямо в привычном интерфейсе GitLab Code Review, рядом с комментариями ваших коллег.

Есть два основных способа интеграции:

• Через Вебхук: это самый простой и удобный вариант для большинства. Вебхук BeeCR запускается автоматически при создании или обновлении Merge Request.
• Через CI/CD: если у вас уже есть развитая конфигурация GitLab CI/CD, этот вариант позволит выполнить более тонкую настройку. BeeCR предоставляет готовые конфигурации или шаблоны CI/CD-задач, которые можно использовать как есть или доработать. Для новых версий GitLab (начиная с 17) доступен CI/CD-компонент.

Можно ли настроить BeeCR под себя?

В BeeCR можно кастомизировать разные рабочие параметры:

• Язык комментариев: по умолчанию комментарии пишутся на английском, но вы можете указать другой язык, например, русский.
• Фильтрация файлов: управляйте списком файлов для проверки (или исключения) с помощью регулярных выражений.
• Языковая модель: в версии On-Premises можно выбрать языковую модель (например, OpenAI или Ollama) и настроить её параметры.
• Дополнительные инструкции: можно задать промты, чтобы получить более специфичные комментарии, через конфигурационный файл или комментарий в Merge Request.
• Триггер и путь к конфигу: вы можете переопределить ключевое выражение-триггер (по умолчанию /beecr) и путь к конфигурационному файлу .beecr.yml. Настройки задаются через HTTP-заголовки вебхука, параметры запроса в URL, конфигурационный файл .beecr.yml в корне репозитория, переменные окружения сервера API (для On-Premises) или параметры задачи CI/CD.

Как попробовать и сколько это стоит?

BeeCR предлагает пробный период на 1 месяц без ограничений. Стоимость рассчитывается по количеству активных участников в запросах на слияние в GitLab. К таким участникам относятся разработчики, ревьюверы, участники дискуссий и ответственные за слияние ветки. Сервис доступен в облачной версии (SaaS) или для локальной установки (On-Premises).

В версии On-Premises можно использовать как локально развернутые, так и внешние модели ИИ (например, ChatGPT), при этом оплата внешних моделей ложится на клиента. BeeCR включен в реестр Российского программного обеспечения (реестровая запись №25382 от 12.12.2024).

Reshift — автоматическая проверка безопасности JS-кода

Reshift предлагает легковесный JavaScript-плагин для npm, призванный выявлять уязвимости ещё на этапе разработки. Он выполняет быстрое сканирование изменений и даёт подсказки по исправлению, одновременно обучая и поддерживая разработчика через понятные рекомендации.

Поддерживаемые языки: JavaScript.

Что именно проверяет?

В функции плагина входят:

• Набор проверок безопасности, разработанных экспертами в области безопасности;
• Подробные, понятные описания обнаруженных проблем (DevSec Coach);
• Рекомендации по исправлению (remediation snippets);
• Ссылки на дополнительные ресурсы по уязвимостям.

Как встраивается?

Сейчас плагин доступен только ограниченной группе участников закрытого бета-тестирования. Чтобы подключиться, нужно записаться на waitlist через сайт Reshift.

Collaborator — расширенное ревью с фокусом на командную работу

Collaborator от SmartBear — это мощный инструмент для организации командного ревью кода, документации и тестов. Он не ограничивается автоматической проверкой — ключевая особенность сервиса в том, что он объединяет разработчиков, тестировщиков, аналитиков и технических писателей в едином процессе. Здесь ревью — это не только поиск ошибок, но и улучшение коммуникации внутри команды.

Практически все популярные языки программирования, включая Java, Python, JavaScript, C#, C++, PHP, Go, Swift, Kotlin и др. Также поддерживается ревью не только исходного кода, но и документации (Markdown, reStructuredText, HTML, PDF, Word) и тестовых сценариев.

Что именно проверяет?

Collaborator сочетает автоматическую проверку и ручное ревью, в его функции входят:

• Ревью исходного кода и документов (Word, PowerPoint, Visio, PDF, изображения, URL и др.)
• Совместное обсуждение изменений, пометки дефектов и контроль версий
• Возможность создания шаблонов ревью, чек-листов и пользовательских рабочих процессов
• Отчёты для анализа процессов, отслеживания дефектов и аудита

Как встраивается?

• Поддерживаются более 11 систем контроля версий: Git, Subversion, Perforce, TFS, CVS, Mercurial, ClearCase, AccuRev, Rational Team Concert и др.
• Также интеграция со средами разработки (Eclipse, Visual Studio), Jira, Web UI и API.

Можно ли настроить под себя?

• Создание чек-листов для обязательных пунктов ревью (например, безопасность, оптимизация, тестирование).
• Настройка уровней серьёзности комментариев (информация, предупреждение, ошибка).
• Возможность использования шаблонов ревью и шаблонов отчётов для стандартизации процесса.
• Поддержка метрик — можно отслеживать, сколько дефектов найдено, сколько времени уходит на ревью, кто из участников наиболее активен.

Как попробовать и сколько стоит?

Community — бесплатная для небольших команд (до ~10 пользователей), с базовым набором функций.

Team — платная, для средних команд (до ~25 пользователей), с расширенными возможностями ревью. $755 в год за пакет на 5 пользователей (до 25 человек).

Enterprise — полная версия для крупных организаций; включает мощные настройки, интеграции и поддержку Simulink моделей. Около $1349 в год за одну concurrent-лицензию, включая поддержку Simulink и расширенные возможности.

Codestriker — лёгкий инструмент для асинхронного ревью

Codestriker — это веб-приложение с открытым исходным кодом (написано на Perl под GPL), предназначенное для асинхронного код-ревью. Оно поддерживает работу с диффами из систем контроля версий и предоставляет удобный интерфейс для коллективного ревью.

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

Что именно проверяет?

Сам по себе Codestriker не выполняет глубокий автоматический анализ кода.

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

Основная функция — хранить диффы и обсуждения, предоставляя удобный интерфейс для комментариев и фиксации договорённостей.

Как встраивается в процесс разработки?

• Работает через веб-интерфейс, не требует сложной установки.
• Поддерживает загрузку диффов и изменений напрямую или через интеграцию с системами контроля версий.
• Сохраняет историю всех ревью для удобного поиска и аудита.
• Поддерживает экспорт результатов и комментариев в HTML или текстовые файлы — полезно для отчётности и архивирования.
• Интегрируется с системами контроля версий: CVS, Subversion, ClearCase, Perforce, Visual SourceSafe.
• Паспортная интеграция с баг-трекерами (Bugzilla, Flyspray) и системой LXR для быстрого просмотра кода.

Можно ли настроить под себя?

Можно дорабатывать под свои процессы, так как это open-source.

• Поскольку Codestriker — это open-source, его можно модифицировать под внутренние процессы: добавить плагины, интеграцию с баг-трекерами, отчёты в специфическом формате.
• Можно настраивать шаблоны комментариев, порядок отображения изменений, форматы экспорта.
• Код доступен для свободной доработки, что делает сервис особенно привлекательным для команд с собственными требованиями.
• Требует наличие сервера и СУБД — поддерживаются MySQL, PostgreSQL, Oracle, SQL Server и любая база через DBI.
• Разворачивается на сервере: конфигурация веб-сервера (Apache/IIS), базы данных, установка Perl-модулей.

Как попробовать и сколько стоит?

• Полностью бесплатен — распространяется под открытой лицензией.
• Можно развернуть на любом сервере или даже локально.
• Подходит как временное решение для небольших команд, так и как база для создания собственного инструмента ревью.

Gerrit — мощный инструмент для распределённых команд

Gerrit — это мощная open-source платформа для ревью кода, тесно интегрированная с Git. Она используется во многих крупных компаниях и open-source проектах, где требуется строгий контроль качества кода и формальный процесс утверждения изменений.

Поддерживаемые языки: любые Gerrit работает на уровне изменений в Git, а не конкретного языка. Можно ревьюить и код, и документацию, и конфигурационные файлы.

Проект начал развиваться как форк от системы Rietveld и был создан Шоном Пирсом (одним из авторов Git) для внутренней разработки Android в Google .

В версии 2.x проект был переписан с Python на Java (Java EE), с использованием SQL для метаданных. Начиная с версии 3.x, Gerrit перешёл на NoteDb, где все метаданные хранятся непосредственно в Git-репозитории.

Что именно проверяет?

Сам по себе Gerrit не выполняет статический анализ, но легко интегрируется с линтерами, CI/CD-пайплайнами и системами тестирования. Основная задача — управление процессом ревью: комментарии к конкретным строкам, обсуждения, обязательное одобрение перед слиянием. Поддерживает настройку правил мёрджа (например, «два апрува от сеньоров» или «все тесты должны пройти»).

Пользователи создают review, отправляя коммит на refs/for/branch, что отличает изменения, требующие ревью, от прямых коммитов. Ревьюеры могут голосовать, модель оценки, например, используется шкала от -2 до +2 для Code-Review и Verified чеков. Доступно изменение изменений в рамках одного change (patch set), с возможностью обсуждения и улучшения кода до принятия.

Как встраивается?

• Работает как веб-приложение поверх Git. Поддержка SSH и HTTPS для работы с Git-клиентами, возможность размещения и управления множеством репозиториев с продвинутым контролем доступа и репликацией (например, геораспределённые зеркала)
• Предоставляет визуальный интерфейс для сравнения изменений и обсуждения.
• Глубокая интеграция с Jenkins, GitHub Actions, GitLab CI и другими CI/CD-системами.
• Поддерживает fine-grained permissions — можно задать права на просмотр, комментирование и утверждение кода на уровне проекта, папки или файла.
• Расширяемый через серверные плагины, доступные в официальном репозитории.

Можно ли настроить под себя?

Доступны плагины, собственные скрипты, тонкая настройка прав доступа:

• Плагины для интеграции с трекерами задач (Jira, Redmine и др.).
• Скрипты для автоматизации ревью и проверки коммитов.
• Возможность настроить workflow под конкретный проект: обязательные шаги, правила коммит-месседжей, формат патчей.

Как попробовать и сколько стоит?

• Полностью бесплатен, распространяется под лицензией Apache 2.0.
• Можно развернуть на своих серверах или использовать облачные инсталляции.
• Отлично подходит для крупных команд с формализованным процессом разработки.
• Gerrit — полностью open-source. Обновления можно скачивать в виде .war или через Maven Central, подписанные ключом автора.
• Сообщество активно поддерживает релизы, документацию и обсуждения через форумы, Discord и пользовательские мероприятия.

Crucible — код-ревью с аналитикой и интеграцией в Atlassian

Crucible от Atlassian — это инструмент для код-ревью, ориентированный на большие компании, которым нужны интеграции с экосистемой Atlassian (Jira, Bitbucket, Confluence) и детальная аналитика по процессу ревью.

Поддерживаемые языки: любые, так как Crucible анализирует текстовые изменения. Есть готовые плагины для популярных языков.

Что именно проверяет?

• Логические ошибки;
• Историю коммитов с возможностью поиска;
• Потенциальные баги и нарушения стиля кода (с помощью подключаемых линтеров);
• Несоответствия между кодом и документацией;
• Общие архитектурные недочёты (в рамках командного обсуждения).

Доступны Review и обсуждения — есть возможность комментировать строки кода, запускать threaded-дискуссии, упоминания и встроенные обсуждения. Ленты событий показывают последние комментарии, обновления, активность команды.

Как встраивается?

• Поддерживает Git, SVN, Mercurial, Perforce и CVS.
• Интегрируется с Jira — можно привязывать задачи к конкретным ревью.
• Есть возможность планировать ревью, назначать ответственных, отслеживать прогресс и статистику по команде.
• Поддерживает расширение через REST API, можно создавать надстройки через плагины.

Можно ли настроить под себя?

Это кроссплатформенное (Windows, Linux, macOS) Java-приложение — требует x86‑64 или аналогичный. Подключаются официально поддерживаемые СУБД: HSQLDB (для тестирования), MySQL, PostgreSQL, Oracle, SQL Server.

• Настраиваемые шаблоны ревью.
• Чек-листы для проверки типовых требований.
• Автоматические уведомления и напоминания для участников.
• Гибкая настройка прав доступа.

Как попробовать и сколько это стоит?

• Платная лицензия: от $10 для 5 пользователей, далее цена зависит от команды.
• Есть 30-дневный бесплатный пробный период.
• Оптимально для компаний, уже использующих Atlassian Jira и Bitbucket.