Enquanto algumas organizações ainda estão a iniciar as suas estratégias de IA, outras estão num purgatório piloto, com poucas experiências ou provas de conceito (POCs) a chegar à produção. Apenas 25% das organizações transferiram 40% ou mais das suas experiências de IA para produção, de acordo com o The State of AI in the Enterprise.
Discutimos a entrega de provas de conceito de IA importantes em um recente Coffee With Digital Trailblazers no LinkedIn Live. Um dos principais motivos pelos quais os POCs tropeçam é quando eles não se alinham bem com a estratégia de negócios de IA ou não têm resultados de negócios definidos. Dois outros problemas: não existe um programa suficiente de gestão de mudanças de IA ou os funcionários não estão envolvidos no processo de desenvolvimento.
Mas há também um problema tecnológico significativo: a arquitetura usada para treinar modelos de IA e desenvolver agentes de IA pode ser muito diferente daquela usada para inferência de IA, executando um modelo treinado para gerar resultados na produção. O treinamento e a inferência têm requisitos de desempenho, escalabilidade, conformidade e segurança muito diferentes, e é errado presumir que a inferência de IA é uma versão ampliada ou reduzida da arquitetura de treinamento.
“O foco da indústria está mudando rapidamente do treinamento de modelos de fronteira para a otimização da inferência de IA em ambientes de produção”, afirma Pascal Jaillon, vice-presidente sênior de produto da OVHcloud EUA. “As empresas estão percebendo que o sucesso da IA a longo prazo depende menos do tamanho bruto do modelo e mais do equilíbrio entre latência, escalabilidade, segurança e economia de infraestrutura em ambientes distribuídos. À medida que as cargas de trabalho de inferência aumentam, as organizações avaliam cada vez mais alternativas às estratégias tradicionais apenas de hiperescala para melhorar a eficiência de custos, a soberania dos dados e a flexibilidade operacional.”
A otimização do ambiente de inferência de IA também deve levar em conta as condições operacionais, os requisitos de conformidade e as compensações de custos. Rick Ross, distinto tecnólogo da EY, afirma: “Para os CIOs, a inferência localizada é uma escolha arquitetônica deliberada reservada para aplicações sensíveis à latência, como robótica, ou onde a regulamentação exige”.
Esperar por um experimento de IA ou POC bem-sucedido antes de considerar sua arquitetura de inferência pode ser um erro. Isso pode gerar retrabalho inesperado ou adicionar complexidades que exijam a reinicialização do processo de desenvolvimento. Aqui estão cinco práticas recomendadas para desenvolver arquitetura, infraestrutura e operações eficazes de inferência de IA.
1. Arquiteto para integração e desempenho
As arquiteturas de treinamento são projetadas para requisitos de dados flexíveis e de rendimento, enquanto a inferência requer baixa latência, alta confiabilidade e operação autônoma. Os ambientes de inferência para agentes de IA também devem considerar como os fluxos de trabalho serão orquestrados com servidores Model Context Protocol (MCP) e integrações de agente para agente (A2A).
“As equipes de TI devem primeiro modernizar as camadas de integração e orquestração, garantindo que possam oferecer suporte a interfaces orientadas a eventos, de baixa latência e de alta confiabilidade antes que os sistemas de IA sejam implantados em escala”, disse Riki Efraim-Lederman, presidente da divisão Amdocs Studios da Amdocs. “Muitos ambientes legados parecem funcionais porque os humanos estão compensando as lacunas nos bastidores, mas quando os sistemas de IA começam a agir de forma autônoma, essa rede de segurança desaparece e essas fraquezas surgem rapidamente.”
À medida que as organizações implantam mais agentes de IA e o uso aumenta, as equipes Devops devem considerar os requisitos de latência para diferentes casos de uso e requisitos de desempenho de pico de carga.
“As equipes de TI subestimam a rapidez com que a complexidade aumenta devido ao tráfego de picos imprevisíveis, pipelines de dados confidenciais e agentes de IA executados em APIs e cadeias de ferramentas opacas”, diz Sridhar Iyer, diretor sênior de IA/ML da Versa. “A inferência de IA requer cada vez mais uma arquitetura distribuída, transferindo cargas de trabalho dinamicamente entre nuvem, local e locais de borda com base na latência, soberania e custo.”
Os ambientes de treinamento geralmente exigem flexibilidade para acessar diversas fontes de dados em grande escala para testar e otimizar modelos de IA. Isso contrasta com os ambientes de inferência, que geralmente se conectam a menos fontes de dados em tempo de execução e onde a disponibilidade e a latência são considerações importantes de design.
“A inferência na borda ou em ambientes distribuídos só funciona quando o banco de dados corresponde a essa arquitetura: local, consistente e altamente disponível”, afirma Phillip Merrick, CEO e cofundador da pgEdge. “As equipes de TI tendem a tratar a decisão sobre infraestrutura e a decisão sobre dados como fluxos de trabalho separados, mas não são, e são a mesma decisão.”
2. Proteja os dados e ações da IA
Em ambientes de treinamento, a TI pode proteger o acesso externo, mascarar dados confidenciais e limitar ações a ambientes de teste. É necessária uma estratégia segura desde a concepção para ambientes de inferência onde os agentes de IA acedem a dados em tempo real, automatizam ações em plataformas SaaS de produção e exigem avaliações de segurança dinâmicas em torno das autoridades de tomada de decisão.
“A inferência é o momento em que um modelo passa da experimentação para operações ao vivo, abordando dados reais, serviços reais e fluxos de trabalho de negócios reais”, diz Gal Ordo, cofundadora e CPO da Native. “Nesse ponto, as questões críticas são o que o modelo pode acessar, quais ações ele pode desencadear e quais condições devem sempre ser mantidas enquanto estiver em execução. Torne os limites explícitos desde o início, para que a inferência opere dentro de um ambiente controlado e determinístico.”
Como as decisões da IA não são determinísticas, a observabilidade, a auditoria e o monitoramento são essenciais para evitar agentes invasores, sinalizar desvios de modelo e alertar antecipadamente sobre padrões de uso inesperados.
“Os departamentos de TI precisam tratar a inferência de IA como outra carga de trabalho com identidade, dados e características de custo incomuns”, diz Mike Toole, diretor de segurança e TI da Blumira. “É fundamental escolher onde ele será executado com base na sensibilidade do que está acontecendo no prompt e aplicar os mesmos controles de acesso, registro e revisão que você aplicaria a qualquer SaaS que envolva dados de produção.”
3. Requisitos separados de treinamento e inferência
Os ambientes de treinamento podem exigir chips GPU e outras arquiteturas de alto desempenho. Para inferência, a infraestrutura precisa se concentrar na conformidade, na latência, no custo e em outros requisitos não funcionais. Os diferentes requisitos resultam frequentemente em infra-estruturas distintas.
“À medida que a computação se torna mais distribuída, a CPU é um componente crítico nas cargas de trabalho de inferência e, com a explosão dos agentes, a computação é onde eles vivem”, diz Michael Reid, CEO da Megaport. “Ao mesmo tempo, a inferência atua como um multiplicador de tráfego norte-sul, aumentando significativamente as demandas de transferência de dados e colocando maior pressão sobre a capacidade da rede. A otimização total para inferência de IA requer, portanto, um ambiente unificado onde a computação, a rede e o armazenamento trabalhem em sincronia.”
Os sistemas Web otimizaram o desempenho incluindo uma camada de cache. Nas arquiteturas de inferência de IA, o cache também reduz a computação redundante e o custo de GPU associado,
“Cada solicitação que reprocessa as mesmas entradas do zero queima ciclos de GPU com custo total”, diz Junchen Jiang, cofundador e CEO da Tensormesh. “O cache de valor-chave elimina essa redundância, reduzindo drasticamente a latência e os gastos com GPU. As equipes de TI que incorporam o cache em sua arquitetura de inferência desde o início serão capazes de escalar sem as contas descontroladas de infraestrutura.”
As grandes empresas terão de considerar a infraestrutura híbrida com base nos requisitos de conformidade e desempenho. Por exemplo, os agentes e aplicações de IA que envolvem a segurança humana precisarão avaliar a infraestrutura de ponta e no local, enquanto as operações de back-office poderão ser executadas inteiramente em nuvens públicas.
“O maior erro que as empresas cometem com a inferência de IA é tratá-la como uma decisão de modelo, quando na verdade é uma decisão de modelo operacional”, diz Andrea Malagodi, CIO da Sonar. “O local onde a inferência é executada, seja na nuvem, no local ou na borda, afeta diretamente a latência, o custo, a exposição dos dados e a resiliência.”
4. Projete operações flexíveis e resilientes
As arquiteturas de inferência não são construídas uma vez e depois ampliadas e reduzidas, como acontece com os aplicativos da Web. Os arquitetos devem planejar modelos, infraestrutura, segurança e gerenciamento de dados para todas as mudanças à medida que a tecnologia, a conformidade e os preços evoluem.
“A inferência de IA está se tornando rapidamente uma carga de trabalho central de produção que exige operações consistentes e automatizadas em ambientes de nuvem híbrida e uma clara cadeia de confiança desde o modelo até a implantação”, afirma Tushar Katarki, chefe de produto, Gen AI Foundation Model Platforms da Red Hat. “O código aberto e os padrões abertos são essenciais aqui; eles dão às empresas a transparência para proteger sua pilha de IA e a flexibilidade para executar inferências onde quer que seus negócios exijam.”
Uma fonte de mudança são as capacidades, o desempenho e os custos do modelo de IA. Ayaz Ahmed Khan, diretor sênior de engenharia da Cloudways, afirma: “Os modelos estão melhorando em velocidades vertiginosas e, assim que o modelo é alterado, os prompts e as proteções devem ser minuciosamente avaliados, revisados e modificados”.
Outra preocupação é rastrear o uso e as interações com plataformas SaaS, fontes de dados e outros agentes de IA. Shannon Weyrick, CTO e cofundador do NetBox Labs, afirma: “As equipes de TI devem encaminhar o tráfego de IA através de um único ponto de controle que forneça visibilidade sobre quais modelos estão em uso, quais dados estão saindo da organização e como os custos estão se acumulando, porque você não pode proteger ou gerenciar o que não pode ver”.
Matt Waxman, diretor de produtos da Precisely, diz que o desafio mais subestimado na inferência de IA empresarial não é o modelo, mas os dados por trás dele. “Os prompts e pipelines de recuperação são extraídos de dezenas de fontes com semântica inconsistente, linhagem ausente e nenhuma camada de governança, e o modelo não tem como saber. Em um mundo agente, onde os sistemas de IA agem de forma autônoma e em escala, essa base se torna ainda mais crítica”, diz Waxman.
David Mytton, CEO e fundador da Arcjet, compartilha um problema prático que sua empresa encontrou com a inferência de produção. “Cada modelo deseja se tornar sua própria API com diferentes formatos de solicitação, verificações de integridade, metadados, comportamento de prontidão, formatos de erro e campos de resposta. Isso não é escalonável quando você tem vários modelos ou back-ends”, diz Mytton. A Arcjet construiu uma abstração usando o Open Inference Protocol em cima de seus modelos de segurança de IA para fornecer serviços de inferência com um formato padronizado para atividade, prontidão, metadados, rotas de modelo versionadas e entradas e saídas de estilo tensor.
5. Otimize os custos e mude os modelos de IA
As organizações que passam de dezenas para milhares de agentes de IA precisarão avançar em seus programas de finops para levar em conta como a seleção e a otimização do modelo de IA afetam os custos.
“À medida que as equipes passam de protótipos de agente único para pipelines multiagentes, os custos de inferência não crescem apenas linearmente. Um sistema multiagente pode queimar 15 vezes mais tokens do que uma única interação por chat”, diz Andrew Marshall, vice-presidente de marketing de produto da Yugabyte. “Esse multiplicador é um problema de dados, não um problema de modelo, baseado em quanto contexto é passado entre os agentes, quanto é recuperado de forma redundante e quanto estado precisa ser reconstruído do zero em cada chamada.”
Além de alterar os modelos de IA, os arquitetos devem considerar que os modelos de fronteira usados durante o treinamento podem ajudar a desenvolver modelos menores e mais eficientes que serão então usados para inferência.
Jason Rolles, CEO e diretor administrativo da BlueOptima, afirma: “Os LLMs estão evoluindo rapidamente para duas categorias amplas: modelos de fronteira em escala de nuvem, que provavelmente permanecerão reservados aos hiperescaladores, e modelos especializados menores e altamente destilados, implantados na borda da empresa”. Isto dá às empresas a opção de encaminhar tarefas de baixo nível e baixa ambiguidade para modelos mais pequenos, ao mesmo tempo que utilizam modelos de fronteira para decisões que exigem raciocínio e precisão, poupando custos globais.
Andrew Filev, CEO e fundador da Zencoder, diz: “Depois que os agentes se tornaram úteis, o uso aumentou 10 vezes, os contextos aumentaram e as empresas começaram a pagar preços de modelo de fronteira em cada token. Muitos agora gastam os orçamentos anuais de IA em meses, e a maior parte desses gastos vem da execução de um modelo principal em cada etapa, incluindo tarefas simples”.
Para aumentar o número de modelos e agentes de IA de produção, as empresas precisarão de um plano sólido para construir arquiteturas de inferência resilientes e escaláveis. Mas à medida que o uso, a conformidade, a tecnologia e os preços mudam, planeje reavaliar e evoluir a arquitetura.
