Research Insights Made Simple

Модель поместилась в GPU, тестовый запрос отработал быстро. Что произойдёт, когда одновременно придут сотни запросов с разной длиной контекста и ответа? 23 сентября 2026 года в эфире Research Insights Made Simple #32 разберу whitepaper 2023 года про vLLM и устройство инференса LLM: как управление памятью, планирование запросов и передача состояния между узлами влияют на скорость сервиса. Начнём с KV-кеша — ключей и значений уже обработанных токенов, которые модель сохраняет для следующих шагов генерации. Посмотрим, как PagedAttention применяет идеи виртуальной памяти к этому кешу и позволяет эффективнее размещать активные запросы на GPU. А дальше разберём, какие задачи приходится решать вокруг движка. Выпуск для инженеров, архитекторов и платформенных команд, которые разворачивают LLM, выбирают движок инференса или хотят понять, что происходит за API модели. Исследование PagedAttention, SOSP 2023:https://arxiv.org/abs/2309.06180 Все выпуски Research Insights Made Simple:https://polomodov.tech/research-insights/ Timeline00:00 - Почему возвращаемся к статье 2023 года03:26 - Обработка промпта и генерация токенов06:09 - Бюджет памяти и цена KV-кеша11:10 - Резерв и два вида фрагментации13:36 - Почему даже знание длины ответа не спасает Orca15:58 - Страничная память: идея из операционных систем19:42 - PagedAttention и косвенный доступ к блокам23:36 - Как растущий запрос получает новые блоки26:11 - Общий префикс и копирование при записи29:44 - Дерево блоков для beam search32:21 - Вытеснение: перенос или повторное вычисление36:01 - Планировщик и рабочие процессы GPU38:05 - Пропускная способность при той же задержке39:17 - Цена косвенности и выбор размера блока41:37 - Инженерные выводы и границы применимости

В этом выпуске разберу, как провести границу владения AI-стеком и связать модель, агентную обвязку, инструменты, контекст и проверки результата в работающую систему. Поговорим о том: Когда использовать готовый цикл агента и где оправдана собственная обвязка; Почему способности модели, полномочия агента и выполненная задача — три разных вещи; Какие проблемы можно исправить маршрутизацией, контекстом и контрактами инструментов, а какие требуют изменений модели или инфраструктуры; Чем телеметрия отличается от evals и данных для обучения; Как сохранить эпизод, воспроизвести его, изменить один слой и проверить результат повторным прогоном; Когда повторяемую задачу можно передать меньшей модели и при каких условиях возвращать её большой. Выпуск для инженеров, архитекторов, руководителей разработки и платформенных команд, которые выбирают или строят AI-инструменты для SDLC. Слайды доклада на Deep Tech Night:https://polomodov.tech/2026-09-05-deep-tech-night-ai-development-stack-codesign/ Все выпуски Research Insights Made Simple:https://polomodov.tech/research-insights/ Напишите в комментариях, какую часть AI-стека вы уже делаете сами и почему. Это как раз те решения, на которых хочется проверить предложенную рамку. Timeline00:00 - Зачем понадобилась режиссёрская версия02:42 - Что арендовать, дорабатывать и чем владеть14:15 - Маршрутизация, контекст и внутренние адаптеры18:15 - Полномочия агента и границы делегирования22:39 - Трассировка, проверки качества и переносимость26:04 - Почему модель — только часть системы33:10 - Как начать собирать проверочные случаи39:20 - Быстрый и медленный циклы улучшений45:58 - Как проверить полезность контекста48:37 - Разные способы связать слои AI-стека1:02:27 - Инструменты: MCP, ошибки и конечное состояние1:06:40 - Почему демонстраций и телеметрии недостаточно1:13:28 - Каталог проверяемых инженерных эпизодов1:19:30 - Меньшие модели и разделение планирования и исполнения1:21:50 - Что стоило изменить во внедрении и безопасности

Представим, что сборки стали быстрее, AI помогает писать код, а графики активности растут. Как понять, что команде стало легче достигать полезного результата? Кто тратит время на проверку, объяснение и сопровождение того, что удалось быстрее создать? В Research Insights Made Simple #30 соберу исследования и мои разборы серии в общую картину: от целей инженера и методов измерения до качества, совместной работы и последствий использования AI. Посмотрим, как скорость, удобство работы и качество результата связаны между собой и какие вопросы стоит задавать перед выбором метрик. В выпуске: Цели разработчиков: что именно человек пытается сделать и где заканчивается задача; Измерения: как сопоставлять логи, опросы и наблюдения и что делать, когда они дают разную картину; Рабочая среда: ожидание сборок, предсказуемость, сосредоточенность и переключения; Адаптация новичков: как учитывать обучение, самостоятельность и время наставника; Качество и технический долг: процесс, код, система, продукт и цена будущих изменений; Командная работа: помощь коллегам, передача контекста и перенос нагрузки между командами; AI-инструменты: потребности разработчика, доверие, проверка результата и сохранение возможностей учиться. В конце предложу практический план первого месяца для вашей команды: выбрать одну инженерную цель, собрать исходную картину, попробовать одно ограниченное изменение и вместе с командой оценить последствия. Это отправная точка для вашей программы улучшений. Выпуск для руководителей разработки, тимлидов, платформенных команд и инженеров, которые хотят понять, какие изменения действительно помогают в работе. Timeline00:00 - Почему активность не равна результату07:56 - Скорость, простота и качество13:50 - Цели инженеров вместо отдельных инструментов21:16 - Опросы, интервью и эксперименты25:18 - Какая метрика помогает принимать решения29:24 - Сборки: ожидание, предсказуемость и адаптация36:55 - Сосредоточенность, гибридная работа и новички43:12 - Четыре уровня качества и роль архитектуры56:38 - Что изменится, если технический долг исчезнет1:03:56 - Командная работа и цена локального ускорения1:08:26 - Творчество и переиспользование решений1:13:43 - Какую помощь инженеры хотят от ИИ1:16:52 - Место человека в агентном процессе1:19:14 - Четыре противоречия ИИ и долг понимания1:27:36 - Первый месяц улучшений и доверие команды

Кодинговые агенты уже пишут код гораздо быстрее. Но если планирование, архитектурное ревью, безопасность, тестирование и деплой остаются на «человеческой скорости», ускоряется ли delivery — или очередь просто переезжает в соседний этап? 27 августа в 14:00 в прямом эфире Research Insights Made Simple вместе с Антоном Костериным, principal engineer RnD-центра Т-Банка, разбирали свежий материал Anthropic — "The AI-Native SDLC playbook" (https://claude.com/blog/the-ai-native-sdlc-playbook) С Антоном мы уже говорили об architecture governance, RFC/ADR и архитектурных ревью (https://youtu.be/CEii3K0hAUw). Теперь вопрос шире: как перестроить под агентов не только написание кода, но весь SDLC. Тезис playbook: после ускорения Build bottleneck смещается в Plan, Test/Review и Deploy. Anthropic предлагает замкнуть шесть стадий, от Plan до Maintain, в цикл. intent.md, spec.md, plan.md, diff с тестами, результаты review и записи об инцидентах образуют цепочку версионируемых артефактов и одновременно audit trail. Человек остаётся ответственным, но подключается в точках, где действительно требуется суждение. Обсудим: Действительно ли код перестал быть узким местом и где теперь скапливается очередь; Зачем нужны markdown-артефакты, если уже есть Jira, wiki и архитектурные процессы; Как превратить знания компании в CLAUDE.md, skills и проверяемые политики, не законсервировав ошибки; Как связать continuous evals, hooks, агентное и человеческое review с production monitoring; С какого участка SDLC начинать и какими метриками доказывать эффект. Это практическое руководство команды Claude, а не исследование со сравнительным экспериментом. Поэтому отдельно проверим, где здесь переносимый инженерный подход, а где пока видение поставщика — особенно для большой регулируемой организации.Timeline00:00 - Антон Костерин: как устроен AI-native SDLC03:59 - Чем полезен playbook и почему знакомые практики снова актуальны08:22 - Планирование: превращаем идею в intent.md13:26 - Проектирование: spec.md и ограничения организации16:57 - Skills как способ задать правила работы агента20:04 - Разработка начинается с проверенного человеком plan.md24:22 - CLAUDE.md, hooks, команды и агенты в рабочем цикле29:21 - Первоначальные вложения, доверие и принятие нового процесса35:35 - Тестирование: детерминированные проверки в CI/CD38:20 - Непрерывные evals для проверки работы агентов40:54 - Развёртывание: знакомые механики и практический рецепт44:54 - Проверка кода как новое узкое место48:23 - Эксплуатация: инцидент запускает новый цикл разработки53:37 - От инструкций по восстановлению к самостоятельной работе агента1:03:44 - Как применять playbook на практике #AI4SDLC #AI #Agents #Engineering #Architecture #DevOps #Research

В шестом выпуске (https://t.me/book_cube/2874) Research Insights Made Simple мы с Николаем Головым разбирали, как строить дата-платформы в 2025 году. В 28 выпуске мы возвращаемся к теме с вопросом посложнее: что происходит, когда аккуратная схема из storage, compute, catalog и orchestration встречается с legacy, стоимостью миграции и реальными аналитическими запросами? В гостях Николай Голов (https://harbour.space/faculty/Nikolay-Golov) и Александр Филатов. Николай — директор по продукту Tengri Data, в прошлом руководитель дата-платформ в Avito и ManyChat и преподаватель Harbour.Space. Александр пришёл в DWH из backend-разработки: до этого писал инструменты обработки данных на Python и C++. Почти десять лет он развивал хранилище данных Авито, в 2022–2025 годах занимался переходом с Vertica на Trino/Iceberg/S3, а теперь возглавляет разработку Tengri Data. Поговорим о том: - Где проходит граница между OLTP и OLAP, почему аналитика на реплике быстро упирается в потолок и отчего «давайте просто прикрутим ClickHouse» — ещё не архитектура;- Как профиль чтения и записи меняет устройство системы и почему инженеру важно отличать то, что аналитик просит, от того, что ему действительно нужно;- Когда классическое MPP-хранилище становится тормозом и что на практике даёт разделение storage и compute в Lakehouse;- Как переехать на новый стек, не остановив аналитику: параллельные контуры, проверка результатов, стоимость и эксплуатационные риски;- Что AI-агенты меняют в требованиях к платформе — от метаданных и прав доступа до прозрачности действий и контроля ресурсов;- Нужна ли в итоге отдельная AI-native дата-платформа или хороший фундамент остаётся тем же. Хочется уйти от каталога модных технологий и разобрать инженерные компромиссы: когда миграция действительно нужна, чем за неё придётся заплатить и какие решения выдерживают не только презентацию, но и production. Прямой эфир пройдет сегодня (24 августа) в 16:00.