Tradução automática

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

MLOps vs LLMOps: Infraestrutura para Modelos Fundacionais e Sistemas LLM

Os modelos fundacionais quebraram a maioria dos pressupostos em que o MLOps clássico assentava. Este é um percurso pelo que mudou, pelo que se manteve, e pelos padrões que preencheram essa lacuna.

MLOps clássico antes dos modelos fundacionais

Há poucos anos, MLOps significava sobretudo DevOps para ML — automatizar o ciclo de vida desde a preparação de dados até ao deployment e à monitorização. Os modelos eram suficientemente pequenos para serem treinados de raiz com dados do domínio, e a infraestrutura refletia isso.

1.1. Pipelines end-to-end

As equipas construíam pipelines para extração de dados, treino, validação e deployment. Airflow tratava do ETL e da orquestração do treino. CI/CD executava testes e colocava modelos em produção. Os modelos eram empacotados como contentores Docker a servir endpoints REST ou batch jobs. O objetivo de tudo isto era reprodutibilidade e automação.

1.2. Tracking de experiências e versionamento de modelos

MLflow e Weights & Biases eram o padrão para registar execuções, hiperparâmetros e métricas. Os data scientists podiam comparar experiências e reproduzir resultados de forma fiável. Os model registries davam números de versão, o que tornava os rollbacks simples quando um modelo novo tinha pior desempenho.

1.3. Treino contínuo e CI/CD

Os pipelines eram desenhados em torno da integração contínua de novos dados. Uma configuração típica voltava a treinar todas as noites ou todas as semanas à medida que os dados chegavam, executava uma bateria de testes e fazia auto-deploy se tudo passasse. Jenkins e GitLab CI/CD garantiam que qualquer alteração nos dados ou no código acionava o pipeline de forma fiável.

1.4. Infraestrutura e serving

O serving tinha uma pegada relativamente pequena — alguns cores de CPU ou uma única GPU para inferência em tempo real. Kubernetes e Docker eram o padrão para serviços de inferência escaláveis. A monitorização cobria três áreas: métricas de desempenho (latência, throughput, memória), métricas do modelo (accuracy, drift) e saúde do sistema (uptime, error rates).

1.5. Feature stores e gestão de dados

Em finanças e e-commerce, as features construídas manualmente eram tão importantes como o modelo. Os feature stores davam um local central para as gerir e mantinham treino e serving consistentes. Dados estruturados e feature engineering eram o centro de gravidade. Dados não estruturados — texto, imagens — eram tratados em separado, fora destes stores.

Esta abordagem funcionou bem até os modelos começarem a ficar muito maiores.

2. A mudança de paradigma: ascensão dos modelos fundacionais de grande escala

Por volta de 2018–2020, o panorama mudou rapidamente. Os investigadores começaram a disponibilizar modelos fundacionais — modelos muito grandes pré-treinados em corpora amplos que podiam ser adaptados a muitas tarefas.

A progressão foi rápida:

• 2018–2019: BERT e GPT-2 tornaram o transfer learning credível à escala.
• 2020–2021: GPT-3 e PaLM mostraram o que a escala bruta conseguia fazer.
• 2021–2023: Modelos de imagem como DALL-E e Stable Diffusion levaram a IA generativa para o mainstream.
• 2023–2024: Os modelos fundacionais tornaram-se infraestrutura por defeito — disponíveis no Hugging Face, AWS Bedrock, Vertex AI Model Garden e diretamente a partir de fornecedores de API.

Eis o que os modelos fundacionais mudaram efetivamente na infraestrutura de ML.

2.1. O pré-treinado vence o treino de raiz

Em vez de treinar de raiz, as equipas passaram a começar com um modelo pré-treinado e a fazer fine-tuning para a tarefa. O tempo de treino caiu de semanas para horas. Os requisitos de dados desceram de milhões de exemplos para milhares. Equipas mais pequenas passaram a conseguir lançar produtos de IA sérios sem uma organização de investigação por trás.

Os maiores modelos (milhares de milhões de parâmetros) são geralmente usados tal como estão via APIs ou afinados com adapters leves. A descrição do trabalho mudou: menos "como é que construo um modelo?" e mais "como é que uso e integro um?"

2.2. Tamanho do modelo e exigências computacionais

À escala dos LLM, o resto da stack também tem de mudar. Um modelo com 175B parâmetros não é apenas uma versão maior de um com 50M — não cabe no mesmo hardware, não se treina da mesma forma, nem é servido da mesma forma.

As dores de cabeça:

• Training exige hardware potente (GPUs, TPUs) e computação distribuída.
• Model parallelism divide um único modelo por várias GPUs.
• Data parallelism sincroniza muitos workers de GPU durante o treino.
• Inference precisa frequentemente de várias GPUs ou runtimes especializados para manter a latência dentro do esperado.

DeepSpeed e ZeRO (Zero Redundancy Optimizer) surgiram especificamente para tornar viável o treino de modelos enormes. Os requisitos de infraestrutura aumentaram por ordens de grandeza.

2.3. O aparecimento de LLMOps

Executar estes modelos em produção exigiu extensões ao MLOps clássico. Daí surgiu LLMOps — MLOps especializado para modelos grandes, com os mesmos princípios mas uma superfície de problemas diferente:

• Compute: gerir clusters de GPU caros, e não pools de CPU.
• Prompt engineering: moldar o comportamento através do desenho do input.
• Safety monitoring: detetar bias, conteúdo nocivo e fuga de dados.
• Performance management: equilibrar latência, qualidade e custo por token.

Problemas que quase não contavam em modelos mais pequenos — texto enviesado, dados de treino expostos — tornaram-se riscos reais à escala dos LLM.

O diagrama da NVIDIA mostra bem como estas especialidades se encaixam: MLOps clássico no exterior, depois GenAI Ops (qualquer modelo generativo), depois LLMOps (modelos de linguagem de grande dimensão especificamente), e depois RAGOps para sistemas com retrieval augmentation. O ponto desta estrutura aninhada é que cada camada interior assenta nas práticas das camadas exteriores — não as substitui.

2.4. Modelos fundacionais como serviço

A outra grande mudança: muitas aplicações já não alojam os seus próprios modelos, chamam os modelos de terceiros. OpenAI, Cohere e AI21 Labs oferecem LLMs alojados. Google Vertex AI disponibiliza um Model Garden de modelos pré-treinados. AWS Bedrock aloja modelos fundacionais proprietários. Hugging Face aloja milhares de pesos abertos que pode descarregar ou executar na cloud.

Isto reorganiza a arquitetura. Os pipelines de produção chamam APIs externas para inferência, o que elimina a gestão de GPU mas introduz novos custos:

• Latência: os round-trips de rede acrescentam overhead.
• Custo: pricing pay-per-token significa que picos de utilização impactam diretamente a fatura.
• Privacidade de dados: tudo o que é enviado para um fornecedor sai do seu perímetro.
• Vendor lock-in: o comportamento da API, o pricing e as políticas não estão sob o seu controlo.

O trade-off funciona para a maioria das equipas. Gerir a sua própria stack de serving para LLMs é um investimento de engenharia real, e nem sempre é um investimento que valha a pena fazer.

3. Novos requisitos e capacidades na infraestrutura moderna de ML

A infraestrutura moderna de ML tem de suportar coisas que há poucos anos eram de nicho ou inexistentes. As mais comuns são estas:

3.1. Treino distribuído e model parallelism

Treinar um modelo com mil milhões de parâmetros excede a capacidade de uma única máquina. A infraestrutura moderna orquestra o treino por muitos nós:

Duas divisões principais importam:

• Model parallelism: dividir as camadas do modelo por GPUs (cada GPU executa parte do forward pass).
• Data parallelism: replicar o modelo por GPUs e dividir os dados de treino, sincronizando depois os gradientes.

PyTorch Lightning e Horovod tratam do treino distribuído geral. NVIDIA Megatron-LM é a referência para transformers massivos. A stack JAX/TPU da Google cobre clusters de TPU.

Há poucos anos, a maioria das equipas treinava num único servidor. Agora as plataformas de ML lançam jobs em clusters de GPU, gerem falhas e agregam gradientes de dezenas ou centenas de workers sem o engenheiro ter de pensar nisso.

3.2. Técnicas eficientes de fine-tuning

Mesmo fazer fine-tuning de um modelo com vários milhares de milhões de parâmetros pode ser caro. Existem métodos eficientes em termos de parâmetros exatamente por essa razão:

• LoRA (Low-Rank Adaptation): treina um pequeno conjunto de parâmetros adapter; os pesos base ficam congelados. Grande redução em compute e memória.
• Prompt tuning: otimiza apenas os embeddings do prompt; o próprio modelo fica congelado.
• Adapter modules: insere pequenas camadas treináveis entre camadas congeladas.

Configurar LoRA com peft:

from peft import LoraConfig, get_peft_model

# Configure LoRA
peft_config = LoraConfig(
    r=16,
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM"
)

# Apply to base model
model = get_peft_model(base_model, peft_config)
model.print_trainable_parameters()

A infraestrutura tem de suportar o workflow multi-etapas: obter um modelo base de um hub, aplicar deltas de pesos resultantes de fine-tuning, fazer deploy da combinação final. Os pipelines tradicionais tiveram de evoluir para lidar com este passo de customização.

3.3. Prompt engineering e gestão de prompts

O novo artefacto nos pipelines modernos de ML é o prompt. Com LLMs, o prompt determina grande parte do que o modelo faz — muito mais do que os vetores de features alguma vez determinaram no ML clássico.

Isto tem consequências práticas. As equipas mantêm agora bibliotecas de prompts, versionam-nas como código, fazem testes A/B a variantes e guardam versões de prompts ao lado das versões dos modelos no registry. Isto é genuinamente diferente do ML clássico, onde os inputs eram apenas vetores de features. Frameworks como LangChain tratam a otimização de prompts como funcionalidade de primeira classe.

Uma evolução simples tem este aspeto:

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}"

Cada versão produz resultados diferentes. Fazer tracking e testar prompts acaba por ser tão importante como fazer tracking dos pesos do modelo.

3.4. Retrieval-Augmented Generation (RAG)

Os modelos fundacionais têm um cutoff de conhecimento fixo e uma janela de contexto finita. Para manter as respostas atuais e fundamentadas, Retrieval-Augmented Generation (RAG) tornou-se prática padrão.

Em vez de voltar constantemente a treinar um modelo com novos dados — o que é lento e caro — o RAG vai buscar documentos relevantes no momento da query e acrescenta-os ao prompt como contexto.

Uma cadeia RAG simplificada em LangChain:

from langchain.vectorstores import Pinecone
from langchain.llms import OpenAI
from langchain.chains import RetrievalQA

# 1. Load the vector database
vector_db = Pinecone.from_existing_index("my-index", embeddings)

# 2. Initialize the LLM
llm = OpenAI(temperature=0)

# 3. Create the RAG chain
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vector_db.as_retriever()
)

# 4. Ask a question
response = qa_chain.run("How does LLMOps differ from MLOps?")

Os novos componentes de infraestrutura:

• Bases de dados vetoriais (Pinecone, Weaviate, FAISS, Milvus) para pesquisa rápida por similaridade sobre embeddings.
• Embedding models para converter documentos e queries em vetores.
• Gestão de índices para manter os embeddings sincronizados com a source of truth.

As bases de dados vetoriais assumiram em grande parte o papel que os feature stores tradicionais tinham. Dados não estruturados e pesquisa semântica são agora o centro da ação, e não o feature engineering manual.

3.5. Data streaming e feeds de dados em tempo real

As aplicações modernas — especialmente assistentes suportados por LLM — ingerem dados continuamente: conversas de chat, dados de sensores, event streams. Esses dados precisam de atualizar o conhecimento do modelo (via RAG) ou desencadear respostas em tempo real.

O MLOps clássico era orientado a batch (retraining diário ou semanal). O LLMOps moderno tende a ser orientado a streams: Kafka e plataformas de event streaming, bases de dados em tempo real (Redis, DynamoDB), feature stores online com atualizações contínuas e pipelines de embeddings em streaming que mantêm os índices vetoriais atualizados.

A linha entre data engineering e MLOps ficou mais difusa. Os pipelines de dados alimentam agora diretamente a inferência, e não apenas o treino.

3.6. Infraestrutura de serving escalável e especializada

Fazer serving de um modelo massivo é um projeto de engenharia por si só. Três capacidades são as mais importantes.

Serving com alto throughput e baixa latência. As aplicações interativas precisam de respostas rápidas. Isso implica aceleração com GPU/TPU, quantização do modelo para comprimir pesos e acelerar a inferência, batching em GPU para servir múltiplos pedidos em paralelo, e motores otimizados como NVIDIA TensorRT, Triton Inference Server ou DeepSpeed-Inference.

Escalabilidade serverless e elástica. Plataformas como Modal apresentam-se como "AWS Lambda but with GPU support" — traz o código, eles tratam da infraestrutura e do scaling. Não paga por servidores idle, o compute arranca sob procura, escala para zero quando não acontece nada e cresce sob carga. O trade-off é latência de cold start, statelessness e menos controlo sobre o runtime. É uma boa opção para workloads irregulares em que manter um cluster de GPU ativo não faz sentido.

Serving distribuído de modelos. Para modelos demasiado grandes para uma única GPU, a própria inferência passa a ser distribuída. O modelo é dividido por várias máquinas, cada uma a tratar parte do forward pass. Fazer serving on-prem de um modelo com 175B parâmetros significa realisticamente várias GPUs a cooperar. A infraestrutura moderna tem de lançar réplicas de inferência distribuída e encaminhar pedidos para o shard certo.

3.7. Monitorização, observabilidade e guardrails

Os modelos grandes podem produzir outputs errados ou inseguros de formas que os modelos pequenos não conseguiam. A monitorização tem agora três camadas.

Desempenho e fiabilidade. O básico continua a aplicar-se: latência, throughput, memória, utilização de GPU, custo. O autoscaling é mais importante porque os minutos de GPU são caros — em carga elevada, recorra a um modelo mais pequeno se o maior não justificar a fila.

Qualidade e segurança dos outputs. Agora monitoriza-se o que o modelo diz, e não apenas se respondeu. Filtragem de conteúdo para hate speech, PII e conteúdo nocivo. APIs de moderação (da OpenAI ou próprias). Avaliação contínua de bias. Guardrails que intercetam inputs adversariais e mantêm os outputs dentro do âmbito. Nada disto é opcional em LLMOps de produção.

Feedback loops. A melhoria contínua passa agora também por humanos. Recolha interações (likes, correções, classificações), use-as para fine-tuning ou para ajustar prompts e, em sistemas críticos, execute RLHF (Reinforcement Learning from Human Feedback) para codificar preferências no modelo. A infraestrutura tem de capturar e gerir estes dados de feedback de forma segura.

4. Evolução da arquitetura de sistemas e padrões de design

Então, com todos estes novos requisitos, como são realmente construídos os sistemas de ML hoje? Há alguns padrões que aparecem repetidamente.

4.1. Pipelines modulares e orquestração

As ferramentas clássicas (Kubeflow Pipelines, Apache Airflow) continuam presentes para workflows de fine-tuning, batch scoring e retraining periódico. Ferramentas mais recentes — Metaflow, Flyte, ZenML — oferecem workflows Pythonic que se ligam diretamente a bibliotecas de ML. Para inferência de baixa latência, o código da aplicação substitui muitas vezes por completo um motor de workflow pesado.

A mudança prática: os engenheiros já não precisam de sair do seu ambiente de desenvolvimento para gerir o percurso desde os dados até ao deployment.

4.2. Model hubs e registries

A gestão de modelos passou para hubs centralizados. O Hugging Face Hub aloja milhares de modelos, datasets e scripts — um balcão único com arquitetura plug-and-play (obter modelos no arranque). Registries internos como MLflow e SageMaker Model Registry tratam de modelos à medida, frequentemente combinados com modelos fundacionais externos.

A mudança: em vez de construir tudo internamente, os engenheiros planeiam como fazer fine-tuning e adaptar modelos de terceiros. É um modelo mental diferente e muito mais rápido.

4.3. Feature stores vs. bases de dados vetoriais

A camada de dados mudou de forma:

Os feature stores tradicionais tratavam dados estruturados com feature engineering manual. As bases de dados vetoriais modernas (Pinecone, Weaviate, Chroma, Milvus) tratam embeddings de alta dimensionalidade, pesquisa rápida por similaridade, deduplicação semântica e RAG.

Em sistemas reais vai ver ambos: uma vector DB para lookup semântico em dados não estruturados e um data warehouse para analytics estruturada. Não são substitutos.

4.4. Plataformas unificadas (end-to-end)

A complexidade do ML moderno levou as equipas a adotar plataformas end-to-end que abstraem a camada de infraestrutura.

As grandes plataformas cloud apostaram fortemente nisso:

• Google Vertex AI: treino auto-distribuído em pods de TPU, Model Garden com LLMs, deployment com um clique.
• AWS SageMaker: treino distribuído, model parallelism, além de Bedrock para modelos fundacionais alojados.
• Azure ML: treino, deployment e monitorização integrados.

Estas plataformas oferecem serviços geridos como "fazer fine-tune deste modelo com 20B parâmetros nos seus dados" ou "gerar embeddings e indexar o seu texto para retrieval". Ferramentas open-source e de startups complementam-nas: MosaicML (agora Databricks) para treino eficiente e deployment de modelos grandes, Argilla e Label Studio para anotação de dados e criação de datasets de prompts, ClearML e MLflow para experiment tracking ligado à execução de pipelines.

4.5. Inference gateways e APIs

Quando tem modelos de vários tamanhos, precisa de uma forma de encaminhar pedidos de forma inteligente. Isso é um inference gateway:

Útil para routing com base em requisitos de latência, servir modelos diferentes a diferentes níveis de subscrição, fazer testes A/B a novos modelos sobre uma fração do tráfego e recorrer a modelos mais pequenos sob carga elevada. O gateway desacopla a API exposta ao cliente da implementação do modelo, o que torna substituições e experiências muito menos disruptivas.

4.6. Sistemas agentic

O padrão mais recente é o dos AI agents — sistemas que escolhem sequências de ações de forma dinâmica em vez de executarem uma cadeia fixa. Um agent pode chamar ferramentas externas (calculadoras, motores de busca, bases de dados), decidir o seu workflow em runtime com base no contexto e invocar modelos diferentes para subtarefas diferentes.

Frameworks como o modo agent da LangChain, o function calling da OpenAI e sistemas ao estilo AutoGPT tornam isto prático. As práticas operacionais associadas (por vezes chamadas "AgentOps") não são opcionais: monitorização para detetar ações indesejadas, logging detalhado para traçar caminhos de decisão e guardrails para limitar o que o agent pode fazer.

Os sistemas agentic ainda não estão amplamente disseminados em produção, mas uma grande parte da fronteira de LLMOps está aí.

5. Como começar com LLMOps

Se está a começar nisto, o ecossistema de LLMOps é vasto. Eis o percurso que eu sugeriria:

1. Experimente APIs. Comece com OpenAI ou Anthropic para perceber prompt engineering.
2. Construa uma app RAG. Use LangChain ou LlamaIndex para lançar uma demo "Chat with your PDF". Vai tocar em bases de dados vetoriais e retrieval pelo caminho.
3. Experimente fine-tuning. Use Hugging Face para fazer fine-tuning de um modelo pequeno (Llama-3-8B ou Mistral-7B) num dataset personalizado no Google Colab.
4. Faça deploy. Execute vLLM ou Ollama localmente primeiro e depois mova para um cloud provider.

6. Conclusão: de MLOps para LLMOps e além

Os fundamentos de MLOps — automação, reprodutibilidade, deployment fiável — continuam válidos. O que mudou foi a escala (milhares de milhões de parâmetros), a abordagem (adaptar modelos fundacionais em vez de treinar de raiz), a camada de dados (bases de dados vetoriais a partilhar espaço com feature stores) e a superfície de monitorização (segurança de conteúdo, não apenas latência). O LLMOps nasceu dessas mudanças. A próxima vaga — AgentOps e RAGOps — está a fazer o mesmo, uma camada acima.