Inferência de IA distribuída: o que líderes de provedores de serviços de telecomunicações devem saber

Todos os provedores de serviços de telecomunicações estão operacionalizando a IA no momento. Os casos de uso incluem bots de atendimento ao cliente, copilotos de operação de rede e IA como serviço (AIaaS) gerenciada para clientes empresariais externos e outros. 

A parte desconfortável é a correlação do caso de uso com o caso de negócios, em que o fator principal é o custo do acelerador de IA, seja uma unidade de processamento gráfico (GPU), unidade de processamento de tensor (TPU) ou unidade de processamento neural (NPU). O custo por inferência decide se esses aceleradores de IA aumentam ou reduzem as margens de lucro. Para manter os custos baixos, o modelo de IA escolhido é tão importante quanto a forma como você o implanta e o disponibiliza em uma escala geográfica distribuída.

Em um artigo recente, especialistas da Red Hat trabalharam em desafios da implantação de inferência como um problema de arquitetura moldado pelo tráfego e pela escala, e não apenas pelo tamanho do modelo. Este post resume essas descobertas.

Como o custo por inferência afeta lucros e perdas

Cada solicitação de IA tem duas tarefas distintas no mesmo hardware: 

• Primeiro, ele lê o prompt/entrada, seja um histórico de cobranças, um ticket de problema, um log de rede ou qualquer outra coisa que precise ser processada. 
• Em seguida, ele gera a resposta para essa entrada, um token por vez.

A fase de leitura decide quanto tempo o usuário espera pela primeira palavra; a fase de escrita decide se a conversa parece fluida ou se tem interrupções frequentes. As duas fases precisam de perfis de recursos e otimizações diferentes e, quando compartilham os recursos do acelerador de IA, elas competem.

Essa tensão afeta os lucros e as perdas de maneira distinta em diferentes casos de uso de IA e tipos de carga de trabalho. Por exemplo, com os chatbots de atendimento ao cliente, o custo do atendimento por contato aumenta quando os bots param e as sessões são escalonadas para os agentes. As ofertas de IA empresarial acumulam penalidades de contrato de nível de serviço (SLA) quando não cumprem os compromissos de latência. E a margem em produtos de IA business-to-business (B2B) diminui quando o custo por consulta excede o preço definido no contrato. 

A maioria dos erros de implantação são erros de compensação e surgem quando uma equipe otimiza uma métrica que seu produto não vende. Analisar algumas maneiras específicas pelas quais a IA gera receita pode ilustrar a implantação adequada para cada tipo de carga de trabalho.

Atendimento ao cliente

O atendimento ao cliente é o caso mais claro. O tráfego de atendimento consiste em milhares de sessões de chat curtas e simultâneas que reutilizam o mesmo preâmbulo de tarifa e política em todas as chamadas. Os especialistas da Red Hat identificaram o seguinte nos benchmarks do vLLM da Red Hat:

• Dividir e dimensionar corretamente os pools de leitura e gravação reduz os custos em 25% a 40% nesse formato de tráfego.
• O roteamento com reconhecimento de cache, a abordagem de agendamento implementada pelo projeto open source llm-d, entregou de duas a três vezes mais tokens por GPU e um custo de três a cinco vezes menor por token onde a reutilização de prompts é alta.

Os sistemas de produção não terão esse nível de melhoria, mas a tendência se manteve em todas as cargas de trabalho medidas. Com dezenas de milhões de interações de atendimento por mês, reduzir os custos de inferência em até mesmo alguns pontos pode economizar o suficiente para pagar pelo próximo ciclo da solução sem novas despesas de capital (CapEx) com o acelerador.

Operações de rede

As operações de rede têm o formato oposto: há poucos usuários e os documentos processados são muito longos. A análise de incidentes relê constantemente os mesmos runbooks, registros de topologia e manuais de fornecedores. Assim, o principal fator de custo é o armazenamento em cache do que já foi processado. O resultado é um diagnóstico mais rápido e menos escalações para os engenheiros seniores.

IA gerenciada vendida para empresas

A venda de IA para clientes empresariais adiciona um terceiro formato: muitos clientes, SLAs em camadas e demanda intermitente. Dois mecanismos podem proteger a margem nesses cenários:

• O modelo em cascata envia consultas de rotina a um modelo pequeno e escala apenas as difíceis, reduzindo os custos do cluster em 40% a 60% onde as consultas fáceis dominam.
• O controle de admissões vinculado a objetivos de nível de serviço (SLOs) rejeita solicitações que violariam um SLA em vez de enfileirá-las até a falha, protegendo a credibilidade do contrato sob carga.

Conforme mostrado na Tabela 1, esses três casos de uso juntos podem servir de modelo para as camadas de preços gold, silver e bronze, em vez de forçar os clientes a apostarem em um pool compartilhado de aceleradores de IA. No entanto, duas restrições adicionais complementam o cenário para os provedores de serviços e ilustram como os serviços de IA podem ser personalizados para clientes específicos. 

IA soberana com capacidade de cloudbursting

As regras de soberania exigem que os dados dos assinantes permaneçam em seu país de origem. O padrão que melhor atende a essa necessidade é uma linha de base on-premise regulamentada com cloudbursting que se mantém inativa entre os picos. Um único plano de controle como o Red Hat OpenShift AI mantém os dois ambientes alinhados para que a conformidade não dependa apenas da disciplina de configuração.

Edge computing

Ao considerar a edge da rede, com cerca de 100 sessões simultâneas ou menos, a resposta certa é um modelo por acelerador sem pooling inteligente.  As consultas difíceis devem ser encaminhadas via backhaul para que os gastos com transporte acompanhem a complexidade, e não o volume.

Tabela 1. Como os tipos de carga de trabalho geram resultados de negócios tangíveis

Estas são as perguntas que os provedores precisam fazer ao considerar cada um desses casos de uso:

• Atendimento ao cliente: Quanto custa hoje uma conversa de atendimento totalmente automatizada e qual mudança isolada mais afeta esse número? Uma boa resposta cita o custo por contato contido medido no tráfego em tempo real, com uma alavanca testada e seus números de antes e depois.
• Operações de rede: Quanto tempo um engenheiro espera por uma resposta útil dos registros de incidentes e os mesmos documentos são reprocessados todas às vezes? Uma boa resposta mostra com que frequência runbooks e registros do site são fornecidos pelo cache em vez de relidos, além da tendência no tempo para a primeira resposta.
• Serviços B2B: Qual SLA empresarial é interrompido primeiro sob carga de pico e a correção é mais hardware ou melhor roteamento? Uma boa resposta identifica a camada de falha em um teste de carga e mostra que uma correção de roteamento ou admissão foi tentada antes de uma solicitação de compra.
• Soberania e picos: Quanta capacidade fica ociosa entre eventos de pico apenas para atender às regras de residência de dados? Uma boa resposta relata o uso da linha de base e um design de burst que não gera custos enquanto espera.
• Edge e campo: Qual parcela das consultas de campo retorna a um cluster central e quanto custa esse transporte? Uma boa resposta fornece a taxa de resolução local por site, com o escalonamento reservado para consultas que o modelo local não consegue processar.

Trajetória de investimento

Após estabelecer um caso de uso de IA, a próxima etapa é criá-lo de maneira eficiente e econômica. A sequência é mais importante do que o destino. Cada estágio é acionado por uma medição, não por uma data do roadmap, e cada um se paga antes do início do próximo:

1. Comece com um nó: execute uma única instância de serviço em tráfego real de atendimento ou rede por uma semana. Essa linha de base é a medida para todas as decisões posteriores; o tráfego sintético de laboratório será enganoso.
2. Adicione roteamento inteligente: uma segunda réplica oferece menos de 1,8 vez a taxa de transferência de uma. Essa lacuna significa que as solicitações estão chegando a servidores que devem reler o contexto que outro servidor já possui. Trata-se de desperdício de roteamento, não de falta de capacidade. Portanto, corrija-o antes de comprar hardware.
3. Separe os pools de leitura e gravação: faça isso somente quando as medições mostrarem que uma fase prejudica a outra o suficiente para justificar a complexidade operacional adicional.
4. Adote o grid multitenant: quando várias aplicações e clientes B2B compartilham a plataforma, os mecanismos que protegem SLAs em camadas justificam sua complexidade. Abaixo dessa escala, eles são um desperdício de esforço.

Cada etapa redefine a linha de base. A estratégia de inferência de IA é uma série de apostas medidas, não uma aprovação única de arquitetura. Os provedores de serviços já utilizam esse playbook com o espectro sem fio: aloque capacidade para os produtos com retorno sobre o investimento (ROI), meça continuamente e recupere o que estiver ocioso. Os aceleradores de IA merecem a mesma disciplina.

Conclusão

A inferência de IA distribuída decide se os produtos de IA do provedor de serviços mantêm sua margem. Nada do que foi descrito neste post exige um compromisso orçamentário arriscado: cada mecanismo é uma etapa medida que se comprova no tráfego do provedor de serviços antes do início da próxima, e a Tabela 1 mostra onde procurar primeiro.

Quando você estiver pronto para trabalhar nisso em seu portfólio de atendimento, rede ou B2B, leve seus dados de tráfego para sua Red Hat account team. vLLM, llm-d e Red Hat OpenShift AI são como executamos esse padrão com provedores de serviços hoje, e a conversa flui melhor quando começa pelas suas necessidades, não por um modelo genérico.