Cloud revenue and earnings for the three major cloud service providers (CSPs)—Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP)—surpassed high expectations in the first quarter of 2024, driven by strong demand for AI generativa (Genai). Coletivamente, eles geraram US $ 53,7 bilhões em receita, com um aumento seqüencial trimestral de US $ 2,6 bilhões. O Azure liderou o pacote com 31,1% de crescimento de receita ano a ano. O GCP também teve um desempenho excepcionalmente bem, com a receita aumentando 28,4% ano a ano. Segundo o Gartner, os gastos gerais em nuvem deverão representar 58% dos gastos com 2027, crescendo a 18% CAGR.
About the Series
As cloud spending grows, BCG is keeping an eye on recent pricing changes using our Índice de Preços Nimbus (NPI). O NPI, que reflete os preços médios em dólares americanos convertidos em moeda constante nos três principais CSPs, viu uma pequena diminuição de 0,4% desde a última parcela de nosso Tampa de nuvens Relatório em novembro de 2023. A diminuição teria sido maior, mas o GCP realmente aumentou os preços em 0,9%, em média, impulsionado por novos locais de alto custo. A AWS conseguiu reduzir os preços, em parte, omitindo alguns serviços de computação na cidade de alto custo da Cidade do Cabo. (Consulte o Anexo 1.) As taxas de armazenamento e rede permaneceram consistentes. Globalmente, os ajustes de preços do Azure resultaram em pequenas alterações em cada região. As mudanças mais dramáticas ocorreram em Osaka (+US $ 128), Abu Dhabi (+US $ 31), Cidade do Cabo (+US $ 30), Mumbai ( - US $ 50) e São Paulo ( - US $ 105). Mesmo com o aumento substancial da taxa de Osaka, o Azure ainda oferece as taxas mais baixas nessa cidade. Além disso, seu preço competitivo em Tóquio significa que o Azure é o CSP mais acessível do Japão. (Veja o Anexo 2.) Azure adicionou dois locais (Tel Aviv, Varsóvia); A AWS também adicionou dois (Tel Aviv, Calgary); Enquanto o GCP adicionou quatro locais (Berlim, Dammam na Arábia Saudita, Doha e Carolina do Sul). Um pouco menos que o Azure e US $ 147/ano a menos que a AWS. Enquanto isso, a AWS é o primeiro provedor em Calgary, embora sua taxa de US $ 1.671/ano seja caro, mesmo acima de sua taxa de Toronto. No geral, as taxas canadenses da AWS são as mais altas entre os fornecedores. O GCP também estreou em Doha com uma taxa de US $ 1.723/ano, que é US $ 150/ano a menos que o Azure, o outro fornecedor da região. Além disso, na primeira metade do GCP adicionou Berlim, mais uma vez em competição com o Azure, mas com taxas menos competitivas a US $ 124/ano acima do Azure. Finalmente, o GCP se tornou o primeiro provedor com três hubs nos EUA, acrescentando a Carolina do Sul à Virgínia e Ohio.
Azure was the only CSP that changed rates in existing locations in the first half of 2024, driven by adjustments in compute rates. (See Exhibit 1.) Storage and network rates remained consistent. Globally, Azure’s pricing adjustments resulted in mostly small changes in each region. The most dramatic swings occurred in Osaka (+$128), Abu Dhabi (+$31), Cape Town (+$30), Mumbai (–$50), and São Paulo (–$105). Even with the substantial Osaka rate increase, Azure still offers the lowest rates in that city. Moreover, its competitive pricing in Tokyo means Azure is the most affordable CSP in Japan.
Providers Add Locations
While AWS, Azure, and GCP all added locations in the first half of 2024, there were notable differences in the expansion strategies. (See Exhibit 2.) Azure added two locations (Tel Aviv, Warsaw); AWS also added two (Tel Aviv, Calgary); while GCP added four locations (Berlin, Dammam in Saudi Arabia, Doha, and South Carolina).
With the addition of Tel Aviv by AWS and Azure, GCP is no longer the only provider in that city—although GCP rates remain the lowest ($1,575/year), slightly less than Azure, and $147/year less than AWS. Meanwhile, AWS is the first provider in Calgary, though its rate of $1,671/year is pricy, even above its Toronto rate. Overall, AWS’s Canadian rates are the highest among the providers.
Meanwhile, GCP’s addition of Dammam gives it the first location in Saudi Arabia, though on the expensive end of the spectrum ($2,222/year)—similar in cost to Brazil and South Africa. GCP also debuted in Doha with a rate of $1,723/year, which is $150/year less than Azure, the other provider in the region. Also, in the first half GCP added Berlin, once again in competition with Azure, but with less competitive rates at $124/year higher than Azure. Finally, GCP became the first provider with three hubs in the US, adding South Carolina to Virginia and Ohio.
Serviços sem servidor
Como a introdução do serviço da AWS Lambda em 2015, o servidor sem servidor ganhou impulso no Computação em nuvem Espaço e pode, em última análise, revolucionar como a indústria desenvolve arquiteturas de TI de última geração. (Veja o Apêndice 1 para diferentes níveis de infraestrutura gerenciada.)
com sem servidor, Equipes do DevOps Pode criar e executar aplicativos e serviços sem pensar nos servidores executando o código. Eles podem se concentrar em melhorar os procedimentos de código, processos e atualizações, em vez de provisionar, dimensionar e manter servidores. As funções do AWS Lambda, Azure Funções e Google Cloud são algumas das ofertas mais populares no mercado em nuvem sem servidor. (Consulte o Anexo 3.)
Preço sem servidor
A desvantagem dos parâmetros de servidores é que, em contraste com o modelo tradicional de preços virtuais, o preço de um determinado conjunto de parâmetros é frequentemente inconsistente. (Consulte o Apêndice 2 para obter diferenças de preços e apêndice 3 para preços no nível da cidade.) O Azure é o único jogador no mercado que mostra preços consistentes por unidade em todas as regiões, algo que as equipes de engenharia apreciam, pois podem executar suas aplicações nas funções do Azure sem se preocupar muito com a região mais econômica. (Consulte o Anexo 4.)
Se compararmos o preço dos três fornecedores, atualmente o Azure é a opção mais barata entre as regiões, seguida por AWS e depois GCP. Na maioria das regiões, a AWS é de 4% a 9% mais cara, enquanto o GCP é de 20% a 60% mais caro. Apesar dos preços premium do GCP - os custos de computação sem servidor de segunda geração são quase o dobro em algumas regiões -, oferece a atribuição mais generosa de solicitações mensais gratuitas. Eventualmente, esse recurso pode tornar o GCP uma alternativa mais economicamente viável para aplicações com solicitações de volume mais leves. Por exemplo, uma função AWS Lambda define quanto “recursos de computação” a função recebe uma vez acionada (medida em MB de memória). O custo de uma função varia com base nos recursos de computação alocados e no número de milissegundos necessários para executar. Portanto, para otimizar o custo de uma função, a empresa deve buscar alocações menores de recursos de computador e tempo de execução mais curto. (Consulte Anexo 5.)
Pricing Optimization
While most billing charges are based on service consumption, some services require that customers choose configuration parameters that partially determine the amount billed, which creates an opportunity for customers to optimize these parameters. For example, an AWS Lambda function defines how much “computing resources” the function receives once triggered (measured in MB of memory). The cost of a function varies based on the allocated computing resources and the number of milliseconds it takes to execute. So, to optimize a function’s cost, the company should aim for smaller computer resource allocations and shorter execution time. (See Exhibit 5.)
Além da memória, a AWS aloca mais CPU a alocações de energia maiores, resultando em execução mais rápida da função. Determinar a configuração ideal de energia significa encontrar o ponto ideal entre a execução mais rápida e o menor custo. Por exemplo, como mostrado no Anexo 5, o tempo de execução passa de 35s com 128 MB para menos de 3s com 1,5 GB, sendo 14% mais barato para executar. Custo dos modelos Genai "Construção versus compra". (Consulte o Apêndice 4.) Os modelos de "compra" que analisamos estão prontos, sem a opção de adaptá-los. Neste relatório, nos aprofundamos na pergunta "compra" e exploramos os fatores de custo a serem considerados ao decidir se deve ou não ajustar um modelo genai.
Fine-Tuning Your GenAI Model
In our last Cloud Cover report, we outlined a framework to estimate the cost of “building versus buying” GenAI models. (See Appendix 4.) The “buy” models we looked at are ready-made, without the option to tailor them. In this report, we dive deeper into the “buy” question and explore the cost factors to consider when deciding whether or not to fine-tune a GenAI model.
Ajuste fino geralmente envolve modelos pré-treinados e um conjunto de dados personalizado. Modelos pré-treinados são modelos de uso amplo que foram treinados inicialmente em conjuntos de dados grandes e não marcados. Esses modelos são mais treinados ou "ajustados", em um conjunto de dados menor e mais específico relevante para a tarefa em questão. Através do ajuste fino, os modelos podem aprender as nuances de um campo ou conjunto de dados específico, resultando em melhores previsões, traduções ou outras saídas mais alinhadas com os requisitos da empresa.
Modelos personalizados vêm com algumas desvantagens. Eles são intensivos em recursos e consomem mais poder computacional do que os modelos genéricos. Os dados usados para ajuste fino podem às vezes introduzir ou perpetuar vieses, exigindo seleção e monitoramento cuidadosos para garantir a justiça e a relevância.
Custos de ajuste fino
O custo dos modelos Genai de ajuste fina depende principalmente do tamanho do conjunto de dados de treinamento em tokens e do número de iterações (ou épocas) necessárias para o treinamento. Normalmente, quanto mais épocas e, portanto, mais exposição aos dados, melhor o modelo se torna. Para casos de uso mais simples e menores, uma recomendação geral é treinar usando 5 a 10 épocas. (Consulte o Apêndice 5 para cenários de complexidade do modelo.) Uma vez construído, há um aumento exponencial nos recursos necessários para executar os modelos em todas as camadas de uso. Curiosamente, enquanto os custos de uso aumentam de pré-treinado para ajustado, a escala do aumento para modelos complexos é menos drástica (4,5x) em comparação com modelos simples (8x) e modelos médios (12x). (Consulte Anexo 6-8 Slideshow). Em maior volume, o modelo complexo pode ser mais econômico. Modelos complexos podem se tornar mais baratos para funcionar do que os modelos médios a altas taxas de uso. (Veja o Anexo 9.) Esses insights demonstram que o alinhamento da complexidade do modelo com o uso esperado é extremamente importante para otimizar o desempenho e os custos. Ofertas, outros CSPs e evolução dos preços ao longo do tempo. Também conduziremos uma análise mais detalhada comparando a economia da implantação de máquinas VM versus funções sem servidor.
As model complexity escalates, so does the cost of fine-tuning—from a mere 0.032 million USD for a simple model, to 0.48 million USD for an average model, to 0.64 million USD for a complex model. (See Appendix 5 for model complexity scenarios.) Once built, there’s an exponential increase in the resources needed to run the models across all usage tiers. Interestingly, while usage costs escalate from pre-trained to fine-tuned, the scale of the increase for complex models is less drastic (4.5x) compared to simple models (8x) and average models (12x). (See Exhibits 6-8 slideshow).
Also worth noting is that while the simple model offers better efficiency at lower usage levels, at higher volume the complex model might be more economical. Complex models can become less expensive to run than average models at high usage rates. (See Exhibit 9.) These insights demonstrate that aligning model complexity with expected usage is extremely important to optimize performance and costs.
Please keep an eye out for the next issue of Cloud Cover, where we’ll continue to develop the NPI and address key questions on cloud services and pricing—including insights on specialist offerings, other CSPs, and price evolution over time. We will also be conducting a more detailed analysis comparing the economics of deploying VM machines versus serverless functions.
Apêndices 1-6
