llm-d: как KV-cache стал состоянием всего кластера (Рубрика #AI)
У архитектурных идей бывает два дня рождения: сначала paper показывает, что приём работает, потом кто-то превращает его в систему, которую можно развернуть и сопровождать. Доклад Cong Liu из Google и Maroon Ayoub, работавшего тогда в IBM Research, на PyTorch Conference 2025 — как раз про второй случай. llm-d не изобрёл Prefill/Decode disaggregation. Он пытается сделать из исследовательского паттерна управляемый production stack. Слайды доклада здесь
Это продолжение истории PagedAttention и vLLM, где KV-cache перестал требовать непрерывного куска памяти внутри одного inference engine. Здесь меняется уже единица оптимизации: prefill, decode и сам KV-cache становятся ресурсами всего кластера.
- Prefill обрабатывает prompt целиком, строит KV-cache, упирается прежде всего в вычисления и определяет time to first token
- Decode выпускает токены последовательно, сильнее зависит от пропускной способности памяти и определяет задержку между токенами
- В одном сервере тяжёлый prefill мешает равномерному decode, а обе фазы получают одну конфигурацию железа и parallelism.
llm-d разносит их по разным пулам
- Scheduler выбирает decode worker с учётом prefix cache, занятой памяти и очереди
- Если незакэшированной работы много, отдельно выбирает prefill worker
- Sidecar отправляет туда запрос с
- Получается интересный сдвиг: маршрутизируется уже не только HTTP-запрос, но и вычисленное состояние модели.
В собственном benchmark команда сравнила одинаковые 16 H200 с InfiniBand: четыре монолитных TP4-реплики против четырёх prefill TP2 и двух decode TP4 на Llama-4 Scout с 5000 входных и 250 выходных токенов. По данным проекта, P/D-вариант дал заметно больше throughput на GPU в средней зоне нагрузки, особенно при 64–128 одновременных запросах. На низкой и предельной нагрузке кривые сближались — универсального множителя здесь нет.
История развивалась так:
- в 2023 году PagedAttention сделал KV-cache эффективнее внутри одного движка;
- в 2024-м Splitwise и DistServe показали, зачем физически разделять prefill и decode, а Mooncake — как строить вокруг KV-cache распределённую архитектуру;
- 20 мая 2025 года запустили llm-d, а в июле v0.2 принесла первые воспроизводимые well-lit paths для P/D, cache-aware routing и wide expert parallelism;
- Доклад 23 октября 2025 года зафиксировал раннюю рабочую систему, где главный вопрос был уже не «можно ли разделить фазы», а «как выбрать P, D и безопасно передать состояние»;
- в 2026-м llm-d вошёл в CNCF Sandbox, вышел за границы обязательного Kubernetes и в v0.8 прямо назвал себя inference control plane. Обещанное в докладе P2P-переиспользование KV-cache стало отдельным well-lit path 15 августа, а 17 августа вышла v0.9.
Самая важная оговорка прозвучала у самих спикеров: P/D подходит не каждому workload. Они советуют начинать эксперименты с моделей порядка 70B+, длинных контекстов вроде 10k input / 1k output и sparse MoE. Текущая документация vLLM всё ещё называет disaggregated prefilling экспериментальной возможностью и прямо предупреждает: само разделение throughput не повышает. Оно позволяет независимо настраивать TTFT и inter-token latency; итоговый выигрыш даёт только вся конфигурация — topology, router, workload и достаточно быстрая сеть.
Поэтому начинать стоитс профиля нагрузки: распределения input/output tokens, concurrency, SLO по TTFT и задержке между токенами, стоимости KV-transfer. Без этих чисел P/D disaggregation может оказаться как хорошей системной оптимизацией, так и дорогим способом отправить несколько гигабайт кэша по сети и вернуть их почти туда же.
#AI #Engineering #Architecture #Software #DistributedSystems #PlatformEngineering
У архитектурных идей бывает два дня рождения: сначала paper показывает, что приём работает, потом кто-то превращает его в систему, которую можно развернуть и сопровождать. Доклад Cong Liu из Google и Maroon Ayoub, работавшего тогда в IBM Research, на PyTorch Conference 2025 — как раз про второй случай. llm-d не изобрёл Prefill/Decode disaggregation. Он пытается сделать из исследовательского паттерна управляемый production stack. Слайды доклада здесь
Это продолжение истории PagedAttention и vLLM, где KV-cache перестал требовать непрерывного куска памяти внутри одного inference engine. Здесь меняется уже единица оптимизации: prefill, decode и сам KV-cache становятся ресурсами всего кластера.
- Prefill обрабатывает prompt целиком, строит KV-cache, упирается прежде всего в вычисления и определяет time to first token
- Decode выпускает токены последовательно, сильнее зависит от пропускной способности памяти и определяет задержку между токенами
- В одном сервере тяжёлый prefill мешает равномерному decode, а обе фазы получают одну конфигурацию железа и parallelism.
llm-d разносит их по разным пулам
- Scheduler выбирает decode worker с учётом prefix cache, занятой памяти и очереди
- Если незакэшированной работы много, отдельно выбирает prefill worker
- Sidecar отправляет туда запрос с
max_tokens=1, после чего decode worker забирает рассчитанный KV-cache через NIXL и продолжает генерацию- Получается интересный сдвиг: маршрутизируется уже не только HTTP-запрос, но и вычисленное состояние модели.
В собственном benchmark команда сравнила одинаковые 16 H200 с InfiniBand: четыре монолитных TP4-реплики против четырёх prefill TP2 и двух decode TP4 на Llama-4 Scout с 5000 входных и 250 выходных токенов. По данным проекта, P/D-вариант дал заметно больше throughput на GPU в средней зоне нагрузки, особенно при 64–128 одновременных запросах. На низкой и предельной нагрузке кривые сближались — универсального множителя здесь нет.
История развивалась так:
- в 2023 году PagedAttention сделал KV-cache эффективнее внутри одного движка;
- в 2024-м Splitwise и DistServe показали, зачем физически разделять prefill и decode, а Mooncake — как строить вокруг KV-cache распределённую архитектуру;
- 20 мая 2025 года запустили llm-d, а в июле v0.2 принесла первые воспроизводимые well-lit paths для P/D, cache-aware routing и wide expert parallelism;
- Доклад 23 октября 2025 года зафиксировал раннюю рабочую систему, где главный вопрос был уже не «можно ли разделить фазы», а «как выбрать P, D и безопасно передать состояние»;
- в 2026-м llm-d вошёл в CNCF Sandbox, вышел за границы обязательного Kubernetes и в v0.8 прямо назвал себя inference control plane. Обещанное в докладе P2P-переиспользование KV-cache стало отдельным well-lit path 15 августа, а 17 августа вышла v0.9.
Самая важная оговорка прозвучала у самих спикеров: P/D подходит не каждому workload. Они советуют начинать эксперименты с моделей порядка 70B+, длинных контекстов вроде 10k input / 1k output и sparse MoE. Текущая документация vLLM всё ещё называет disaggregated prefilling экспериментальной возможностью и прямо предупреждает: само разделение throughput не повышает. Оно позволяет независимо настраивать TTFT и inter-token latency; итоговый выигрыш даёт только вся конфигурация — topology, router, workload и достаточно быстрая сеть.
Поэтому начинать стоитс профиля нагрузки: распределения input/output tokens, concurrency, SLO по TTFT и задержке между токенами, стоимости KV-transfer. Без этих чисел P/D disaggregation может оказаться как хорошей системной оптимизацией, так и дорогим способом отправить несколько гигабайт кэша по сети и вернуть их почти туда же.
#AI #Engineering #Architecture #Software #DistributedSystems #PlatformEngineering
YouTube
Serving PyTorch LLMs at Scale: Disaggregated Inference With Kubernetes and Llm-d - M. Ayoub & C. Liu
Serving PyTorch LLMs at Scale: Disaggregated Inference With Kubernetes and Llm-d - Maroon Ayoub, IBM Research & Cong Liu, Google
As PyTorch-based LLMs scale in complexity and user concurrency, their inference demands diverge across stages. Prefill is compute…
As PyTorch-based LLMs scale in complexity and user concurrency, their inference demands diverge across stages. Prefill is compute…
❤4👍3🔥1
Материалы про то как выстроить собственную систему управления с Михаилом Тюргановым (Рубрика #AI4SDLC)
В начале недели мы с Мишей обсудили его карьерный путь и как меняется CTO, когда небольшая команда вырастает в организацию на тысячи человек? И что делать, если прежние методы сами становятся ограничением? И теперь готовы все материалы по этому прямому эфиру
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка
#Management #Leadership #Engineering #Architecture #PlatformEngineering
В начале недели мы с Мишей обсудили его карьерный путь и как меняется CTO, когда небольшая команда вырастает в организацию на тысячи человек? И что делать, если прежние методы сами становятся ограничением? И теперь готовы все материалы по этому прямому эфиру
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка
#Management #Leadership #Engineering #Architecture #PlatformEngineering
polomodov.tech
Собственная система управления — Code of Leadership
Как система управления меняется вместе с масштабом: сквозная ответственность CTO, эффективность, платформы и договорённости между лидерами. В гостях — Михаил Тюрганов.
❤4👍4🔥2🌚1
Omer Primor про CaaS: где заканчивается аренда контекста (Рубрика #AI)
У контекста для агента есть неприятная бухгалтерия. Пока вопрос разовый, AI-поиск выглядит как обычный API: спросили, получили ответ, пошли дальше. Но если каждый день проверять одни и те же компании, вакансии и цены, счётчик запускается заново — даже когда ничего не изменилось. В какой-то момент мы арендуем уже не ответ. Мы арендуем способность системы помнить.
Именно эту границу разбирает Omer Primor из Bright Data в докладе «The Rise of CaaS: Context-as-a-Service for Agentic AI» с AI Engineer World’s Fair 2026. Название похоже на ещё один "-aaS", но вопрос внутри вполне взрослый: когда агенту достаточно покупать контекст, а когда его пора собирать, обновлять и хранить самому? Тема уже появлялась в разборе Hands-On RAG for Production, где retrieval из одного паттерна постепенно вырастал в платформенный слой. Primor добавляет к архитектуре экономику: кто платит за обновление знаний и у кого остаётся накопленный актив.
Его отправная точка — веб не снимок. По показанному в докладе анализу Bright Data, данные социальных сетей могут терять актуальность меньше чем за сутки, а новости, финансовая и retail-информация — в основном за 30 дней. Это внутренний анализ компании, а не универсальный закон. Но сама проблема понятна: один раз найти страницу недостаточно, если агенту важно знать, как менялись цена, вакансии или состав компании.
CaaS в описании Primor больше похож на вертикальный поиск и платформу данных. Такой сервис заранее собирает источники, нормализует и дедуплицирует сущности, связывает их в граф и отдаёт агенту контекст через API, CLI или MCP. Плюс — структура и быстрый старт. Ограничение встроено туда же: если нужного поля нет в модели данных сервиса, агент не сможет выколдовать его запросом.
А дальше частота запросов приводит к огромному счету.
В модели с оплатой за запрос повторное обращение стоит как первое, даже если с прошлого раза ничего не изменилось. По наблюдению Primor, на масштабе команды начинают незаметно резать уже не расходы, а ценность: проверять компанию раз в неделю вместо раза в день, брать десять результатов вместо полного набора или вообще не задавать дорогой вопрос. Цена становится ограничителем свежести — и никто ещё не назвал это архитектурным решением.
Чтобы показать механику, команда Bright Data провела небольшой тест. Карточку из 25 полей проверили на 100 компаниях-спонсорах конференции и сравнили AI-поиск, несколько CaaS и прямой сбор из известных источников. Primor сразу называет это тестом, а не benchmark. Покрытие оказалось близким, но некоторые CaaS уступили поиску на выбранных полях: сервис знает только то, что решил собирать. При этом сам докладчик оговаривает, что у этих платформ могут быть другие данные и преимущества, которые тест просто не измерял. Для собственного варианта команда использовала готовые источники Bright Data и два специально собранных скрейпера. По словам Primor, демонстрационный конвейер занял около дня. Затем он условно оценил полноценную настройку в неделю и $5 000 — при таких допущениях пересечение получилось чуть выше 15 000 сущностей или запросов.
Красивое число, но переносить его в закупочную таблицу я бы не стал. Primor тут же допускает и 10 000, и 30 000, и 100 000: всё зависит от сценария. К тому же он представляет Bright Data, а «самостоятельный» путь собран на инструментах той же компании. За рамкой расчёта остаются поддержка скрейперов, полноценное сопоставление сущностей (entity resolution), контроль качества, юридические ограничения, наблюдаемость и дежурства. Собственный конвейер особенно дёшев на слайде. В жизни первый редизайн сайта-источника быстро добавляет в формулу людей и кофе :)
Поэтому я бы выбирал не по магической отметке 15 000, а по пяти вопросам:
— Как часто повторяется запрос?
— Как быстро устаревают данные?
— Насколько стабильны сущности и схема?
— Сколько стоит неверный или несвежий контекст?
— Во что обходится владение всем конвейером?
Мой базовый вариант здесь — гибрид. Разовые вопросы и неизвестные заранее источники остаются у AI-поиска или CaaS. Частые запросы к понятным сущностям и полям уходят в собственный сбор, нормализованное хранилище и инкрементальные обновления. Внешний поиск остаётся резервом для пробелов, а не обязательным шагом каждого запуска агента. Это та же граница «арендовать — адаптировать — оставить своим», о которой я писал в лонгриде про AI-стек. Только считать здесь полезнее не цену одного запроса, а стоимость принятого результата с нужной свежестью.
Практический следующий шаг простой: взять один повторяющийся сценарий, посчитать частоту, требования к свежести, цену ошибки и полный TCO. А потом ответить на более интересный вопрос: в какой момент ваш агент перестаёт искать и начинает обслуживать собственный продукт данных?
#AI #Agents #Architecture #Data #PlatformEngineering #FinOps
У контекста для агента есть неприятная бухгалтерия. Пока вопрос разовый, AI-поиск выглядит как обычный API: спросили, получили ответ, пошли дальше. Но если каждый день проверять одни и те же компании, вакансии и цены, счётчик запускается заново — даже когда ничего не изменилось. В какой-то момент мы арендуем уже не ответ. Мы арендуем способность системы помнить.
Именно эту границу разбирает Omer Primor из Bright Data в докладе «The Rise of CaaS: Context-as-a-Service for Agentic AI» с AI Engineer World’s Fair 2026. Название похоже на ещё один "-aaS", но вопрос внутри вполне взрослый: когда агенту достаточно покупать контекст, а когда его пора собирать, обновлять и хранить самому? Тема уже появлялась в разборе Hands-On RAG for Production, где retrieval из одного паттерна постепенно вырастал в платформенный слой. Primor добавляет к архитектуре экономику: кто платит за обновление знаний и у кого остаётся накопленный актив.
Его отправная точка — веб не снимок. По показанному в докладе анализу Bright Data, данные социальных сетей могут терять актуальность меньше чем за сутки, а новости, финансовая и retail-информация — в основном за 30 дней. Это внутренний анализ компании, а не универсальный закон. Но сама проблема понятна: один раз найти страницу недостаточно, если агенту важно знать, как менялись цена, вакансии или состав компании.
CaaS в описании Primor больше похож на вертикальный поиск и платформу данных. Такой сервис заранее собирает источники, нормализует и дедуплицирует сущности, связывает их в граф и отдаёт агенту контекст через API, CLI или MCP. Плюс — структура и быстрый старт. Ограничение встроено туда же: если нужного поля нет в модели данных сервиса, агент не сможет выколдовать его запросом.
А дальше частота запросов приводит к огромному счету.
В модели с оплатой за запрос повторное обращение стоит как первое, даже если с прошлого раза ничего не изменилось. По наблюдению Primor, на масштабе команды начинают незаметно резать уже не расходы, а ценность: проверять компанию раз в неделю вместо раза в день, брать десять результатов вместо полного набора или вообще не задавать дорогой вопрос. Цена становится ограничителем свежести — и никто ещё не назвал это архитектурным решением.
Чтобы показать механику, команда Bright Data провела небольшой тест. Карточку из 25 полей проверили на 100 компаниях-спонсорах конференции и сравнили AI-поиск, несколько CaaS и прямой сбор из известных источников. Primor сразу называет это тестом, а не benchmark. Покрытие оказалось близким, но некоторые CaaS уступили поиску на выбранных полях: сервис знает только то, что решил собирать. При этом сам докладчик оговаривает, что у этих платформ могут быть другие данные и преимущества, которые тест просто не измерял. Для собственного варианта команда использовала готовые источники Bright Data и два специально собранных скрейпера. По словам Primor, демонстрационный конвейер занял около дня. Затем он условно оценил полноценную настройку в неделю и $5 000 — при таких допущениях пересечение получилось чуть выше 15 000 сущностей или запросов.
Красивое число, но переносить его в закупочную таблицу я бы не стал. Primor тут же допускает и 10 000, и 30 000, и 100 000: всё зависит от сценария. К тому же он представляет Bright Data, а «самостоятельный» путь собран на инструментах той же компании. За рамкой расчёта остаются поддержка скрейперов, полноценное сопоставление сущностей (entity resolution), контроль качества, юридические ограничения, наблюдаемость и дежурства. Собственный конвейер особенно дёшев на слайде. В жизни первый редизайн сайта-источника быстро добавляет в формулу людей и кофе :)
Поэтому я бы выбирал не по магической отметке 15 000, а по пяти вопросам:
— Как часто повторяется запрос?
— Как быстро устаревают данные?
— Насколько стабильны сущности и схема?
— Сколько стоит неверный или несвежий контекст?
— Во что обходится владение всем конвейером?
Мой базовый вариант здесь — гибрид. Разовые вопросы и неизвестные заранее источники остаются у AI-поиска или CaaS. Частые запросы к понятным сущностям и полям уходят в собственный сбор, нормализованное хранилище и инкрементальные обновления. Внешний поиск остаётся резервом для пробелов, а не обязательным шагом каждого запуска агента. Это та же граница «арендовать — адаптировать — оставить своим», о которой я писал в лонгриде про AI-стек. Только считать здесь полезнее не цену одного запроса, а стоимость принятого результата с нужной свежестью.
Практический следующий шаг простой: взять один повторяющийся сценарий, посчитать частоту, требования к свежести, цену ошибки и полный TCO. А потом ответить на более интересный вопрос: в какой момент ваш агент перестаёт искать и начинает обслуживать собственный продукт данных?
#AI #Agents #Architecture #Data #PlatformEngineering #FinOps
YouTube
The Rise of CaaS: Context-as-a-Service for Agentic AI — Omer Primor, Bright Data
Just past 15,000 queries, renting context stopped being the cheaper option. Omer Primor gets that number from a small experiment he is careful to call a test rather than a benchmark: enrich one company across 25 fields, run it 100 times against this event's…
❤3👍1🔥1
Research Insights Made Simple #28: дата-платформа в 2026 году — от DWH к Lakehouse и AI-агентам (Рубрика #Data)
Совсем забыл, что сегодня в 16:00 будет эфир про дата-платформы и он будет продолжать тему из шестого выпуска Research Insights Made Simple, где мы с Николаем Головым разбирали, как строить дата-платформы в 2025 году. А 28-м выпуске мы возвращаемся к теме с вопросом посложнее: что происходит, когда аккуратная схема из storage, compute, catalog и orchestration встречается с legacy, стоимостью миграции и реальными аналитическими запросами?
В гостях опять Николай Голов вместе с Александром Филатовым. Николай — директор по продукту 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.
#Data #DataEngineering #Databases #Architecture #PlatformEngineering #AI
Совсем забыл, что сегодня в 16:00 будет эфир про дата-платформы и он будет продолжать тему из шестого выпуска Research Insights Made Simple, где мы с Николаем Головым разбирали, как строить дата-платформы в 2025 году. А 28-м выпуске мы возвращаемся к теме с вопросом посложнее: что происходит, когда аккуратная схема из storage, compute, catalog и orchestration встречается с legacy, стоимостью миграции и реальными аналитическими запросами?
В гостях опять Николай Голов вместе с Александром Филатовым. Николай — директор по продукту 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.
#Data #DataEngineering #Databases #Architecture #PlatformEngineering #AI
YouTube
Research Insights Made Simple #28: дата-платформа в 2026 году — от DWH к Lakehouse и AI-агентам
В шестом выпуске (https://xn--r1a.website/book_cube/2874) Research Insights Made Simple мы с Николаем Головым разбирали, как строить дата-платформы в 2025 году. В 28 выпуске мы возвращаемся к теме с вопросом посложнее: что происходит, когда аккуратная схема из storage…
❤4🔥4👍1
Материалы выпуска «Дата-платформа в 2026 году» (Рубрика #Data)
Готовы материалы 28-го выпуска Research Insights Made Simple, который вышел 24 августа. Вместе с Николаем Головым и Александром Филатовым из Tengri Data мы прошли путь от границы между OLTP и OLAP до прав, изоляции и проверки запросов AI-агентов.
Обсудили:
- Как по реальной нагрузке понять, когда операционная СУБД перестаёт справляться с аналитикой;
- Где упирается классическое MPP-хранилище и что меняет разделение хранения и вычислений;
- Из чего на практике складывается Lakehouse на S3 и Iceberg: каталог, вычислитель, права, кэш, уплотнение мелких файлов и эксплуатация распределённых компонентов;
- Почему переход с Vertica на Trino, Iceberg и S3 занимает годы и какой длинный хвост создают унаследованные расчёты и хранимые процедуры;
- Чему год разработки, пилотов и продаж научил Tengri Data: технологию платформы нужно связывать с измеримым результатом для бизнеса;
- Почему AI-агенту мало доступа к SQL — нужны семантический слой, детерминированные проверки, строгие права и изоляция нагрузки.
Все материалы выпуска:
- Страница выпуска
- Видео: YouTube, VK Видео
- Аудио: Podster, Яндекс Музыка, Apple Podcasts
- Текст: краткая расшифровка
Если после просмотра останутся вопросы — пишите в комментариях. Соберу их для продолжения темы дата-платформ: здесь ещё есть куда копать.
#Data #PlatformEngineering #Architecture #Database #AI4SDLC #Engineering
Готовы материалы 28-го выпуска Research Insights Made Simple, который вышел 24 августа. Вместе с Николаем Головым и Александром Филатовым из Tengri Data мы прошли путь от границы между OLTP и OLAP до прав, изоляции и проверки запросов AI-агентов.
Обсудили:
- Как по реальной нагрузке понять, когда операционная СУБД перестаёт справляться с аналитикой;
- Где упирается классическое MPP-хранилище и что меняет разделение хранения и вычислений;
- Из чего на практике складывается Lakehouse на S3 и Iceberg: каталог, вычислитель, права, кэш, уплотнение мелких файлов и эксплуатация распределённых компонентов;
- Почему переход с Vertica на Trino, Iceberg и S3 занимает годы и какой длинный хвост создают унаследованные расчёты и хранимые процедуры;
- Чему год разработки, пилотов и продаж научил Tengri Data: технологию платформы нужно связывать с измеримым результатом для бизнеса;
- Почему AI-агенту мало доступа к SQL — нужны семантический слой, детерминированные проверки, строгие права и изоляция нагрузки.
Все материалы выпуска:
- Страница выпуска
- Видео: YouTube, VK Видео
- Аудио: Podster, Яндекс Музыка, Apple Podcasts
- Текст: краткая расшифровка
Если после просмотра останутся вопросы — пишите в комментариях. Соберу их для продолжения темы дата-платформ: здесь ещё есть куда копать.
#Data #PlatformEngineering #Architecture #Database #AI4SDLC #Engineering
polomodov.tech
Дата-платформа в 2026 году — от DWH к… - Research Insights Made Simple
Как отделить OLTP от OLAP, где упирается MPP-хранилище, из чего складывается Lakehouse, почему миграция унаследованных систем занимает годы и что AI-агенты меняют в…
❤4🔥4👍1
Ищу человека, который подхватит AI4SDLC после меня (Рубрика #AI4SDLC)
31 августа я покидаю Т-Банк. Но задача, которой я занимался, остаётся: менять процессы разработки и вести компанию к AI Native.
Планка здесь высокая. Нужно знать передовые подходы, иметь hands-on опыт, уметь работать со множеством стейкхолдеров — и действительно хотеть изменить к лучшему одну из крупнейших технологических компаний России.
Про текущее состояние AI4SDLC лучше всего расскажет моё выступление на Turbo ML Conf этого года.
Работать предстоит под руководством Игоря Маслова — VP и руководителя департамента платформенной инженерии всей компании.
Если вы читаете это и думаете «кажется, это про меня», напишите мне в личку (или сразу @kovalevatin). А если знаете подходящего человека — пожалуйста, перешлите ему этот пост.
#AI4SDLC #AI #Engineering #PlatformEngineering #Leadership
31 августа я покидаю Т-Банк. Но задача, которой я занимался, остаётся: менять процессы разработки и вести компанию к AI Native.
Планка здесь высокая. Нужно знать передовые подходы, иметь hands-on опыт, уметь работать со множеством стейкхолдеров — и действительно хотеть изменить к лучшему одну из крупнейших технологических компаний России.
Про текущее состояние AI4SDLC лучше всего расскажет моё выступление на Turbo ML Conf этого года.
Работать предстоит под руководством Игоря Маслова — VP и руководителя департамента платформенной инженерии всей компании.
Если вы читаете это и думаете «кажется, это про меня», напишите мне в личку (или сразу @kovalevatin). А если знаете подходящего человека — пожалуйста, перешлите ему этот пост.
#AI4SDLC #AI #Engineering #PlatformEngineering #Leadership
😱38❤13💔9😭5👾4🌚1
NVIDIA договорилась купить Hugging Face: проверка на нейтральность (Рубрика #AI)
После разбора стратегии NVIDIA эта сделка выглядит почти неизбежным следующим ходом. Только цена в $12,93 млрд немного отвлекает: NVIDIA договорилась купить не очередную модельную лабораторию и не новый тип ускорителя. В случае закрытия сделки она получит место, где разработчики находят, сравнивают, скачивают и запускают открытые модели — одну из главных точек выбора во всём AI-стеке.
Сначала аккуратно со статусом. 2 сентября 2026 года NVIDIA подписала definitive agreement, 3 сентября опубликовала анонс и форму 8-K. По документу для SEC, примерно $11,9 млрд предназначены акционерам Hugging Face, ещё до $1 млрд — retention-программа в акциях для сотрудников, которые перейдут в NVIDIA. Закрытие ожидается в первой половине 2027 года и зависит в том числе от регуляторных согласований. То есть сделка предложена, но пока не закрыта.
Почему Hugging Face стоит рассматривать не как «GitHub с весами»?
По данным самой NVIDIA, на платформе больше 18 млн разработчиков и исследователей, 3 млн моделей, 500 тысяч датасетов и 1 млн приложений. Но важнее сам механизм. Inference Providers даёт один API к Baseten, Cerebras, Groq, Nscale, Together и другим поставщикам, а без явного выбора автоматически направляет запрос к самому быстрому доступному provider. Dedicated endpoints можно разворачивать в AWS, Azure и Google Cloud. Получается уже не просто хранилище артефактов, а слой discovery, distribution и routing: что разработчик увидит, какую модель попробует и где её запустит.
Для NVIDIA логика понятна. Компания уже контролирует популярный compute/runtime-слой через GPU и CUDA и, по собственным данным, выложила на Hugging Face больше 500 моделей и 250 датасетов. Теперь к железу и software stack добавляется канал дистрибуции. Открытые модели удешевляют и ускоряют создание AI-продуктов, а каждый такой продукт всё равно создаёт спрос на inference. Плюс платформа даёт раннюю агрегированную картину того, какие модели, архитектуры и способы запуска набирают популярность. Последний пункт — интерпретация аналитиков, а не раскрытая цель сделки.
NVIDIA обещает сохранить Hugging Face открытой: её железо не будет обязательным, разработчики смогут выбирать модели, frameworks, clouds, inference providers и compute platforms. В 8-K обещание сформулировано чуть уже, но всё равно предметно: сохранить возможность загружать и скачивать выбранные модели и датасеты и продолжать поддержку других производителей чипов.
Это сильнее обычного «бренд останется прежним». Но открытость артефактов ещё не равна нейтральности платформы. Публичные документы пока не отвечают на четыре практических вопроса:
1️⃣ Кто и по каким правилам управляет ранжированием и рекомендациями моделей;
2️⃣ Как выбираются дефолты в маршрутизации инференса и какие провайдеры получают приоритет;
3️⃣ Будет ли одинаковой скорость интеграции и оптимизации для CUDA, ROCm, Trainium, TPU и CPU;
4️⃣ Где пройдёт граница использования телеметрии и данных о поведении разработчиков.
Сейчас нет доказательств, что NVIDIA собирается подкручивать эти механизмы в свою пользу. Но именно здесь и будет проходить настоящая проверка, а не в возможности скачать файл с весами. Поэтому обещание «Hugging Face останется открытой» — не сноска к пресс-релизу, а главный критерий приемки сделки. Если после закрытия конкурирующее железо и независимые провайдеры инференса будут появляться в роутинге, документации и оптимизациях на равных, а правила ранжирования и использования данных станут прозрачнее, ресурсы NVIDIA действительно могут усилить экосистему. Если нет, веса останутся открытыми, но площадка, на которой все их выбирают, перестанет быть нейтральной.
#AI #PlatformEngineering #OpenSource #Architecture #Infrastructure #Bigtech
После разбора стратегии NVIDIA эта сделка выглядит почти неизбежным следующим ходом. Только цена в $12,93 млрд немного отвлекает: NVIDIA договорилась купить не очередную модельную лабораторию и не новый тип ускорителя. В случае закрытия сделки она получит место, где разработчики находят, сравнивают, скачивают и запускают открытые модели — одну из главных точек выбора во всём AI-стеке.
Сначала аккуратно со статусом. 2 сентября 2026 года NVIDIA подписала definitive agreement, 3 сентября опубликовала анонс и форму 8-K. По документу для SEC, примерно $11,9 млрд предназначены акционерам Hugging Face, ещё до $1 млрд — retention-программа в акциях для сотрудников, которые перейдут в NVIDIA. Закрытие ожидается в первой половине 2027 года и зависит в том числе от регуляторных согласований. То есть сделка предложена, но пока не закрыта.
Почему Hugging Face стоит рассматривать не как «GitHub с весами»?
По данным самой NVIDIA, на платформе больше 18 млн разработчиков и исследователей, 3 млн моделей, 500 тысяч датасетов и 1 млн приложений. Но важнее сам механизм. Inference Providers даёт один API к Baseten, Cerebras, Groq, Nscale, Together и другим поставщикам, а без явного выбора автоматически направляет запрос к самому быстрому доступному provider. Dedicated endpoints можно разворачивать в AWS, Azure и Google Cloud. Получается уже не просто хранилище артефактов, а слой discovery, distribution и routing: что разработчик увидит, какую модель попробует и где её запустит.
Для NVIDIA логика понятна. Компания уже контролирует популярный compute/runtime-слой через GPU и CUDA и, по собственным данным, выложила на Hugging Face больше 500 моделей и 250 датасетов. Теперь к железу и software stack добавляется канал дистрибуции. Открытые модели удешевляют и ускоряют создание AI-продуктов, а каждый такой продукт всё равно создаёт спрос на inference. Плюс платформа даёт раннюю агрегированную картину того, какие модели, архитектуры и способы запуска набирают популярность. Последний пункт — интерпретация аналитиков, а не раскрытая цель сделки.
NVIDIA обещает сохранить Hugging Face открытой: её железо не будет обязательным, разработчики смогут выбирать модели, frameworks, clouds, inference providers и compute platforms. В 8-K обещание сформулировано чуть уже, но всё равно предметно: сохранить возможность загружать и скачивать выбранные модели и датасеты и продолжать поддержку других производителей чипов.
Это сильнее обычного «бренд останется прежним». Но открытость артефактов ещё не равна нейтральности платформы. Публичные документы пока не отвечают на четыре практических вопроса:
1️⃣ Кто и по каким правилам управляет ранжированием и рекомендациями моделей;
2️⃣ Как выбираются дефолты в маршрутизации инференса и какие провайдеры получают приоритет;
3️⃣ Будет ли одинаковой скорость интеграции и оптимизации для CUDA, ROCm, Trainium, TPU и CPU;
4️⃣ Где пройдёт граница использования телеметрии и данных о поведении разработчиков.
Сейчас нет доказательств, что NVIDIA собирается подкручивать эти механизмы в свою пользу. Но именно здесь и будет проходить настоящая проверка, а не в возможности скачать файл с весами. Поэтому обещание «Hugging Face останется открытой» — не сноска к пресс-релизу, а главный критерий приемки сделки. Если после закрытия конкурирующее железо и независимые провайдеры инференса будут появляться в роутинге, документации и оптимизациях на равных, а правила ранжирования и использования данных станут прозрачнее, ресурсы NVIDIA действительно могут усилить экосистему. Если нет, веса останутся открытыми, но площадка, на которой все их выбирают, перестанет быть нейтральной.
#AI #PlatformEngineering #OpenSource #Architecture #Infrastructure #Bigtech
NVIDIA Blog
NVIDIA to Acquire Hugging Face
NVIDIA has agreed to acquire Hugging Face. Together, we will scale Hugging Face’s platform, strengthen its infrastructure and expand access to AI for developers and institutions worldwide.
❤5🔥2🍾2
Stanford MS&E435: кто выбирает технологический стек — разработчик или кодинговый агент? (Рубрика #AI)
«Я вообще не знаю, что такое Vercel. Мой агент привёл меня сюда». Так, по словам Guillermo Rauch, написал ему в личку в X один из новых клиентов, столкнувшийся с ошибкой. В одной фразе — новая экономика дистрибуции софта: человек не сравнивал облака и, возможно, вообще не знал названия платформы. Платформу для развёртывания выбрал его любимый кодинговый агент:)
Это очередной разбор лекции из курса Stanford MS&E435, где мы начинали с карты экономики AI-суперцикла, а теперь дошли приложений и вопроса, а кто забирает ценность, когда софта становится больше. Guillermo Rauch, основатель и CEO Vercel, предлагает такой ответ: код дешевеет, но результат всё ещё нужно развернуть, запустить и обслуживать. Экономическая ставка Vercel — занять слой между намерением и работающим продуктом: дать агенту API для развёртывания, preview URL, изолированную среду, шлюз к моделям и долгоживущие процессы, а в перспективе — облако, которое само диагностирует эксплуатационные проблемы. Это одновременно содержательная лекция и аккуратно собранный питч от вендора.
Но интереснее то, что происходит до развертывания. По словам Rauch, агент приходит с уже сложившейся «картиной мира»: модели успели узнать Next.js, React и open-source инструменты Vercel из материалов в интернете. Такой агент не проводит нейтральный анализ. Я бы сформулировал экономическое следствие так: open source здесь становится дистрибуцией, а runtime — монетизацией.
В выступлении это подкрепляется цифрами из исследования Amplifying: Claude Code выбрал shadcn/ui в 64 из 71 ответов с извлечённым основным выбором (90,1%), а Vercel — во всех извлечённых deployment-ответах для Next.js и React SPA. Здесь важна сноска. Это 2 430 успешных ответов Claude Code с тремя моделями Claude на четырёх greenfield-репозиториях; Vercel получил 86 из 112 deployment picks в целом, то есть 76,8%. Это не доля рынка и не доказательство того, что выбранный продукт качественнее альтернатив.
Именно поэтому формула «агент выбрал» не равна формуле «рынок порешал». Выбор складывается из обучающих данных модели, системной инструкции, текущего стека, качества документации, видимости проекта в open source и того, может ли агент понять и применить компонент локально. В разборе Developer Experience для кодинговых агентов мы уже говорили про стандартный стек, CLI/API, быстрые тесты и понятные ошибки. Теперь видно экономическое продолжение: агентная эргономика становится не просто хорошим DevEx, а каналом продаж.
Есть и второй слой. Rauch считает, что интерфейс и локальный сценарий работы всё чаще будут генерироваться под задачу, а система учёта (system of record), данные, права доступа и API останутся. Я бы описал это как два периода полураспада софта: одноразовая оболочка и долговечное ядро. В самой лекции есть оговорка к тезису «software is basically free»: над сложным инфраструктурным кодом в Vercel, по словам Rauch, иногда собирают три агента и сильных инженеров, чтобы понять одну строку.
То есть дешевеет реализация, но не обязательно архитектура, проверка, безопасность и владение системой. В The New SDLC harness — это обвязка вокруг модели, делающая генерацию управляемой. Здесь появляется следующий экономический слой: агент и его harness становятся точкой выбора компонентов.
Для поставщика инструмента отсюда новый вопрос: сможет ли агент сам найти продукт, понять документацию, установить его, восстановиться после ошибки и объяснить свой выбор? Для покупателя — другой: почему агент принёс именно эту зависимость и какие варианты он даже не рассматривал? Раньше DevRel конкурировал за внимание разработчика. Теперь ему приходится бороться ещё и за место в картине мира модели — а этот gatekeeper часто вообще не виден пользователю.
#AI #Agents #PlatformEngineering #DevTools #Product #Economics
«Я вообще не знаю, что такое Vercel. Мой агент привёл меня сюда». Так, по словам Guillermo Rauch, написал ему в личку в X один из новых клиентов, столкнувшийся с ошибкой. В одной фразе — новая экономика дистрибуции софта: человек не сравнивал облака и, возможно, вообще не знал названия платформы. Платформу для развёртывания выбрал его любимый кодинговый агент:)
Это очередной разбор лекции из курса Stanford MS&E435, где мы начинали с карты экономики AI-суперцикла, а теперь дошли приложений и вопроса, а кто забирает ценность, когда софта становится больше. Guillermo Rauch, основатель и CEO Vercel, предлагает такой ответ: код дешевеет, но результат всё ещё нужно развернуть, запустить и обслуживать. Экономическая ставка Vercel — занять слой между намерением и работающим продуктом: дать агенту API для развёртывания, preview URL, изолированную среду, шлюз к моделям и долгоживущие процессы, а в перспективе — облако, которое само диагностирует эксплуатационные проблемы. Это одновременно содержательная лекция и аккуратно собранный питч от вендора.
Но интереснее то, что происходит до развертывания. По словам Rauch, агент приходит с уже сложившейся «картиной мира»: модели успели узнать Next.js, React и open-source инструменты Vercel из материалов в интернете. Такой агент не проводит нейтральный анализ. Я бы сформулировал экономическое следствие так: open source здесь становится дистрибуцией, а runtime — монетизацией.
В выступлении это подкрепляется цифрами из исследования Amplifying: Claude Code выбрал shadcn/ui в 64 из 71 ответов с извлечённым основным выбором (90,1%), а Vercel — во всех извлечённых deployment-ответах для Next.js и React SPA. Здесь важна сноска. Это 2 430 успешных ответов Claude Code с тремя моделями Claude на четырёх greenfield-репозиториях; Vercel получил 86 из 112 deployment picks в целом, то есть 76,8%. Это не доля рынка и не доказательство того, что выбранный продукт качественнее альтернатив.
Именно поэтому формула «агент выбрал» не равна формуле «рынок порешал». Выбор складывается из обучающих данных модели, системной инструкции, текущего стека, качества документации, видимости проекта в open source и того, может ли агент понять и применить компонент локально. В разборе Developer Experience для кодинговых агентов мы уже говорили про стандартный стек, CLI/API, быстрые тесты и понятные ошибки. Теперь видно экономическое продолжение: агентная эргономика становится не просто хорошим DevEx, а каналом продаж.
Есть и второй слой. Rauch считает, что интерфейс и локальный сценарий работы всё чаще будут генерироваться под задачу, а система учёта (system of record), данные, права доступа и API останутся. Я бы описал это как два периода полураспада софта: одноразовая оболочка и долговечное ядро. В самой лекции есть оговорка к тезису «software is basically free»: над сложным инфраструктурным кодом в Vercel, по словам Rauch, иногда собирают три агента и сильных инженеров, чтобы понять одну строку.
То есть дешевеет реализация, но не обязательно архитектура, проверка, безопасность и владение системой. В The New SDLC harness — это обвязка вокруг модели, делающая генерацию управляемой. Здесь появляется следующий экономический слой: агент и его harness становятся точкой выбора компонентов.
Для поставщика инструмента отсюда новый вопрос: сможет ли агент сам найти продукт, понять документацию, установить его, восстановиться после ошибки и объяснить свой выбор? Для покупателя — другой: почему агент принёс именно эту зависимость и какие варианты он даже не рассматривал? Раньше DevRel конкурировал за внимание разработчика. Теперь ему приходится бороться ещё и за место в картине мира модели — а этот gatekeeper часто вообще не виден пользователю.
#AI #Agents #PlatformEngineering #DevTools #Product #Economics
YouTube
Stanford MS&E435 Economics of the AI Supercycle | Spring 2026 | Applications, Coding AI
For more information about Stanford’s graduate programs, visit: https://online.stanford.edu/graduate-education
This seminar covers applications, coding AI, and the future of software.
Follow along with the schedule: https://mse435.stanford.edu/
Guest Speaker:…
This seminar covers applications, coding AI, and the future of software.
Follow along with the schedule: https://mse435.stanford.edu/
Guest Speaker:…
👍5❤2🔥1
TokenOps: как управлять бюджетом всего AI-agent run (Рубрика #AI4SDLC)
Недавно я писал, почему token burn полезен как финансовая телеметрия, но опасен как доказательство ценности. В 21-минутном докладе «FinOps for AI Agents: Who Spent All the Tokens?» два инженера Microsoft, Tisha Chawla и Susheem Koul, заходят с другой стороны: если стоимость всё-таки нужно контролировать, как делать это во время работы агента, а не после счёта от провайдера?
Их ответ — TokenOps, ранний open-source prototype и reference architecture, а не продукт Microsoft или Azure. Главный тезис мне кажется правильным: единицей управления должен быть весь run, а не отдельный LLM-запрос. Одна агентная задача проходит через модели, tools и subagents; обычный per-request лимит видит фрагменты, но теряет общую стоимость и причинность.
TokenOps добавляет к исполнению несколько вещей:
- Единый
- Бюджеты и policies назначаются сегментам: пользователю, команде, workload или типу запуска;
- Control plane возвращает одно из решений:
- Preview mode сначала показывает, какие правила сработали бы, но ничего не ломает.
Самая интересная идея здесь — по возможности STEER before HALT. Жёсткий стоп сохраняет бюджет, но уничтожает уже почти готовый результат. Поэтому систему предлагают корректировать раньше: сократить число RAG-chunks, ограничить tool output, сжать контекст, попросить модель отвечать короче или остановить бесполезный loop. В демонстрации retrieval вернул 20 фрагментов, хотя полезны были первые пять: governor может оставить пять ещё до следующего дорогого вызова модели.
Это не магия поверх шлюзов. Приложение нужно инструментировать: размечать границы и оборачивать вызовы, чтобы control plane видел структуру run. Зато решение о политике остаётся снаружи бизнес-логики, а исполняется там, где ещё можно изменить траекторию агента.
Авторы показывают и собственный benchmark на Browser Use и MetaGPT: сумма spend по 27 scored trials снизилась с $1.839 до $0.388, то есть на 78.9%, а число успешных запусков внутри бюджета выросло с 18/27 до 26/27. Но это пока иллюстрация PoC, а не доказанный production ROI: сценариев всего три, они специально подобраны для демонстрации ловушек, независимой репликации нет. Есть и несостыковка: в устном рассказе baseline назван простым throttling, а статья и таблица сравнивают TokenOps с vanilla/ungoverned запуском. Поэтому здесь важнее направление эффекта, чем красивый процент.
И ещё одна граница. Доклад начинается с перехода от token maxing к value maxing, но value-aware слой авторы пока не построили. Текущая система дисциплинирует стоимость; «задача завершилась внутри бюджета» ещё не означает, что ответ верный или полезный. Следующий взрослый шаг — связывать такой ledger с evals, риском и rework и считать cost per accepted task.
Я бы рекомендовал запись платформенным командам, которые уже запускают агентов в production. Не как готовый продукт, а как архитектурный checklist: стабильный
#AI4SDLC #AI #Agents #FinOps #Engineering #PlatformEngineering
Недавно я писал, почему token burn полезен как финансовая телеметрия, но опасен как доказательство ценности. В 21-минутном докладе «FinOps for AI Agents: Who Spent All the Tokens?» два инженера Microsoft, Tisha Chawla и Susheem Koul, заходят с другой стороны: если стоимость всё-таки нужно контролировать, как делать это во время работы агента, а не после счёта от провайдера?
Их ответ — TokenOps, ранний open-source prototype и reference architecture, а не продукт Microsoft или Azure. Главный тезис мне кажется правильным: единицей управления должен быть весь run, а не отдельный LLM-запрос. Одна агентная задача проходит через модели, tools и subagents; обычный per-request лимит видит фрагменты, но теряет общую стоимость и причинность.
TokenOps добавляет к исполнению несколько вещей:
- Единый
run_id проходит через model и tool calls, а расходы складываются в общий ledger;- Бюджеты и policies назначаются сегментам: пользователю, команде, workload или типу запуска;
- Control plane возвращает одно из решений:
ALLOW, STEER или HALT;- Preview mode сначала показывает, какие правила сработали бы, но ничего не ломает.
Самая интересная идея здесь — по возможности STEER before HALT. Жёсткий стоп сохраняет бюджет, но уничтожает уже почти готовый результат. Поэтому систему предлагают корректировать раньше: сократить число RAG-chunks, ограничить tool output, сжать контекст, попросить модель отвечать короче или остановить бесполезный loop. В демонстрации retrieval вернул 20 фрагментов, хотя полезны были первые пять: governor может оставить пять ещё до следующего дорогого вызова модели.
Это не магия поверх шлюзов. Приложение нужно инструментировать: размечать границы и оборачивать вызовы, чтобы control plane видел структуру run. Зато решение о политике остаётся снаружи бизнес-логики, а исполняется там, где ещё можно изменить траекторию агента.
Авторы показывают и собственный benchmark на Browser Use и MetaGPT: сумма spend по 27 scored trials снизилась с $1.839 до $0.388, то есть на 78.9%, а число успешных запусков внутри бюджета выросло с 18/27 до 26/27. Но это пока иллюстрация PoC, а не доказанный production ROI: сценариев всего три, они специально подобраны для демонстрации ловушек, независимой репликации нет. Есть и несостыковка: в устном рассказе baseline назван простым throttling, а статья и таблица сравнивают TokenOps с vanilla/ungoverned запуском. Поэтому здесь важнее направление эффекта, чем красивый процент.
И ещё одна граница. Доклад начинается с перехода от token maxing к value maxing, но value-aware слой авторы пока не построили. Текущая система дисциплинирует стоимость; «задача завершилась внутри бюджета» ещё не означает, что ответ верный или полезный. Следующий взрослый шаг — связывать такой ledger с evals, риском и rework и считать cost per accepted task.
Я бы рекомендовал запись платформенным командам, которые уже запускают агентов в production. Не как готовый продукт, а как архитектурный checklist: стабильный
run_id, прозрачная атрибуция, per-run budget, preview policies, ранний steering и hard stop только последним рубежом.#AI4SDLC #AI #Agents #FinOps #Engineering #PlatformEngineering
YouTube
FinOps for AI Agents: Who Spent All the Tokens? — Tisha Chawla & Susheem Koul, Microsoft
Turning the full policy suite on cut average agent spend by about 78% across benchmark runs on two open source repos, and lifted the share of runs that actually completed from 67% to roughly 96%. That second number is the point. Simple throttling holds the…
👍7❤5🔥3😱1
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
В беседе 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
YouTube
Stanford MS&E435 Economics of the AI Supercycle | Spring 2026 | Applications, Applied AI
For more information about Stanford’s graduate programs, visit: https://online.stanford.edu/graduate-education
This seminar covers applications, applied AI, and agent monetization.
Follow along with the course schedule: https://mse435.stanford.edu/
Guest…
This seminar covers applications, applied AI, and agent monetization.
Follow along with the course schedule: https://mse435.stanford.edu/
Guest…
❤4🔥2👍1
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
Этот выпуск 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
YouTube
Open Models Change The Economics of AI
Ollama (YC W21) is used by 9 million developers and 85% of the Fortune 500, giving co-founder and CEO Jeffrey Morgan a unique view into which AI models people are actually using and how that’s changing.
Right now, the biggest shift he sees is toward open…
Right now, the biggest shift he sees is toward open…
❤8🔥3👍2
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 постепенно строит общий слой подключения ускорителей через
Но до взаимозаменяемости ещё далеко. 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️⃣ Смогут ли
3️⃣ Будут ли приниматься upstream-изменения в Inductor, distributed stack и domain libraries, а не только расти внешние vendor-репозитории.
Если это произойдёт, PyTorch станет для AI-железа настоящим слоем переносимости и немного уменьшит программный lock-in NVIDIA. Не отменит CUDA, её зрелые kernels, NCCL и инструменты — именно уменьшит цену первого шага в сторону другого ускорителя. Если нет, членство останется дорогим логотипом на сайте.
#AI #OpenSource #PlatformEngineering #Infrastructure #Architecture #Bigtech
В этой новости легко зацепиться за геополитику: 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
www.linuxfoundation.org
Alibaba Cloud, Ant Group, Cambricon and Huawei Come Together in Shanghai to Advance the Open Source AI Stack at PyTorch Conference…
❤4🔥2👍1
AI4SDLC на ИТ-Пикнике: материалы выступления (Рубрика #AI4SDLC)
Собрал материалы моего выступления на ИТ-Пикнике 8 августа — «State of AI4SDLC: AI сдвигает узкие места разработки». Это было моё последнее выступление от имени Т-Банка. В нём я подвёл итог AI4SDLC в том виде, в котором развивал это направление: с исследованием, инженерной платформой, агентами и перестройкой работы команд.
В докладе разбираю, что происходит после того, как код научились писать быстрее. Задачи начинают скапливаться на ревью и тестировании, а дальше выясняется, что ограничением стали постановка и приёмка результата. Выдать всем AI-инструменты — только начало работы. Отсюда и остальные темы: зачем снова нужны спецификации, как подготовить внутреннюю платформу к работе агентов, почему стоит измерять ожидание, переделки, качество и стоимость. И как меняется работа инженера, который всё больше формулирует задачи, собирает контекст и проверяет сделанное агентами.
Материалы можно открыть в удобном формате:
— Слайды
— Видео выступления
— Конспект и сокращённая расшифровка — около 7 минут чтения, подготовлены по субтитрам и слайдам.
#AI4SDLC #Agents #PlatformEngineering #Conference
Собрал материалы моего выступления на ИТ-Пикнике 8 августа — «State of AI4SDLC: AI сдвигает узкие места разработки». Это было моё последнее выступление от имени Т-Банка. В нём я подвёл итог AI4SDLC в том виде, в котором развивал это направление: с исследованием, инженерной платформой, агентами и перестройкой работы команд.
В докладе разбираю, что происходит после того, как код научились писать быстрее. Задачи начинают скапливаться на ревью и тестировании, а дальше выясняется, что ограничением стали постановка и приёмка результата. Выдать всем AI-инструменты — только начало работы. Отсюда и остальные темы: зачем снова нужны спецификации, как подготовить внутреннюю платформу к работе агентов, почему стоит измерять ожидание, переделки, качество и стоимость. И как меняется работа инженера, который всё больше формулирует задачи, собирает контекст и проверяет сделанное агентами.
Материалы можно открыть в удобном формате:
— Слайды
— Видео выступления
— Конспект и сокращённая расшифровка — около 7 минут чтения, подготовлены по субтитрам и слайдам.
#AI4SDLC #Agents #PlatformEngineering #Conference
polomodov.tech
State of AI4SDLC: как AI сдвигает узкие… — ИТ-Пикник 2026 · Т-Банк
Версия для ИТ-Пикника: как AI ускоряет кодинг и переносит узкие места в постановку, ревью, тесты и delivery; agent-first платформа, evals и метрики потока
👍7🔥5❤3
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
Супер-крутой доклад — прямо много попаданий в реальность. Пока слушал, то и дело ловил дежавю. И у этой истории есть первый акт: в 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
YouTube
We doubled engineering productivity at eBay, but couldn't change culture
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
❤11🔥5👍4
Habitat: эволюция слоя хранения OpenAI (Рубрика #AI4SDLC)
Во втором квартале 2026 года два инженера с помощью Codex и GPT‑5.5 переписали Habitat с Python на Rust. В статье от 11 сентября OpenAI сообщила: Rust уже обслуживает 95% запросов этого сервиса. Habitat — это слой между ChatGPT, Codex и хранилищами: маршрутизация, права доступа, шифрование и правила размещения данных. И это интересный кейс AI-assisted миграции критической инфраструктуры, причем миграции масштабной — по данным OpenAI: почти 40 регионов, свыше 500 ПБ и 70 млн внутренних запросов в секунду. Компания заявляет выигрыш в эффективности CPU в 6 раз, памяти — в 15, правда, методики сравнения в статье нет.
Но изюминка здесь — в том, как ребята дошли до момента, когда переписывание стало правильной следующей задачей.
1️⃣ В 2023 году Habitat начинался как Python-библиотека над Cosmos DB. Она прятала детали хранения от продуктовых команд. Удобно: подключил библиотеку и работаешь с данными, не разбираясь каждый раз с маршрутизацией и авторизацией.
2️⃣ К середине 2025-го эта простота стала дорого обходиться. Новую логику приходилось раскатывать через десятки сервисов. Добавили проверку на теневом трафике — ещё несколько дней согласований. Исправили ошибку — новый круг. А потом одна команда откатила свой сервис по другой причине и вернула старый баг. Получили именно тот сбой, от которого пытались защититься.
3️⃣ Общая библиотека перестала быть удобной границей управления
— Habitat выделили в сервис: теперь изменения хранения, наблюдаемость и политики доступа можно было контролировать централизованно.
— И тут команда сознательно оставила Python. Сначала требовалось стабилизировать платформу и API, разблокировать продуктовую разработку. За эффективность решили заплатить позже, рассчитывая в том числе на развитие кодинг-моделей. Техдолг здесь был осознанным выбором порядка работ.
— При этом API намеренно сделали менее мощным. Простые операции над объектами и связями, предсказуемый объём работы, никаких произвольных SQL-запросов и неограниченных обходов графа. Объект и его связи лежат в одной партиции; соседние объекты могут оказаться в другом регионе. Красивый граф в модели данных ещё не обещает дешёвого обхода.
— Для сложных запросов — отдельные экземпляры Rockset, получающие изменения через CDC. Их масштабируют сами команды. Да, клиентам добавили хлопот. Зато цена сложного запроса становится их явной задачей, а аналитика изолирована от оперативного доступа к данным.
4️⃣ Следующий вызов — хвостовые latency внутри самого сервиса
База уже ответила, но занятый asyncio-цикл ещё не дал обработать результат. Команда стала измерять задержку планирования задач. Даже периодический разбор большого конфига feature flags оказался источником тормозов: помогли уменьшение конфига и разнесение обновлений во времени. А пул соединений с LIFO создал совсем неприятную петлю: медленный сервер позже возвращал соединение, оно первым использовалось снова, и перегруженный процесс получал ещё больше работы (это была ситуация с метастабильными отказами). Переход на FIFO разорвал эту обратную связь.
5️⃣ До Rust дошли уже с работающей платформой и понятными ограничениями. Python-версия на пике обслуживала более 20 млн запросов в секунду. Дальше пришло время снижать ресурсную цену этой архитектуры. Поэтому «два инженера переписали сервис» — финал длинной истории. До него пришлось определить границы ответственности, ограничить стоимость операций и разобраться с поведением системы под нагрузкой.
В общем, AI помог переписать реализацию, но сам кейс гораздо интереснее.
#AI4SDLC #Architecture #PlatformEngineering #Engineering #Rust #AI
Во втором квартале 2026 года два инженера с помощью Codex и GPT‑5.5 переписали Habitat с Python на Rust. В статье от 11 сентября OpenAI сообщила: Rust уже обслуживает 95% запросов этого сервиса. Habitat — это слой между ChatGPT, Codex и хранилищами: маршрутизация, права доступа, шифрование и правила размещения данных. И это интересный кейс AI-assisted миграции критической инфраструктуры, причем миграции масштабной — по данным OpenAI: почти 40 регионов, свыше 500 ПБ и 70 млн внутренних запросов в секунду. Компания заявляет выигрыш в эффективности CPU в 6 раз, памяти — в 15, правда, методики сравнения в статье нет.
Но изюминка здесь — в том, как ребята дошли до момента, когда переписывание стало правильной следующей задачей.
1️⃣ В 2023 году Habitat начинался как Python-библиотека над Cosmos DB. Она прятала детали хранения от продуктовых команд. Удобно: подключил библиотеку и работаешь с данными, не разбираясь каждый раз с маршрутизацией и авторизацией.
2️⃣ К середине 2025-го эта простота стала дорого обходиться. Новую логику приходилось раскатывать через десятки сервисов. Добавили проверку на теневом трафике — ещё несколько дней согласований. Исправили ошибку — новый круг. А потом одна команда откатила свой сервис по другой причине и вернула старый баг. Получили именно тот сбой, от которого пытались защититься.
3️⃣ Общая библиотека перестала быть удобной границей управления
— Habitat выделили в сервис: теперь изменения хранения, наблюдаемость и политики доступа можно было контролировать централизованно.
— И тут команда сознательно оставила Python. Сначала требовалось стабилизировать платформу и API, разблокировать продуктовую разработку. За эффективность решили заплатить позже, рассчитывая в том числе на развитие кодинг-моделей. Техдолг здесь был осознанным выбором порядка работ.
— При этом API намеренно сделали менее мощным. Простые операции над объектами и связями, предсказуемый объём работы, никаких произвольных SQL-запросов и неограниченных обходов графа. Объект и его связи лежат в одной партиции; соседние объекты могут оказаться в другом регионе. Красивый граф в модели данных ещё не обещает дешёвого обхода.
— Для сложных запросов — отдельные экземпляры Rockset, получающие изменения через CDC. Их масштабируют сами команды. Да, клиентам добавили хлопот. Зато цена сложного запроса становится их явной задачей, а аналитика изолирована от оперативного доступа к данным.
4️⃣ Следующий вызов — хвостовые latency внутри самого сервиса
База уже ответила, но занятый asyncio-цикл ещё не дал обработать результат. Команда стала измерять задержку планирования задач. Даже периодический разбор большого конфига feature flags оказался источником тормозов: помогли уменьшение конфига и разнесение обновлений во времени. А пул соединений с LIFO создал совсем неприятную петлю: медленный сервер позже возвращал соединение, оно первым использовалось снова, и перегруженный процесс получал ещё больше работы (это была ситуация с метастабильными отказами). Переход на FIFO разорвал эту обратную связь.
5️⃣ До Rust дошли уже с работающей платформой и понятными ограничениями. Python-версия на пике обслуживала более 20 млн запросов в секунду. Дальше пришло время снижать ресурсную цену этой архитектуры. Поэтому «два инженера переписали сервис» — финал длинной истории. До него пришлось определить границы ответственности, ограничить стоимость операций и разобраться с поведением системы под нагрузкой.
В общем, AI помог переписать реализацию, но сам кейс гораздо интереснее.
#AI4SDLC #Architecture #PlatformEngineering #Engineering #Rust #AI
OpenAI
Rapidly scaling online storage to serve over 1 billion ChatGPT users
Learn how OpenAI evolved Habitat from a Python library into a globally distributed storage platform serving 1 billion ChatGPT users and 22M requests per second.
🔥5❤3👍3🫡1
Как AI изменит разработку ПО: материалы Organized Programming №92 (Рубрика #AI4SDLC)
Собрал материалы разговора с Кириллом Мокевниным: 13 сентября 2026 года вышел выпуск №92 Organized Programming, где я был гостем. Обсуждали, как AI меняет программистов, команды и IT-компании. Делился опытом внедрения AI в Т-Банке — и тем, почему после ускорения написания кода ещё приходится разбираться со всей остальной разработкой.
Если продуктовый менеджер быстрее пишет постановки, аналитик — требования, а разработчик — код, очереди между ними могут только вырасти. Интереснее посмотреть, сколько людей и согласований проходит одна задача, прежде чем результат увидит пользователь.
Обсудили
🔸 Команды с агентами
Один инженер может брать на себя больше этапов работы, сокращая передачи задачи между людьми. При этом необходимые роли сохраняются. Компактная команда — обсуждаемое направление изменений, а не уже достигнутая норма для любой компании.
🔸 Внедрение на масштабе
Общий доступ к моделям, инструменты, навыки для агентов и изолированные среды дают техническую основу. А менять процесс должно само продуктовое направление: исключения, на которых взлетел пилот, ещё нужно научиться воспроизводить для остальных.
🔸 Спецификации и проверку плана
Кирилл рассказал, как использует эти практики даже в небольших проектах: агенты снижают стоимость оформления. Но требования к качеству всё равно нужно подкреплять автоматическими проверками — один документ ничего не гарантирует.
🔸 Знания и внутренние платформы
Агенту трудно разобраться с неявными правилами и корпоративным форком, который ведёт себя иначе, чем исходный продукт. При этом документацией пользуются и люди вне разработки: переезд всего знания в Git меняет их работу тоже.
🔸 Три уровня измерения пользы
Используют ли инструмент, сколько времени он высвобождает и что компания получает с учётом всех затрат. Больше закрытых задач может означать, что команда просто добралась до менее полезной части очереди. Нужны новые стоящие гипотезы и понимание, куда направить освободившееся время.
🔸 Обучение и границы автономии
Готовая функция мало говорит о том, чему научился джун: надо разбирать постановку, план и понимание результата. В сложном легаси похожая проблема — сначала выяснить, почему система устроена именно так и кто зависит от её поведения.
Материалы выпуска
📌 Страница выпуска
📖 Когда код пишет агент: что остаётся инженерией — лонгрид подготовки к разговору.
🎬 Запись на YouTube
📝 Текстовый конспект разговора
Если уже внедряете агентов в команде, расскажите: что теперь дольше всего задерживает полезное изменение на пути к пользователю?
#AI4SDLC #AI #Agents #Engineering #PlatformEngineering #Management
Собрал материалы разговора с Кириллом Мокевниным: 13 сентября 2026 года вышел выпуск №92 Organized Programming, где я был гостем. Обсуждали, как AI меняет программистов, команды и IT-компании. Делился опытом внедрения AI в Т-Банке — и тем, почему после ускорения написания кода ещё приходится разбираться со всей остальной разработкой.
Если продуктовый менеджер быстрее пишет постановки, аналитик — требования, а разработчик — код, очереди между ними могут только вырасти. Интереснее посмотреть, сколько людей и согласований проходит одна задача, прежде чем результат увидит пользователь.
Обсудили
Один инженер может брать на себя больше этапов работы, сокращая передачи задачи между людьми. При этом необходимые роли сохраняются. Компактная команда — обсуждаемое направление изменений, а не уже достигнутая норма для любой компании.
Общий доступ к моделям, инструменты, навыки для агентов и изолированные среды дают техническую основу. А менять процесс должно само продуктовое направление: исключения, на которых взлетел пилот, ещё нужно научиться воспроизводить для остальных.
Кирилл рассказал, как использует эти практики даже в небольших проектах: агенты снижают стоимость оформления. Но требования к качеству всё равно нужно подкреплять автоматическими проверками — один документ ничего не гарантирует.
Агенту трудно разобраться с неявными правилами и корпоративным форком, который ведёт себя иначе, чем исходный продукт. При этом документацией пользуются и люди вне разработки: переезд всего знания в Git меняет их работу тоже.
Используют ли инструмент, сколько времени он высвобождает и что компания получает с учётом всех затрат. Больше закрытых задач может означать, что команда просто добралась до менее полезной части очереди. Нужны новые стоящие гипотезы и понимание, куда направить освободившееся время.
Готовая функция мало говорит о том, чему научился джун: надо разбирать постановку, план и понимание результата. В сложном легаси похожая проблема — сначала выяснить, почему система устроена именно так и кто зависит от её поведения.
Материалы выпуска
📌 Страница выпуска
📖 Когда код пишет агент: что остаётся инженерией — лонгрид подготовки к разговору.
🎬 Запись на YouTube
📝 Текстовый конспект разговора
Если уже внедряете агентов в команде, расскажите: что теперь дольше всего задерживает полезное изменение на пути к пользователю?
#AI4SDLC #AI #Agents #Engineering #PlatformEngineering #Management
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Как AI изменит разработку ПО: будущее программистов, команд и IT-компаний /Александр Поломодов #92
🔹 Присоединяйся к курсу «Системный дизайн» https://ru.hexlet.io/programs/system-design?utm_source=youtube
Через несколько лет в IT может не остаться привычного разделения на фронтендеров, бэкендеров, аналитиков и тестировщиков. Не потому, что эти задачи…
Через несколько лет в IT может не остаться привычного разделения на фронтендеров, бэкендеров, аналитиков и тестировщиков. Не потому, что эти задачи…
❤6👍4🔥2💯1
YC Paper Club: что делает модель рабочим агентом (Рубрика #AI4SDLC)
Посмотрел интересную встречу YC Paper Club про harness, которая называлась «Why The Harness Matters More Than The Model» и где обсуждалась обвязка модели: инструменты, память, выполнение кода и управление работой агента. Сама запись появилась 7 сентября и хоть заголовок видео спорный, но внутри четыре инженерных выступления о том, а что меняется, когда той же модели дают больше возможностей работать с окружающей средой.
1️⃣ Вступление François Chaubard из Y Combinator отлично работает как вступление. Он проходит путь от генерации текста к инструментам, памяти, навыкам, субагентам и системам, которые меняют собственную обвязку по результатам работы (тут прямо много отсылок к whitepapers). Заодно показывает свой эксперимент с автоматизацией исследований: задаёшь идею и метрику, дальше агенты ищут статьи, ставят эксперименты и готовят текст. Среди ролей есть даже научный руководитель, который периодически напоминает исследователю, что пора двигаться дальше. Академическую жизнь тоже автоматизируют :)
2️⃣ Seth Karten из Prime Intellect рассказывает про Prime Agent. У него интересная аналогия с иерархией памяти компьютера: веса модели, активный контекст, переменные в работающем Python-процессе и долговременные файлы. Большой результат инструмента можно оставить в памяти процесса, обработать кодом и передать модели только нужный фрагмент. Субагента можно вернуть к задаче с сохранённым контекстом. По мере работы обновлять навыки и инструкции, чтобы полезный опыт переживал отдельную сессию. Кстати, сама идея «дать агентам общаться друг с другом» выросла у Karten из вполне человеческой проблемы: надоело самому переносить информацию между параллельно работающими помощниками.
Среди примеров — создание эмуляторов игровых систем, оптимизация GPU-ядер и многодневные исследовательские задачи. Есть и история про почти идеальный результат на ARC-AGI: по словам Karten, первый запуск показал 99,9%, но просмотр логов обнаружил жульничество. Пришлось исправлять изоляцию среды и запускать заново. Полезная деталь для всех, кто привык смотреть только на итоговую цифру бенчмарка.
3️⃣ Jon Saad-Falcon из Stanford показывает OpenJarvis — персонального помощника, работающего на собственном устройстве. Здесь интересна схема настройки: сильная облачная модель изучает ошибки локальной системы и предлагает изменения модели, инструментов, памяти и логики агента. Изменения проходят проверку, а готовая конфигурация выполняет задачи локально. Авторы заявляют снижение предельных API-затрат примерно в 800 раз на своих тестах. Это не полная стоимость владения с железом и электричеством. Но сама возможность использовать облачную модель для подготовки более дешёвого локального помощника заслуживает внимания.
4️⃣ Самая прикладная часть — Josh France и Regan Bell из YC Labs про QM, внутреннюю платформу агентов для сотрудников YC. До неё команда подняла больше 50 Hermes-агентов в виртуальных машинах. Помощники были полезными, но требовали настройки и постоянного обслуживания: приходилось заходить в отдельные экземпляры и что-то чинить.
В QM историю и состояние разговоров вынесли в PostgreSQL, а песочницы стали ресурсами, которые агент подключает по необходимости. Обсуждают и менее очевидные трудности: агент слишком рано заканчивает работу; автоматические исправления помогают одному участку, но не учитывают систему целиком; информация из личного разговора может попасть в общий канал, потому что модель плохо понимает социальный контекст.
В общем, рекомендую посмотреть оригинальную запись - она длится всего час и там есть и исследовательские идеи и прикладной опыт.
#AI4SDLC #AI #Agents #Engineering #PlatformEngineering
Посмотрел интересную встречу YC Paper Club про harness, которая называлась «Why The Harness Matters More Than The Model» и где обсуждалась обвязка модели: инструменты, память, выполнение кода и управление работой агента. Сама запись появилась 7 сентября и хоть заголовок видео спорный, но внутри четыре инженерных выступления о том, а что меняется, когда той же модели дают больше возможностей работать с окружающей средой.
1️⃣ Вступление François Chaubard из Y Combinator отлично работает как вступление. Он проходит путь от генерации текста к инструментам, памяти, навыкам, субагентам и системам, которые меняют собственную обвязку по результатам работы (тут прямо много отсылок к whitepapers). Заодно показывает свой эксперимент с автоматизацией исследований: задаёшь идею и метрику, дальше агенты ищут статьи, ставят эксперименты и готовят текст. Среди ролей есть даже научный руководитель, который периодически напоминает исследователю, что пора двигаться дальше. Академическую жизнь тоже автоматизируют :)
2️⃣ Seth Karten из Prime Intellect рассказывает про Prime Agent. У него интересная аналогия с иерархией памяти компьютера: веса модели, активный контекст, переменные в работающем Python-процессе и долговременные файлы. Большой результат инструмента можно оставить в памяти процесса, обработать кодом и передать модели только нужный фрагмент. Субагента можно вернуть к задаче с сохранённым контекстом. По мере работы обновлять навыки и инструкции, чтобы полезный опыт переживал отдельную сессию. Кстати, сама идея «дать агентам общаться друг с другом» выросла у Karten из вполне человеческой проблемы: надоело самому переносить информацию между параллельно работающими помощниками.
Среди примеров — создание эмуляторов игровых систем, оптимизация GPU-ядер и многодневные исследовательские задачи. Есть и история про почти идеальный результат на ARC-AGI: по словам Karten, первый запуск показал 99,9%, но просмотр логов обнаружил жульничество. Пришлось исправлять изоляцию среды и запускать заново. Полезная деталь для всех, кто привык смотреть только на итоговую цифру бенчмарка.
3️⃣ Jon Saad-Falcon из Stanford показывает OpenJarvis — персонального помощника, работающего на собственном устройстве. Здесь интересна схема настройки: сильная облачная модель изучает ошибки локальной системы и предлагает изменения модели, инструментов, памяти и логики агента. Изменения проходят проверку, а готовая конфигурация выполняет задачи локально. Авторы заявляют снижение предельных API-затрат примерно в 800 раз на своих тестах. Это не полная стоимость владения с железом и электричеством. Но сама возможность использовать облачную модель для подготовки более дешёвого локального помощника заслуживает внимания.
4️⃣ Самая прикладная часть — Josh France и Regan Bell из YC Labs про QM, внутреннюю платформу агентов для сотрудников YC. До неё команда подняла больше 50 Hermes-агентов в виртуальных машинах. Помощники были полезными, но требовали настройки и постоянного обслуживания: приходилось заходить в отдельные экземпляры и что-то чинить.
В QM историю и состояние разговоров вынесли в PostgreSQL, а песочницы стали ресурсами, которые агент подключает по необходимости. Обсуждают и менее очевидные трудности: агент слишком рано заканчивает работу; автоматические исправления помогают одному участку, но не учитывают систему целиком; информация из личного разговора может попасть в общий канал, потому что модель плохо понимает социальный контекст.
В общем, рекомендую посмотреть оригинальную запись - она длится всего час и там есть и исследовательские идеи и прикладной опыт.
#AI4SDLC #AI #Agents #Engineering #PlatformEngineering
YouTube
Why The Harness Matters More Than The Model | YC Paper Club
Harnesses get dismissed as just scaffolding, just prompt engineering, and not real research. But that couldn't be farther from the truth. The same model weights that score 30% on ARC-AGI score 95% with a better harness.
So we gathered a group of researchers…
So we gathered a group of researchers…
❤5👍3🔥3
Kubernetes: слишком сложно? Материалы DevOps Deflope №62 (Рубрика #PlatformEngineering)
Сходил в гости к DevOps Deflope — вместе с Александром Качмашевым из «Точка Банк». В выпуске №62 от 13 сентября 2026 года поговорили о том, почему запустить приложение в Kubernetes проще, чем потом со всем этим жить.
Обсудили:
- Сложность Kubernetes. Что происходит, когда за привычным Helm-чартом приходится разбираться с сетями и протекающими абстракциями.
- Внутренние платформы. Какую работу они снимают с разработчиков и кто берёт её на себя. Число подключённых команд ещё не говорит, насколько им удобно.
- AI-агентов в кластере. Читать состояние, советовать и менять инфраструктуру — три разных уровня доверия. Обсудили проверки, ограниченные права и изменения через GitOps.
Материалы выпуска:
🎧 Apple Podcasts , Яндекс Музыка, Spotify
📌 Страница выпуска у меня на сайте и текстовый конспект
📖 Лонгрид моей подготовки: куда переезжает сложность Kubernetes
А у вас какая часть сложности осталась у разработчиков, а какая переехала в платформенную команду?
#PlatformEngineering #Kubernetes #DevOps #AI #Engineering
Сходил в гости к DevOps Deflope — вместе с Александром Качмашевым из «Точка Банк». В выпуске №62 от 13 сентября 2026 года поговорили о том, почему запустить приложение в Kubernetes проще, чем потом со всем этим жить.
Обсудили:
- Сложность Kubernetes. Что происходит, когда за привычным Helm-чартом приходится разбираться с сетями и протекающими абстракциями.
- Внутренние платформы. Какую работу они снимают с разработчиков и кто берёт её на себя. Число подключённых команд ещё не говорит, насколько им удобно.
- AI-агентов в кластере. Читать состояние, советовать и менять инфраструктуру — три разных уровня доверия. Обсудили проверки, ограниченные права и изменения через GitOps.
Материалы выпуска:
🎧 Apple Podcasts , Яндекс Музыка, Spotify
📌 Страница выпуска у меня на сайте и текстовый конспект
📖 Лонгрид моей подготовки: куда переезжает сложность Kubernetes
А у вас какая часть сложности осталась у разработчиков, а какая переехала в платформенную команду?
#PlatformEngineering #Kubernetes #DevOps #AI #Engineering
Apple Podcasts
062 - Kubernetes: слишком сложно?
Podcast Episode · DevOps Дефлопе подкаст · September 13 · 1h 26m
❤4🔥3👍1
Research Insights Made Simple #31: AI4SDLC — что бы я делал по-другому (Рубрика #AI4SDLC)
С чего начинать свой AI-стек: с выбора модели, покупки GPU, написания собственной обвязки? На Deep Tech Night 5 сентября в рамках lighting talk я предложил начать с границы владения: что арендовать, что дорабатывать под свою среду и что обязательно держать под своим контролем.
22 сентября в 13:00 МСК в прямом эфире расскажу режиссёрскую версию этого выступления, за которое набролось 100+ голосов в одном из прошлых постов.
В центре выпуска — несколько вполне практических вопросов:
- Зачем писать собственный цикл агента, если рынок уже развивает готовые? И где своя обвязка всё-таки оправданна?
- Почему одна и та же модель даёт разный результат с разными инструментами, контекстом и правами?
- Как отличить красивый трейс от выполненной задачи — и проверить, что очередная доработка действительно помогла?
- Какие задачи можно передать меньшей модели, а где пока стоит оставить большую?
Cлайды выступления уже на сайте. Сам выпуск — 22 сентября на YouTube. Приходите, особенно если сейчас решаете, какую часть AI-стека действительно стоит делать своей.
#AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Evals
С чего начинать свой AI-стек: с выбора модели, покупки GPU, написания собственной обвязки? На Deep Tech Night 5 сентября в рамках lighting talk я предложил начать с границы владения: что арендовать, что дорабатывать под свою среду и что обязательно держать под своим контролем.
22 сентября в 13:00 МСК в прямом эфире расскажу режиссёрскую версию этого выступления, за которое набролось 100+ голосов в одном из прошлых постов.
В центре выпуска — несколько вполне практических вопросов:
- Зачем писать собственный цикл агента, если рынок уже развивает готовые? И где своя обвязка всё-таки оправданна?
- Почему одна и та же модель даёт разный результат с разными инструментами, контекстом и правами?
- Как отличить красивый трейс от выполненной задачи — и проверить, что очередная доработка действительно помогла?
- Какие задачи можно передать меньшей модели, а где пока стоит оставить большую?
Cлайды выступления уже на сайте. Сам выпуск — 22 сентября на YouTube. Приходите, особенно если сейчас решаете, какую часть AI-стека действительно стоит делать своей.
#AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Evals
YouTube
AI4SDLC: что бы я делал по-другому | Режиссёрская версия | Research Insights Made Simple #31
Что арендовать у AI-провайдеров, что дорабатывать под свою среду и чем владеть самим? 22 сентября 2026 года в 13:00 МСК выйдет Research Insights Made Simple #31 — режиссёрская версия моего выступления на Deep Tech Night 5 сентября: «AI4SDLC: что бы я делал…
🔥7👍6❤4
Homa: почему GPU ждут сеть (Рубрика #AI)
Посмотрел свежий доклад Джона Оустерхаута из Stanford про Homa (Джон - соавтор протокола консенсуса Raft, а также автор крутой книги "A Philosophy of Software Design", о которой я уже рассказывал). В заголовке доклада заявлен тизис «конец TCP для AI-кластеров», а внутри интересный инженерный вопрос: сколько времени дорогие GPU простаивают, пока маленькое сообщение ждёт за большой передачей? По мысли Оустерхаута, в инференсе и агентных системах растёт роль коротких обменов: проверить запись в распределённом KV-кэше, согласовать следующий шаг вычислений. Здесь важна хвостовая задержка: один запоздавший ответ может задержать всех участников синхронизации.
Проблема хорошо известна распределённым системам (она буквально продолжает историю "The Tail at Scale", что я разбирал вчера). Когда несколько серверов одновременно отправляют данные одному получателю, перед его сетевым портом растёт очередь — incast. Короткому сообщению тоже приходится ждать.
Homa предлагает перестроить транспорт вокруг сообщений:
— Знать длину сообщения и давать преимущество тем, которым осталось передать меньше байтов.
— Управлять потоком со стороны получателя: отправитель передаёт начальную порцию, а дальше получает разрешения — grants.
— Использовать приоритетные очереди коммутаторов, чтобы короткие сообщения обходили большие передачи.
В показанном бенчмарке, по данным автора, p99 задержки коротких сообщений у Homa примерно в 13 раз ниже, чем у TCP. Большие сообщения при этом тоже выигрывают. Уже есть Linux-модуль, тесты и утилиты измерений. Но с заголовком и широтой выводов я бы поспорил.
1️⃣ На слайде презентации сетевой бенчмарк, который демонстрирует эффект использования протокола
Ускорения LLM в 13 раз из него не следует: нужно измерять время ответа приложения, tokens/s и загрузку GPU. Выигрыш зависит от того, какая доля ожидания действительно приходится на транспорт.
2️⃣ Отрасль давно работает над этой проблемой
Google описал промышленное применение Swift, а SIRD исследует, как согласовывать решения получателей, когда узким местом становится общий канал. Сравнение с TCP ещё не закрывает спор о лучшем транспорте.
3️⃣ Границы применимости существенны: Homa рассчитан на сеть внутри дата-центра. Нужны интеграция с приложением и настройка сети; разработка grpc_homa приостановлена. Для внедрения работы хватает.
Почитать подробнее — научные статьи и техническое обоснование:
— Homa, SIGCOMM 2018 — устройство протокола.
— Linux-реализация, USENIX ATC 2021 — измерения на 40 узлах; на странице есть PDF.
— It’s Time to Replace TCP in the Datacenter — аргументы Оустерхаута против архитектуры TCP в ЦОД.
Кстати, в конце доклада автор приглашает экспериментировать с Homa и обещает помощь: ouster@cs.stanford.edu. Хорошая задача для входа — проверить, сколько сетевого выигрыша сохраняется в реальной AI-нагрузке. Вот такой результат мне было бы интересно увидеть.
#AI #Architecture #Engineering #Research #PlatformEngineering
Посмотрел свежий доклад Джона Оустерхаута из Stanford про Homa (Джон - соавтор протокола консенсуса Raft, а также автор крутой книги "A Philosophy of Software Design", о которой я уже рассказывал). В заголовке доклада заявлен тизис «конец TCP для AI-кластеров», а внутри интересный инженерный вопрос: сколько времени дорогие GPU простаивают, пока маленькое сообщение ждёт за большой передачей? По мысли Оустерхаута, в инференсе и агентных системах растёт роль коротких обменов: проверить запись в распределённом KV-кэше, согласовать следующий шаг вычислений. Здесь важна хвостовая задержка: один запоздавший ответ может задержать всех участников синхронизации.
Проблема хорошо известна распределённым системам (она буквально продолжает историю "The Tail at Scale", что я разбирал вчера). Когда несколько серверов одновременно отправляют данные одному получателю, перед его сетевым портом растёт очередь — incast. Короткому сообщению тоже приходится ждать.
Homa предлагает перестроить транспорт вокруг сообщений:
— Знать длину сообщения и давать преимущество тем, которым осталось передать меньше байтов.
— Управлять потоком со стороны получателя: отправитель передаёт начальную порцию, а дальше получает разрешения — grants.
— Использовать приоритетные очереди коммутаторов, чтобы короткие сообщения обходили большие передачи.
В показанном бенчмарке, по данным автора, p99 задержки коротких сообщений у Homa примерно в 13 раз ниже, чем у TCP. Большие сообщения при этом тоже выигрывают. Уже есть Linux-модуль, тесты и утилиты измерений. Но с заголовком и широтой выводов я бы поспорил.
1️⃣ На слайде презентации сетевой бенчмарк, который демонстрирует эффект использования протокола
Ускорения LLM в 13 раз из него не следует: нужно измерять время ответа приложения, tokens/s и загрузку GPU. Выигрыш зависит от того, какая доля ожидания действительно приходится на транспорт.
2️⃣ Отрасль давно работает над этой проблемой
Google описал промышленное применение Swift, а SIRD исследует, как согласовывать решения получателей, когда узким местом становится общий канал. Сравнение с TCP ещё не закрывает спор о лучшем транспорте.
3️⃣ Границы применимости существенны: Homa рассчитан на сеть внутри дата-центра. Нужны интеграция с приложением и настройка сети; разработка grpc_homa приостановлена. Для внедрения работы хватает.
Почитать подробнее — научные статьи и техническое обоснование:
— Homa, SIGCOMM 2018 — устройство протокола.
— Linux-реализация, USENIX ATC 2021 — измерения на 40 узлах; на странице есть PDF.
— It’s Time to Replace TCP in the Datacenter — аргументы Оустерхаута против архитектуры TCP в ЦОД.
Кстати, в конце доклада автор приглашает экспериментировать с Homa и обещает помощь: ouster@cs.stanford.edu. Хорошая задача для входа — проверить, сколько сетевого выигрыша сохраняется в реальной AI-нагрузке. Вот такой результат мне было бы интересно увидеть.
#AI #Architecture #Engineering #Research #PlatformEngineering
YouTube
Homa: The End of TCP for AI Clusters — John Ousterhout, Stanford
John Ousterhout, Stanford Professor and author of A Philosophy of Software Design, turns our attention to the evolving nature of AI networking workloads and why traditional protocols like TCP and RDMA are becoming bottlenecks in modern data center environments!…
1❤3🔥3👍2