—
самая дешевая платформа в месяц—RunPod / месяц
—Басетен / месяц
—Модальный/месяц
Разброс затрат — та же номинальная ставка графического процессора в долларах в час.
—
Разбивка по платежам по платформам
Те же входные данные, что и выше, применяются через отдельную логику выставления счетов каждой платформы. Оплачиваемые единицы/день — это необработанное количество, за которое фактически взимает плату каждая платформа: секунды для RunPod и Modal, минуты для Baseten.
Ежемесячная стоимость по тарифу холодного запуска (интенсивность трафика)
Те же входные данные длительности, скорости и буфера, что и выше, с учетом скорости холодного запуска — насколько распределены ваши запросы. Выделенная строка наиболее близка к текущему введенному значению скорости холодного запуска. Посмотрите, как может измениться самая дешевая платформа по мере увеличения трафика.
| Скорость холодного запуска | RunPod / месяц | Басетен / месяц | Модальный/месяц | Самый дешевый |
|---|
Как это связано с другими инструментами
Этот калькулятор дает ответ на один конкретный, узкий вопрос: для BURSTY-трафика с низким количеством запросов в секунду, как одна и та же номинальная ставка в долларах за час графического процессора превращается в очень разные реальные счета в зависимости от механизма выставления счетов платформы — посекундно, поминутно округленно или посекундно плюс буфер поддержания тепла. Он намеренно не моделирует аренду графического процессора с высокой загрузкой по фиксированной ставке, при которой вы платите за непрерывные часы независимо от схемы запроса — эту структуру см. Калькулятор стоимости облака графического процессора и Калькулятор стоимости аренды графического процессора, где стоимость графического процессора рассчитывается как $/час × использованные часы. Этот инструмент существует именно потому, что математика с фиксированной ставкой не работает для спорадических рабочих нагрузок, склонных к холодному запуску — внутренний инструмент, вызываемый несколько сотен раз в день, ведет себя совсем не так, как загруженный API, закрепляющий графический процессор при высокой загрузке, а разница в форме выставления счетов между платформами проявляется только после того, как вы явно моделируете холодный запуск и время простоя, а не предполагаете фиксированную ставку, умноженную на часы.
Как работает этот калькулятор
The Калькулятор оплаты бессерверной платформы графических процессоров разделяет ваш ежедневный трафик на два сегмента с помощью скорость холодного запуска: холодные запросы (запросы в день × скорость холодного запуска) — это запросы, которые поступают после того, как контейнер обнулился и должен оплатить полную стоимость. продолжительность холодного старта плюс продолжительность теплого вывода; теплые просьбы (оставшаяся часть) попадает в уже загруженный контейнер и оплачивает только продолжительность вывода. Затем каждая платформа применяет свою собственную логику выставления счетов к этим двум сегментам. RunPod счета в секунду за каждую секунду активности контейнера (холодного или теплого), поэтому его ежедневный счет равен просто общему количеству активных секунд ÷ 3600 × ваш Часовая ставка графического процессора. Бастен счета взимаются поминутно и округляются до следующей полной минуты, поэтому даже 3-секундный теплый звонок и 11-секундный холодный звонок занимают одну полную оплаченную минуту; его ежедневный счет составляет общую сумму оплаченных минут ÷ 60 × почасовую ставку. Модальный счетов в секунду, как RunPod для реальных вычислений, но добавляет буфер для поддержания тепла в режиме ожидания в качестве дополнительных оплачиваемых секунд для каждого теплого запроса — контейнер остается активным и выставляет счета за это буферное окно, поэтому следующий запрос может пропустить собственный холодный запуск.
Число, заслуживающее внимания, это ежемесячный разброс затрат между самой дешевой и самой дорогой платформой — в собственных рабочих настройках калькулятора по умолчанию (200 запросов в день, 3 секунды горячего запуска, 8 секунд холодного запуска, 40 % скорости холодного запуска, 2,49 доллара США в час) этот разброс составляет примерно 9-10x между RunPod и Baseten с одинаковой номинальной почасовой частотой графического процессора. Этот разрыв не является уловкой ценообразования — это то, что происходит, когда типичная продолжительность вызова рабочей нагрузки (несколько секунд) сталкивается с детализацией выставления счетов, созданной для более длительных заданий (полная минута). Чем короче и спорадичнее ваши звонки, тем больше эта форма имеет большее значение, чем фиксированная ставка в долларах за час. Этот инструмент моделирует МЕХАНИКУ, публично документированную этими типами платформ — посекундное выставление счетов, поминутное округление, буферы поддержания тепла — как приближение, чтобы показать форму разницы; всегда проверяйте текущие страницы цен поставщиков перед совершением сделки, поскольку точные ставки и правила округления могут измениться.
Часто задаваемые вопросы
Почему Baseten стоит дороже, чем RunPod за тот же графический процессор?
Не потому, что базовая частота графического процессора различается (в этом сравнении оба тарифа оплачиваются по одинаковой цене в долларах в час), а из-за того, как каждая платформа работает круглосуточно. Бессерверная тарификация RunPod производится посекундно: вы платите ровно за те секунды, в которых контейнер активен, включая время загрузки при холодном запуске, и ничего больше. Baseten выставляет счета поминутно и округляет каждый вызов ВВЕРХ до следующей полной минуты. Теплый 3-секундный вызов вывода по-прежнему оплачивается как полная 60-секундная минута, а 11-секундный вызов с холодным запуском также оплачивается как та же полная минута, поскольку оба округляются до 1. Для пакетной рабочей нагрузки с низким количеством запросов в секунду, когда большинство отдельных вызовов длятся всего несколько секунд, такое округление является жестоким: вы фактически платите за в 15–20 раз больше вычислительного времени, чем вы фактически использовали для каждого отдельного вызова. Разрыв — это не ценовая уловка, это чистое округление с точностью до минуты, применяемое к очень коротким заданиям, и оно увеличивается каждый раз, когда рабочая нагрузка такая короткая и частая.
Что такое «холодный старт» и почему он стоит денег?
Бессерверная платформа графического процессора не обеспечивает работу контейнера (и выставление вам счетов), когда ничего не происходит — она масштабирует контейнер до нуля после периода бездействия, чтобы сэкономить вам деньги на время простоя. Компромисс заключается в том, что следующий запрос после масштабирования до нуля должен дождаться запуска совершенно нового контейнера: извлечь образ контейнера, загрузить веса модели в графический процессор, инициализировать среду выполнения и только затем начать фактический вывод. Этот процесс загрузки представляет собой «холодный старт», и в рабочих нагрузках LLM или логического вывода, размещенных на графическом процессоре, он обычно занимает от нескольких секунд до десятков секунд, поскольку вес модели может достигать гигабайт, и их перемещение в память графического процессора не происходит мгновенно. Важно отметить, что время загрузки не является бесплатным вычислительным временем, предоставляемым вам — графический процессор полностью выделяется и выставляет счета во время него на каждой смоделированной здесь платформе, точно так же, как это было бы во время фактического вывода. Таким образом, каждый запрос на холодный старт фактически стоит вам секунд холодного старта ПЛЮС фактических секунд вывода, и чем более распределен (повышенный) ваш трафик, тем больше ваших запросов попадает в холодный контейнер, а не в еще теплый, и тем большая часть вашего общего счета — это чистые накладные расходы на загрузку, а не полезные вычисления.
Должен ли я использовать буфер поддержания тепла для своей рабочей нагрузки по выводу?
Это зависит от того, оптимизируете ли вы задержку или стоимость, и эти две цели тянутся в противоположных направлениях для неравномерного трафика. Буфер поддержания тепла (смоделированный здесь как подход Modal) сохраняет работоспособность контейнера и загружает его для окна после завершения каждого запроса, поэтому, если следующий запрос поступает внутри этого окна, он полностью пропускает холодный старт и отвечает быстро. Это настоящее преимущество для пользователей при работе с трафиком, чувствительным к задержкам. Но вы платите полную стоимость активности графического процессора за каждую секунду простоя, в которой контейнер находится в ожидании, независимо от того, прибудет ли когда-либо другой запрос вовремя — модальная модель калькулятора добавляет буфер простоя в качестве оплачиваемых секунд для каждого запроса, который получает выгоду от «теплого» контейнера. Для очень спорадического трафика — длинных, непредсказуемых промежутков между вызовами — это время простоя в основном является пустой тратой денег, потому что срок действия буфера все равно истекает до того, как появится следующий запрос, и вы заплатили за него даром. Буферы поддержания тепла имеют наибольший экономический смысл, когда пробелы в запросах группируются непосредственно внутри буферного окна; для действительно случайного или редкого трафика использование случайного холодного запуска обычно дешевле, чем платить за поддержание тепла графического процессора на случай, если скоро поступит следующий вызов.
Какая оплата за использование графического процессора — посекундная или поминутная — лучше при интенсивном трафике?
Для пульсирующего, кратковременного трафика посекундная тарификация почти всегда предпочтительнее, и чем короче ваш типичный вызов вывода относительно минуты, тем больше преимущество. Поминутная оплата с округлением (как в модели Бастена) взимает полную минуту независимо от того, заняло ли фактическое вычисление 3 секунды или 55 секунд — степень детализации биллинга грубее, чем рабочая нагрузка, поэтому короткие звонки облагаются самым тяжелым налогом в процентном выражении. Посекундная оплата (как в случае с активными вычислениями RunPod и Modal здесь) взимает плату, близкую к той, что была использована, поэтому 3-секундный вызов стоит примерно двадцатую часть 60-секундного вызова вместо той же суммы. Поминутная оплата за одно место перестает быть явным недостатком, когда типичная продолжительность звонка уже близка к минуте или превышает ее — потери на округление сокращаются до нуля по мере того, как продолжительность звонка приближается к степени детализации выставления счетов. Для внутреннего инструмента или спорадического API, вызываемого несколько сотен раз в день с многосекундными ответами, поминутная оплата может легко оказаться на порядок дороже, чем посекундная оплата при той же номинальной почасовой ставке графического процессора.