Padrões de Inferência de IA
Como os recursos de IA e aprendizado de máquina são cada vez mais vistos como essenciais para impulsionar a inovação e a eficiência em empresas de todos os tamanhos, as organizações devem determinar a melhor forma de fornecer aos seus desenvolvedores de aplicativos acesso a esses recursos. Em muitos casos, um serviço de inferência de IA será usado, ou seja: “um serviço que invoca modelos de IA para produzir uma saída com base em uma entrada fornecida” (como prever uma classificação ou gerar texto), mais tipicamente em resposta a uma chamada de API de outro código de aplicativo.
Esses serviços de inferência podem ser criados e consumidos de diversas maneiras (mesmo dentro de uma única organização). Esses serviços podem ser desenvolvidos inteiramente internamente ou consumidos como um SaaS, aproveitar projetos de código aberto e usar modelos abertos ou comerciais. Eles podem vir como parte de uma “Plataforma de Aprendizado de Máquina” totalmente funcional que oferece suporte a esforços mais amplos de ciência de dados e criação de modelos, ou podem fornecer nada além de um ponto de extremidade de API para invocar os modelos. Eles podem ser executados em um data center privado, em uma nuvem pública, em uma instalação de colocation ou como uma mistura destes. Organizações maiores provavelmente dependerão de mais de uma única opção para inferência de IA (especialmente em níveis mais baixos de maturidade organizacional nesse espaço). Embora não exista uma abordagem única que funcione para todos, alguns padrões comuns estão surgindo.
Visão geral do padrão
Examinaremos três amplos padrões de consumo de inferência de IA, bem como seus vários pontos fortes e fracos:
- Inferência de IA como um SaaS – Os aplicativos se conectam a um provedor de serviços de inferência de IA externo dedicado.
- Inferência de IA gerenciada na nuvem – Os aplicativos se conectam a serviços de inferência de IA totalmente gerenciados em execução na nuvem pública.
- Inferência de IA autogerenciada – Os aplicativos consomem inferência de IA gerenciada pela própria organização, seja como parte de um serviço centralizado ou diretamente no nível do aplicativo.
Pontos de decisão principais
Ao avaliar as compensações entre os seguintes padrões operacionais, há alguns fatores importantes a serem considerados:
Considerações operacionais
- Escalabilidade – Quem é responsável por, e quão bem uma determinada opção se expande para cima e para baixo conforme as necessidades de capacidade mudam ao longo do tempo? Existem limites de escala ou tetos de capacidade?
- Custo – Serviços totalmente gerenciados podem parecer mais caros à primeira vista, mas considerar o custo total de propriedade (incluindo qualquer hardware especializado e equipe) pode tornar a decisão menos clara. Como os custos operacionais são dimensionados conforme a capacidade aumenta ou diminui; há limites mínimos para os custos?
- Manutenção / Suporte – Quem é responsável por manter o serviço de inferência? Sua organização precisará contratar funcionários ou pagar consultores com experiência nessa área, ou uma oferta de serviço gerenciado faria mais sentido?
Considerações sobre desenvolvimento
- Facilidade de integração da carga de trabalho – Com que rapidez o serviço de IA pode ser integrado às cargas de trabalho consumidoras? A oferta de serviço funciona com seu padrão de uso esperado (por exemplo, inferência offline/em lote) e ambientes operacionais?
- Agilidade – Com que rapidez o aplicativo geral pode ser adaptado às mudanças nos requisitos de negócios? Quais aspectos da arquitetura estão mais incorporados e seriam difíceis de mudar?
Considerações sobre desempenho
- Desempenho – A localização física do serviço (em relação aos consumidores do serviço) e a latência da inferência são importantes para seus casos de uso?
- Disponibilidade de hardware – Há algum requisito especial de hardware para o serviço e, em caso afirmativo, você tem capacidade para atender às demandas esperadas (aplicável a ambientes locais e na nuvem)?
Considerações sobre dados
- Vazamento de dados – Existe a preocupação de que dados confidenciais possam ser enviados ao serviço de inferência ou possam estar presentes no resultado da inferência? Se sim, o tráfego pode ser inspecionado e guarda-corpos podem ser aplicados?
- Governança de dados – Para onde geograficamente os dados do aplicativo são enviados (e como)? O controle direto permanece dentro da organização ou é enviado a terceiros? Existem regulamentações especiais ou políticas de conformidade que se aplicam à forma como você deve tratar os dados?
Padrão SaaS
As organizações podem optar por consumir serviços de um provedor de SaaS dedicado que se concentra em hospedar modelos de IA para inferência (como OpenAI ou Cohere). Nesse caso, as cargas de trabalho em execução na infraestrutura de uma organização (seja um data center privado, colocation ou nuvem pública) aproveitam as APIs publicadas pelo provedor de SaaS. Com esse padrão, o ônus associado à operação da infraestrutura necessária para hospedar os modelos recai inteiramente sobre o provedor de SaaS, e o tempo necessário para começar a operar pode ser muito breve. Esses benefícios, no entanto, têm um custo de controle, sendo esse padrão o menos “flexível” dos que abordaremos. Da mesma forma, o controle sobre dados confidenciais é normalmente menor com esse modelo, onde a internet pública é geralmente usada para se conectar ao serviço, e o fornecedor de SaaS externo tem menos probabilidade de conseguir lidar com preocupações rigorosas de conformidade regulatória.
Bem adequado para
- Tempo de lançamento no mercado: Prototipagem rápida, lançamentos de MVP.
- Organizações sem experiência/conhecimento interno significativo em inferência de IA.
- Aplicações sem necessidades significativas ou rigorosas de segurança/governança de dados.
Pontos fortes
- Curto tempo de lançamento no mercado: Um modelo operacional simples pode levar a tempos de integração curtos.
- Provedores de serviços focados estão bem equipados para lidar com desafios de dimensionamento de inferência.
- Não requer investimento em hardware ou pessoal especializado.
Desafios
- Preocupações com latência e conectividade em relação a serviços colocados junto com cargas de trabalho de aplicativos.
- Preocupações com privacidade, governança e segurança de dados dependem (ou podem ser incompatíveis com) um provedor de SaaS externo.
- O custo das despesas operacionais em escalas maiores pode ser maior do que em modelos de auto-hospedagem.
- Serviços de hospedagem de modelos personalizados e personalização de modelos podem não ser suportados.
Padrão gerenciado em nuvem
Nesse padrão, as organizações aproveitam serviços gerenciados fornecidos por provedores de nuvem pública (por exemplo, Azure OpenAI, Google Vertex, AWS Bedrock). Assim como no primeiro padrão, o ônus operacional para implantar, dimensionar e manter os modelos de IA recai sobre o Provedor de Nuvem e não sobre a organização consumidora. A principal diferença entre esse padrão e o padrão SaaS acima é que, neste caso, os pontos de extremidade da API de inferência são geralmente acessíveis por meio de redes privadas, e as cargas de trabalho do consumidor de IA podem ser colocadas junto com o serviço do Modelo de IA (por exemplo, mesma zona, região). Como resultado, os dados normalmente não transitam pela internet pública, a latência provavelmente será menor e os mecanismos para conexão a esses serviços são semelhantes aos de outros serviços gerenciados por provedores de nuvem (ou seja, contas de serviço, políticas de acesso, ACLs de rede). Organizações que aproveitam redes multinuvem podem obter alguns desses mesmos benefícios, mesmo em casos em que cargas de trabalho e serviços de inferência de IA são hospedados em nuvens diferentes.
Bem adequado para
- Organizações com investimentos existentes em nuvem pública.
- Aplicativos em execução ou conectados a outros serviços gerenciados na nuvem.
Pontos fortes
- Muitas organizações já estão familiarizadas com a conexão de suas cargas de trabalho a outros serviços gerenciados de provedores de nuvem (por exemplo, bancos de dados, armazenamentos de objetos, etc.).
- A carga operacional e de infraestrutura para executar e dimensionar modelos recai principalmente sobre o provedor de nuvem.
- Preocupações com latência e algumas questões de privacidade de dados podem ser mais fáceis de resolver.
Desafios
- Aplicativos de nuvem múltipla/híbrida exigem esforço adicional para conectar e proteger.
- A falta de uniformidade entre serviços gerenciados em nuvem e APIs pode levar ao bloqueio de fornecedores.
- Organizações sem uma ampla presença na nuvem pública podem enfrentar dificuldades.
- O custo das despesas operacionais em escalas maiores pode ser maior do que em modelos de auto-hospedagem.
- Serviços de hospedagem de modelos personalizados e personalização de modelos podem não ser suportados.
Padrão autogerenciado
Para o modelo autogerenciado, discutiremos primeiro o caso em que a inferência do modelo de IA é executada como um "serviço compartilhado" centralizado, depois examinaremos o caso em que não existe nenhum serviço centralizado e as preocupações operacionais são deixadas para equipes de aplicativos individuais.
Serviço compartilhado e autogerenciado
Na variante “Serviço Compartilhado” do padrão Autogerenciado, uma organização pode ter equipes dedicadas responsáveis por manter a infraestrutura de inferência, os modelos que são executados nela, as APIs usadas para se conectar a ela e todos os aspectos operacionais do ciclo de vida do serviço de inferência. Assim como nos outros padrões, as cargas de trabalho de aplicativos de IA consumiriam serviços de inferência por meio de chamadas de API. O modelo que atende à infraestrutura pode ser executado em data centers privados, em nuvem pública ou em uma instalação de colocation. As equipes responsáveis pela operação do serviço de inferência podem aproveitar plataformas de aprendizado de máquina auto-hospedadas (como Anyscale Ray ou MLFlow). Como alternativa, eles podem contar com ferramentas de inferência mais focadas, como o servidor de inferência de geração de texto da Hugging Face ou software desenvolvido internamente. Com a inferência autogerenciada, as organizações ficam limitadas a usar modelos que elas mesmas treinaram ou que estão disponíveis para execução local (portanto, modelos proprietários de um serviço orientado a SaaS podem não ser uma opção).
Bem adequado para
- Organizações maduras com ampla experiência em gerenciamento de infraestrutura.
- Organizações com altos requisitos de inferência que justificam o TCO de um serviço autogerenciado.
- Aplicativos com os mais rigorosos requisitos de privacidade e conformidade de dados.
Pontos fortes
- As organizações têm controle total de todos os aspectos do serviço de inferência.
- Os desafios de privacidade de dados geralmente são mais fáceis de resolver com modelos auto-hospedados.
- O custo em larga escala pode ser mais eficiente do que serviços de inferência gerenciados em nuvem ou baseados em SaaS.
Desafios
- As organizações têm controle total sobre todos os aspectos do serviço de inferência (é provável que sejam necessários grandes investimentos em infraestrutura e pessoal, além de preocupações contínuas com manutenção, desenvolvimento e escalabilidade).
- Normalmente não é econômico para organizações com necessidades mínimas de inferência e preocupações mínimas com privacidade de dados.
- Nenhum acesso a modelos fechados/proprietários que podem estar disponíveis como SaaS ou serviços gerenciados em nuvem.
Autogerenciado, não um serviço compartilhado
Organizações sem uma equipe central responsável por executar serviços de inferência de IA para consumo de aplicativos são a outra variante do padrão autogerenciado. Nesta versão, equipes de aplicativos individuais podem executar seus modelos na mesma infraestrutura que foi alocada a eles para a carga de trabalho do aplicativo. Eles podem escolher acessar esses modelos via API ou consumi-los diretamente de forma “offline”. Com esse padrão, os desenvolvedores podem obter alguns dos mesmos benefícios do modelo autogerenciado de “Serviço Compartilhado” em uma escala menor.
Bem adequado para
- Aplicações que exigem processamento em lote e inferência offline.
- Organizações com consumo de inferência muito baixo, mas com requisitos rigorosos de privacidade e conformidade de dados.
Pontos fortes
- Mais flexível para desenvolvedores de aplicativos, permitindo uma ampla gama de possibilidades de integração com cargas de trabalho.
- Pode atingir metas de privacidade de dados e latência em pequena escala.
- Pode ser mais econômico do que os outros modelos discutidos em alguns casos (como equipe única com requisitos de alto consumo).
Desafios
- A carga operacional do ciclo de vida do modelo é colocada nas equipes de aplicativos individuais.
- Não aproveita as economias de escala à medida que o consumo de inferência de IA de uma organização cresce (falta de consistência, utilização ineficiente de recursos, etc.)
Resumo das compensações de padrões
Protegendo aplicativos de IA e serviços de inferência de modelos
Em sua essência, os aplicativos de IA são muito parecidos com qualquer outro aplicativo moderno. Eles são construídos com uma mistura de componentes de backend e voltados para o usuário, geralmente dependem de armazenamentos de dados externos, fazem uso intenso de chamadas de API, etc. Esses aplicativos herdam os mesmos desafios de segurança comuns a todos os aplicativos modernos e precisam das mesmas proteções aplicadas da mesma maneira (por exemplo, AuthNZ, proteções DDoS, WAF, práticas de desenvolvimento seguro, etc.). No entanto, os aplicativos de IA, especialmente aqueles que utilizam IA generativa, também estão sujeitos a uma série de preocupações específicas que podem não se aplicar a outros aplicativos (por exemplo, consulte OWASP Top 10 For LLMs ). A natureza geralmente imprevisível desses modelos pode levar a novos problemas, especialmente em casos de uso em que os modelos recebem uma agência significativa.
Felizmente, devido à forte dependência de interações orientadas por API com inferência de modelos de IA nos padrões discutidos acima, muitas organizações já estão bem posicionadas para implementar essas novas medidas de segurança. Por exemplo, um gateway de API que fornece funcionalidade tradicional de limitação de taxa, autenticação, autorização e gerenciamento de tráfego pode ser estendido para oferecer suporte a limites de taxa baseados em token para ajudar no controle de custos (seja de saída no nível do aplicativo para um serviço gerenciado por SaaS/provedor ou autorização RBAC de entrada como proteção diante de um serviço de inferência autogerenciado). Da mesma forma, a infraestrutura que atualmente executa serviços tradicionais de Web Application Firewall (WAF), como verificação de injeção de SQL ou XSS, pode ser um lugar lógico para adicionar proteções contra injeção rápida e ataques semelhantes. A maioria das práticas modernas de observabilidade são diretamente aplicáveis a casos de uso específicos de inferência de IA orientada por API, e as equipes devem ser capazes de fazer bom uso das ferramentas e práticas existentes nesse espaço.
Conclusão
Embora o burburinho em torno de aplicativos e serviços de inferência com tecnologia de IA seja certamente novo, os princípios fundamentais em jogo ao implantá-los e protegê-los já existem há muito tempo. As organizações precisarão ponderar as compensações ao determinar a melhor forma de aproveitar os recursos de IA, assim como fazem ao consumir qualquer outra tecnologia; com base em seus casos de uso específicos, recursos disponíveis e objetivos de longo prazo. Da mesma forma, embora os casos de uso de IA (e particularmente de IA generativa) apresentem alguns novos desafios de segurança, as necessidades que eles compartilham com outros aplicativos modernos e a forte dependência da interação de modelos orientados por API apresentam uma grande oportunidade de usar e estender padrões, práticas e ferramentas existentes. Seja um serviço auto-hospedado ou gerenciado, garantir que os desenvolvedores tenham acesso a uma solução segura, escalável e de alto desempenho que atenda aos seus requisitos comerciais específicos é essencial para maximizar o valor e o impacto dos seus investimentos em IA.