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.
Lendo os números
Nos padrões – 100.000 usuários ativos mensais, 50 inferências por usuário por dia, US$ 0,001 por inferência na nuvem, uma construção única no dispositivo de US$ 40.000, 60% dos usuários em dispositivos capazes, uma taxa de fallback de nuvem de 5% para esses usuários capazes, amortizada em 12 meses — a linha de base da nuvem pura custa US$ 150.000/mês. A adoção do híbrido reduz a conta residual da nuvem para US$ 64.500/mês (60.000.000 inferências de usuários somente na nuvem mais 4.500.000 inferências substitutas de usuários capacitados), acrescenta cerca de US$ 3.333/mês em custo de configuração amortizado e chega a um total híbrido próximo de US$ 67.833/mês – uma economia de cerca de US$ 82.167/mês, ou aproximadamente 55% de desconto na linha de base da nuvem pura. O custo de configuração de US$ 40.000 atinge o equilíbrio em menos de meio mês neste volume, porque o gasto mensal com nuvem que ele desvia (cerca de US$ 85.500/mês) supera o custo único de construção quase imediatamente. Essa matemática muda rapidamente em escala menor: execute as mesmas entradas em 5.000 usuários em vez de 100.000 e o ponto de equilíbrio se estende por cerca de 20 vezes mais – cerca de 9,4 meses em vez de menos de meio mês – porque simplesmente não há inferências desviadas suficientes por mês para recuperar rapidamente o custo de construção. Conecte o MAU real do seu aplicativo, não um aspiracional, antes de comprometer o orçamento de engenharia para uma construção no dispositivo.
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 usuário por dia × usuários ativos mensais × 30, com preço de acordo com sua taxa de nuvem por inferência — isso é o que você pagaria sem nenhum modelo no dispositivo. Em seguida, ele divide sua base de usuários 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 geralmente executam 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 for 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, remessa) é dividido pela janela de amortização escolhida e adicionado ao topo 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.