Цены на использование и облако
Возможности устройства и резервный вариант
—
ежемесячная экономия по сравнению с использованием чистого облака и гибридным подходом на устройстве—экономия %
—базовый уровень чистого облака в месяц
—гибрид всего/мес.
Разбивка затрат
| Позиция | Выводы / мес. | Стоимость / мес. |
|---|
| Базовый вариант чистого облака (100 % облако, без использования устройства) | — | — |
| — пользователи только облака (без возможности использования на устройстве) | — | — |
| — Облачный резерв от пользователей, поддерживающих устройства. | — | — |
| = Счет за гибридное облако | — | — |
| + Амортизированная стоимость установки на устройстве. | — | — |
| = Общая ежемесячная стоимость гибридного варианта | — | — |
Безубыточность единовременных затрат на установку
—
Как это связано с другими инструментами
Два калькулятора, уже представленные на этом сайте, оценивают схожее, но конструктивно разное решение. Калькулятор стоимости самостоятельного хостинга и API и Калькулятор LLM на собственном хостинге и API обе модели серверная часть Самостоятельный хостинг — аренда собственного графического процессора или облачного экземпляра и выполнение логических выводов там самостоятельно, по сравнению с оплатой провайдеру за токен или за вызов. Форма затрат в обоих случаях по-прежнему представляет собой сервер где-то с реальным счетом за хостинг, только тот, который вы контролируете, а не поставщика. Этот калькулятор вместо моделей клиентская сторона Вывод на устройстве, выполняемый непосредственно на аппаратном обеспечении телефона конечного пользователя — отсутствие необходимости арендовать сервер, фактически нулевая предельная стоимость вывода после поставки модели и совершенно другое узкое место: не часы работы графического процессора, а то, какая часть ваших пользователей владеет достаточно функциональными устройствами и как часто даже этим устройствам все равно приходится возвращаться в облако. Если вы выбираете между арендой графического процессора и оплатой облачного API, воспользуйтесь самостоятельными калькуляторами; если вы решаете, стоит ли размещать квантованную модель внутри вашего мобильного приложения, именно она соответствует этой форме стоимости.
Чтение чисел
По умолчанию — 100 000 активных пользователей в месяц, 50 выводов на пользователя в день, 0,001 доллара США за вывод в облаке, единовременная сборка на устройстве в размере 40 000 долларов США, 60 % пользователей на совместимых устройствах, 5 % коэффициент перехода к облаку для этих способных пользователей, амортизируемый в течение 12 месяцев — базовый план для чистого облака составляет 150 000 долларов США в месяц. Переход на гибридный подход снижает остаточный счет за облако до 64 500 долларов США в месяц (60 000 000 выводов от пользователей, использующих только облако, плюс 4 500 000 резервных выводов от опытных пользователей), добавляет примерно 3 333 доллара США в месяц к амортизированной стоимости установки и приводит к итоговой гибридной стоимости около 67 833 долларов США в месяц — экономия около 82 167 долларов США в месяц или примерно Скидка 55 % на базовую версию чистого облака. The $40,000 setup cost itself breaks even in under half a month at this volume, because the monthly cloud spend it deflects (about $85,500/month) dwarfs the one-time build cost almost immediately. That math changes fast at lower scale: run the same inputs at 5,000 users instead of 100,000 and the break-even stretches to roughly 20x longer — about 9.4 months instead of under half a month — because there simply are not enough deflected inferences per month to recoup the build cost quickly. Plug in your app's real MAU, not an aspirational one, before committing engineering budget to an on-device build.
Как работает этот калькулятор
- Вывод AI на Edge/на устройстве и калькулятор облачного API сначала вычисляет базовую линию чистого облака: выводов на пользователя в день × активных пользователей в месяц × 30, оценивается по вашей ставке Cloud-per-Inference — это то, что вы заплатили бы с нулевой моделью на устройстве. Затем он разделяет вашу пользовательскую базу на on-device-capable percentage способных пользователей и пользователей, работающих только в облаке. Пользователи, работающие только в облаке, генерируют полный облачный счет для каждого из своих выводов, поскольку их устройства вообще не могут запускать локальную модель. Пользователи, способные работать на устройстве, в основном выполняют вывод локально при практически нулевых предельных затратах, кроме для процент возврата к облаку их запросов — слишком сложный, с низким зарядом батареи, холодный старт до того, как локальная модель завершит загрузку, или локальный результат с низкой степенью достоверности — который все еще учитывается в облачном API.
Преднамеренно, этот калькулятор делает нет put a dollar figure on the on-device compute, battery drain or storage footprint itself — it treats the marginal cost of a local inference as zero once the model has shipped. That's a realistic simplification for small, well-quantized models running on modern flagship chips, where the incremental battery and compute cost per inference is negligible next to a cloud API bill. It understates the real cost for very large on-device models or older/low-end devices, where thermal throttling, battery drain and storage pressure are real (if hard-to-price-in-dollars) costs worth weighing separately. The residual cloud-only and cloud-fallback inferences get summed into a гибридное облако, затем единовременная стоимость установки на устройстве (проектирование, квантование, доставка) делится на выбранное вами окно амортизации и добавляется сверху, чтобы получить общая месячная стоимость гибрида. Сравнение этого с базовым показателем чистого облака дает ежемесячную экономию и процент экономии, при этом стоимость установки делится на ежемесячно облачные расходы, которые он отклоняет (чистое облако минус счет за гибридное облако, игнорирование амортизации) дает автономный безубыточность в месяцах — как быстро разовая сборка окупается только за счет облачной экономии.
Часто задаваемые вопросы
Почему вывод на устройстве имеет единовременную стоимость, а не стоимость каждого вывода, как в случае с облачными API?
Because the expensive part of on-device inference is building it, not running it. Quantizing a model down to a size that fits on a phone, converting it to Core ML or a TensorFlow Lite / NNAPI format, testing it across device tiers, and shipping it inside the app binary or as a downloadable asset is a fixed engineering project with a fixed price tag, paid once regardless of whether one user or ten million users end up running it. A cloud API instead bills per request because the provider's GPU time is a real marginal cost on every single call. Once the on-device model is quantized and shipped, running one more inference on a user's own phone costs the app owner essentially nothing beyond a sliver of the user's battery and compute — no server, no per-call bill — which is exactly what turns the one-time setup cost into something worth amortizing over months rather than expensing per call.
Что произойдет, если мой процент возможности использования устройства будет низким — перестанет ли когда-нибудь использование устройства того стоить?
Да, и этот калькулятор создан для того, чтобы точно показывать, где находится эта линия. По мере того, как процент поддержки устройств падает, большая часть вашей пользовательской базы возвращается в корзину только для облака, поэтому остаточный ежемесячный счет за облако возвращается к базовому уровню чистого облака, в то время как вы все еще платите за амортизацию затрат на установку поверх него — при некотором достаточно низком проценте возможностей гибридный подход может стоить больше, чем когда-либо стоило бы чистое облако, а не меньше. Другой рычаг, который не менее важен, — это общий объем выводов: те же затраты на установку, которые окупаются менее чем за месяц при 100 000 активных пользователей в месяц, могут занять много месяцев или фактически никогда не окупиться в течение срока службы продукта при нескольких тысячах пользователей, потому что из счета за облако просто не хватает выводов, чтобы окупить затраты на создание. Прежде чем выделять инженерный бюджет на сборку на устройстве, стоит указать фактическое значение MAU и наилучшую реальную оценку возможностей устройства, а не предполагать, что экономические показатели уменьшаются линейно.
Почему даже для пользователей, работающих на устройстве, по-прежнему взимается счет за облако?
Потому что на практике возможности устройства никогда не работают по принципу «все или ничего». Даже на телефоне, который полностью способен работать с локальной моделью, некоторая часть запросов все равно должна отправляться в облако: слишком сложный запрос или слишком выходящий за пределы локальной модели запрос, чтобы сжатая версия на устройстве могла хорошо обрабатываться, ситуация с низким зарядом батареи или температурным регулированием, когда ОС ограничивает вычисления на устройстве, окно холодного запуска до завершения загрузки ресурса локальной модели после установки или обновления или просто локальный вывод, который возвращается с низкой достоверностью и требует облачной модели для перепроверьте это. Этот калькулятор моделирует это как процент возврата к облаку, применяемый только к запросам пользователей, поддерживающих устройства, в дополнение к полному счету за облако, который все еще причитается пользователям, чьи устройства вообще не могут выполнять логический вывод на устройстве, поэтому остаточная облачная позиция в гибридном итоге никогда не равна нулю, даже при очень высоких показателях возможностей устройств.
Чем это отличается от локального калькулятора LLM и API, который уже есть на этом сайте?
И калькулятор Self-Host vs API, и Self-Hosted LLM vs API Calculator уже представлены на этом сайте, моделируя самостоятельный хостинг на стороне сервера: аренда собственного экземпляра графического процессора или облачного хранилища и выполнение выводов там самостоятельно, по сравнению с оплатой облачному провайдеру за токен или за вызов — в обоих случаях форма затрат по-прежнему представляет собой сервер где-то со счетом за хостинг, только ваш, а не поставщика. Этот калькулятор моделирует нечто структурно иное: вывод на стороне клиента на устройстве, выполняемый непосредственно на аппаратном обеспечении телефона конечного пользователя, где нет необходимости арендовать сервер, а предельные затраты на вывод фактически равны нулю после поставки модели. Что заменяет здесь счет за хостинг, так это единовременные затраты на разработку и квантование модели, амортизируемые в течение нескольких месяцев, а также верхний предел того, сколько расходов на облако вы можете фактически отклонить — установленный тем, какая часть ваших пользователей владеет достаточно функциональными устройствами и как часто даже этим устройствам все равно приходится возвращаться в облако.