Выжать больше из локальных LLM (Рубрика #AI)
Я редко пишу про статьи на Habr, но тут не смог удержаться - уж очень понравилась мне большая и практичная статья про запуск локальных LLM. Эта тема мне интересна, но я особо не экспериментировал раньше, ограничиваясь запуском стандартных моделек в своей LMStudio на толстом AMD Ryzen AI Max+ 395. А эта статья позволяет выжать больше скорости, качества и контекста из вашего железа, например автор объясняет на пальцах почему ollama удобна, но медленнее llama.cpp, а также что такое квантование и какое оно бывает и что дает. Если чуть подробнее рассказать про основные темы, то они такие
1️⃣ Разница между Dense и MoE-моделями
У Dense-модели все параметры активны всегда, поэтому она часто стабильнее и "умнее", но медленнее. У MoE активна только часть экспертов, поэтому такая модель может быть быстрее, но требует более аккуратного запуска. И вот здесь начинается самое интересное: если просто выгрузить часть слоёв на GPU, как это часто делает Ollama, видеокарта может быть забита полностью, но работать неэффективно. А llama.cpp умеет умнее раскладывать тензоры и включать режимы вроде cmoe/ncmoe, что на MoE-моделях даёт очень заметный выигрыш.
2️⃣ Квантование - что это такое и что дает
Честно говоря, эта часть мне показалась супер-полезной, так как автор объяснил, что стандартный выбор "Q4_K_M по умолчанию" уже не всегда лучший вариант. Современные динамические кванты вроде UD-Q4_K_XL могут давать больше качества при близком размере, а иногда Q4_K_M оказывается примерно на уровне более лёгкого UD-Q3_K_XL. И это важный практический вывод: при локальном запуске не стоит слепо брать дефолтный квант из Ollama или LM Studio. Лучше посмотреть, есть ли версия от Unsloth, Ubergarm или другие более свежие варианты.
3️⃣ Использование локальных моделей для кодинга
Автор показывает, что даже сильное квантование UD-Q2_K_XL может быть достаточно рабочим для генерации и доработки кода: модель собирала прототипы игр, исправляла баги и работала через агента. Это не значит, что Q2 теперь всегда лучший выбор, но значит, что старое правило "ниже Q4 не смотреть" уже не всегда верно.
Плюс в статье много практических советов, что интересно проверить на практике
- Попробовать llama.cpp вместо Ollama, особенно для MoE-моделей;
- Искать не только Q4_K_M, но и динамические кванты UD-Q4_K_XL / UD-Q3_K_XL / IQ-варианты;
- Помнить, что меньший квант не всегда быстрее, потому что i-кванты могут требовать больше вычислений на CPU;
- Использовать
- Увеличивать
- Подключать маленькую draft-модель для speculative decoding, если задача похожа на кодинг или перевод;
- Освобождать VRAM: браузер, Windows и лишние приложения легко съедают 2–3 ГБ, которые могли бы уйти под модель или контекст;
- Смотреть на дату выхода модели, а не на старые списки "лучших LLM", где до сих пор всплывают модели, давно уступившие новым поколениям.
Эффект от этих настроек может быть очень ощутимым. В статье llama.cpp на MoE-модели показывал скорость примерно в 3 раза выше Ollama на том же железе. Настройка обработки контекста давала кратный рост PP. Спекулятивное декодирование ускоряло Dense-модель примерно в 1.5 раза на коде и переводе. А правильный выбор кванта позволял либо получить больше качества в том же размере, либо уместить модель в доступную VRAM.
В общем, это хорошая статья для инженеров, кто уже пробовал локальные LLM и столкнулся с ощущением, что "модель вроде неплохая, но работает медленно".
P.S.
Эхх, я бы хотел поковыряться со своей железкой и испробовать эти советы на майских праздниках, но улетаю с женой и детишками в Лондон в воскресенье, поэтому отложу это уже на вторые майские праздники. А с подписчиками канала буду следующие 2 недели делится туристическими фотками и своими размышлениями про AI:)
#AI #LLM #LocalLLM #Engineering #Performance #Agents #llamacpp
Я редко пишу про статьи на Habr, но тут не смог удержаться - уж очень понравилась мне большая и практичная статья про запуск локальных LLM. Эта тема мне интересна, но я особо не экспериментировал раньше, ограничиваясь запуском стандартных моделек в своей LMStudio на толстом AMD Ryzen AI Max+ 395. А эта статья позволяет выжать больше скорости, качества и контекста из вашего железа, например автор объясняет на пальцах почему ollama удобна, но медленнее llama.cpp, а также что такое квантование и какое оно бывает и что дает. Если чуть подробнее рассказать про основные темы, то они такие
1️⃣ Разница между Dense и MoE-моделями
У Dense-модели все параметры активны всегда, поэтому она часто стабильнее и "умнее", но медленнее. У MoE активна только часть экспертов, поэтому такая модель может быть быстрее, но требует более аккуратного запуска. И вот здесь начинается самое интересное: если просто выгрузить часть слоёв на GPU, как это часто делает Ollama, видеокарта может быть забита полностью, но работать неэффективно. А llama.cpp умеет умнее раскладывать тензоры и включать режимы вроде cmoe/ncmoe, что на MoE-моделях даёт очень заметный выигрыш.
2️⃣ Квантование - что это такое и что дает
Честно говоря, эта часть мне показалась супер-полезной, так как автор объяснил, что стандартный выбор "Q4_K_M по умолчанию" уже не всегда лучший вариант. Современные динамические кванты вроде UD-Q4_K_XL могут давать больше качества при близком размере, а иногда Q4_K_M оказывается примерно на уровне более лёгкого UD-Q3_K_XL. И это важный практический вывод: при локальном запуске не стоит слепо брать дефолтный квант из Ollama или LM Studio. Лучше посмотреть, есть ли версия от Unsloth, Ubergarm или другие более свежие варианты.
3️⃣ Использование локальных моделей для кодинга
Автор показывает, что даже сильное квантование UD-Q2_K_XL может быть достаточно рабочим для генерации и доработки кода: модель собирала прототипы игр, исправляла баги и работала через агента. Это не значит, что Q2 теперь всегда лучший выбор, но значит, что старое правило "ниже Q4 не смотреть" уже не всегда верно.
Плюс в статье много практических советов, что интересно проверить на практике
- Попробовать llama.cpp вместо Ollama, особенно для MoE-моделей;
- Искать не только Q4_K_M, но и динамические кванты UD-Q4_K_XL / UD-Q3_K_XL / IQ-варианты;
- Помнить, что меньший квант не всегда быстрее, потому что i-кванты могут требовать больше вычислений на CPU;
- Использовать
-fit, -cmoe, -ncmoe и не пытаться руками угадывать оптимальную раскладку;- Увеличивать
-ub и -b, если важна скорость обработки большого контекста;- Подключать маленькую draft-модель для speculative decoding, если задача похожа на кодинг или перевод;
- Освобождать VRAM: браузер, Windows и лишние приложения легко съедают 2–3 ГБ, которые могли бы уйти под модель или контекст;
- Смотреть на дату выхода модели, а не на старые списки "лучших LLM", где до сих пор всплывают модели, давно уступившие новым поколениям.
Эффект от этих настроек может быть очень ощутимым. В статье llama.cpp на MoE-модели показывал скорость примерно в 3 раза выше Ollama на том же железе. Настройка обработки контекста давала кратный рост PP. Спекулятивное декодирование ускоряло Dense-модель примерно в 1.5 раза на коде и переводе. А правильный выбор кванта позволял либо получить больше качества в том же размере, либо уместить модель в доступную VRAM.
В общем, это хорошая статья для инженеров, кто уже пробовал локальные LLM и столкнулся с ощущением, что "модель вроде неплохая, но работает медленно".
P.S.
Эхх, я бы хотел поковыряться со своей железкой и испробовать эти советы на майских праздниках, но улетаю с женой и детишками в Лондон в воскресенье, поэтому отложу это уже на вторые майские праздники. А с подписчиками канала буду следующие 2 недели делится туристическими фотками и своими размышлениями про AI:)
#AI #LLM #LocalLLM #Engineering #Performance #Agents #llamacpp
Хабр
Выжать больше из локальных LLM. Ollama медленнее llama.cpp в 3 раза. UD_Q4_K_XL лучше чем Q4_K_M, а вес тот же и т.д
Самый простой способ запустить локальную LLM - это установить ollama или LM Studio. Это быстро и просто, но вы теряете и в скорости, и в качестве. Почему UD_Q4_K_XL лучше при том же размере, почему...
🔥14👍13❤8😁1
The Great GPU Shortage – Rental Capacity – Launching our H100 1 Year Rental Price Index (Рубрика #AI)
Интересная статья от SemiAnalysis про агрессивный рынок аренды GPU, который вошел в клинч и цены взлетели вверх из-за роста спроса. Стоимость годового контракта на H100 выросла примерно на 40% - с $1.70 за GPU-час в октябре 2025 до $2.35 к марту 2026. On-demand capacity по сути выбрана по всем типам GPU, а Blackwell-кластеры, которые выходят в строй в середине 2026 года, во многих случаях уже заранее заняты. Даже найти кластер на 64 Hopper GPU стало нетривиально.
Авторы прямо связывает новую волну давления на рынок с резким ростом спроса на фоне agentic нагрузок поверх моделей. То есть узкое место теперь формируется не только гонкой лабораторий в тренировке новых моделей, а продакшен-инференсом, где модель перестаёт быть "чатом" и становится исполнителем рабочих процессов. В классическом chat UX экономика была относительно простой: один пользовательский запрос, один inference-pass, один ответ. В агентном мире одна задача раскладывается в дерево вызовов: оркестратор строит план, порождает субагентов, те параллельно ищут источники, читают код, ходят в инструменты, возвращают промежуточные результаты, после чего отдельный контур делает синтез, критику и верификацию. Например, cнаружи задача может выглядеть как "разбери инцидент" или "подготовь PR", а под капотом это уже рой субагентов.
В итоге, спрос на рынке растет уже не только от числа пользователей и не только от числа компаний, а скорее от того сколько задач делегируются агентам. Один и тот же разработчик, аналитик или исследователь теперь может запускать не один запрос к модели, а десятки координированных проходов - с длинным контекстом, ретраями, проверками и параллельными ветками. У мульти-агентных нагрузок есть неприятная для инфраструктуры особенность: они увеличивают не только суммарное потребление токенов, но и пиковую конкурентность, а это уже прямое давление на флот GPU.
Интересно, что этот спрос неравномерен. Авторы пишут, что часть inference-нагрузок, особенно большие MoE-сценарии, лучше работает на свежих системах вроде GB300 NVL72, тогда как тренировки и часть нагрузок, где важна стоимость к производительности, продолжают отлично жить на H100. Иными словами, новый агентный слой не просто "съедает Blackwell" - он одновременно поддерживает спрос и на Hopper, продлевая экономическую жизнь уже поставленных GPU. Поэтому у провайдеров сейчас не ценовая война за загрузку, а рынок продавца с длинными контрактами, предоплатой и выбором, кому вообще отдавать capacity.
Отсюда можно почерпнуть несколько выводов:
1️⃣ Планирование мощностей по модели "сколько у нас чатов в день" больше не работает - считать нужно fan-out на подагентов, глубину циклов верификации и уровень параллелизма (максимальный для задачи)
2️⃣ Юнит экономику надо считать не по запросам, а по выполненным задачам: агент может быть дорогим в токенах, но дешёвым относительно стоимости человека или цены задержки бизнес-процесса
3️⃣ Если ROI от AI-инструментов действительно остаётся кратно выше их стоимости, как пишет SemiAnalysis, то спрос на вычисления ещё долго будет слабо чувствителен к цене. А значит, рост GPU-потребления - это не временный всплеск хайпа, а новая реальность.
TLDR;
Раньше GPU в основном потребляли модели, а теперь GPU потребляют бизнес-процессы, разложенные на рой агентных подзадач. И именно мульти-агентные нагрузки могут оказаться главным скрытым драйвером нового дефицита вычислений.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity #Agents #Economics
Интересная статья от SemiAnalysis про агрессивный рынок аренды GPU, который вошел в клинч и цены взлетели вверх из-за роста спроса. Стоимость годового контракта на H100 выросла примерно на 40% - с $1.70 за GPU-час в октябре 2025 до $2.35 к марту 2026. On-demand capacity по сути выбрана по всем типам GPU, а Blackwell-кластеры, которые выходят в строй в середине 2026 года, во многих случаях уже заранее заняты. Даже найти кластер на 64 Hopper GPU стало нетривиально.
Авторы прямо связывает новую волну давления на рынок с резким ростом спроса на фоне agentic нагрузок поверх моделей. То есть узкое место теперь формируется не только гонкой лабораторий в тренировке новых моделей, а продакшен-инференсом, где модель перестаёт быть "чатом" и становится исполнителем рабочих процессов. В классическом chat UX экономика была относительно простой: один пользовательский запрос, один inference-pass, один ответ. В агентном мире одна задача раскладывается в дерево вызовов: оркестратор строит план, порождает субагентов, те параллельно ищут источники, читают код, ходят в инструменты, возвращают промежуточные результаты, после чего отдельный контур делает синтез, критику и верификацию. Например, cнаружи задача может выглядеть как "разбери инцидент" или "подготовь PR", а под капотом это уже рой субагентов.
В итоге, спрос на рынке растет уже не только от числа пользователей и не только от числа компаний, а скорее от того сколько задач делегируются агентам. Один и тот же разработчик, аналитик или исследователь теперь может запускать не один запрос к модели, а десятки координированных проходов - с длинным контекстом, ретраями, проверками и параллельными ветками. У мульти-агентных нагрузок есть неприятная для инфраструктуры особенность: они увеличивают не только суммарное потребление токенов, но и пиковую конкурентность, а это уже прямое давление на флот GPU.
Интересно, что этот спрос неравномерен. Авторы пишут, что часть inference-нагрузок, особенно большие MoE-сценарии, лучше работает на свежих системах вроде GB300 NVL72, тогда как тренировки и часть нагрузок, где важна стоимость к производительности, продолжают отлично жить на H100. Иными словами, новый агентный слой не просто "съедает Blackwell" - он одновременно поддерживает спрос и на Hopper, продлевая экономическую жизнь уже поставленных GPU. Поэтому у провайдеров сейчас не ценовая война за загрузку, а рынок продавца с длинными контрактами, предоплатой и выбором, кому вообще отдавать capacity.
Отсюда можно почерпнуть несколько выводов:
1️⃣ Планирование мощностей по модели "сколько у нас чатов в день" больше не работает - считать нужно fan-out на подагентов, глубину циклов верификации и уровень параллелизма (максимальный для задачи)
2️⃣ Юнит экономику надо считать не по запросам, а по выполненным задачам: агент может быть дорогим в токенах, но дешёвым относительно стоимости человека или цены задержки бизнес-процесса
3️⃣ Если ROI от AI-инструментов действительно остаётся кратно выше их стоимости, как пишет SemiAnalysis, то спрос на вычисления ещё долго будет слабо чувствителен к цене. А значит, рост GPU-потребления - это не временный всплеск хайпа, а новая реальность.
TLDR;
Раньше GPU в основном потребляли модели, а теперь GPU потребляют бизнес-процессы, разложенные на рой агентных подзадач. И именно мульти-агентные нагрузки могут оказаться главным скрытым драйвером нового дефицита вычислений.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Productivity #Agents #Economics
Semianalysis
The Great GPU Shortage – Rental Capacity – Launching our H100 1 Year Rental Price Index
GPU Rental Pricing Dashboard Launch
25❤5🔥5💯5😁1🤨1
The How to be British Collection (Рубрика #Humor)
Из прошлой поездки в Лондон я привез пару шуточных книг о том, как быть британцем. Я их полистал по приезду, но прочитал полностью только сейчас, когда пришла пора лететь в Лондон всей семьей. Могу отметить, забавные иллюстрации и меткие описания, которые хорошо описывают то, что я видел/чувствовал в первой поездке.
Уже завтра смогу сравнить юмор авторов этого сборника и реальность Лондона:)
#Travel #Humor
Из прошлой поездки в Лондон я привез пару шуточных книг о том, как быть британцем. Я их полистал по приезду, но прочитал полностью только сейчас, когда пришла пора лететь в Лондон всей семьей. Могу отметить, забавные иллюстрации и меткие описания, которые хорошо описывают то, что я видел/чувствовал в первой поездке.
Уже завтра смогу сравнить юмор авторов этого сборника и реальность Лондона:)
#Travel #Humor
😁16❤9👍2
Code of Leadership 2. Эпизод #2 - Не усложняй. Управление проектами с Дмитрием Ильенковым (Рубрика #Management)
Вышел второй выпуск второго сезона моего подкаста Code of Leadership. В этот раз в гостях был Дмитрий Ильенков - основатель @pmclub, человек с большим опытом в проектном управлении и соавтор книги «Не усложняй! Управление проектами по методу P3.express», о которой я уже рассказывал раньше. Говорили мы в этом эпизоде о проектном управлении без лишнего пафоса и без попытки превратить менеджмент в набор тяжелых ритуалов. Главная тема выпуска - как управлять проектами так, чтобы методология помогала доводить работу до результата, а не превращалась в бюрократический театр.
- P3.express хорошо ложится на роль практического входа в проектное управление
- Простота методологии не минус, а плюс
- Принципы важны, потому что без них методология легко превращается в карго-культ
- Управление проектами - это постоянный поиск слабого звена в цепочке и его оптимизация
- Метрики полезны, но цель нельзя сводить только к цифре
- Хороший процесс нужен не вместо результата, а для того, чтобы можно было получить предсказуемый результат
В общем, выпуск получился не про "еще одну методологию", а про здравый смысл в управлении проектами. Как не усложнять там, где можно сделать проще, но и не скатываться в хаос под видом гибкости. Рекомендую тем, кто управляет проектами, продуктами, командами или просто регулярно оказывается в ситуации, где нужно довести сложную работу до результата вместе с другими людьми.
Выпускк доступен на разных платформах: Youtube, VK, Ya Music, Podster.fm.
#Management #Leadership #ProjectManagement #Processes #Engineering
Вышел второй выпуск второго сезона моего подкаста Code of Leadership. В этот раз в гостях был Дмитрий Ильенков - основатель @pmclub, человек с большим опытом в проектном управлении и соавтор книги «Не усложняй! Управление проектами по методу P3.express», о которой я уже рассказывал раньше. Говорили мы в этом эпизоде о проектном управлении без лишнего пафоса и без попытки превратить менеджмент в набор тяжелых ритуалов. Главная тема выпуска - как управлять проектами так, чтобы методология помогала доводить работу до результата, а не превращалась в бюрократический театр.
- P3.express хорошо ложится на роль практического входа в проектное управление
- Простота методологии не минус, а плюс
- Принципы важны, потому что без них методология легко превращается в карго-культ
- Управление проектами - это постоянный поиск слабого звена в цепочке и его оптимизация
- Метрики полезны, но цель нельзя сводить только к цифре
- Хороший процесс нужен не вместо результата, а для того, чтобы можно было получить предсказуемый результат
В общем, выпуск получился не про "еще одну методологию", а про здравый смысл в управлении проектами. Как не усложнять там, где можно сделать проще, но и не скатываться в хаос под видом гибкости. Рекомендую тем, кто управляет проектами, продуктами, командами или просто регулярно оказывается в ситуации, где нужно довести сложную работу до результата вместе с другими людьми.
Выпускк доступен на разных платформах: Youtube, VK, Ya Music, Podster.fm.
#Management #Leadership #ProjectManagement #Processes #Engineering
YouTube
Code of Leadership - S2E2 - Не усложняй или управление проектами с Дмитрием Ильенковым
Второй выпуск второго сезона моего подкаста Code of Leadership. В этот раз в гостях был Дмитрий Ильенков — основатель pmclub https://youtube.com/@PMCLUBpro, человек с большим опытом в проектном управлении и соавтор книги «Не усложняй! Управление проектами…
❤7👍7🔥1
Measuring the effectiveness of software development tools and practices (Рубрика #Productivity)
Я часто рассказываю про тему продуктивности инженеров, а также подходов к этому крупных компаний (смотри статьи от Google, или статьи запрещенной в России Meta), а также про то, как мы внутри Т-Банка подходим к этому. Но сегодня я хотел рассказать про подход Amazon к этому непростому снаряду - авторы предлагают метод измерения экономического эффекта от инструментов и практик разработки. Они предлагают смотреть на единую метрику CTS-SW (cost-to-serve software) - по сути, сколько ресурсов уходит на доставку единицы ПО до клиента. Эта метрика должна связать привычные engineering-метрики в духе DORA/SPACE с понятным бизнес-результатом: сэкономленной инженерной емкостью или деньгами.
Интересно, что у нас внутри Т-Банка тоже есть похожие подходы к расчетам, которые основаны на унификации процессов разработки и выделении уровня задач в командах, что приносят понятный бизнес-результат. Но давайте вернемся к оригинальной статье и посмотрим как работает подход авторов
1️⃣ Они берут "стоимость доставки ПО" как итоговую метрику, а не пытаются детально оценить каждый шаг разработки
Авторы говорят, что классический activity-based costing для софта слишком хрупок и поэтому они упрощают задачу до "входные затраты → единица результата", а затем уже ищут драйверы этой стоимости по всему жизненному циклу: coding, CI/CD, planning, incident management, maintenance, search for information и т.д. Единица результата тоже подбирается под архитектуру
- Микросервисы - деплои
- Монолит - зашипленный в мастер код
- Библиотеки - коммиты
2️⃣Дальше они строят панельные данные (микс факторов + время) и используют линейные смешанные модели
У них есть телеметрия по тысячам "two-pizza teams" за пять лет, и они моделируют CTS-SW через время разработчиков на деплой. Линейные смешанные модели нужны им потому, что они одновременно ловят общий эффект факторов и различия между командами. Так они нашли основные кандидаты-драйверы CTS-SW:
- Team velocity (сколько отревьювернного кода команда мерджит в неделю на инженера) - самый сильный предиктор
- Здоровье деливери (например, рейт ролбеков)
- Пейджи на on-call инженера
3️⃣ Переходят от корреляции к причинности через causal inference
После нахождения эффектов авторы ищут возможность для эксперимента. Таким естественным экспериментом для них стало внедрение genAI-инструментов, в частности Amazon Q Developer. Для оценки они строят панельную регрессию с dynamic two-way fixed effects: учитывают постоянные различия между командами, общие временные эффекты, лаг прошлой скорости и time-varying covariates вроде доли команды, использующей Q Developer, rollback rate и manual interventions. Цель - не просто увидеть корреляцию, а изолировать именно причинный вклад инструмента в CR velocity и deployment velocity.
4️⃣ Добавляют "страховку" от переоценки эффекта AI
Авторы отдельно признают, что если просто складывать эффекты разных экспериментов, можно завысить реальное влияние. Поэтому они разрабатывают baseline model, чтобы нормализовать оценки влияния AI-инструментов.
В общем, это явно интересный подход, который позволяет
- Решать, какие dev tools и AI tools масштабировать, исходя из измеримого эффекта
- Приоритизировать CI/CD автоматизации и практики надежности, потому что они свзяаны с лучшим CTS-SW.
- Создавать через онбординг условия для высокой team velocity, но использовать это именно как командную, а не индивидуальную метрику.
- Осторожно интерпретировать "полезные" сигналы
В будущем авторы хотят расширить модель, чтобы сравнивать архитектурные решения и давать рекомендации.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Software #Agents #Economics
Я часто рассказываю про тему продуктивности инженеров, а также подходов к этому крупных компаний (смотри статьи от Google, или статьи запрещенной в России Meta), а также про то, как мы внутри Т-Банка подходим к этому. Но сегодня я хотел рассказать про подход Amazon к этому непростому снаряду - авторы предлагают метод измерения экономического эффекта от инструментов и практик разработки. Они предлагают смотреть на единую метрику CTS-SW (cost-to-serve software) - по сути, сколько ресурсов уходит на доставку единицы ПО до клиента. Эта метрика должна связать привычные engineering-метрики в духе DORA/SPACE с понятным бизнес-результатом: сэкономленной инженерной емкостью или деньгами.
Интересно, что у нас внутри Т-Банка тоже есть похожие подходы к расчетам, которые основаны на унификации процессов разработки и выделении уровня задач в командах, что приносят понятный бизнес-результат. Но давайте вернемся к оригинальной статье и посмотрим как работает подход авторов
1️⃣ Они берут "стоимость доставки ПО" как итоговую метрику, а не пытаются детально оценить каждый шаг разработки
Авторы говорят, что классический activity-based costing для софта слишком хрупок и поэтому они упрощают задачу до "входные затраты → единица результата", а затем уже ищут драйверы этой стоимости по всему жизненному циклу: coding, CI/CD, planning, incident management, maintenance, search for information и т.д. Единица результата тоже подбирается под архитектуру
- Микросервисы - деплои
- Монолит - зашипленный в мастер код
- Библиотеки - коммиты
2️⃣Дальше они строят панельные данные (микс факторов + время) и используют линейные смешанные модели
У них есть телеметрия по тысячам "two-pizza teams" за пять лет, и они моделируют CTS-SW через время разработчиков на деплой. Линейные смешанные модели нужны им потому, что они одновременно ловят общий эффект факторов и различия между командами. Так они нашли основные кандидаты-драйверы CTS-SW:
- Team velocity (сколько отревьювернного кода команда мерджит в неделю на инженера) - самый сильный предиктор
- Здоровье деливери (например, рейт ролбеков)
- Пейджи на on-call инженера
3️⃣ Переходят от корреляции к причинности через causal inference
После нахождения эффектов авторы ищут возможность для эксперимента. Таким естественным экспериментом для них стало внедрение genAI-инструментов, в частности Amazon Q Developer. Для оценки они строят панельную регрессию с dynamic two-way fixed effects: учитывают постоянные различия между командами, общие временные эффекты, лаг прошлой скорости и time-varying covariates вроде доли команды, использующей Q Developer, rollback rate и manual interventions. Цель - не просто увидеть корреляцию, а изолировать именно причинный вклад инструмента в CR velocity и deployment velocity.
4️⃣ Добавляют "страховку" от переоценки эффекта AI
Авторы отдельно признают, что если просто складывать эффекты разных экспериментов, можно завысить реальное влияние. Поэтому они разрабатывают baseline model, чтобы нормализовать оценки влияния AI-инструментов.
В общем, это явно интересный подход, который позволяет
- Решать, какие dev tools и AI tools масштабировать, исходя из измеримого эффекта
- Приоритизировать CI/CD автоматизации и практики надежности, потому что они свзяаны с лучшим CTS-SW.
- Создавать через онбординг условия для высокой team velocity, но использовать это именно как командную, а не индивидуальную метрику.
- Осторожно интерпретировать "полезные" сигналы
В будущем авторы хотят расширить модель, чтобы сравнивать архитектурные решения и давать рекомендации.
#AI #Engineering #Management #SystemDesign #Architecture #Processes #Software #Software #Agents #Economics
Amazon Science
Measuring the effectiveness of software development tools and practices
New cost-to-serve-software metric that accounts for the full software development lifecycle helps determine which software development innovations provide quantifiable value.
1❤12👍5🔥2👎1🤔1
1❤16👍9🔥3
Недавно вышедший эпизод с Димой получился очень плотным и потребовал follow up поста чо списком книг, что мы упоминали в обсуждениях.
🤔1
Forwarded from Дмитрий Ильенков | pmclub | Автор книги «Не усложняй!»
carousel_codes2e2.pdf
8.1 MB
Очень плотно пообщались с Alexander Polomodov про проектное управление и книги.
Вот как об этом подкасте отозвался Миша Селезнев:
«Классный подкаст, посмотрите если ещё не. Ребята вроде собрались обсудить новую книгу Димы «Не усложняй! Управление проектами по методу P3․express», но пока они дошли до самой книги там столько всего успели обсудить. И с самого начала как с пулемёта начали цитировать или упоминать 100500 авторов и книг»
Собрал все 100500 авторов и книг в один список. Надеюсь, ничего не упустил — сам хочу пройтись по Сашиным рекомендациям:
1. Элияху Голдратт — Цель. Процесс непрерывного совершенствования
2. Джин Ким, Кевин Бер, Джордж Спаффорд — Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему
3. Джин Ким — The Unicorn Project. Роман о цифровой трансформации, разработчиках и обгоне конкурентов
4. Максим Ильяхов, Людмила Сарычева — Пиши, сокращай
5. Рита Мулкахи — PMP Exam Prep
6. Бент Фливбьерг, Дэн Гарднер — How Big Things Get Done
7. Стивен Хокинг — Краткая история времени
8. Ричард Фейнман — Вы, конечно, шутите, мистер Фейнман!
9. Даниэль Канеман — Думай медленно… решай быстро
10. Авинаш Диксит, Барри Нейлбафф — Стратегические игры. Доступный учебник по теории игр
11. Томас Кун — Структура научных революций
12. Атул Гаванде — Чек-лист. Как избежать глупых ошибок, ведущих к фатальным последствиям
13. Питер Тиль — От нуля к единице. Как создать стартап, который изменит будущее
14. Крис Восс — Never Split the Difference (Никаких компромиссов)
15. Дмитрий Ильенков, Валерия Ильенкова — Не усложняй. Управление проектами по методу P3․express
Если бы меня попросили выбрать из этих книг три, я бы выбрал себя, Тиля и Голдратта. И Фливбьорга. А вы?
@ilenkovda
Вот как об этом подкасте отозвался Миша Селезнев:
«Классный подкаст, посмотрите если ещё не. Ребята вроде собрались обсудить новую книгу Димы «Не усложняй! Управление проектами по методу P3․express», но пока они дошли до самой книги там столько всего успели обсудить. И с самого начала как с пулемёта начали цитировать или упоминать 100500 авторов и книг»
Собрал все 100500 авторов и книг в один список. Надеюсь, ничего не упустил — сам хочу пройтись по Сашиным рекомендациям:
1. Элияху Голдратт — Цель. Процесс непрерывного совершенствования
2. Джин Ким, Кевин Бер, Джордж Спаффорд — Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему
3. Джин Ким — The Unicorn Project. Роман о цифровой трансформации, разработчиках и обгоне конкурентов
4. Максим Ильяхов, Людмила Сарычева — Пиши, сокращай
5. Рита Мулкахи — PMP Exam Prep
6. Бент Фливбьерг, Дэн Гарднер — How Big Things Get Done
7. Стивен Хокинг — Краткая история времени
8. Ричард Фейнман — Вы, конечно, шутите, мистер Фейнман!
9. Даниэль Канеман — Думай медленно… решай быстро
10. Авинаш Диксит, Барри Нейлбафф — Стратегические игры. Доступный учебник по теории игр
11. Томас Кун — Структура научных революций
12. Атул Гаванде — Чек-лист. Как избежать глупых ошибок, ведущих к фатальным последствиям
13. Питер Тиль — От нуля к единице. Как создать стартап, который изменит будущее
14. Крис Восс — Never Split the Difference (Никаких компромиссов)
15. Дмитрий Ильенков, Валерия Ильенкова — Не усложняй. Управление проектами по методу P3․express
Если бы меня попросили выбрать из этих книг три, я бы выбрал себя, Тиля и Голдратта. И Фливбьорга. А вы?
@ilenkovda
❤12👍6🔥4
Atomic Heart: советская техноутопия, автономные роботы и мультиагентные системы (Рубрика #Games)
Недавно прошел игру Atomic Heart, и это оказался один из тех редких для меня случаев, когда я был готов играть в одиночном режиме, а не в кооперативе с женой или детьми:) Конкретно мне понравилось оказаться внутри огромной советской техноутопии, где роботы должны были освободить человека от рутины, а в итоге все сломалось примерно так, как ломается большая распределенная система, если у нее есть автономия, но плохо настроены ограничения, наблюдаемость и контур управления:) Особенно забавно проходить такую игру вечером, когда днем на работе занимаешься построением мультиагентных систем:)
Интересные моменты, что мне зашли
1️⃣ Это не просто игра про роботов, а игра про доверие к автономии
В Atomic Heart роботы изначально выглядят как продолжение мечты про автоматизацию: они работают на заводах, помогают людям, обслуживают инфраструктуру и вообще должны быть частью удобного мира будущего. Но когда система управления начинает вести себя не так, вся эта красота превращается в проблему с огромным радиусом поражения. И это очень знакомая инженерная мысль. В software engineering мы тоже все время пытаемся отдавать больше автономии системам: сервисам, платформам, AI-агентам, автоматическим пайплайнам, self-healing инфраструктуре. Но чем больше автономии, тем важнее вопросы governance: кто ставит цель, кто ограничивает действия, кто видит аномалии, как устроен kill switch и что будет, если локально разумное поведение глобально начнет разрушать систему.
2️⃣ Советская эстетика как часть идеи
Мне понравилось, что сеттинг СССР здесь не ощущается просто декоративной оберткой. Это не "давайте нарисуем плакаты и поставим роботов на фоне серпа и молота". В игре сама идея будущего выглядит очень по-советски: единая большая система, централизованная научная программа, вера в инженерный прогресс, заводы как храмы модерна, человек как часть большого проекта. Если киберпанк часто рассказывает про корпорации, рынок и приватизированное будущее, то Atomic Heart скорее рассказывает про другую версию техноутопии: будущее как централизованная платформа. Почти госплан для роботов, нейросетей и автоматизированного быта.
3️⃣ Геймплей хорошо поддерживает ощущение системного сбоя
В игре ты постоянно чувствуешь, что находишься не просто на наборе уровней, а внутри большой инфраструктуры, у которой случился каскадный сбой. Камеры, локальные контуры безопасности, ремонтные дроны, роботы, которые возвращаются в строй, лаборатории, полигоны, подземные комплексы - все это создает ощущение живой, но враждебной системы. И это как раз одна из причин, почему одиночный режим здесь хорошо работает. В кооперативе было бы веселее, но потерялась бы важная часть атмосферы: ты один, вокруг автономные системы, не все объяснения надежны, а твой помощник в перчатке слишком много знает про происходящее, чтобы ему просто верить.
4️⃣ В игре хорошо показана цена красивой техноутопии
Atomic Heart постоянно играет на контрасте: солнечные парки, музыка, красивые здания, счастливые лозунги, и рядом - мертвые сотрудники, лабораторный хаос, биомеханические эксперименты и роботы, которые вместо помощи начинают устранять людей как источник проблемы. Это довольно сильная метафора для любой большой технологической программы. Пока система работает, все говорят про эффективность, автоматизацию и новый уровень жизни. Но когда она ломается, внезапно выясняется, что важны не только возможности, но и отказоустойчивость, безопасность, права доступа, аудит, границы ответственности и способность остановить систему до того, как она начнет масштабировать ошибку.
В общем, Atomic Heart мне понравился не только как шутер, а скорее как интересное погружение в мир автономных роботов, построенных явно не на трех законах робототехники Айзека Азимова:)
#Games #AI #Robotics #Agents #Architecture #Software #SystemDesign
Недавно прошел игру Atomic Heart, и это оказался один из тех редких для меня случаев, когда я был готов играть в одиночном режиме, а не в кооперативе с женой или детьми:) Конкретно мне понравилось оказаться внутри огромной советской техноутопии, где роботы должны были освободить человека от рутины, а в итоге все сломалось примерно так, как ломается большая распределенная система, если у нее есть автономия, но плохо настроены ограничения, наблюдаемость и контур управления:) Особенно забавно проходить такую игру вечером, когда днем на работе занимаешься построением мультиагентных систем:)
Интересные моменты, что мне зашли
1️⃣ Это не просто игра про роботов, а игра про доверие к автономии
В Atomic Heart роботы изначально выглядят как продолжение мечты про автоматизацию: они работают на заводах, помогают людям, обслуживают инфраструктуру и вообще должны быть частью удобного мира будущего. Но когда система управления начинает вести себя не так, вся эта красота превращается в проблему с огромным радиусом поражения. И это очень знакомая инженерная мысль. В software engineering мы тоже все время пытаемся отдавать больше автономии системам: сервисам, платформам, AI-агентам, автоматическим пайплайнам, self-healing инфраструктуре. Но чем больше автономии, тем важнее вопросы governance: кто ставит цель, кто ограничивает действия, кто видит аномалии, как устроен kill switch и что будет, если локально разумное поведение глобально начнет разрушать систему.
2️⃣ Советская эстетика как часть идеи
Мне понравилось, что сеттинг СССР здесь не ощущается просто декоративной оберткой. Это не "давайте нарисуем плакаты и поставим роботов на фоне серпа и молота". В игре сама идея будущего выглядит очень по-советски: единая большая система, централизованная научная программа, вера в инженерный прогресс, заводы как храмы модерна, человек как часть большого проекта. Если киберпанк часто рассказывает про корпорации, рынок и приватизированное будущее, то Atomic Heart скорее рассказывает про другую версию техноутопии: будущее как централизованная платформа. Почти госплан для роботов, нейросетей и автоматизированного быта.
3️⃣ Геймплей хорошо поддерживает ощущение системного сбоя
В игре ты постоянно чувствуешь, что находишься не просто на наборе уровней, а внутри большой инфраструктуры, у которой случился каскадный сбой. Камеры, локальные контуры безопасности, ремонтные дроны, роботы, которые возвращаются в строй, лаборатории, полигоны, подземные комплексы - все это создает ощущение живой, но враждебной системы. И это как раз одна из причин, почему одиночный режим здесь хорошо работает. В кооперативе было бы веселее, но потерялась бы важная часть атмосферы: ты один, вокруг автономные системы, не все объяснения надежны, а твой помощник в перчатке слишком много знает про происходящее, чтобы ему просто верить.
4️⃣ В игре хорошо показана цена красивой техноутопии
Atomic Heart постоянно играет на контрасте: солнечные парки, музыка, красивые здания, счастливые лозунги, и рядом - мертвые сотрудники, лабораторный хаос, биомеханические эксперименты и роботы, которые вместо помощи начинают устранять людей как источник проблемы. Это довольно сильная метафора для любой большой технологической программы. Пока система работает, все говорят про эффективность, автоматизацию и новый уровень жизни. Но когда она ломается, внезапно выясняется, что важны не только возможности, но и отказоустойчивость, безопасность, права доступа, аудит, границы ответственности и способность остановить систему до того, как она начнет масштабировать ошибку.
В общем, Atomic Heart мне понравился не только как шутер, а скорее как интересное погружение в мир автономных роботов, построенных явно не на трех законах робототехники Айзека Азимова:)
#Games #AI #Robotics #Agents #Architecture #Software #SystemDesign
Mundfish
https://mundfish.com
👍21🔥13❤11
Мюзиклы в Лондоне (Рубрика #Culture)
Наш выбор представлений сильно зависит от нашего состава: в прошлый раз мы с Настей, моей женой, были одни и выбралм мюзикл "Back to the Future", а теперь со всеми детишками мы пришли на "The Lion King". Первый мюзикл был топовым и нам очень понравился, а второй только начнется через 5 минут, но ожидания изначально высоки:)
#Culture #Theater
Наш выбор представлений сильно зависит от нашего состава: в прошлый раз мы с Настей, моей женой, были одни и выбралм мюзикл "Back to the Future", а теперь со всеми детишками мы пришли на "The Lion King". Первый мюзикл был топовым и нам очень понравился, а второй только начнется через 5 минут, но ожидания изначально высоки:)
#Culture #Theater
❤10🔥4👍2🌚2😎1
Object Oriented Design Interview: An Insider’s Guide (Рубрика #SystemDesign)
Эта книга вышла в 2025 году как продолжение линейки “Insider’s Guide” от ByteByteGo, но уже не про высокоуровневый system design, а про более низкоуровневый объектно-ориентированный дизайн (OOD, object-oriented design), где идеи превращаются в классы, интерфейсы, состояния, потоки выполнения и так далее. Интересно, что уже почти готов и перевод от издательства Питер причем с моим отзывом на обложке книги:)
Авторами книги являются трио: Fawaz Bokhari, Alex Xu и Desmond Zhou, в котором Alex Xu известен лучше всего по начальной серии "System Design Interview: An Insider’s Guide", про которую я уже рассказывал (и которая теперь есть в разборе на system-design.space). В этой книге авторы решили рассказать про новый тип интервью, где проверяются умение строить логичные, расширяемые и поддерживаемые системы, применять принципы ООП и паттерны, а не просто писать синтаксически корректный код. Среди примеров, где используются такие интервью упоминаются Amazon, Bloomberg и Uber.
Книга выглядит как тренажер для кандидата, который получает три важные вещи
1️⃣ Рамка решения OOD-задач
В книге заявлен 4-шаговый фреймворк для любой object-oriented design задачи:
- Понять требования
- Выделить сущности и связи
- Продумать взаимодействия
- Уточнить дизайн и edge cases
2️⃣ Набор типовых задач
В книге 11 реальных OOD interview questions с подробными решениями: Parking Lot, Movie Ticket Booking, Unix File Search, Vending Machine, Elevator, Grocery Store, Tic-Tac-Toe, Blackjack, Shipping Locker, ATM и Restaurant Management System
3️⃣ Визуальная модель проектирования
В книге приведены 133 диаграммы, которые объясняют архитектуру, workflows и связи между частями системы. В общем, именно визуальная составляющая на интервью ясно кандидат показывает ответственности, границы, состояния и взаимодействия.
Первые три главы книги дают базовое понимание про объектно-ориентированное интервью, как к нему подходить и какие базовые принципы надо держать в голове. А следующие главы уже содержат конкретные задачи, которые можно использовать при подготовке. На каждой задаче стоит делать паузу до чтения решения: самому набросать классы, интерфейсы, последовательность вызовов и основные edge cases. Только после этого сравнивать с авторским решением.
Если смотреть на другие типы интервью, то объектно-ориентированный дизайн - это что-то посередине между кодинговым интервью и системным дизайном. Это уже выше по абстракции написания алгоритмов, но все еще про написание кода внутри сервисов. В этой схеме system design - это про то, какие сервисы есть, как они общаются, где хранятся данные и так далее. А вот low-level или объектно ориентированный дизайн отвечает: какие объекты живут внутри сервиса, кто за что отвечает, какие состояния возможны, где инварианты, как добавлять новые сценарии без переписывания всего кода. Поэтому книга хорошо дополняет классический System Design. Она не заменяет знания про distributed systems, но помогает довести архитектурную идею до уровня, на котором её реально можно реализовать.
#SystemDesign #OOD #Architecture #Interview #Software #Engineering
Эта книга вышла в 2025 году как продолжение линейки “Insider’s Guide” от ByteByteGo, но уже не про высокоуровневый system design, а про более низкоуровневый объектно-ориентированный дизайн (OOD, object-oriented design), где идеи превращаются в классы, интерфейсы, состояния, потоки выполнения и так далее. Интересно, что уже почти готов и перевод от издательства Питер причем с моим отзывом на обложке книги:)
Авторами книги являются трио: Fawaz Bokhari, Alex Xu и Desmond Zhou, в котором Alex Xu известен лучше всего по начальной серии "System Design Interview: An Insider’s Guide", про которую я уже рассказывал (и которая теперь есть в разборе на system-design.space). В этой книге авторы решили рассказать про новый тип интервью, где проверяются умение строить логичные, расширяемые и поддерживаемые системы, применять принципы ООП и паттерны, а не просто писать синтаксически корректный код. Среди примеров, где используются такие интервью упоминаются Amazon, Bloomberg и Uber.
Книга выглядит как тренажер для кандидата, который получает три важные вещи
1️⃣ Рамка решения OOD-задач
В книге заявлен 4-шаговый фреймворк для любой object-oriented design задачи:
- Понять требования
- Выделить сущности и связи
- Продумать взаимодействия
- Уточнить дизайн и edge cases
2️⃣ Набор типовых задач
В книге 11 реальных OOD interview questions с подробными решениями: Parking Lot, Movie Ticket Booking, Unix File Search, Vending Machine, Elevator, Grocery Store, Tic-Tac-Toe, Blackjack, Shipping Locker, ATM и Restaurant Management System
3️⃣ Визуальная модель проектирования
В книге приведены 133 диаграммы, которые объясняют архитектуру, workflows и связи между частями системы. В общем, именно визуальная составляющая на интервью ясно кандидат показывает ответственности, границы, состояния и взаимодействия.
Первые три главы книги дают базовое понимание про объектно-ориентированное интервью, как к нему подходить и какие базовые принципы надо держать в голове. А следующие главы уже содержат конкретные задачи, которые можно использовать при подготовке. На каждой задаче стоит делать паузу до чтения решения: самому набросать классы, интерфейсы, последовательность вызовов и основные edge cases. Только после этого сравнивать с авторским решением.
Если смотреть на другие типы интервью, то объектно-ориентированный дизайн - это что-то посередине между кодинговым интервью и системным дизайном. Это уже выше по абстракции написания алгоритмов, но все еще про написание кода внутри сервисов. В этой схеме system design - это про то, какие сервисы есть, как они общаются, где хранятся данные и так далее. А вот low-level или объектно ориентированный дизайн отвечает: какие объекты живут внутри сервиса, кто за что отвечает, какие состояния возможны, где инварианты, как добавлять новые сценарии без переписывания всего кода. Поэтому книга хорошо дополняет классический System Design. Она не заменяет знания про distributed systems, но помогает довести архитектурную идею до уровня, на котором её реально можно реализовать.
#SystemDesign #OOD #Architecture #Interview #Software #Engineering
👍12🔥5⚡2❤2😘1