MLOps vs LLMOps: infraestrutura para foundation models

Viacheslav Dubrov

2025-05-06 · Atualizado 2026-10-02 · 15 min · Infraestrutura de IA

Tradução automática

Este artigo foi traduzido automaticamente a partir da versão original em inglês.

Este artigo destina-se a engenheiros de ML e de plataforma que já praticam MLOps e agora operam um sistema construído sobre um foundation model. Num sistema destes, uma regressão pode vir de um prompt, de um índice, de uma permissão de ferramenta ou de uma rota alterados, mesmo que os pesos do modelo não mudem. O artigo explica que práticas de MLOps continuam a aplicar-se, o que mais é preciso versionar quando prompts, retrieval, ferramentas e routing podem mudar o comportamento, como avaliar e fazer o tracing desse sistema, e que ferramentas fazem cada tarefa.

O que o MLOps já resolveu

O diagrama mostra o ciclo de MLOps em cinco passos; a aresta tracejada leva a evidência de incidentes de volta à verificação offline do release. O MLOps estabeleceu estas práticas, e elas continuam a aplicar-se quando o modelo gera texto:

• linhagem desde os dados, o código, a configuração e o modelo até um release
• pipelines de treino ou de build repetíveis
• validação offline antes da promoção
• registos e identidade imutável dos artefactos
• rollout faseado, objetivos de nível de serviço, rollback e resposta a incidentes
• telemetria de infraestrutura e planeamento de capacidade
• controlo de acesso, retenção e política de auditoria para os dados

A maior parte das ferramentas de orquestração que já usa continua a servir, mas não em todos os caminhos:

Os foundation models não eliminam estas necessidades. Tornam a antiga expressão “versão do modelo” demasiado pequena.

A unidade de release passou a ser um manifesto do sistema

O grupo de cima do diagrama é o que o MLOps já versiona; o grupo de baixo é o que um sistema baseado em foundation model acrescenta. Uma aresta de cada grupo leva ao manifesto, porque qualquer componente pode alterar o comportamento.

Para um sistema baseado em foundation model, recomendo um manifesto que registe pelo menos:

application code revision
model provider + model/revision + serving configuration
system and task prompts
response schema + decoding parameters
retrieval corpus snapshot + parser + chunker + embedding model + index
tool definitions + implementation revisions + permission policy
routing, fallback, caching, and budget policy
safety and business-rule revisions
evaluation dataset + scorer revisions

A lista exata depende do sistema. A regra é identificar cada componente que muda de forma independente e que pode alterar o comportamento visível para o utilizador.

Trate o nome de um modelo de um fornecedor como mutável, a menos que o fornecedor documente uma revisão imutável. O hash de um checkpoint ajuda a identificar pesos auto-alojados, mas eu continuaria a registar o runtime, a quantização, o chat template e a configuração de paralelismo. A entrada do modelo vem de um registo: use o MLflow Model Registry para pesos e adaptadores que treina, e o Hugging Face Hub para pesos abertos, fixados a um commit com o argumento revision em vez de um nome de branch.

Guarde o manifesto como um ficheiro junto de cada release. Quando um release regride, compare-o com o anterior. Neste exemplo de um assistente de suporte, só mudaram o prompt de resposta e o snapshot do retrieval:

-    answer: prompts/answer.md@v9
+    answer: prompts/answer.md@v10
-    corpus: kb-snapshot-2026-09-28
-    index: kb-idx-2026-09-28-01
+    corpus: kb-snapshot-2026-10-01
+    index: kb-idx-2026-10-01-01

O diff indica os componentes a verificar primeiro: o prompt de resposta e o novo índice. Os pesos, as ferramentas e o routing não mudaram.

Que componente inspecionar primeiro

O diff do manifesto diz o que mudou. O tipo de falha diz onde procurar quando o diff, por si só, não explica o problema:

Para escolher entre alterar o prompt, acrescentar retrieval e fazer fine-tuning, veja fine-tuning vs RAG vs prompting.

Cinco componentes que podem alterar o comportamento

As secções seguintes tratam, por ordem, cinco componentes do diagrama do manifesto: o modelo e o seu serving, depois os prompts e o schema, o corpus e o índice de retrieval, as ferramentas e as permissões, e as regras de segurança e de negócio. Cada secção indica o que registar, o que testar e que ferramentas fazem o trabalho. O routing e o fallback têm uma secção própria, com o gateway.

1. Modelo e serving

A primeira decisão é saber se um fornecedor aloja o modelo ou se o serve você mesmo. Uma API alojada elimina o trabalho com GPUs. Cada pedido atravessa a rede, paga-se por token, os dados que envia saem da sua rede, e o fornecedor controla os pesos, as revisões, as quotas e o preço. Com o auto-alojamento, controla a revisão, a quantização, o batching, a região e a cache. Também passa a gerir a capacidade de GPU, e paga por ela esteja ocupada ou ociosa.

O diagrama coloca os dois modos lado a lado: quem controla o quê, o que se paga e quando cada um se adequa. Em ambos os modos, o manifesto regista a rota e corre-se o mesmo conjunto de tarefas.

Se fizer auto-alojamento, escolha o motor de serving conforme a forma do deployment:

Os modelos grandes demais para uma única GPU precisam de paralelismo de tensores ou de pipeline no serving; Scaling LLMs with multi-GPU and multi-node parallelism explica cada método. Para escolher um formato de pesos para o runtime e o hardware, veja LLM quantization formats.

Em qualquer dos modos, inclua verificações de latência, erros, débito, saturação, custo e qualidade da tarefa na decisão de release.

2. Prompts e schema

Num sistema que monta os pedidos em tempo de execução, versione o pedido montado e não apenas o texto do prompt: a ordem das mensagens, as descrições das ferramentas, o schema da resposta, o decoding, as repetições, o truncamento e o código envolvente podem, cada um, alterar o comportamento.

Uma pequena alteração no prompt pode mudar o formato da saída. Aqui estão três versões de um prompt de sentimento:

v1: "Classify this text as positive or negative: {text}"
v2: "You are a sentiment analyzer. Classify: {text}"
v3: "Analyze sentiment. Return only 'positive' or 'negative': {text}"

v1 e v2 podem devolver uma frase como “The sentiment is positive.” O v3 pede uma só palavra. O código que interpreta a resposta tem de mudar com o prompt, por isso o prompt, o schema e o parser entram juntos no manifesto.

Trate o JSON interpretável como uma verificação de transporte e teste as invariantes de negócio da tarefa em separado.

3. Corpus e índice de retrieval

O retrieval acrescenta um produto de dados independente entre a fonte de verdade e o modelo:

Siga um pedido pelo diagrama: a versão do índice alimenta o retrieval e, depois, três verificações separadas testam a autorização, a evidência recuperada e a resposta.

Num sistema com retrieval aumentado, conserve a revisão da fonte, as versões do parser e do chunker, a identidade dos embeddings, o build do índice, os metadados de controlo de acesso e o estado de eliminação. O desenho original do RAG separa o retrieval da geração; use essa separação para testar de forma independente a recuperação da evidência, o filtro de autorização e o uso da evidência. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks descreve a arquitetura de recuperar e depois gerar. RAG evaluation metrics cobre as métricas de cada verificação, e RAG evaluation tools compara as bibliotecas que as calculam.

Escolha o armazenamento do índice consoante quem o usa. Uma biblioteca em processo, como a FAISS, basta quando um único serviço é dono do índice e este cabe na memória desse serviço. Use um servidor de base de dados vetorial, como Pinecone, Weaviate ou Milvus, quando vários serviços partilham o índice, quando precisa de filtros de metadados no momento da consulta, ou quando o índice deixa de caber numa máquina. Para o desenho do retrieval em si (uma passagem, pesquisa iterativa ou GraphRAG), veja RAG architecture.

Escolha o método de atualização conforme o quão desatualizada uma resposta pode estar. Uma reconstrução agendada serve quando uma resposta com um dia é aceitável. Quando uma alteração tem de aparecer em minutos, faça streaming das atualizações, por exemplo com eventos Kafka que alimentam um job de embeddings que escreve no índice. Em ambos os casos, o manifesto regista que build do índice serviu cada resposta.

Não use um índice vetorial como substituto de uma feature store ou de um data warehouse: a recuperação por semelhança, as features point-in-time e os factos analíticos têm necessidades de consulta e de consistência diferentes.

Os dois painéis mostram a diferença: uma feature store devolve os factos corretos de uma entidade num dado momento, e uma base de dados vetorial devolve documentos ordenados pela semelhança com a consulta. Mantenha o data warehouse para a análise.

4. Ferramentas e permissões

Quando um modelo pode chamar APIs, coloque estas verificações em torno de cada tool call: autenticação da ferramenta, privilégio mínimo, validação dos argumentos, timeouts, idempotência, política de aprovação e verificação das pós-condições. O Generative AI Profile do NIST identifica riscos de conteúdo nocivo, privacidade e segurança.

O diagrama mostra quatro destas verificações por ordem e onde uma chamada para: uma permissão ou um argumento rejeitado, uma aprovação negada, ou um resultado que não corresponde à pós-condição esperada.

Faça o trace de que ferramenta foi oferecida, selecionada, chamada, rejeitada, repetida e confirmada. Uma resposta final fluente não prova que o caminho da ação estava correto.

5. Regras de segurança e de negócio

Os filtros de conteúdo são um controlo, não uma camada de guardrails completa. As ameaças incluem também prompt injection, retrieval entre tenants, divulgação de segredos, agência excessiva (uma entrada do OWASP Top 10 for LLM Applications), ficheiros de modelo não confiáveis ou código personalizado carregado em runtime, e argumentos de ferramentas inseguros.

Sempre que possível, expresse as regras de negócio determinísticas fora do modelo. Defina os riscos residuais, teste casos adversariais e atribua um responsável pelas alterações de política. O Generative AI Profile do NIST é um inventário de riscos útil, não um teste de aceitação pronto a usar.

A avaliação decide o release

Nas decisões de release sobre saída livre, não dependa de um único número agregado de accuracy. Use vários tipos de evidência e defina qual é a autoritativa para cada modo de falha.

Uma pilha de avaliação para um sistema baseado em foundation model tem seis camadas:

1. Verificações determinísticas: validade do schema, citações presentes, ferramentas permitidas, restrições nos argumentos, regras de política, latência e orçamento.
2. Métricas por componente: recall e ranking do retrieval, accuracy na seleção de ferramentas, correção dos argumentos das ferramentas e seleção de rota.
3. Tarefas de ponta a ponta: entradas representativas com critérios de sucesso explícitos e etiquetas de slice.
4. Pontuação baseada em modelo: juízos guiados por rubricas, calibrados com etiquetas de especialistas e monitorizados quanto à deriva do juiz.
5. Revisão humana: casos ambíguos, com consequências, novos ou amostrados, em que a automação não é autoritativa.
6. Testes adversariais: casos de injection, de fronteira de dados, de abuso, de recusa e de efeitos secundários, ligados ao modelo de ameaças.

Guarde os resultados por exemplo, e não só as médias, para que a revisão do release possa inspecionar regressões por idioma, tenant, tipo de documento ou classe de ação.

Para uma decisão de deployment, compare um manifesto candidato com o release atual no mesmo conjunto versionado. Defina limiares para qualidade, segurança, latência e custo em conjunto, e rejeite uma rota mais barata que falhe o conjunto de tarefas.

Se todos os resultados estiverem dentro do limiar, inicie um rollout faseado. Se um falhar, rejeite o candidato. Se o resultado de um slice não for claro, envie-o para revisão humana.

Para escolher uma ferramenta de avaliação para traces, datasets e verificações de CI, veja AI agent evaluation tools.

Os traces ligam a produção de volta à avaliação

Leia o diagrama a partir do passo 1: um pedido em produção torna-se um trace, uma falha revista e um caso de regressão etiquetado. A avaliação compara uma alteração candidata com o release atual, e a aresta tracejada leva o resultado monitorizado do release faseado de volta à produção.

As métricas de infraestrutura podem mostrar uma chamada lenta ao modelo. Não conseguem mostrar que o retrieval devolveu um documento não autorizado ou que uma ferramenta foi chamada com a conta errada. A documentação de tracing do MLflow descreve traces que capturam os passos intermédios e os metadados necessários para inspecionar este caminho.

Capture um trace ao longo do caminho de decisão:

• identidade do manifesto de release e correlação do pedido
• chamadas ao modelo e ao fornecedor, latência, utilização e estado final
• consulta de retrieval, identificadores dos documentos, pontuações e decisões de filtragem
• revisão do prompt/template sem guardar indiscriminadamente conteúdo sensível
• ferramentas oferecidas, argumentos, aprovações, resultados e identificadores de efeitos secundários
• decisões de política, repetições, fallbacks e resultado final

Os traces são um novo repositório de dados sensíveis. Aplique minimização, redação, isolamento de tenants, encriptação, amostragem, retenção e revisão de acessos antes de recolher prompts ou documentos completos. As convenções semânticas GenAI do OpenTelemetry podem ajudar na interoperabilidade, mas continuam em desenvolvimento. Fixe a versão da convenção ou do schema, da instrumentação e do collector.

O feedback dos utilizadores pode priorizar a investigação, mas um polegar para cima não é verdade de referência. Preserve o trace envolvente e obtenha etiquetas de especialistas para os casos com consequências. O Label Studio recolhe etiquetas para texto, imagens e outros tipos de dados; o Argilla recolhe feedback sobre texto e saídas de LLMs e pode enviar os datasets para o Hugging Face Hub. AI agent evaluation in production mostra como transformar traces etiquetados num conjunto de regressão versionado.

O gateway de serving é dono do routing e da política

No diagrama, cada pedido segue uma rota pelo gateway e recebe de volta o mesmo contrato de resposta; a aresta tracejada ao lado mostra que o conjunto de tarefas avalia cada rota offline antes da promoção.

Um gateway pode desacoplar os clientes da aplicação dos fornecedores ou dos motores auto-alojados. As responsabilidades que vale a pena pôr aí incluem:

• autenticação, orçamentos por tenant, quotas e limites de taxa
• contratos de pedido e de resposta estáveis
• seleção de rota por capacidade, região, latência ou qualidade avaliada
• routing por nível de subscrição, por exemplo um modelo maior para os planos pagos
• enviar uma pequena parte do tráfego para um novo modelo antes do rollout completo
• repetições limitadas, circuit breakers e semântica de fallback explícita
• partição da cache e política de dados sensíveis
• atribuição de utilização e propagação do manifesto de release

O LiteLLM Proxy é um gateway open-source: expõe muitos fornecedores através de uma única API compatível com OpenAI e define orçamentos e limites de taxa por chave ou por equipa.

O fallback é tanto uma alteração de comportamento como um mecanismo de fiabilidade. Se um modelo mais pequeno, um fornecedor alternativo ou um contexto reduzido alterar a qualidade da tarefa, avalie e faça o trace desse ramo como uma rota própria.

Não ponha todas as decisões de orquestração no gateway. Mantenha as regras de domínio perto da aplicação e torne visível quem é o responsável.

Fine-tuning e LoRA

A última linha da tabela de falhas em “Que componente inspecionar primeiro” é o caso do fine-tuning: o comportamento de que a tarefa precisa não se consegue recuperar a partir do prompt nem do contexto recuperado. A LoRA congela os pesos pré-treinados e acrescenta matrizes de baixo rank treináveis, reduzindo o número de parâmetros treináveis para a tarefa final. Essa otimização não elimina a governação dos datasets, o licenciamento do modelo base, a avaliação, a compatibilidade de serving nem os requisitos de rollback.

Registe as definições do adaptador no manifesto, junto da revisão do modelo base: o rank (r), o fator de escala (lora_alpha) e as camadas que altera (target_modules). Cada uma muda o que o adaptador aprende. O LLM fine-tuning guide cobre datasets, QLoRA e ferramentas de treino, e o LoRAX serving guide cobre o serving de muitos adaptadores num único modelo base.

Uma sequência prática de adoção

1. Defina a tarefa do utilizador, os limites de dano, os objetivos de serviço e o envelope de custo.
2. Crie o manifesto de release antes de introduzir um registo de prompts, uma base de dados vetorial ou um produto de gateway.
3. Construa um conjunto de avaliação pequeno e com slices, e testes determinísticos por componente.
4. Instrumente um trace de ponta a ponta com controlos de privacidade e identidades de release estáveis.
5. Promova através de tráfego shadow, canary ou limitado, com um gatilho de rollback explícito.
6. Transforme as falhas revistas em produção em casos de regressão e repita.

Acrescente infraestrutura apenas quando ela fizer uma tarefa que o manifesto nomeia ou quando eliminar um gargalo medido.

Referências

• MLflow: evaluating production traces - Reutilize traces de produção para avaliação e pontue a informação intermédia do trace.
• MLflow: LLM and agent tracing - Capture os passos intermédios e os metadados do trace para investigação.
• OpenTelemetry GenAI semantic conventions - Convenções atuais, em estado de desenvolvimento, para spans, métricas, eventos e dados específicos de fornecedores de GenAI.
• NIST AI 600-1: Generative AI Profile - Categorias de risco para prompt injection, privacidade, segurança e outras preocupações de IA generativa.
• OWASP Top 10 for LLM Applications - Inclui agência excessiva (LLM06:2025) e prompt injection (LLM01:2025).
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks - Arquitetura original de recuperar e depois gerar.
• LoRA: Low-Rank Adaptation of Large Language Models - Pesos pré-treinados congelados mais matrizes de baixo rank treináveis para adaptação a tarefas finais.
• PEFT LoRA reference - Parâmetros de LoraConfig e get_peft_model.
• vLLM documentation - Motor de serving com continuous batching, quantização, multi-LoRA e um servidor compatível com OpenAI.
• NVIDIA Dynamo-Triton - Servidor de inferência anteriormente chamado Triton Inference Server, com um backend TensorRT-LLM.
• LiteLLM Proxy - Gateway open-source com uma API única para vários fornecedores, orçamentos, limites de taxa e fallbacks.