Книжный куб

Залетайте на прямой эфир с Кириллом Евсеенко, техническим директором Звука. Мы с Кириллом планируем обсудить его карьеру, а также ответить на вопрос, а где у CTO больше свободы - в стартапе или в корпорации. Если будет вопросы, то мы с удовольствием по ходу будем на них отвечать.

[2/2] DistServe: параллелизм, очереди и баланс GPU (Рубрика #Research) В первой части поста мы остановились на разделения prefill и decode. И после этого у нас появляется свобода: каждой стадии можно выделить свои GPU и по-своему распределить модель. Теперь эту свободу надо превратить в работающую конфигурацию. Есть два подхода к параллелизму: - Intra-op делит одну операцию, например умножение матриц, между GPU. В этом контексте — tensor parallelism. Отдельный шаг выполняется быстрее, но GPU часто обмениваются данными. Ускорение зависит от того, сколько съедает коммуникация. - Inter-op делит слои модели на стадии конвейера — pipeline parallelism. Пока одна GPU обрабатывает следующий запрос, другая заканчивает предыдущий. Запрос всё ещё проходит все стадии; зато конвейер пропускает больше запросов. Расплата — простои, если стадии загружены неравномерно. То есть можно ускорять прохождение одного запроса, а можно увеличивать частоту, с которой конвейер принимает следующие. Под нагрузкой второй вариант тоже сокращает задержку: меньше времени уходит на ожидание входа. Здесь авторы достают из чулана теорию очередей. Для начала они упрощают prefill: одинаковые промпты, постоянное время обработки D, пуассоновский поток R запросов/с, одна обслуживающая очередь без батчинга. Получается модель M/D/1: TTFT = D + R·D² / [2·(1 − R·D)] Это среднее время: вычисление плюс ожидание. Формула работает при R·D < 1. Если D = 100 мс, при 5 запросах/с среднее TTFT составит 150 мс, а при 9 запросах/с — 550 мс. Само вычисление осталось тем же. Выросла очередь. Для двух GPU авторы сравнивают: - intra-op: D/K + R·D² / [2K·(K − R·D)] - inter-op: D + R·D² / [4·(2 − R·D)] K — ускорение intra-op, здесь между 1 и 2. Во втором случае предполагаются две равные стадии и пренебрежимо малый обмен между ними. Каждая формула применима, пока соответствующая очередь устойчива. При редких запросах intra-op выигрывает за счёт быстрого вычисления. По мере роста потока inter-op может выиграть за счёт очереди. Очень строгий TTFT снова делает скорость отдельного запроса критичной. У decode свой баланс: размер батча, память под кэш и требование к TPOT. Правила «prefill всегда так, decode всегда иначе» здесь нет. Но реальные промпты и ответы разной длины, а сервису нужна заданная доля запросов в SLO. Одной формулы среднего недостаточно. Поэтому дальше ребята переходят к симуляции нагрузки. DistServe использует модель времени вычислений и профиль запросов: интенсивность поступления, распределения длин входа и выхода. Перебирает допустимые конфигурации параллелизма и размещения, а бинарным поиском находит поток, при котором ещё соблюдается целевой SLO attainment. Затем подбирает число экземпляров стадий под требуемую нагрузку. При медленной сети варианты prefill и decode приходится выбирать совместно. Получается баланс для конкретной модели, железа, нагрузки и SLO. Когда профиль меняется, расчёт надо повторять. Формулы объясняют механизм, симулятор помогает выбрать конфигурацию; проверка на настоящем кластере остаётся необходимой. В продолжении рассмотрении этой темы дальше я планирую прочитать несколько статей и потрогать llm-d. План примерно такой - Splitwise, ISCA 2024 — соседняя работа про выбор разного железа для фаз, стоимость и энергопотребление. - Sarathi-Serve, OSDI 2024 — другая ветка: дробить prefill на части и совмещать их с decode через планирование батчей. - Mooncake, FAST 2025 — другой масштаб: распределённый KV-кэш, его хранение и повторное использование становятся центром архитектуры. А в мае 2025-го llm-d уже предложил объединять disaggregated serving и маршрутизацию с учётом кэша с Kubernetes-инфраструктурой. Так что через эти работы можно пройти путь от разделения двух стадий до управления вычислениями и состоянием всего кластера. #Research #AI #Architecture #Engineering #DistributedSystems

[1/2] DistServe: зачем разделять prefill и decode (Рубрика #Research) Этот пост посвящен статье DistServe от команды из Peking University, UC San Diego и StepFun, опубликованной на OSDI 2024. Причем в разборе llm-d я уже рассказывал про разделение prefill и decode. А в работе DistServe очень хорошо разобрана инженерная сторона этого решения: что выигрываем, когда разносим стадии по разным GPU, и чем за это платим. Помимо самой статьи есть и открытый код который позволяет не только посмотреть на результаты авторов, но и почитать при желании код. Если возвращаться к основной теме, то у запроса к LLM есть две довольно разные части: - Prefill обрабатывает входной текст, вычисляет KV-кэш и первый токен ответа. Позиций много, их можно обрабатывать параллельно; при достаточно длинном промпте стадия обычно упирается в вычислительную мощность. - Decode выпускает следующие токены по одному на запрос. При небольшом батче вычислений относительно мало, а веса и кэш приходится читать из памяти снова и снова. Здесь ограничением часто становится её пропускная способность. Объединение запросов в батч помогает эффективнее использовать GPU. Когда обе стадии живут вместе, новый тяжёлый prefill задерживает уже идущую генерацию. Даём приоритет decode — новые пользователи дольше ждут начала ответа. Плюс обеим стадиям достаётся одна конфигурация параллелизма, хотя потребности у них разные. В DistServe процесс выглядит так: Запрос → очередь prefill → обработка промпта и первый токен → передача KV-кэша → очередь decode → генерация остальных токенов. У prefill- и decode-экземпляров свои копии весов модели. KV-кэш содержит промежуточные ключи и значения attention: с ними другая GPU продолжает вычисление, не обрабатывая промпт заново. Prefill и decode теперь можно отдельно масштабировать и настраивать. Дальше начинается знакомая жизнь распределённой системы: появились сеть, дополнительная память и ещё одно место, где может вырасти очередь :) Для OPT-66B авторы оценивают кэш промпта из 512 токенов примерно в 1,13 ГБ. При 10 запросах/с это около 90 Гбит/с только на кэш. Причём совпадения средней потребности с полосой мало: всплескам нагрузки нужен запас. Если decode принимает работу медленнее prefill, готовые кэши тоже начинают ждать и занимать память. Поэтому DistServe учитывает топологию. При медленной сети между серверами соответствующие стадии prefill и decode размещаются на разных GPU внутри одного сервера, чтобы передавать кэш по NVLink. В их измерениях более 95% запросов передавали кэш менее чем за 30 мс. Цель авторов — goodput на GPU: предельный поток запросов при заданной доле соблюдения требований к задержке (SLO). Проверяются TTFT (time to first token) — время до первого токена — и TPOT (time per output token), среднее время на следующий токен. Обычно целевая доля — 90% запросов. Средний TPOT, кстати, ещё не гарантирует отсутствие отдельных пауз в генерации. Они проверяли свой подход на OPT-13B/66B/175B, кластере из 32 A100 и данных для чата, дополнения кода и суммаризации. В чатовых тестах получили в 2–4,6 раза больший поток на GPU относительно тогдашнего vLLM; максимум 7,4 раза — относительно DeepSpeed-MII. Это выигрыш всей конфигурации при выбранных SLO. Времена поступления запросов синтезировали, а пороги задержки задали сами; переносить множители на произвольный сервис нельзя. Остаётся самая интересная часть: сколько GPU выделить каждой стадии и как разложить на них модель. Во второй части поста будет рассказ про intra-op, inter-op и теорию очередей, которая помогает понять, почему самый быстрый отдельный запрос ещё не определяет лучшую конфигурацию сервиса. #Research #AI #Architecture #Engineering #DistributedSystems

Кстати, выпуск 3 AImigo про джунов стартанул.

Материалы выпуска: первые 90 дней CTO (Рубрика #Leadership) Собрал материалы сольного выпуска Code of Leadership «Первые 90 дней CTO». Эфир прошёл 9 сентября 2026 года — это расширенная версия доклада, который я рассказывал на мероприятии Стратоплана. Начинаю с того, что первый рабочий день — уже середина перехода. Компания выбрана, ожидания сформированы, о части полномочий вы уже договорились. А о части, возможно, решили поговорить потом. Вот это «потом» и может оказаться самым интересным местом испытательного срока :) В выпуске разобрал: - Что скрывается за названием CTO. Главный архитектор, партнёр продукта, руководитель масштабирования и человек, которого зовут разбираться с кризисом, — очень разные работы. Как заранее понять, какая из них нужна компании, и проследить связь технологий с деньгами бизнеса. - О чём договориться до выхода. Какого результата ждут через 30 и 90 дней, что вы можете менять самостоятельно, какие есть бюджет и кадровые полномочия, кто поддерживает изменения. Это важно и при внутреннем повышении: знакомая компания не делает договорённости очевидными. - Как провести первый месяц. С кем поговорить, на какие рабочие процессы посмотреть и как отделять факты от чужих интерпретаций. Фраза «в прошлой компании мы делали так» легко мешает увидеть, что здесь устроено иначе. При этом срочные угрозы безопасности и непрерывности бизнеса не ждут конца диагностики. - Что выбрать на дни 30–90. Одно-два изменения с понятной болью, владельцем и наблюдаемым результатом. Как проверить гипотезу в пределах испытательного срока, заработать доверие и не замкнуть все решения на себе. - Что делать, если обещания разошлись с реальностью. Мандат сузился, бюджет не появился, поддержка исчезла. Как назвать расхождение, зафиксировать его и поставить срок для новой договорённости, пока ответственность ещё можно привести в соответствие с полномочиями. Моя рамка здесь — испытательный срок проходит и компания. Она тоже проверяется: можно ли в ней решить ту задачу, ради которой вас нанимали. Материалы выпуска: 📌 Страница выпуска с таймкодами и слайды доклада 📖 Лонгрид о переходе в роль CTO 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Конспект эфира Какая договорённость при выходе на руководящую роль у вас оказалась самой важной — или выяснилось, что её стоило обсудить заранее? Делитесь в комментариях. #CodeOfLeadership #Management #Leadership #CTO #Career #Engineering

Randy Shoup про eBay: инженерия ускорилась, а система — нет (Рубрика #Management) Супер-крутой доклад — прямо много попаданий в реальность. Пока слушал, то и дело ловил дежавю. И у этой истории есть первый акт: в 2023 году я уже разбирал, как Randy Shoup с командой удвоил engineering productivity в eBay. Новый доклад — неприятный второй акт. Техническая трансформация сработала, а траектория бизнеса и культура руководящего слоя, по оценке Шоупа, почти не изменились. Шоуп был Chief Architect и VP of Platform Engineering в eBay в 2020–2022 годах. По его данным, инициатива Velocity дала 2× по числу features и bug fixes на единицу времени. Deployment frequency выросла в 10 раз, lead time сократился с 10 до 2 дней, change failure rate и time to recover улучшились втрое. Это цифры из доклада и слайдов, а не независимый аудит. Но масштаб всё равно впечатляет: около 5000 инженеров в компании; Velocity со временем охватила 400 продуктовых команд и 4500 приложений и сервисов. Секретного фреймворка не было. Команды спрашивали: если завтра придётся выкатываться ежедневно, что именно вам помешает? Ответы становились бэклогом Platform Engineering. Дальше — сокращение build, test и PR validation time, автоматизация deployment и обновлений, общая staging-среда, DORA как outcome-метрики и developer friction как входной сигнал. Но важнее инструментов была механика взаимодействия. Сильных IC из платформы встраивали в продуктовые команды, руководители синхронизировались ежедневно, команды делились локальными автоматизациями, а Security, Compliance, Accessibility и Localization переставали быть внешними «воротами» и становились участниками улучшения потока. Начали с пилотов, затем расширялись квартальными когортами и повторяли цикл: нашли bottleneck, сняли, посмотрели, кто теперь получил повышение. А затем Шоуп задаёт неприятный вопрос: если инженерная продуктивность выросла вдвое, почему это не развернуло бизнес? Его ответ состоит из трёх слоёв. 1️⃣ Стратегия и планирование Годовой план собирался централизованно и надолго. Работа получала деньги, только если была достаточно большой для executive-level инициативы; небольшие изменения выживали как «прицеп» к гигантским программам. Новые знания появлялись, а курс уже нельзя было менять. 2️⃣ Execution Нормой оставались релизы на десятки команд и годы работы. Вознаграждалось выполнение обещанного списка, а не изменение клиентской или бизнес-метрики. То есть feature factory стала выпускать больше features — ровно как и было заказано. 3️⃣ Культура Используя типологию Ron Westrum, Шоуп описывает её как pathological: страх ошибок, поиск виноватого, zero-sum борьба руководителей за scope и headcount, Not Invented Here. В такой системе осторожность — не дефект отдельных людей, а рациональная стратегия выживания. Вот здесь дежавю становится особенно сильным. Ускорить CI/CD политически проще, чем изменить бюджетный процесс, права на решения и систему стимулов. Можно дать командам прекрасную дорогу, но если маршрут определён 18 месяцев назад, они просто быстрее приедут не туда. В ретроспективе Шоуп считает, что поддержки CEO сверху и энтузиазма команд снизу оказалось недостаточно: трансформации нужен ещё middle-out — союз с peer-руководителями, чьи границы и стимулы она неизбежно затрагивает. Его рассказ об увольнении и культуре — личная версия событий, не независимое расследование. Но именно поэтому доклад хорош: автор не продаёт очередной transformation playbook, а честно показывает предел уже успешного. И да, в 2026 году невозможно не увидеть продолжение про AI. Если агенты ускорят производство кода, но не выбор задач, обратную связь и принятие решений, feature factory просто получит двигатель помощнее. Поэтому до вопроса «насколько мы ускорились?» стоит задать другой: «а инженерная скорость вообще ограничивает результат всей системы?» #Management #Leadership #Culture #DevOps #PlatformEngineering #Engineering #Metrics

AI4SDLC на ИТ-Пикнике: материалы выступления (Рубрика #AI4SDLC) Собрал материалы моего выступления на ИТ-Пикнике 8 августа — «State of AI4SDLC: AI сдвигает узкие места разработки». Это было моё последнее выступление от имени Т-Банка. В нём я подвёл итог AI4SDLC в том виде, в котором развивал это направление: с исследованием, инженерной платформой, агентами и перестройкой работы команд. В докладе разбираю, что происходит после того, как код научились писать быстрее. Задачи начинают скапливаться на ревью и тестировании, а дальше выясняется, что ограничением стали постановка и приёмка результата. Выдать всем AI-инструменты — только начало работы. Отсюда и остальные темы: зачем снова нужны спецификации, как подготовить внутреннюю платформу к работе агентов, почему стоит измерять ожидание, переделки, качество и стоимость. И как меняется работа инженера, который всё больше формулирует задачи, собирает контекст и проверяет сделанное агентами. Материалы можно открыть в удобном формате: — Слайды — Видео выступления — Конспект и сокращённая расшифровка — около 7 минут чтения, подготовлены по субтитрам и слайдам. #AI4SDLC #Agents #PlatformEngineering #Conference

ArchDays в эпоху AI (Рубрика #Architecture) Я в программном комитете ArchDays с 2019 года, с основания конференции. Мне кажется, в эпоху AI такие встречи особенно важны. Когда AI пишет код, вопросы к архитектору только прибавляются. Как поставить задачу, чтобы результат можно было проверить? Где нужны ревью и участие человека? Кто отвечает за решение, которое предложил агент? Быстрее получить код — еще не значит быстрее получить работающую систему. Поэтому для меня архитектурная конференция сегодня — это возможность не просто узнать про новые технологии, но и разобраться в редизайне инженерных процессов: от требований и экспериментов до проверки изменений и эксплуатации. А еще — понять, как меняется профессия архитектора. Думаю, все больше внимания придется уделять тому, как люди и AI вместе принимают решения и проверяют их последствия. Здесь полезно сравнить опыт команд, обсудить ошибки и поспорить с коллегами. ArchDays — 27 ноября 2026. Приходите обсуждать. P.S. Я хотел по традиции выступить на этой конфе, но я буду уже не в Москве, а она полностью в оффлайне. Но думаю, что мы с Сережей Барановым придумаем как мне рассказать свой доклад может быть не в рамках конфы, а в виде отдельного онлайн эфира на youtube канале Archdays. #AI #Engineering #Conference

Материалы выпуска: продуктовый инженер — разговор с Глебом Михеевым (Рубрика #Leadership) Собрал материалы разговора с Глебом Михеевым, CPO ГигаАгента в Сбере. Эфир Code of Leadership прошёл 8 сентября 2026 года. Говорили о том, что происходит с работой инженера, когда можно быстро получить несколько работающих реализаций — и всё равно остаётся вопрос, какую из них вообще стоило делать. Глеб рассказал, как на полгода вернулся из менеджмента в индивидуальную инженерную роль и каждый день работал с агентами. Из этого опыта вырос разговор о продуктовой ответственности, устройстве команд и обучении. Обсудили: - Продуктового инженера. Понять проблему пользователя, предложить решение, выпустить его и собрать обратную связь. Как дать человеку такую ответственность и не навесить на него несколько прежних должностей с прежней нагрузкой. - Очередь после ускорения. В разговоре есть хороший мысленный пример: если разработка ускорилась в пять раз, нижние четыре пятых старого бэклога от этого полезнее не стали. Дальше упираемся в выбор гипотез, проверку результата и эксплуатацию. - Размер команды и границы специализации. Глеб считает, что агенты позволят небольшим командам закрывать больше работы. Но для платёжных и других критичных систем он делает оговорку: там цена ошибки требует более строгой проверки и сохранения специализации. - Рост джунов. Готовый pull request уже мало говорит о том, чему человек научился. Как проверить, что он может объяснить устройство решения, заметить ошибку и разобраться, если условия задачи изменились. - Переучивание опытных разработчиков. Как перестроить привычку делать всё руками, сохранить инженерное суждение и не застрять в бесконечном цикле «ещё одну задачу агенту — и спать». Материалы выпуска: 📌 Страница выпуска с таймкодами 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект #CodeOfLeadership #AI4SDLC #Engineering #Product #Leadership #Career

Stanford MS&E435: от мегаватта до молекулы — весь курс в девяти разборах (Рубрика #AI) С курсом Stanford MS&E435 «Economics of the AI Supercycle» в канале всё: девять лекций — девять разборов, от экономики GPU и строительства дата-центров до кодинговых агентов и разработки лекарств. Курс интересен тем, что не пытается выбрать «лучшую модель», а рассматривает AI как большую производственную и экономическую систему. На каждом слое повторяются одни и те же вопросы: где сейчас бутылочное горлышко, кто оплачивает капитальные затраты, что становится commodity, а у кого остаются влияние на цены, данные и замкнутый цикл обратной связи. Если сложить лекции вместе, бутылочное горлышко всё время переезжает: из чипов — в электричество и готовые дата-центры, затем в корпоративный контекст, человеческое внимание, evals, дистрибуцию и лабораторный эксперимент. Вместе с ним перемещается и граница между тем, что компания может купить как услугу, и тем, что ей приходится контролировать самой. Все разборы по порядку: 1️⃣ Экономика AI-суперцикла — вводная лекция интересна картой всего стека chips → infrastructure → models → applications и вопросом, почему основная экономика пока сосредоточена внизу. 2️⃣ Inference как производственная система — разговор с Sunny Madra и Brad Gerstner показывает, почему prefill и decode могут требовать разного железа, а считать полезнее стоимость проверенного результата, а не число сожжённых токенов. 3️⃣ Дефицитный мегаватт AI-фабрики — Чейз Локмиллер из Crusoe опускает «облачный AI» на землю: к подстанциям, охлаждению, стройке и дефициту площадок, где GPU вообще можно включить. 4️⃣ Али Годси: AGI уже здесь, а компания — ещё нет — лекция интересна кейсом Databricks, в котором заметный рост throughput появился после перепроектирования процесса, а не после замены модели. 5️⃣ Sachin Katti и человек как bottleneck AI-системы — взгляд оператора frontier-лаборатории связывает динамические агентные нагрузки, гетерогенную инфраструктуру и цену человеческого внимания, проверки и ответственности. 6️⃣ Yash Patil: внутреннее знание компании как learning loop — здесь корпоративная экспертиза превращается из абстрактного «контекста» в evals, reward, post-training и воспроизводимый цикл обучения. 7️⃣ Кто выбирает технологический стек — разработчик или кодинговый агент? — Guillermo Rauch показывает, как агент становится новым gatekeeper, а open source, документация и агентная эргономика — каналом дистрибуции. 8️⃣ Baseten и как юнит-экономика меняет стратегию — история полезна симметрией: по мере роста приложение забирает под контроль модели, а инфраструктурная платформа — вычислительные мощности. 9️⃣ Chai и Claude: кто заберёт деньги в AI-биотехе? — финальная лекция переносит ту же экономическую рамку в drug discovery, где ценность зависит не от красивой молекулы, а от замкнутого цикла гипотеза → дизайн → эксперимент → данные и прав на результат. Это не нейтральный учебник: среди гостей инвесторы, основатели и руководители компаний, которые продают ровно те слои стека, о которых рассказывают. Но если отделять механизм от vendor pitch, получается редкая сквозная карта AI — от электронов до молекул. Если времени на весь плейлист нет, выбирайте слой, за который отвечаете. А если есть — я бы шёл по порядку: так особенно хорошо видно, как дефицит и ценность путешествуют по стеку. #AI #Engineering #Infrastructure #Product #Strategy #Economics

3 AImigo S1E5: джун без простых задач. Как войти в IT в эпоху AI? Начать делать продукты в IT стало проще. Начать получать за это деньги — сложнее. AI-агенты уже справляются с багфиксами и небольшими фичами, на которых джуны раньше «тренировались на кошечках». А если простые задачи исчезают, то как теперь вырастить следующего инженера? В пятницу в 12:00 в пятом выпуске 3 AImigo продолжаем разговор о найме, но смотрим на него со стороны тех, кто только выбирает профессию, заканчивает университет или пытается получить первую работу. У привычной лестницы "junior → middle → senior" сломалась нижняя ступень. Индустрии всё ещё нужны новые инженеры, но отдельному бизнесу выгоднее усилить опытного специалиста агентами, чем годами растить новичка. Для индустрии это риск, для джуна — новая реальность. Обсудим, что может стать рабочим входным билетом: — собственный end-to-end проект: от проблемы и критериев приёмки до production, поддержки и плана отката; — умение не просто получить код, а объяснить решение агента, проверить его и принять ответственность; — способность учиться: находить пробелы, задавать вопросы и встраивать ответы, а не складывать их в чек-лист; — интерес к бизнесовой задаче и пользователю, а не только к технологии; — отношения с людьми и профессиональное сообщество — этот путь никуда не исчез. Как обычно, разбираемся втроём: Евгений Сергеев, Алексей Литвинов и Александр Поломодов. #AI #AI4SDLC #Agents #Engineering #Career #Education

Заходите на прямой эфир про первые 90 дней CTO, которые начинаются задолго до выхода на работу:) 40-минутную версию этого доклада я рассказал на мероприятии Стратоплана, а теперь я расскажу расширенную версию + поотвечаю на ваши вопросы.

PyTorch как слой переносимости: зачем туда пришли Cambricon и Ant Group (Рубрика #AI) В этой новости легко зацепиться за геополитику: Alibaba Cloud, Ant Group, Cambricon и Huawei вместе выступили на PyTorch Conference China в Шанхае. Но мне здесь интереснее другой вопрос. Зачем производителю собственных AI-ускорителей платить $350 тысяч в год за Platinum-членство в PyTorch Foundation, если код PyTorch и так открыт? Сначала поправлю новостную оптику. Не все четыре компании «только что вошли в PyTorch». Cambricon объявили Platinum-участником 7 сентября 2026 года, Ant Group — Gold-участником 8 сентября. Alibaba Cloud состоит в Foundation с 26 мая 2026 года, Huawei — с 17 октября 2023-го. Свежая часть истории — Cambricon и Ant, а общий шанхайский анонс собрал китайский AI-стек на одной сцене: модели Qwen, облачную инфраструктуру, чипы MLU и Ascend, а также runtime для агентов. Моя интерпретация: китайские компании покупают не контроль над PyTorch, а место за столом, где снижают стоимость ухода от CUDA. За $350 тысяч Platinum-участник получает по голосующему месту в Governing Board и Technical Advisory Council. Gold-членство стоит $150 тысяч, но отдельного кресла Ant не гарантирует: Gold-компании выбирают одного представителя на троих. Это влияние на бюджет, рабочие группы, CI и общие приоритеты экосистемы. Но не право нажимать Merge: техническое управление PyTorch закреплено за конкретными maintainers на основе вклада, а не за компаниями по уровню взноса. И вот здесь начинается действительно важная часть. Проблема альтернативного AI-чипа — не только в FLOPS. Нужны операторы, compiler, distributed collectives, профилировщик, интеграции с библиотеками и синхронизация с каждым новым релизом PyTorch. Именно этот длинный программный хвост превратил CUDA в moat, который нельзя догнать одной красивой таблицей производительности. PyTorch постепенно строит общий слой подключения ускорителей через PrivateUse1, эталонный backend OpenReg и Accelerator Integration Working Group. Идея в том, чтобы модель и большая часть прикладного кода видели единый PyTorch API, а CUDA, ROCm, CANN или Neuware оставались ниже. Тогда производители конкурируют уже качеством backend: покрытием операторов, поддержкой torch.compile, стабильностью distributed training и скоростью выпуска обновлений. Но до взаимозаменяемости ещё далеко. Cambricon сейчас требует отдельный пакет torch_mlu и vendor-компоненты CNToolkit, CNNL и CNCL. Huawei продвинулась дальше: Ascend уже есть в публичной CI рабочей группы, но torch_npu всё равно устанавливается отдельно и зависит от CANN. Иными словами, общий фасад появляется, а под ним пока остаются разные лестницы, ключи и инструкции по эвакуации :) Ant Group здесь про соседний слой. Компания показала runtime для AI-агентов на базе Kubernetes Agent Sandbox и Kata Containers. Это не вклад в PyTorch core и не ускоритель; скорее признак того, что вокруг Foundation начинают собирать более широкий open-source AI stack — от tensor runtime до изолированного выполнения агентов. Общей технической архитектуры четыре компании пока не объявили. Поэтому смотреть я бы стал не на число китайских логотипов в Foundation, а на три скучных инженерных сигнала: 1️⃣ Появится ли Cambricon MLU в общей публичной CI рядом с Ascend; 2️⃣ Смогут ли torch_mlu и torch_npu поддерживать актуальный стабильный PyTorch без специальных сборок и долгого отставания; 3️⃣ Будут ли приниматься upstream-изменения в Inductor, distributed stack и domain libraries, а не только расти внешние vendor-репозитории. Если это произойдёт, PyTorch станет для AI-железа настоящим слоем переносимости и немного уменьшит программный lock-in NVIDIA. Не отменит CUDA, её зрелые kernels, NCCL и инструменты — именно уменьшит цену первого шага в сторону другого ускорителя. Если нет, членство останется дорогим логотипом на сайте. #AI #OpenSource #PlatformEngineering #Infrastructure #Architecture #Bigtech

Заходите на очередной прямой эфир Code of Leadership, что стартует прямо сейчас. Сегодня мы с Глебом Михеевым (@tired_glebmikheev) поговорим про то как, поменяется роль программистов в ближайшие три года и обсудим концепцию продуктового инженера.

Ollama: как агенты меняют экономику открытых моделей (Рубрика #AI4SDLC) Этот выпуск YC Lightcone с сооснователем Ollama Джеффом Морганом хорошо собирает несколько тем, которые в канале до этого жили отдельно: экономику токенов, локальные модели, routing и быстро меняющуюся агентную обвязку. Ценность разговора для меня в том, что знакомая архитектурная схема уже превращается в устройство рынка. Тезис Моргана такой: агенты резко увеличивают потребление токенов, поэтому использовать дорогую frontier-модель для каждого промежуточного шага становится бессмысленно. Большой объём работы заберут дешёвые открытые модели, а самые сильные закрытые останутся для сложных решений и эскалации. В выпуске прозвучали несколько оценок Ollama 1️⃣ С начала 2026 года общий объём токенов в Ollama Cloud, по данным компании, вырос примерно в 150 раз. Это внутренняя метрика Ollama, а не независимый замер эффективности. 2️⃣ Морган прогнозирует, что открытые модели смогут выполнять 80–90% корпоративных токенов, получая лишь 10–20% общего AI-бюджета. Пока это гипотеза участника рынка, но асимметрия интересная: массовая работа и основная маржа могут оказаться в разных слоях. 3️⃣ Архитектура будет гибридной: простые и чувствительные задачи можно исполнять локально, тяжёлые — отправлять в облако, сохраняя общий интерфейс. Многое здесь подтверждает то, о чём я писал раньше. [Цена токена плохо описывает экономику агента: считать нужно завершённую и принятую задачу вместе с проверкой, повторами и последствиями ошибки. Сам рост token volume тоже нельзя путать с ростом ценности — в разборе данных OpenCode я отдельно показывал, как на объём влияют длина сессий, кеш и небольшая группа тяжёлых пользователей. Routing тоже уже перестал быть красивой схемой на слайде. AT&T описывает 45 млрд токенов в день, cache-aware router и экономию до 90% на своих сценариях. А в истории OpenCode мы видели ту же продуктовую ставку: агрегировать спрос, проверять связки «модель + провайдер» и давать приложению переключаться между моделями. Что для меня здесь новое 1️⃣ К приватности и суверенности как причинам выбирать открытые модели добавляется агентная экономика. Когда один запрос превращается в сотни model calls, дешёвый исполнитель нужен уже для масштабирования самого цикла. 2️⃣ Ollama хочет зарабатывать на самом скоропортящемся месте стека — совместимости модели, inference engine, железа, облачной ёмкости и agent harness в день релиза. Я недавно писал, что generic harness разумно арендовать, оставляя своими задачу, контекст и evals. Ollama пробует стать поставщиком похожего изменчивого слоя этажом ниже. 3️⃣ Яснее разошлись роли знакомых инструментов. LM Studio тяготеет к персональной рабочей среде, vLLM — к производительному serving engine, а Ollama претендует на слой дистрибуции и совместимости между локальным запуском, облаком и агентными приложениями. Поэтому её сравнение с Docker здесь содержательнее обычного «ещё один способ запустить LLM». Но open weights не делают систему автоматически локальной, дешёвой или безопасной. В разборе конфигураций агентного стека я разделял модель, harness, инструменты, identity и границы исполнения. А локальная модель просто переносит расходы из API в GPU, эксплуатацию и риск недозагрузки. Если ставка Ollama сработает, открытые модели не уничтожат платформы. Они создадут новый класс платформ поверх взаимозаменяемых весов. И тогда компании полезно владеть не каждым компонентом, а теми слоями, где находится её реальная ценность: контрактом задачи, состоянием, полномочиями, воспроизводимыми эпизодами и outcome-evals. Остальные слои можно арендовать — но [перепроверять после каждого заметного сдвига модели и обвязки. #AI4SDLC #AI #Agents #Architecture #PlatformEngineering #FinOps

AI для среднего бизнеса: материалы выпуска (Рубрика #AI) Собрал материалы 75-го выпуска Code of Leadership — «Как действовать среднему бизнесу с AI, которому „по науке“ дорого?» С Александром Воронцовым, партнёром Revelio Tech и автором AI Subjects, поговорили о компаниях, у которых нет собственной AI-лаборатории и большой команды внедрения. Зато есть падающая маржа, ручные таблицы, проблемы с ассортиментом и наймом. В разговоре: - Как торговая компания начала с задач сотрудников, выделила бюджет эксперимента и устроила конкурс прототипов с денежными призами; - Зачем рядом со специалистом по AI нужен аналитик, понимающий реальные данные и особенности 1С; - Почему автоматизация в аутстафинговой компании распалась на отдельные инициативы; - Как получилось, что готовым агентом для товарной аналитики никто не пользовался; - С чего начать: за одну-две недели изучить фактическую работу и выбрать одну-три задачи, которые можно улучшить сразу. Главная мысль: AI снижает порог входа в автоматизацию. Но сотрудникам всё ещё нужно понимать, зачем менять привычный процесс, кто поможет и что они получат от этих изменений. Подготовил и конспект на 7 минут — с кейсами, ограничениями и практическими выводами, если удобнее читать. 📌 Все материалы и таймкоды 📖 Читать конспект 🎬 Смотреть: YouTube · VK Видео 🎧 Слушать: Яндекс Музыка · Apple Podcasts · Podster #AI #Management #Leadership #Podcast

Stanford MS&E435: Chai и Claude - кто заберёт деньги в AI-биотехе? (Рубрика #AI) Последняя лекция курса Stanford MS&E435, о котором я писал посвящена теме life sciences и здесь обсуждается вопрос где в AI-стеке экономика. В биотехе один удачный результат может стоить десятки миллиардов, но между демкой и продажами — годы биологии, клиники и регуляторики. Ведущий Apoorv Agrawal разговаривает с Joshua Meier, сооснователем Chai Discovery, и Eric Kauderer-Abrams, Head of Life Sciences в Anthropic. Они предлагают не «лекарство по одному промпту», а новую архитектуру R&D. Как выглядит обычный процесс Если сжать его до одной строки: болезнь и группа пациентов → биологическая мишень → тип терапии → первый hit → оптимизированный lead → кандидат в лекарство → доклиника → фазы I–III → регистрация и производство Путь нередко занимает 10–15 лет, а программа может умереть на любой ступени: неверная мишень, токсичная или непроизводимая молекула, отсутствие эффекта в клинике. Поэтому: binder ≠ кандидат в лекарство ≠ лекарство. Что предлагают Chai и Anthropic 1️⃣ Chai строит «CAD для молекул» — внутренний контур. Модель получает структуру мишени и проектирует антитела, которые должны с ней связаться. В собственном нерецензированном препринте Chai-2 компания сообщает о hit rate около 16%: для 52 мишеней проверяли не более 20 дизайнов на каждую и для половины нашли хотя бы один binder менее чем за две недели. Сильный результат discovery, но ещё не доказательство эффективности лекарства. 2️⃣ Claude — внешний контур: прочитать литературу, выбрать инструмент, запустить специализированную модель, подготовить эксперимент, разобрать данные и предложить следующий шаг. Chai проектирует деталь, Claude координирует процесс, а лаборатория остаётся источником истины. Откуда ускорение относительно стандартного процесса - Обычный discovery перебирает большие библиотеки и повторяет цикл «синтез → тест → анализ → новый дизайн». Здесь модель сужает поиск до десятков конструкций, а агент сокращает передачи между людьми, софтом и лабораторией. Быстрее становится весь feedback loop. - Дальше AI может помогать с мишенями и клиническими испытаниями. Eric предполагает, что полный цикл удастся сократить примерно до пяти, а затем и до нескольких лет. Пока это прогноз: биологию человека, длительное наблюдение и регулятора из конвейера не убрать. - Лабораторной работы при этом может стать больше. Если каждый эксперимент дешевле и информативнее, выгодно проверять больше гипотез — парадокс Джевонса в халате. Где будут деньги - Фарма владеет кандидатом, клинической инфраструктурой, производством и продажами. Здесь пока остаётся основная ценность успешного препарата. - Создатели инструментов — Chai, Anthropic, лабораторная автоматизация и CRO — продают доступ, вычисления и эксперименты. Чтобы забирать больше, им нужно доказать рост вероятности успеха программы. Но Eric предупреждает: продавать инструменты большой фарме — тяжёлый бизнес. - AI-native biotech может небольшой командой владеть молекулами и лицензировать их после первых доказательств. Это максимальный upside вместе с клиническим и капитальным риском. Если дизайн станет доступен всем, moat сместится в выбор мишени, данные, лабораторный feedback loop и права на препарат. Насколько большой рынок IQVIA оценивает выручку глобальной life-sciences-индустрии в 2025 году примерно в $1,94 трлн, а расходы биофармы на разработку лекарств — в $199 млрд. Это разные круги: $1,94 трлн — не TAM (Total Addressable Market) для Chai или Claude. Инструменты конкурируют за часть R&D-бюджета; владелец одобренного препарата — за конечный рынок. Масштаб разницы хорошо показывает одна молекула: tirzepatide под брендами Mounjaro и Zepbound принёс Lilly 36,5 млрд продаж за 2025 год. Поэтому главный вопрос не в том, кто первым сгенерирует красивую молекулу, а в том, кто замкнёт цикл «гипотеза → дизайн → эксперимент → данные», сохранит права на результат и доведёт его до пациента. #AI #Biotech #DrugDiscovery #LifeSciences #Engineering #Economics

Code of Leadership S2E20: Где у CTO больше свободы — в стартапе или корпорации с Кириллом Евсеенко (Рубрика #Leadership) В стартапе CTO может утром принять решение, а вечером увидеть его в продукте — но людей, денег и времени почти всегда не хватает. В корпорации ресурсов гораздо больше, но любое серьёзное изменение приходится проводить через множество зависимостей. Так где в итоге больше свободы? И что важнее — свобода принимать решения или способность реально менять большую систему? 11 сентября в 18:00 МСК будет новый прямой эфир Code of Leadership с Кириллом Евсеенко — CTO музыкального сервиса «Звук». Кирилл начинал с заправки картриджей и системного администрирования, работал над туристическими сервисами и медицинским стартапом, руководил технологиями и продуктом в START, а теперь — CTO «Звука». Поэтому стартап и корпорацию будем сравнивать не по привычным мемам про скорость и бюрократию, а по реальным решениям, ограничениям и цене ошибки. У Кирилла есть свой канал @tak_ya_vse_pridumal Поговорим о том: • какие привычки из стартапа помогают на большом масштабе, а какие превращают самого CTO в узкое место; • где согласования действительно защищают от дорогой ошибки, а где просто размывают ответственность; • какие решения CTO должен оставлять за собой, а какие принципиально не должен принимать; • как перейти от личного контроля к системе сильных лидеров и при этом не потерять контакт с инженерной реальностью; • что вообще происходит со скоростью, ответственностью и влиянием руководителя, когда команда вырастает от десятков до сотен человек. Отдельно проверим формулу «быстрый стартап — медленная корпорация». Возможно, с ростом масштаба скорость никуда не исчезает. Просто раньше ты ускорял компанию тем, что быстро действовал сам, а теперь — тем, что создаешь систему, в которой сотни людей могут быстро принимать хорошие решения без тебя. И попробуем ответить на главный вопрос: в какой момент технический руководитель перестает быть главным инженером и становится CTO? Приносите в комментарии вопросы Кириллу и свои истории перехода между стартапами и большими компаниями. #Management #Leadership #Career #Strategy #Engineering #Podcast #Strategy #Startup #Enterprise

Приходите на новый подкаст «Где профит от данных, Лебовски?» о данных и их ценности для бизнеса. Первый выпуск будет ключевым и будет посвящен теме «Превращаем данные в деньги: что это значит и какие есть варианты». Обсуждать будем втроем - Андрей Цыбин - взгляд со стороны продуктовой аналитики и онлайн-экспериментов - Николай Голов - взгляд со стороны дата-архитектуры и продуктовой разработки платформы данных - Александр Поломодов - взгляд со стороны software архитектуры, AI4SDLC и инженерного лидерства #Data #Database #Analytics #Money #Metrics #Business

Stanford MS&E435: Baseten и как юнит-экономика меняет стратегию (Рубрика #AI) В беседе Apoorv Agrawal с Тухином Шриваставой, сооснователем Baseten, из стэнфордского курса Economics of the AI Supercycle мне понравилась история о том, как рост бизнеса заставляет пересматривать архитектуру. Сначала компания берёт готовые API, потом обзаводится своими моделями. А её инфраструктурный провайдер тем временем начинает задумываться о собственных GPU. У обоих постепенно меняется ответ на вопрос: что мы можем делегировать? На старте логика понятная: run fast. Берёшь топовую модель провайдера, собираешь продукт, проверяешь спрос. Пока непонятно, нужен ли кому-то твой сервис, строить команду эксплуатации моделей довольно дорого. Гораздо полезнее быстро выяснить, за что люди готовы платить. Дальше появляются пользователи, повторяющиеся задачи и счёт за инференс. Тут начинается run effective: имеет смысл взять модель с открытыми весами и дообучить под свой сценарий. Универсальность большой модели оплачивается в каждом запросе, хотя конкретному продукту нужна лишь часть её возможностей. По оценке Шриваставы, открытые модели можно запускать на 70–90% дешевле передовых закрытых. Это оценка спикера, а не обещание такой экономии любому продукту. Считать придётся стоимость успешно выполненной задачи, включая обучение, проверки качества, повторные попытки и работу команды. При достаточном объёме экономия начинает окупать всю эту возню. Но между «скачать веса» и «отвечать за работающий сервис» лежит отдельная профессия. Нужны люди, которые подготовят данные, дообучат модель, развернут её, добьются нужной задержки и будут разбираться, почему ночью всё упало. Здесь появляется Baseten: по описанию Шриваставы, платформа берёт на себя инфраструктуру обучения и инференса. Клиент приносит данные и определяет, что считать хорошим результатом. Понимание собственного продукта делегировать сложнее. К экономике добавляется конкуренция. Вот наглядный пример не из лекции. Anthropic поставляет модели разработчикам приложений и одновременно развивает Claude Code, который работает с той же аудиторией, что и Cursor. Поставщик вполне может захотеть сам продавать конечный продукт. При этом собственные модели Cursor появились ещё до Claude Code: Tab работает на кастомной модели с марта 2024 года. Позже компания представила Composer 2 на базе Kimi K2.5, с дополнительным предобучением и reinforcement learning. Кстати, Baseten действительно работает с Cursor, хотя из этого не следует, что весь его инференс обслуживается там. Я бы отделял эту конкуренцию от страха, что провайдер обучится на твоих данных. Использование данных регулируется условиями работы; у Anthropic для коммерческого API уже действует отказ от обучения по умолчанию. Но такой запрет не мешает поставщику самостоятельно выйти на твой рынок. Собственные модели дают больше контроля над себестоимостью и развитием продукта. И дальше та же история повторяется этажом ниже. Baseten строит программную платформу поверх чужих облаков: оптимизирует инференс, собирает доступные мощности, обеспечивает отказоустойчивость. По словам Шриваставы, дефицит GPU заставляет компанию двигаться к владению частью оборудования: нужно гарантировать ресурсы под будущую нагрузку клиентов. Вместе с железом появляются расходы на его покупку, риск недозагрузки и устаревания. При дефиците посредник, умеющий находить мощности у разных поставщиков, становится особенно полезным. Но если ты обещаешь клиенту надёжную услугу, в какой-то момент приходится брать под контроль поставку критического ресурса. Через долгосрочную аренду, собственное оборудование или сочетание обоих вариантов. Получается симметрия: Cursor наращивает контроль над моделями, Baseten — над вычислениями. Масштаб меняет границу между тем, что удобно покупать как услугу, и тем, за что уже приходится отвечать самому. И эту границу полезно пересматривать вместе со счётом за инфраструктуру. #AI #Architecture #PlatformEngineering #Product #Management