Uso e preços da nuvem
Capacidade e substituto do dispositivo
—
economia mensal versus abordagem de nuvem pura e híbrida no dispositivo—% de poupança
—linha de base de nuvem pura / mês
—total híbrido / mês
Detalhamento de custos
| Item de linha | Inferências / mês | Custo / mês |
|---|
| Linha de base de nuvem pura (100% nuvem, sem dispositivo) | — | — |
| — usuários somente na nuvem (não compatíveis com o dispositivo) | — | — |
| — fallback na nuvem de usuários com capacidade no dispositivo | — | — |
| = Conta de nuvem híbrida | — | — |
| + Custo amortizado de configuração no dispositivo | — | — |
| = Custo mensal total híbrido | — | — |
Ponto de equilíbrio no custo de configuração único
—
Como isso se conecta a outras ferramentas
Duas calculadoras já neste site avaliam uma solução semelhante, mas estruturalmente diferente. O Calculadora de custos de auto-hospedagem vs API e o LLM auto-hospedado vs calculadora API ambos os modelos lado do servidor auto-hospedagem – alugando sua própria GPU ou instância de nuvem e executando inferência lá você mesmo, em comparação com o pagamento de um provedor por token ou por chamada. O custo em ambos ainda é um servidor em algum lugar com uma conta de hospedagem real, apenas um que você controla em vez de um fornecedor. Esta calculadora, em vez disso, modela lado do cliente inferência no dispositivo executada diretamente no hardware do telefone do usuário final – sem servidor para alugar, custo marginal efetivamente zero por inferência assim que o modelo for lançado e um gargalo completamente diferente: não horas de GPU, mas que fração de seus usuários possui dispositivos com capacidade suficiente e com que frequência até mesmo esses dispositivos ainda precisam voltar para a nuvem. Se você estiver decidindo entre alugar uma caixa de GPU e pagar uma API em nuvem, use as calculadoras auto-hospedadas; se você está decidindo se deseja enviar um modelo quantizado dentro do seu próprio aplicativo móvel, este é aquele que corresponde a esse formato de custo.
Ler os números
At the defaults — 100,000 monthly active users, 50 inferences per user per day, $0.001 per cloud inference, a $40,000 one-time on-device build, 60% of users on capable devices, a 5% cloud-fallback rate on those capable users, amortized over 12 months — the pure-cloud baseline runs $150,000/month. Going hybrid brings the residual cloud bill down to $64,500/month (60,000,000 inferences from cloud-only users plus 4,500,000 fallback inferences from capable users), adds roughly $3,333/month in amortized setup cost, and lands on a hybrid total near $67,833/month — a savings of about $82,167/month, or roughly 55% de desconto na linha de base da nuvem pura. 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.
Como funciona esta calculadora
O Inferência de IA no Edge/no dispositivo versus calculadora de API na nuvem primeiro calcula uma linha de base de nuvem pura: inferências por utilizador por dia × utilizadores ativos mensais × 30, ao preço da sua taxa de interferência na nuvem — é isso que você pagaria com o modelo zero no dispositivo. Em seguida, divide a sua base de utilizadores por porcentagem compatível com o dispositivo em usuários capazes e usuários somente na nuvem. Os usuários somente na nuvem geram uma conta completa da nuvem para cada uma de suas inferências, já que seus dispositivos não conseguem executar o modelo local. Os usuários habilitados para uso no dispositivo executam principalmente inferências localmente com custo marginal efetivamente zero, exceto por um porcentagem de fallback na nuvem de suas consultas – muito complexas, com bateria fraca, uma inicialização a frio antes que o download do modelo local termine ou um resultado local de baixa confiança – que ainda cobra da API da nuvem.
Deliberadamente, esta calculadora faz não coloque um valor em dólares na computação no dispositivo, no consumo de bateria ou no espaço de armazenamento em si - ele trata o custo marginal de uma inferência local como zero depois que o modelo é enviado. Essa é uma simplificação realista para modelos pequenos e bem quantizados executados em chips modernos, onde a bateria incremental e o custo de computação por inferência são insignificantes perto de uma conta de API em nuvem. Ele subestima o custo real para modelos de dispositivos muito grandes ou dispositivos mais antigos/de baixo custo, onde o afogamento térmico, o consumo de bateria e a pressão de armazenamento são custos reais (se difíceis de precificar em dólares) que valem a pena pesar separadamente. As inferências residuais apenas de nuvem e de fallback de nuvem são resumidas em um conta de nuvem híbrida, então o custo único de configuração no dispositivo (engenharia, quantização, envio) é dividido pela janela de amortização escolhida e adicionado por cima para obter o custo mensal total híbrido. Comparar isso com a linha de base da nuvem pura fornece a economia mensal e a porcentagem de economia, enquanto divide o custo de configuração pelo mensal gastos na nuvem que ele desvia (nuvem pura menos conta de nuvem híbrida, ignorando a amortização) fornece o autônomo ponto de equilíbrio em meses — a rapidez com que a construção única se paga apenas com a economia na nuvem.
Perguntas frequentes
Por que a inferência no dispositivo tem um custo único em vez de um custo por inferência, como as APIs em nuvem?
Porque a parte cara da inferência no dispositivo é construí-la, e não executá-la. Quantizar um modelo até um tamanho que caiba em um telefone, convertê-lo para Core ML ou formato TensorFlow Lite/NNAPI, testá-lo em camadas de dispositivos e enviá-lo dentro do binário do aplicativo ou como um ativo para download é um projeto de engenharia fixo com um preço fixo, pago uma vez, independentemente de um usuário ou dez milhões de usuários acabarem executando-o. Em vez disso, uma API em nuvem cobra por solicitação porque o tempo de GPU do provedor é um custo marginal real em cada chamada. Depois que o modelo no dispositivo é quantizado e enviado, executar mais uma inferência no próprio telefone do usuário custa ao proprietário do aplicativo essencialmente nada além de uma fatia da bateria e da computação do usuário - sem servidor, sem conta por chamada - que é exatamente o que transforma o custo único de configuração em algo que vale a pena amortizar ao longo de meses, em vez de contabilizar como despesa por chamada.
O que acontece se minha porcentagem de capacidade no dispositivo for baixa – o dispositivo deixa de valer a pena?
Sim, e esta calculadora foi construída para mostrar exatamente onde está essa linha. À medida que a porcentagem de capacidade no dispositivo cai, mais usuários da sua base voltam para o segmento somente de nuvem, de modo que a conta mensal residual da nuvem sobe de volta para a linha de base da nuvem pura enquanto você ainda paga para amortizar o custo de configuração. A outra alavanca que importa tanto é o volume total de inferência: o mesmo custo de configuração que se paga em menos de um mês para 100.000 usuários ativos mensais pode levar muitos meses, ou efetivamente nunca atingir o equilíbrio durante a vida útil de um produto, para alguns milhares de usuários, porque simplesmente não há inferências suficientes sendo desviadas da conta da nuvem para recuperar o custo de construção. Antes de comprometer o orçamento de engenharia para uma construção no dispositivo, vale a pena conectar seu MAU real e sua melhor estimativa real da capacidade do dispositivo, em vez de assumir que a economia diminuirá linearmente.
Por que ainda existe uma conta de nuvem mesmo para usuários que executam no dispositivo?
Porque a capacidade no dispositivo nunca é tudo ou nada na prática. Mesmo em um telefone que é totalmente capaz de executar o modelo local, uma fração das consultas ainda precisa ir para a nuvem: uma consulta muito complexa ou muito fora do escopo do modelo local para que uma versão compactada no dispositivo seja bem tratada, uma situação de bateria fraca ou de aceleração térmica em que o sistema operacional restringe a computação no dispositivo, uma janela de inicialização a frio antes que o ativo do modelo local termine de baixar após a instalação ou atualização ou simplesmente uma inferência local que retorna com baixa confiança e precisa de um modelo de nuvem para verifique novamente. Esta calculadora modela isso como uma porcentagem de fallback na nuvem aplicada apenas às consultas dos usuários com capacidade no dispositivo, além da conta total da nuvem ainda devida pelos usuários cujos dispositivos não podem executar inferência no dispositivo - portanto, o item de linha de nuvem residual no total híbrido nunca é zero, mesmo em taxas de capacidade do dispositivo muito altas.
Como isso difere da calculadora LLM vs API auto-hospedada já existente neste site?
Tanto o Self-Host vs API Calculator quanto o Self-Hosted LLM vs API Calculator já estão neste modelo de site de auto-hospedagem no lado do servidor: alugar sua própria instância de GPU ou caixa de nuvem e executar inferência lá você mesmo, em comparação com o pagamento de um provedor de nuvem por token ou por chamada - a forma de custo em ambos os casos ainda é um servidor em algum lugar com uma conta de hospedagem, apenas sua em vez de um fornecedor. Esta calculadora modela algo estruturalmente diferente: inferência no dispositivo do lado do cliente executada diretamente no hardware telefônico do próprio usuário final, onde não há servidor para alugar e o custo marginal por inferência é efetivamente zero quando o modelo é enviado. O que substitui a conta de hospedagem aqui é um custo único de engenharia para construir e quantizar o modelo, amortizado ao longo de meses, além de um limite máximo para quanto gasto na nuvem você pode realmente desviar – definido pela fração de seus usuários que possuem dispositivos com capacidade suficiente e com que frequência até mesmo esses dispositivos ainda precisam voltar para a nuvem.