Pricing Appendix

Этот документ фиксирует публичные правила расчёта стоимости платформы.

Модель: PLATFORM_PRICING_V2
Статус: Public / normative
Дата вступления версии: 4 марта 2026
Применение: все начисления после даты вступления версии
Scope: Compute, Isolate, Static, Managed PostgreSQL, Common — billable метрики платформы, включая Runtime KV storage/read/write units

1. Назначение и границы

Pricing Appendix задаёт:

какие метрики тарифицируются по каждому слою;
какие события не тарифицируются;
как считаются usage credit, extra usage budget и line items;
как применяются округления и итоговая сумма.

Документ не раскрывает внутреннюю инфраструктуру и не описывает реализацию metering pipeline.

2. Термины

Compute

Invocation — пользовательское выполнение Runtime по запросу
Process Compute CU — единая compute-метрика Runtime. 1 CU соответствует 1 vCPU + 4 ГБ RAM

Isolate

Isolate Compute CU — единая compute-метрика edge runtime. 1 CU соответствует активной runtime работе или 4 ГБ reserved memory time

Static

Egress GB — объём данных, доставленных пользователю
Storage GB-Month — хранение артефактов деплоя
Image Transforms — трансформации изображений
Origin Fetch GB — запросы к origin при cache miss

Managed PostgreSQL

CU Seconds — CU-weighted compute time (cu_size × active_time_seconds)
Storage GB — пиковый объём хранилища (данные + WAL, стоимость включает written_data)
Data Transfer GB — сетевой трафик между приложением и базой
Database Months — количество активных БД за период
Branch Months — количество активных веток за период

3. Billable метрики и единицы

Compute

Ключ	Единица
`process_compute_cu_seconds`	CU-seconds

Static

Ключ	Единица
`egress_gb`	GB
`storage_gb_month`	GB-month
`image_transforms`	count
`origin_fetch_gb`	GB

Managed PostgreSQL

Ключ	Единица
`cu_seconds`	CU-seconds
`storage_gb`	GB
`data_transfer_gb`	GB
`extra_databases`	count
`extra_branches`	count

Common

Ключ	Единица
`build_minutes`	minutes
`kv_storage_gb_month`	GB-month
`kv_read_million_units`	1M read units
`kv_write_million_units`	1M write units

4. Что тарифицируется и что нет

4.1 Тарифицируется

Запрос, дошедший до пользовательского кода и завершившийся пользовательским ответом (Compute)
Ресурсное потребление Compute в CU, включая CPU, память, активное удержание процесса, streaming/WebSocket и тёплое ожидание после freeze
Ресурсное потребление Isolate в CU, включая активное runtime CPU-like время и reserved memory time
Доставка данных пользователю, хранение артефактов и трансформация изображений (Static)
CU-weighted compute, хранилище, трафик и доп. ресурсы managed PostgreSQL
Runtime KV storage, reads и writes

4.2 Не тарифицируется

Запросы, отклонённые до запуска пользовательского кода
ISR cache hits без выполнения isolate
Внутренний service-to-service трафик платформы
Health-check и telemetry вызовы
Кэш-хиты, не создающие origin egress
Системные ретраи без пользовательского ответа

5. Нормализация usage

Compute

Q_invocations        = SUM(invocation_count)
Q_cpu_seconds        = SUM(cpu_us) / 1_000_000
Q_memory_gb_seconds  = SUM(memory_mb_us) / (1024 × 1_000_000)
Q_compute_seconds    = SUM(ready_us + reserved_us + streaming_us + websocket_us) / 1_000_000
Q_frozen_seconds     = SUM(frozen_us) / 1_000_000
Q_process_cu_seconds =
  max(Q_cpu_seconds, Q_memory_gb_seconds / 4, Q_compute_seconds × 0.25)
  + Q_frozen_seconds × 0.05

Isolate

Q_isolate_invocations       = SUM(isolate_invocation_count)
Q_isolate_cpu_seconds       = SUM(isolate_cpu_us) / 1_000_000
Q_isolate_memory_gb_seconds = SUM(isolate_memory_mb_us) / (1024 × 1_000_000)
Q_isolate_cu_seconds        = max(Q_isolate_cpu_seconds, Q_isolate_memory_gb_seconds / 4)
Q_isolate_subrequests       = SUM(isolate_kv_reads + isolate_kv_writes + isolate_fetch_count)

Static

Q_static_egress_gb        = SUM(static_egress_bytes) / (1024³)
byte_seconds              = Σ(artifact_size_bytes × overlap_seconds_in_period)
Q_static_storage_gb_month = byte_seconds / (1024³ × 2_592_000)
Q_static_image_transforms = SUM(static_image_transform_count)
Q_static_origin_fetch_gb  = SUM(static_origin_fetch_bytes) / (1024³)

Примечание: storage_gb_month считается как аналитический byte-seconds интеграл по жизненному циклу артефактов.

Managed PostgreSQL

Q_kaiki_cu_seconds          = SUM(kaiki_cu_seconds)
Q_kaiki_cu_hours            = Q_kaiki_cu_seconds / 3600
Q_kaiki_storage_gb          = MAX(kaiki_data_storage_bytes) / (1024³)
Q_kaiki_data_transfer_gb    = SUM(kaiki_data_transfer_bytes) / (1024³)
Q_kaiki_database_count      = COUNT(databases WHERE status != DELETED)
Q_kaiki_total_branch_count  = COUNT(branches WHERE status != DELETED)

Примечание: cu_seconds = cu_size × active_time_seconds. Для storage берётся пик за период. cu_hours тарифицируется блоками по 1 CU-час (BlockSize = 3600 CU-секунд). Storage стоимость включает written_data (WAL).

Common

build_overlap_seconds_i = overlap_seconds(build_i_started_at..build_i_finished_at, period_start..period_end)
Q_build_minutes         = ceil( SUM(build_overlap_seconds_i) / 60 )
Q_kv_storage_gb_month   = SUM(kv_storage_byte_seconds) / (1024³ × 2_592_000)
Q_kv_read_million_units = SUM(kv_read_units) / 1_000_000
Q_kv_write_million_units = SUM(kv_write_units) / 1_000_000

Примечание: kv_storage_bytes используется как hard-cap gauge. Billable storage считает key + value + metadata + platform overhead во времени. KV read/write тарифицируются пропорционально количеству million units, без минимального блока 1M. Примечание: build_minutes считается по пересечению build-window с расчётным периодом; ceil применяется один раз к суммарной длительности периода.

6. Формулы usage credit и extra usage

Для любой billable-метрики M quantity считается с первой единицы. Limit_M не вычитается из quantity для экономического расчёта: это reference/control value и защитный порог.

GrossLineAmount_M = charge(Q_used_M, Rate_M)
GrossUsage = Σ GrossLineAmount_M
IncludedCreditApplied = min(GrossUsage, IncludedUsageCredit)
ExtraUsage = max(0, GrossUsage - IncludedUsageCredit)
BlockedUnapprovedUsage = max(0, ExtraUsage - ExtraUsageBudget)

6.1 Тариф `per_unit`

GrossLineAmount_M = Q_used_M × Rate_M

6.2 Тариф `per_block`

Blocks_M = ceil(Q_used_M / BlockSize_M)
GrossLineAmount_M = Blocks_M × BlockRate_M

6.3 Итог

Subtotal = ExtraUsage   (после применения included usage credit)

Каждый gross line item содержит layer и metric теги для идентификации слоя и метрики. Для Hobby paid extra usage нет: когда GrossUsage >= IncludedUsageCredit, новые billable-операции блокируются. Для Pro paid usage допускается только в пределах ExtraUsageBudget.

7. Округления

Usage и промежуточные quantity считаются без раннего округления
Для per_block сначала применяется ceil количества блоков
Денежные значения line item округляются round_half_up до денежной точности
Сумма формируется из line items после их округления

8. Структура счёта

InvoiceTotal = Subtotal + Adjustments - Credits

Где:

Subtotal — сумма всех line items (compute + static + managed postgresql + common)
Adjustments — корректировки начислений
Credits — промо/компенсационные кредиты

ONREZA работает на УСН, поэтому НДС не выделяется: в инвойсах и УПД указывается «Без налога (НДС)». Для плательщиков типа ИП и ЮЛ после оплаты автоматически формируется УПД с составом начислений из line items. Подробнее — в разделе Оплата и реквизиты.

9. Invoice diagnostics

Каждый инвойс содержит diagnostics-блок:

quantities — нормализованные значения по каждой метрике
grossUsage — usage до применения included credit
includedUsageCreditApplied — применённый included usage credit
extraUsage — usage сверх included credit
limits — действующие hard caps и защитные пороги

10. Hard Cap и защитные политики

Hard Cap ограничивает максимальные extra usage расходы за период
При достижении порога могут применяться защитные ограничения
Платформа автоматически детектирует резкие аномалии потребления по каждому слою
Полный перечень лимитов и ставок: Лимиты и квоты

11. Источник актуальных ставок

Эта страница описывает методику расчёта
Текущие ставки, usage credit и hard caps публикуются на Pricing и в биллинге workspace

12. Приоритет источников

При расхождении источников:

Индивидуальные коммерческие условия (если есть)
Выставленный инвойс с детализацией line items за конкретный период
Публичная pricing-страница и активные лимиты workspace
Этот appendix как нормативная методика расчёта

13. Версионирование

Изменения модели публикуются как новая версия (PLATFORM_PRICING_V*) с датой вступления. Для каждой версии фиксируются:

список billable-метрик по слоям
формулы usage credit и extra usage
политика округлений
правила применения line items

Ретроактивное изменение уже выставленных и закрытых инвойсов не применяется, кроме случаев явной ошибки начисления.

14. Пример проверки начисления

Возьмите usage по каждой метрике каждого слоя за расчётный период
Примените per_unit или per_block тариф к quantity с первой единицы
Сложите gross line items
Примените included usage credit и extra usage budget
Проверьте округления по правилам раздела 7 и примените корректировки/кредиты/налоги

Для пошаговых формул: Формулы и переменные.

Pricing Appendix

1. Назначение и границы

2. Термины

Compute

Isolate

Static

Managed PostgreSQL

3. Billable метрики и единицы

Compute

Static

Managed PostgreSQL

Common

4. Что тарифицируется и что нет

4.1 Тарифицируется

4.2 Не тарифицируется

5. Нормализация usage

Compute

Isolate

Static

Managed PostgreSQL

Common

6. Формулы usage credit и extra usage

6.1 Тариф per_unit

6.2 Тариф per_block

6.3 Итог

7. Округления

8. Структура счёта

9. Invoice diagnostics

10. Hard Cap и защитные политики

11. Источник актуальных ставок

12. Приоритет источников

13. Версионирование

14. Пример проверки начисления

6.1 Тариф `per_unit`

6.2 Тариф `per_block`