Локальный GPU-сервер или облако: Как посчитать TCO

Локальный GPU-сервер или облако: как посчитать TCO

Нет универсальной загрузки GPU, после которой локальный сервер автоматически становится дешевле облака.

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

Правильная последовательность:

одинаковый workload

        ↓

одинаковый performance / SLA target

        ↓

throughput local и cloud

        ↓

required runtime

        ↓

local cash flow

        ↓

cloud cash flow

        ↓

On-Demand / commitment / reservation / Spot

        ↓

persistent costs

        ↓

cumulative cost

        ↓

crossover

        ↓

sensitivity analysis

Главное правило:

Почему нельзя напрямую сравнить два GPU-hour

Один час локальной GPU и один час облачной GPU могут выполнять разный объём работы.

На результат влияют:

GPU SKU

GPU count

interconnect

precision

batch / concurrency

parallelism

runtime

software version

Поэтому сначала нужен показатель полезной производительности.

Для training это может быть samples/hour, tokens/hour или время завершения одинакового training job.

Для inference — requests/hour или tokens/hour при одинаковых требованиях к latency и throughput.

Если нужно выполнить объём работы W:

Hlocal=WThroughputlocalH_{local}=\frac{W}{Throughput_{local}} Hcloud=WThroughputcloudH_{cloud}=\frac{W}{Throughput_{cloud}}

Именно эти часы затем попадают в финансовую модель.

Условный арифметический пример:

Workload           = 16 000 units

Local throughput   = 100 units/hour

Cloud throughput   = 160 units/hour

Тогда:

Hlocal=160 hoursH_{local}=160\ hours Hcloud=100 hoursH_{cloud}=100\ hours

Это не benchmark и не рекомендация Start Server. Пример показывает только, почему равенство 1 GPU-hour = 1 GPU-hour может быть неверным.

Сначала зафиксируйте одинаковый workload

До расчёта TCO нужны:

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

Для Start Server это соответствует общему правилу: у сравнения должны совпадать методика и нагрузка.

Что входит в TCO локального GPU-сервера

Базовая структура:

INITIAL

server

network / accessories

deployment

initial licenses

+

RECURRING

power

placement

network

support

licenses

administration

maintenance / spares

+

LIFECYCLE

upgrade

decommission

minus residual value

Концептуально:

LocalCashTCO=CAPEX+RecurringOPEX+Upgrades−ResidualValueLocalCashTCO= CAPEX+ RecurringOPEX+ Upgrades- ResidualValue

Используйте реальный CAPEX, а не условный MSRP

На коммерческой стадии исходным значением должна быть датированная нормализованная спецификация:

server BOM

network / accessories

delivery

deployment

licenses

support scope

Если предложение уже разобрано по методике SS-017, его можно использовать как local-side input для SS-018.

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

Энергопотребление: не используйте мощность PSU как расход

Наличие:

2 × 3.2 kW PSU

не означает постоянное потребление:

6.4 kW

То же касается суммы GPU TDP: она не равна энергопотреблению всего сервера и тем более всей площадки.

Базовая модель:

EIT,m=Pactive×Hactive+Pidle×HidleE_{IT,m} = P_{active}\times H_{active} + P_{idle}\times H_{idle}

где P_active и P_idle лучше получать из измерений или хотя бы явно маркированной инженерной оценки конкретной конфигурации.

Что такое PUE и когда его применять

DOE определяет PUE как отношение полной энергии дата-центра к энергии IT-оборудования:

PUE=Total Facility EnergyIT Equipment EnergyPUE= \frac{Total\ Facility\ Energy} {IT\ Equipment\ Energy}

DOE также подчёркивает, что PUE — инфраструктурная метрика и корректнее использовать её на основе длительных, в том числе годовых, измерений, чтобы учесть изменение нагрузки и условий охлаждения.

Если для собственной площадки известен применимый PUE:

Efacility=EIT×PUEE_{facility}=E_{IT}\times PUE EnergyCost=Efacility×TariffEnergyCost=E_{facility}\times Tariff

Но нельзя автоматически ставить:

PUE = 1.4

просто потому, что это кажется «типичным ЦОД».

Не применяйте PUE поверх уже полного colocation bill

У colocation provider модель оплаты может быть основана на:

rack fee

reserved kW

metered energy

network ports

cross-connect

remote hands

Если facility expenses уже отражены в таком счёте, дополнительное:

server energy × PUE × electricity tariff

может повторно посчитать одни и те же расходы.

Поэтому calculator использует альтернативные placement modes:

Cloud bill — не только GPU rate × hours

В облаке могут отдельно тарифицироваться:

compute

GPU

vCPU / RAM

persistent storage

snapshots

network

licenses

support

managed services

capacity commitments

Например, Google Cloud указывает, что attached GPU увеличивает стоимость VM дополнительно к machine type, а GPU pricing зависит от region.

Поэтому любая тарифная строка в модели должна иметь:

provider

region

exact resource

billing unit

pricing mode

date checked

On-Demand и commitment нужно считать отдельно

On-Demand — удобный baseline, но не универсальная стоимость cloud.

Если организация готова взять долгосрочное обязательство, нужен отдельный сценарий.

Минимум:

AWS Savings Plans: скидка в обмен на commitment

AWS Savings Plans дают более низкую цену в обмен на commitment определённого объёма compute usage на один или три года; доступны all-upfront, partial-upfront и no-upfront варианты.

При этом Savings Plans не предоставляют capacity reservation. AWS прямо указывает, что при необходимости capacity assurance нужно использовать EC2 On-Demand Capacity Reservations, а Savings Plans могут применяться к подходящей reserved capacity.

Значит:

price commitment

≠

capacity assurance

Как тарифицируется AWS Capacity Reservation

AWS On-Demand Capacity Reservation удерживает capacity в конкретной Availability Zone.

Неиспользованная capacity тарифицируется по эквивалентной On-Demand ставке. Если соответствующий instance занимает reservation, заказчик платит за instance, а отдельного дополнительного charge за уже занятую им reserved capacity нет. Подходящие Savings Plans и некоторые RI discounts могут применяться к Capacity Reservation.

Поэтому нельзя использовать:

Cloud bill =

instance price

+

full reservation price

+

Savings Plan price

как универсальное простое сложение.

Calculator должен использовать реальные billing rules выбранного продукта.

Google Cloud: resource-based GPU CUD требует отдельной точности

Google Cloud имеет как resource-based, так и spend-based committed use discounts; commitment обычно заключается на один или три года.

Для resource-based commitment на GPU Google требует создать reservation на эти GPU и прикрепить её к commitment. GPU type и объём reserved/committed resources должны соответствовать правилам продукта.

Но это нельзя превращать в универсальное правило для любого Google commitment.

Например, current Compute Engine documentation отдельно указывает, что compute flexible commitments не поддерживают attached reservations; для G2/G4 capacity при необходимости создаётся standalone reservation, а flexible commitment может покрывать соответствующее eligible usage.

Поэтому правильная структура TCO-модели:

Provider:

Pricing product:

Commitment type:

Capacity reservation rule:

Billing interaction:

а не один generic checkbox CUD.

Stopped VM не обязательно означает нулевой cloud bill

У AWS stopped EBS-backed EC2 instance не тарифицируется как работающий instance, но EBS volumes продолжают храниться и тарифицироваться.

У Google Cloud stopped VM также не получает VM usage charges, но persistent disks и static IP resources могут продолжать тарифицироваться до удаления.

Поэтому разделяйте:

RUNTIME COSTS

compute

GPU

runtime-dependent resources

и:

PERSISTENT COSTS

storage

snapshots

IPs

licenses

commitments

reserved capacity

other services

Storage и network — отдельные workload-dependent inputs

Нельзя заранее утверждать, что egress обязательно делает cloud дорогим.

Для одного workload данные почти не выходят из provider network.

Для другого регулярно экспортируются:

models

checkpoints

datasets

video

generated media

Поэтому в calculator достаточно отдельных inputs:

Persistent storage:

Snapshots / backup:

Internet egress:

Inter-zone:

Inter-region:

и датированных тарифов provider.

Spot: низкая ставка ещё не означает низкую стоимость workload

Spot capacity может быть прервана provider.

AWS выдаёт Spot Instance interruption notice за две минуты до stop/terminate; для hibernation действуют другие условия.

В Google Cloud default Spot configuration использует best-effort shutdown period до 30 секунд; сейчас также существует preview-вариант с отдельным 120-second preemption notice.

Поэтому:

SpotCost≠SpotRate×IdealRuntimeSpotCost \neq SpotRate\times IdealRuntime

если workload теряет полезную работу при interruption.

Более полная схема:

SpotEffectiveCost=ComputeBill+CheckpointCost+RestartCost+LostWorkCost+ReacquisitionCostSpotEffectiveCost= ComputeBill+ CheckpointCost+ RestartCost+ LostWorkCost+ ReacquisitionCost

Не нужно автоматически добавлять +10% или другой универсальный коэффициент.

Эти значения должны следовать из конкретного training stack.

Availability нужно нормализовать до расчёта TCO

Сравнение некорректно, если:

LOCAL

1 physical server

без redundancy

сравнивается с:

CLOUD

multi-zone architecture

и вся разница объявляется «премией за облако».

До финансового расчёта зафиксируйте:

Availability target:

Recovery target:

Required redundancy:

Обе candidate architectures должны решать одну задачу.

Cash TCO и depreciation нельзя считать одновременно как два расхода

Для базовой модели SS-018 используем cash view.

В нулевой момент:

LocalCashFlow0=Purchase+Deployment+OneTimeLicensesLocalCashFlow_0= Purchase+ Deployment+ OneTimeLicenses

Далее:

LocalCashFlowm=Power+Placement+Network+Support+Maintenance+OtherLocalCashFlow_m= Power+ Placement+ Network+ Support+ Maintenance+ Other

Accounting depreciation можно построить отдельно, если это требуется финансовой службе.

Но:

full purchase price

+

full depreciation

одного и того же актива нельзя складывать в один cash TCO.

Иначе acquisition cost будет учтён дважды.

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

Остаточная стоимость — отдельное предположение

На конце горизонта server может:

продолжать использоваться

перейти на другой workload

быть продан

быть списан

Поэтому:

LocalCumt=CAPEX0+∑OPEXm+∑Upgradesm−RealizedResidualtLocalCum_t= CAPEX_0+ \sum OPEX_m+ \sum Upgrades_m- RealizedResidual_t

Но значение:

Residual value = 20% CAPEX

не может быть универсальным default.

В Assumption Ledger оно получает:

EVIDENCE-BACKED

или:

ASSUMPTION

или:

UNKNOWN

Почему горизонт расчёта принципиально важен

Одно решение может выглядеть по-разному на:

12 месяцев

36 месяцев

60 месяцев

Local infrastructure обычно имеет крупный initial outflow.

Cloud чаще распределяет значительную часть расходов по периоду использования.

Поэтому horizon — входной параметр, а не выбранный заранее срок, удобный для доказательства одного результата.

Editable GPU TCO Calculator

Ниже — основной самостоятельный инструмент статьи.

PROJECT

Horizon:

Currency:

Tax basis:

FX source/date:

WORKLOAD

Workload:

Model/version:

Precision:

Useful work units/month:

Growth:

Performance target:

Availability target:

Local configuration:

Cloud configuration:

PERFORMANCE

Local throughput:

MEASURED / ASSUMPTION

Source/date:

Cloud throughput:

MEASURED / ASSUMPTION

Source/date:

Required local runtime:

Required cloud runtime:

LOCAL — INITIAL

Server:

Network/accessories:

Delivery:

Deployment:

Licenses:

Other:

LOCAL — PLACEMENT

Mode:

OWN / COLOCATION

Active power:

Idle power:

PUE:

Source/date:

OR

Colocation tariff:

Rack:

Reserved power:

Metered power:

Network:

LOCAL — OPERATIONS

Support:

Administration:

Licenses:

Maintenance:

Spares:

LOCAL — LIFECYCLE

Upgrade:

Decommission:

Residual value:

CLOUD — RESOURCE

Provider:

Region:

Exact resource/instance:

GPU:

GPU count:

Pricing date:

CLOUD — ON-DEMAND

Compute:

GPU:

vCPU/RAM:

Other runtime:

CLOUD — COMMITMENT

Product:

Type:

Term:

Committed amount:

Effective billed rate:

Unused commitment:

Excess usage:

CLOUD — CAPACITY

Reservation:

Required / optional / not used:

Reserved capacity:

Unused reserved capacity:

Provider-specific

billing interaction:

CLOUD — SPOT

Applicable:

YES / NO

Interruption model:

Checkpoint cost:

Restart:

Lost work:

Reacquisition:

CLOUD — PERSISTENT

Storage:

Snapshots:

Backup:

Internet egress:

Inter-zone:

Inter-region:

Licenses:

Support:

Managed services:

MONTHLY OUTPUT

Month 0:

Month 1:

...

Month N:

Local monthly:

Local cumulative:

Cloud On-Demand monthly:

Cloud On-Demand cumulative:

Cloud committed monthly:

Cloud committed cumulative:

Spot:

if applicable

UNIT ECONOMICS

Local cost / useful work unit:

Cloud cost / useful work unit:

CROSSOVER

First crossover:

or

NO CROSSOVER

WITHIN HORIZON

Assumption Ledger

Сам TCO-result не должен существовать без списка исходных предположений.

Пустая строка не превращается в ноль.

Она остаётся:

UNKNOWN

пока проект не подтвердит обратное.

Три разных вида utilization

В финансовой модели полезно разделить три понятия.

Финансово особенно важен paid utilization.

Например, высокая техническая загрузка во время шестичасового job ничего не говорит о том, простаивает ли owned server остальные 18 часов.

С другой стороны, неиспользуемая cloud capacity reservation тоже способна создавать расходы. AWS прямо тарифицирует неиспользованную Capacity Reservation, пока она существует.

Поэтому:

Как считать накопленные затраты

Для каждого месяца:

LocalCum(t)=CAPEX0+∑m=1tLocalCashFlowm+Upgrades−RealizedResidualLocalCum(t)= CAPEX_0+ \sum_{m=1}^{t}LocalCashFlow_m+ Upgrades- RealizedResidual CloudCum(t)=InitialMigration+∑m=1tCloudBillmCloudCum(t)= InitialMigration+ \sum_{m=1}^{t}CloudBill_m

Точка, в которой соответствующие cumulative curves сравниваются, — точка равенства накопленных затрат, или crossover.

Если пересечения нет:

NO CROSSOVER

WITHIN 36 MONTHS

— это нормальный результат.

Не нужно принудительно выдавать срок окупаемости.

Crossover — не ROI

Если:

LocalCum = CloudCum

это означает равенство стоимости двух альтернативных способов выполнить задачу на выбранном горизонте.

Это не означает автоматически:

ROI = 0

или:

инвестиция окупилась

Для ROI нужен отдельный анализ доходов/выгод, а не только сравнение двух cost curves.

Считайте стоимость единицы полезной работы

Дополнительный output:

LocalCostPerWorkUnit=LocalCumCompletedUsefulWorkLocalCostPerWorkUnit= \frac{LocalCum}{CompletedUsefulWork} CloudCostPerWorkUnit=CloudCumCompletedUsefulWorkCloudCostPerWorkUnit= \frac{CloudCum}{CompletedUsefulWork}

Это особенно полезно, когда local и cloud требуют разного accelerator runtime.

Но definition CompletedUsefulWork должно оставаться одинаковым.

Sensitivity analysis обязателен

Один итог:

LOCAL CHEAPER

слишком слаб для инвестиционного решения.

Нужно понять, что произойдёт при изменении assumptions.

Правильный вывод выглядит не так:

При загрузке выше 60% нужно покупать сервер.

А так:

Эти границы вычисляются из данных проекта.

Hybrid — дополнительный сценарий

Иногда полезен третий вариант:

local baseline

+

cloud burst

Например, собственный server обслуживает постоянную нагрузку, а кратковременные пики переходят в cloud.

Тогда:

HybridCost=LocalBaseline+CloudBurstHybridCost= LocalBaseline+ CloudBurst

Но SS-018 не должна превращаться в руководство по проектированию hybrid cloud.

Это всего лишь ещё одна строка financial scenario.

Цена downtime — только при наличии данных

Если компания способна обоснованно оценить:

expected downtime hours

business loss per hour

можно добавить:

ExpectedDowntimeCost=ExpectedDowntimeHours×BusinessCostPerHourExpectedDowntimeCost= ExpectedDowntimeHours \times BusinessCostPerHour

Но без этих данных значение остаётся UNKNOWN.

Универсальной «стоимости часа простоя» для SS-018 нет.

Валюта и налоги нужно привести к одной базе

Если local quote получен в одной валюте, а cloud tariff — в другой:

Calculation currency:

FX rate:

FX source:

FX date:

Также сравнивайте одинаковую налоговую базу:

gross vs gross

или:

net vs net

Финальный алгоритм

1. Определить одинаковую

   полезную работу

        ↓

2. Зафиксировать одинаковый

   availability target

        ↓

3. Выбрать технически достаточные

   local и cloud configurations

        ↓

4. Измерить / оценить throughput

        ↓

5. Рассчитать required runtime

        ↓

6. Внести dated local CAPEX

        ↓

7. Выбрать placement model

        ↓

8. Рассчитать power/facility cost

        ↓

9. Построить cloud On-Demand

        ↓

10. Отдельно построить commitment

        ↓

11. Проверить capacity reservation

    и billing interaction

        ↓

12. Добавить persistent costs

        ↓

13. Spot считать отдельно

        ↓

14. Нормализовать FX / tax

        ↓

15. Построить monthly cash flows

        ↓

16. Найти crossover,

    если он существует

        ↓

17. Посчитать cost / useful work

        ↓

18. Провести sensitivity analysis

Что передать для расчёта

WORKLOAD

model / task

work units/month

growth

performance target

availability target

LOCAL

exact server BOM

dated quote

deployment

support

active/idle power

placement model

electricity / colo

expected lifecycle

CLOUD

provider

region

exact resource

GPU SKU/count

pricing date

On-Demand

commitment type

reservation model

Spot if applicable

storage

network

support

FINANCE

horizon

currency

FX method

tax basis

residual-value method

По этим данным можно построить несколько сценариев и увидеть не только более дешёвый вариант в base case, но и условия, при которых вывод изменится.