Экономика оптимизации производительности ПО: когда дешевле купить железо, а когда — время разработчика

ВВЕДЕНИЕ И ПОСТАНОВКА ВОПРОСА

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

Задача на старте: инженерной команде поручено снизить потребление CPU и RAM в большом проекте (веб-платформе) на величину от 2% до 50%. Вопрос в том, при каком сочетании «объём экономии × трудозатраты на её достижение» такая работа имеет смысл, а при каком дешевле было бы либо докупить железо, либо направить разработчика на продуктовые задачи.

Похожих статей, которые считали бы именно эту точку равновесия — с конкретными формулами, вилкой зарплат и привязкой к закону Мура — в открытом доступе не нашлось. Есть смежные материалы: пост Джеффа Этвуда «Hardware is Cheap, Programmers are Expensive» [1], исследования MIT о программной инженерии производительности в «пост-муровскую» эпоху [2][3], и статистика NBER по цене вычислений [4]. Но сведённого расчёта под конкретный кейс компании эти источники не дают — собственно поэтому ниже выполнен самостоятельный анализ.

ЗАКОН МУРА И СОВРЕМЕННАЯ ИНТЕРПРЕТАЦИЯ

Классический закон Мура (1965) говорит о удвоении числа транзисторов на кристалле каждые два года при практически неизменной стоимости пластины [5]. Формула роста вычислительной мощности \(P(t)\) от базового уровня \(P_{0}\):

\[P(t) = \ P_{0} \times 2^{\frac{t}{2}}\]

где \(t\) — время в годах. В то же время в вопросе упомянут другой ориентир — эмпирически наблюдаемый рост пиковой производительности суперкомпьютеров списка TOP500 — примерно в 10 раз каждые 4 года:

\[P(t) = \ P_{0} \times 10^{\frac{t}{4}}\]

Важно понимать: сам закон Мура в классической форме с середины 2000-х замедляется из-за физических пределов литографии и прекращения деннардовского масштабирования — об этом пишут исследователи MIT в статье «There’s Plenty of Room at the Top» (Science, 2020) [2][3]. Рост производительности в последние годы всё больше опирается на параллелизацию, специализированные чипы (GPU/TPU) и алгоритмические улучшения, а не на рост тактовой частоты одного ядра.

Экономически это означает, что цена единицы вычислительной мощности падает со временем экспоненциально, подтверждает NBER (Flamm, 2018, Working Paper 24553) [4]. Но зарплата разработчика такой динамике не следует — она растёт вместе с инфляцией и спросом на рынке труда. Именно этот разрыв — железо дешевеет, труд дорожает — и задаёт экономическую рамку всей статьи: когда-то проще дождаться следующего поколения железа, чем платить за десятки часов работы senior-инженера ради небольшого прироста эффективности.

ЗАКОН МУРА НА КОНКРЕТНОМ ЖЕЛЕЗЕ: ПОКОЛЕНИЯ ПАМЯТИ И ТЕХПРОЦЕССЫ

Абстрактная кривая "мощность растёт экспоненциально" обретает смысл, если сопоставить её с реальными поколениями оборудования. Ниже — три среза: оперативная память DDR, видеопамять GDDR и техпроцесс производства CPU в нанометрах.

За 24 года (2000-2024) пропускная способность одного канала DDR выросла с 1.6 до 38.4 ГБ/с (×24) [6], а один чип GDDR — с 8 до 192 ГБ/с (×24) [7][8]. Любопытно, что обе линии памяти растут практически синхронно, но с разницей в 3-4 года: GDDR традиционно обгоняет DDR, потому что видеокарты раньше упираются в пропускную способность при параллельных вычислениях.

За 26 лет (1999-2025) техпроцесс сократился с 180 до 2 нм, то есть в 90 раз [9][10]. Плотность размещения транзисторов выросла примерно в (180/2) ² ≈ 8100 раз на единицу площади, но с 2012 года (22 нм) шаг между узлами стал заметно реже и дороже — именно это замедление и стоит за тезисом о затухании классического закона Мура.

ЗАКОН ВИРТА И ОТВЕТ В ВИДЕ SOC

Если закон Мура описывает рост железа, то закон Вирта — обратную сторону медали: «программное обеспечение замедляется быстрее, чем растёт быстродействие железа» (Никлаус Вирт, «A Plea for Lean Software», 1995) [11]. Практически это значит, что часть прироста мощности по закону Мура не доходит до пользователя — её съедают растущие фреймворки, абстракции и неэффективный код. Для экономики статьи это важно: закон Вирта объясняет, почему в реальных компаниях потребление CPU/RAM растёт даже без роста нагрузки — и почему задача оптимизации вообще возникает.

Ответ индустрии на замедление классического закона Мура на уровне одного ядра — не только параллелизация, но и система на кристалле (SoC, system-on-a-chip): CPU, GPU, контроллер памяти и специализированные блоки собираются на одном кристалле с единой шиной памяти (unified memory), убирая лишние пересылки данных между CPU и GPU [12]. Самый известный пример — чипы Apple Silicon (M-серия) в Mac, но та же логика стоит за Qualcomm Snapdragon X в ноутбуках на Windows, AMD Ryzen AI с интегрированной графикой и Intel Lunar Lake/Panther Lake, а также за большинством современных мобильных процессоров (Apple A-серия, Qualcomm Snapdragon для смартфонов, чипы Samsung Exynos).

У линейки Apple M4 пропускная способность единой памяти растёт с ростом числа ядер в пределах одного поколения: 120 ГБ/с у M4, 273 ГБ/с у M4 Pro (×2.3) и 546 ГБ/с у M4 Max (×4.6) [12]. Для сравнения, в сравнительных замерах из научной работы по M-серии типичная DDR5-платформа даёт около 90 ГБ/с (89.6 ГБ/с) [13]. По энергоэффективности разрыв тоже заметен: по многопоточному тесту Cinebench R24 (данные 2026 года) чип M5 Max даёт около 21.5 очков производительности на ватт против 9.4 у Intel Core Ultra 285K — разница примерно в 2.3 раза [14].

Для экономики оптимизации это важно в двух аспектах:

1. SoC сдвигает точку безубыточности в пользу железа там, где рабочая нагрузка упирается в пропускную способность или энергопотребление (CI/CD-агенты, ML-инференс на edge-устройствах, рабочие станции разработчиков) — здесь «купить более эффективное железо» часто дешевле, чем оптимизировать код. Но в облачных серверных расчётах этой статьи (AWS EC2 и аналоги) архитектура фиксирована провайдером, и выбор сводится к типу инстанса, а не к SoC как таковому (облачные ARM-инстансы AWS Graviton — тоже своего рода SoC-подход: в примере из руководства AWS переход с c6i.4xlarge на c7g.4xlarge снижает цену примерно на 15%, а для Graviton2 сама AWS заявляет до 40% лучшей цены за производительность; результат нужно проверять тестами на своей нагрузке [15]).

2. SoC не отменяет закон Вирта, а только отодвигает его границу: выигрыш от unified memory и специализированных блоков — одноразовый, пока софт не начнёт расти в сложности быстрее, чем растёт новый запас мощности — что исторически случалось при каждом скачке мощности железа. То есть SoC поднимает планку, но не отменяет логику статьи: сравнение «часы разработчика vs стоимость железа» остаётся актуальным независимо от того, насколько эффективна архитектура чипа.

СТОИМОСТЬ ВЫЧИСЛИТЕЛЬНЫХ РЕСУРСОВ

Здесь стоит сразу оговорить разницу между провайдерами. У AWS EC2 (как и у Azure) ресурсы продаются только в составе фиксированных типов инстансов — отдельной цены за vCPU или ГБ RAM в прайс-листе нет, и её приходится восстанавливать косвенно, через сравнение типов. Google Cloud тарифицирует vCPU и ГБ памяти отдельно, хотя машины выбираются из готовых типов или custom-конфигураций [16]. А у Yandex Cloud [17], можно собрать виртуальную машину произвольной конфигурации, и в прайсе указана прямая цена за 1 vCPU и 1 ГБ RAM — например, в примерах расчёта Yandex Cloud для ВМ на Intel Ice Lake это ₽1.24 за 100% vCPU в час и ₽0.33 за ГБ RAM в час [17]. Ниже расчёт сделан на AWS EC2 on-demand (регион us-east-1, 2026 год) как на самом распространённом облаке, и именно поэтому цену vCPU и RAM пришлось выводить через сравнение тарифов compute-optimized (c6i) и memory-optimized (r6i) семейств [18][19], а не брать из прайса напрямую.

Провайдер	Модель тарификации	Цена 1 vCPU в месяц (720 ч)	Цена 1 ГиБ RAM в месяц (720 ч)
AWS EC2	Фиксированные типы инстансов, прямой цены за компонент нет	≈$30.6 (расчётно: $0.17/ч ÷ 4 vCPU × 720 ч; us-east-1) [18]	≈$2.46 (расчётно, через дельту c6i/r6i) [18][19]
Google Cloud (E2, us-central1)	Предустановленные и custom machine types, но счёт выставляется по vCPU и ГБ отдельно	≈$15.7 [16]	≈$2.11 [16]
Yandex Cloud (Intel Ice Lake, 100% vCPU)	Гибкая конфигурация, прямая цена за vCPU и ГБ RAM	≈$10.7 (₽1.24/ч × 720 ч ÷ 83.62; курс ЦБ РФ на 17.10.2026) [17][20]	≈$2.84 (₽0.33/ч × 720 ч ÷ 83.62; тот же курс) [17][20]

Для бизнеса разница в модели тарификации важна не только методологически. Если облако продаёт ресурсы раздельно (Google Cloud, Yandex Cloud), экономия от оптимизации RAM или CPU конвертируется в реальное снижение счёта напрямую и предсказуемо — можно просто убрать нужное количество гигабайт или ядер. На AWS EC2 и аналогичных платформах с фиксированными типами экономия обычно реализуется не плавно, а скачком — переходом на другой, более дешёвый тип инстанса, и выигрыш по факту ограничен тем, насколько «подогнанным» под новую нагрузку окажется ближайший доступный типоразмер. Именно поэтому в кейсе «МояФинБет» ниже оптимизация считается как сокращение числа однотипных инстансов, а не доли ресурса внутри одного инстанса — на AWS это ближе к реальности, чем плавное масштабирование.

ОТ ТЕХНИЧЕСКОЙ ЭКОНОМИИ К ДЕНЕЖНОМУ ЭФФЕКТУ

В этой модели необходимо разделять снижение потребления вычислительных ресурсов и сокращение оплачиваемых расходов. Уменьшение загрузки CPU на 20% само по себе не означает, что счёт AWS снизится на 20%: при неизменных количестве и типоразмере инстансов стоимость их работы по тарифу On-Demand останется прежней.

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

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

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

Ресурс	Цена в час	Цена в месяц
1 vCPU (c6i.xlarge, $0.17/ч за 4 vCPU)	$0.0425	$30.6
1 ГиБ RAM (по дельте c6i.xlarge → r6i.xlarge)	$0.0034	$2.46
1 ГБ SSD (EBS gp3, $0.08/ГБ·мес) [21][22]	$0.00011	$0.08

Источники цен: Vantage — c6i.xlarge [18], Vantage — r6i.xlarge [19], AWS EBS Pricing [21], CloudZero — EBS gp3 [22].

Как получены эти цифры: 1 vCPU взят напрямую — цена c6i.xlarge ($0.17/ч, us-east-1) [18] поделена на 4 vCPU в этом инстансе: $0.17 / 4 = $0.0425/ч, то есть $30.6 в месяц при тарификации 720 часов (30 суток × 24 ч). Для RAM прямой цены нет, поэтому использован метод дельты: берём r6i.xlarge (тот же производитель линейки, 4 vCPU, но 32 ГиБ RAM вместо 8 ГиБ у c6i.xlarge) по цене $0.252/ч [19] и вычитаем цену c6i.xlarge: ($0.252 − $0.17) / (32 − 8) ГиБ = $0.082 / 24 ГиБ ≈ $0.00342 за ГиБ в час, то есть около $2.46 в месяц за 1 ГиБ. Ключевой вывод: стоимость 1 ГиБ оперативной памяти в месяц — около $2.46, а один vCPU — около $30.6. Для масштаба: час senior-разработчика ($34.9) стоит примерно, как месяц работы одного vCPU и в 14 раз больше месяца аренды одного ГиБ RAM ($34.9 / $2.46 ≈ 14). Именно с этой арифметикой нужно сопоставлять любую оптимизацию.

Оговорка к методу: дельта-расчёт для RAM — приближение, а не чистая цена памяти. c6i и r6i — разные семейства инстансов, и хотя у обоих здесь по 4 vCPU, AWS может по-разному тарифицировать сам процессорный ресурс в составе разных семейств (сетевая производительность, EBS-пропускная способность и другие параметры тоже не идентичны). Дельта цены поэтому включает не только добавленную память, но и часть этих побочных различий между семействами. Для порядковой оценки («месяц аренды ГиБ RAM стоит примерно в 14 раз меньше часа разработчика») это не критично, но как точную рыночную цену ГиБ RAM эту цифру использовать не стоит.

СТОИМОСТЬ РАБОЧЕГО ЧАСА РАЗРАБОТЧИКА

По данным recruitment.by (2026) [23], senior-разработчик в Минске получает $3 200–$4 500 на руки. Для компании полная стоимость сотрудника выше зарплаты на руки — в неё входят налоги и соцвыплаты работодателя, бенефиты, офис и оборудование, управленческий оверхед. Ориентировочный коэффициент полной стоимости для нанимателя — ×1.45 к net-зарплате.

Формула стоимости часа для компании \(C_{h}\):

\[C_{h}\ = \ \frac{S_{net} \times \ k_{overhead}}{H_{month}}\]

где \(S_{net}\) — нетто-зарплата в месяц, \(k_{overhead}\) ≈ 1.45, \(H_{month}\) ≈ 160 часов. Коэффициент \(k_{overhead}\) получен так: в Беларуси наниматель поверх начисленной (gross) зарплаты платит взносы в ФСЗН (34%) [24] и в Белгосстрах (0.6%), то есть около 34.6% сверху — это даёт множитель порядка 1.35 от gross к полной стоимости для нанимателя. Net-зарплата ниже gross ещё на подоходный налог (13%) и взнос работника в ФСЗН (1%) [24], то есть net ≈ gross × 0.86. Если выразить полную стоимость нанимателя через net, а не через gross, получаем net × 1.35 / 0.86 ≈ net × 1.57 — но этот расчёт для прямого найма. Для IT-сектора Беларуси типична работа через ИП или резидентов ПВТ с иной налоговой базой, а также добавляются непрямые расходы (оборудование, ДМС, офис, рекрутинг), которые частично компенсируют разницу. Итоговый \(k_{overhead}\) ≈ 1.45 — усреднённая по этим схемам оценка, а не точный расчёт по одной формуле; это самое слабое место модели, и при пересчёте под другую юрисдикцию или схему найма коэффициент нужно пересчитывать заново. \(H_{month}\) ≈ 160 часов — это 8-часовой рабочий день при стандартной 40-часовой неделе (20 рабочих дней в месяц).

При подстановке данных по сеньорам получается следующая вилка.

Грейд	Net-зарплата/мес	Полная стоимость для компании/мес	Стоимость часа
Senior	$3 200–$4 500	$4 640–$6 525	$29.0–$40.8

Средняя стоимость часа senior-разработчика для компании — около $34.9. Эта цифра дальше используется как базовая в расчётах кейса.

Источник [23]: recruitment.by — зарплаты в IT Беларуси 2026.

КЕЙС: КОМПАНИЯ «МОЯФИНБЕТ»

Рассмотрим гипотетическую финтех/iGaming-платформу «МояФинБет»: бэкенд-флот из 200 инстансов c6i.xlarge (4 vCPU / 8 ГиБ), работающих круглосуточно под сервисы расчёта ставок и платёжный гейтвей. Годовая стоимость такого флота по on-demand тарифу.

\[C_{flet}\ = n\ \times \ p\ \times \ H_{year}\ = 200\ \times \ 0.17\ \times \ 8760\ \approx \$ 297\ 840\]

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

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

Обозначим долю вычислительных расходов в общем счёте через (\(q\)), а сокращение этих расходов — через (\(p\)). При неизменности остальных статей затрат приблизительное сокращение общего счёта составит:

\[P_{total} \approx q\ \times \ p\]

Например, если вычислительные ресурсы формируют 60% общего счёта, а оптимизация уменьшает расходы на них на 30%, общий счёт сократится приблизительно на 18%, а не на 30%.

В реальном проекте значение (\(q\)) следует определять по фактической структуре расходов. Поэтому все дальнейшие расчёты рассматривают экономию на вычислительных ресурсах; переносить их результаты на общий инфраструктурный бюджет без дополнительного анализа нельзя.

Инженерная команда находит способ сократить потребление CPU/RAM на долю p (от 2% до 50%), что позволяет сократить флот или даунгрейднуть инстансы на ту же долю. Экономия в месяц — просто доля от годовой стоимости флота:

Экономия ресурсов	$/год	$/мес
2%	5 957	496
10%	29 784	2 482
20%	59 568	4 964
30%	89 352	7 446
50%	148 920	12 410

Трудозатраты на саму оптимизацию считаются по стоимости часа senior-разработчика ($34.9), умноженной на затраченные часы \(T\). Точка безубыточности в месяцах (сколько времени нужно, чтобы экономия на железе окупила труд разработчика):

\[T_{breakeven}\ = \ \frac{T\ \times \ C_{h}}{S_{monthly}}\]

Расчёт для разных сочетаний процента экономии и затраченных часов работы (окупаемость в месяцах). Строки 40/80/160/320 часов выбраны как условная шкала «пол-недели / неделя / две недели / месяц» работы одного senior-разработчика — это не эмпирические данные, а шаг для иллюстрации чувствительности модели к объёму трудозатрат. Каждая ячейка считается по формуле выше: например, для 2% экономии и 320 часов — трудозатраты \(T\ \times \ C_{h}\) = 320 × $34.9 ≈ $11 168, экономия в месяц = $297 840 × 0.02 / 12 ≈ $496, окупаемость = $11 168 / $496 ≈ 22.5 месяца:

Экономия	40 ч (1 нед.)	80 ч (2 нед.)	160 ч (1 мес.)	320 ч (2 мес.)
2%	2.8	5.6	11.3	22.5
10%	0.6	1.1	2.3	4.5
20%	0.3	0.6	1.1	2.3
30%	0.2	0.4	0.8	1.5
50%	0.1	0.2	0.5	0.9

Вывод из таблицы: при экономии ниже 10% и больших затратах времени (от месяца и выше) окупаемость растягивается на годы — такая задача экономически не оправдана. При экономии от 20% и выше окупаемость наступает за считанные недели, даже если работа заняла целый месяц.

ОГРАНИЧЕНИЯ РАСЧЁТА СРОКА ОКУПАЕМОСТИ

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

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

Для более полной оценки следует учитывать денежные потоки за выбранный горизонт (H):

\[NVP\ = \ - \ C_{0} + \ \sum_{m = 1}^{H}\frac{S_{m} - \ C_{m}}{{(1 + r)}^{\frac{m}{12}}}\]

где:

\(C_{0}\) — первоначальные затраты на разработку, тестирование и внедрение;

\(S_{m}\) — фактическая ожидаемая экономия в месяце (m);

\(C_{m}\) — дополнительные эксплуатационные затраты в этом месяце;

\(r\) — годовая ставка дисконтирования;

\(H\) — горизонт оценки в месяцах.

Положительное значение \(NVP\) означает, что при выбранном горизонте и ставке дисконтирования проект создаёт положительную приведённую стоимость. Отрицательное значение указывает на то, что ожидаемые денежные выгоды не покрывают приведённые затраты в пределах рассматриваемого периода.

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

АЛЬТЕРНАТИВНАЯ СТОИМОСТЬ ЧАСА РАЗРАБОТЧИКА

Важнее самой окупаемости — вопрос альтернативной стоимости (opportunity cost): что тот же сеньор мог бы сделать вместо оптимизации. Если час его работы над продуктовой фичей в среднем приносит компании больше, чем $34.9 (свою стоимость), то изъятие его из продуктовой работы имеет скрытую цену, которая не видна в бюджете на инфраструктуру, но реальна для бизнеса.

График ниже показывает, как быстро падает срок окупаемости при фиксированных трудозатратах (160 часов) по мере роста процента экономии.

Здесь и проявляется связь с законом Мура: пока железо дешевеет, а труд дорожает, малый процент экономии (2–10%), достигаемый только ценой недель или месяца работы, редко окупается быстрее, чем за год. А вот глубокая архитектурная оптимизация, дающая 20–50%, окупается за недели и практически всегда оправдана — не столько из-за экономии на инфраструктуре, сколько из-за устранения узких мест, которые сами по себе тормозят развитие продукта.

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

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

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

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

КАК ОЦЕНИТЬ ПОТЕНЦИАЛ ЭКОНОМИИ ДО НАЧАЛА РАБОТ

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

1. Снять профиль на боевой нагрузке. Flame graph по CPU, heap-профиль по памяти, топ запросов к БД, трейсы в APM. Результат — доли: какое место тратит сколько процентов ресурса.

2. Посчитать потолок. Если часть p ресурса ускорить в k раз, общая экономия равна p × (1 − 1/k) — это закон Амдала в форме экономии [25]. Функция с долей 30% CPU, ускоренная вдвое, даёт 15% общей экономии. Плоский профиль, где ничто не занимает больше 5%, к 20% не приведёт — это ориентир, а не строгая граница.

3. Проверить, что экономия превратится в деньги. Флот должен реально сократиться. Учитывайте ограничивающий ресурс инстанса (если тип выбран по RAM, экономия CPU ничего не даёт), запас под пики и текущую утилизацию, а также долю compute в счёте: БД, трафик и лицензии оптимизация CPU не уменьшает. Модель тарификации провайдера (см. выше) определяет, будет экономия плавной или скачками.

4. Сделать спайк на 1–3 дня на самом крупном месте из профиля и замерить результат нагрузочным тестом или канарейкой в CPU-секундах на запрос, а не в абсолютном CPU — иначе рост трафика исказит замер. Результат спайка уточняет k в формуле.

5. Сравнить с порогом окупаемости. Минимальная экономия, при которой задача окупается за M месяцев:

\[S_{\min}\ = \ \frac{T\ \times \ C_{h}}{M\ \times \ S_{flet}}\]

где \(T\) — трудозатраты в часах, \(C_{h}\) — стоимость часа ($34.9), \(S_{flet}\) — месячная стоимость тех ресурсов, которые оптимизация реально уменьшит. Порог при окупаемости за 3 месяца:

Трудозатраты	Флот 200 инстансов ($24 820/мес)	Флот 20 инстансов ($2 482/мес)
40 ч	1.9%	18.8%
80 ч	3.8%	37.5%
160 ч	7.5%	75.0%
320 ч	15.0%	больше 100% — не окупится

Поэтому порог «от 20%» из кейса — не универсальное правило, а следствие масштаба флота: на флоте в десять раз меньше те же 160 часов окупаются только при экономии в 75%, а на большом — уже при 7.5%. Перечень типичных мест крупной экономии (N+1 запросы, отсутствующие индексы, избыточная сериализация и логирование, утечки памяти, отсутствие кэша, дефолтные настройки воркеров и heap) — инженерная практика, а не результат исследования; профиль вашей системы важнее любого списка.

ВЫВОДЫ

1. Экономическую эффективность оптимизации определяет не процент снижения потребления ресурсов сам по себе, а измеримый результат для бизнеса. Снижение потребления CPU и RAM становится прямой денежной экономией только тогда, когда позволяет уменьшить оплачиваемые ресурсы. Если количество и типоразмер инстансов не меняются, финансовая экономия может отсутствовать, хотя система получает дополнительный запас производительности.

2. Универсального порога экономии, начиная с которого оптимизация становится выгодной, не существует. Результат зависит от стоимости инфраструктуры, объёма ресурсов, которые действительно можно перестать оплачивать, трудозатрат, полной стоимости инженерного часа и периода сохранения эффекта. В рассмотренном кейсе экономия от 20% обеспечивает короткий срок окупаемости при условии пропорционального сокращения расходов на вычислительный флот. Для системы меньшего масштаба тот же результат может оказаться недостаточным.

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

Критерий	Закон Мура	Закон Вирта
Что утверждает	Количество транзисторов на кристалле исторически удваивается примерно каждые два года [5]	Программное обеспечение замедляется быстрее, чем ускоряется аппаратное обеспечение [11]
Сторона рынка	Предложение: развитие вычислительной техники исторически увеличивало доступную вычислительную мощность и снижало стоимость многих вычислительных операций [4]	Спрос: рост сложности программ может увеличивать потребление CPU и RAM даже без пропорционального роста полезной нагрузки [11]
Текущее состояние	Классическая форма закона замедляется: смена технологических узлов становится сложнее и дороже; дальнейший рост производительности всё больше зависит от архитектурных решений, параллелизации и специализированных вычислителей [2][3][9][10]	Развитие аппаратного обеспечения не гарантирует повышения эффективности программ. SoC и unified memory могут давать преимущества в отдельных сценариях, но не устраняют необходимость оптимизации программного обеспечения [12][13]
Следствие для оптимизации	Более эффективное оборудование может оказаться экономически предпочтительнее ручной оптимизации кода, если позволяет получить необходимую производительность при меньшей совокупной стоимости	Накопление архитектурных узких мест создаёт потенциал для оптимизации, но её целесообразность определяется измеримым эффектом, трудозатратами, рисками и альтернативными способами решения задачи

Вместе они задают рамку решения. Пока час senior-разработчика стоит около $34.9 [23], а железо дешевеет, мелкая оптимизация проигрывает покупке ресурсов: в модели «МояФинБет» 2% экономии при 320 часах работы окупаются за 22.5 месяца, 10% — за 4.5. Но закон Вирта гарантирует, что запас мощности не остаётся бесплатным: он уходит на новые слои абстракции, поэтому архитектурные узкие места копятся, и их устранение (20% и выше) окупается за 1.1–2.3 месяца при 160–320 часах работы.

Прогноз для двух законов разный по природе. Закон Мура — свойство производства и упирается в физику: техпроцесс сократился со 180 до 2 нм за 26 лет, но шаг между узлами растёт [9][10], и выигрыш всё чаще даёт параллелизация и специализированное железо [2][3]. Закон Вирта — свойство самой индустрии разработки, и физического предела у него нет. SoC поднимает планку один раз (у Apple M4 Max пропускная способность памяти в 4.6 раза выше, чем у базового M4 [12]), но не отменяет закон Вирта: сложность софта подтягивается к новому запасу мощности.

Итоговая оценка чувствительна к трём допущениям: к модели тарификации облака (раздельные vCPU и RAM у Google Cloud и Yandex Cloud [16][17] против фиксированных типов AWS [18][19]), к коэффициенту \(k_{overhead}\) ≈ 1.45 — самому слабому месту модели [24] — и к альтернативной стоимости времени разработчика, которой нет в бюджете инфраструктуры. Поэтому практическое правило остаётся простым: считать окупаемость до начала работ по формуле выше, брать задачи с экономией от 20% и отдавать инфраструктурным мерам всё, что окупается дольше 2–3 месяцев. Оптимизировать следует тогда, когда подтверждённый экономический и технический эффект оправдывает стоимость достижения и поддержания результата.

ИСТОЧНИКИ

[1] Jeff Atwood — Hardware is Cheap, Programmers are Expensive

[2] Charles E. Leiserson et al. — There’s Plenty of Room at the Top (Science, 2020)

[3] IEEE Spectrum — Can Software Performance Engineering Save Us From the End of Moore’s Law?

[4] Kenneth Flamm — Measuring Moore’s Law: Evidence from Price, Cost, and Quality Indexes (NBER WP 24553, 2018)

[5] Our World in Data — Moore’s Law: transistors per microprocessor

[6] ServeTheHome — Guide DDR, DDR2, DDR3, DDR4 and DDR5 Bandwidth by Generation

[7] Micron — The evolution of GDDR: From GDDR1 to GDDR7

[8] Rambus — All You Need to Know About GDDR7

[9] AnySilicon — Semiconductor Technology Node History and Roadmap

[10] Wikipedia — 180 nm process · 14 nm process · 3 nm process · 2 nm process

[11] Grokipedia — закон Вирта (со ссылкой на Niklaus Wirth, A Plea for Lean Software, 1995)

[12] kindatechnical.com — Apple M Series Chips Architecture Deep Dive

[13] arXiv — Apple vs. Oranges: Evaluating the Apple Silicon M-Series SoCs for HPC Performance and Efficiency

[14] tech-insider.org — Apple Silicon vs Intel 2026: 2.5x Power Efficiency Gap

[15] AWS Prescriptive Guidance — Use Graviton instances and containers

[16] Google Cloud — VM instance pricing (per-vCPU/per-GB billing)

[17] Yandex Cloud — правила тарификации Compute Cloud

[18] Vantage — c6i.xlarge pricing and specs

[19] Vantage — r6i.xlarge pricing and specs

[20] Банк России — официальный курс USD/RUB на 17.10.2026 (83.6177 ₽/$)

[21] AWS — EBS Pricing

[22] CloudZero — EBS Pricing Explained (2026)

[23] Recruitment.by — Зарплаты в IT Беларуси 2026: бенчмарки по ролям и уровням

[24] BelTA — Кто и в каком объёме платит взносы в ФСЗН, пояснили в Минтруда

[25] Wikipedia — Amdahl’s law

Все цены и зарплаты — по состоянию на октябрь 2026 года. Расчёты по кейсу «МояФинБет» и данные по DDR6 — иллюстративная модель и прогноз отрасли, а не данные конкретной компании.