Infraestrutura AI e PULA

(Secção Tecnologia e Infraestrutura)

Resumo curto

A produção-AI não é um modelo em um único servidor, mas sim um cluster de nós GPU, pool de aceleradores compartilhados, serving unificado, dados/fichas, observabilidade e controle de custo. Para iGaming, é crítico em tempo real: antifrode, personalização, bate-papo, assistentes LLM, recomendações de jogos/promoções. Tijolos básicos: Kubernetes/Slurm para planejamento, isolamento de carga de trabalho, rede de alta velocidade (100/200/400G com RDMA), armazenamento rápido, MLOs maduro, e SLO «de ferro».

1) Mapa arquitetônico

1. Cluster de computação: GPU-nodes (classes A/H, AMD/ROCm, Intel Gaudi etc.), CPU-nodes/fichas.

2. Rede: 100G + Ethernet/IB, RDMA (RoCEv2), topologia NCL, QoS.

3. Armazenamento: objeto (S3- ) , distribuído por POSIX (Ceph/grid), local NVMe-scratch.

4. Dados/fichas: fichestor (online/offline), BB vetorial (ANNE), dinheiro (Redis), filas.

5. Plataforma ML: registro de artefatos e modelos, pipline (CI/CD), controle de versões, fichas como código.

6. Camada de serviço: Triton/KServe/vLLM/text-generation-inference (TGI), A/B/Canary-Depl, recall automático.

7. PII, segredos, auditorias, políticas de exportação, licenças de balança/dataset.

• Monitoramento online (p95 ≤ 50-150 ms) - antifrode, recomendação, classificação.
• O LLM-serving (p95 ≤ 200-800 ms para 128-512 tokens) - bate-papo/agentes/dicas.
• Análise/pré-ensinamento de pacotes - janelas noturnas, métricas offline.
• Fynetuning/adaptação - periodicamente, com prioridade abaixo da linha.

2) Pulas de GPU e planejamento

Modelo de pool

Pool Serving: consultas curtas, batching alto, SLO rigoroso.
Pool «Training/Feintüning»: longa duração, treinamento distribuído (DDP).
Pool «R & D/Experimentos»: quotas/limites, preempção permitida.
Pool «CPU/Pre-/Post-processing»: normalização, tocenização, rerank por CPU.

Planejadores

Kubernetes (+ device-plugin, NodeFeatureDiscovery, taints/tolerations, PriorityClass, PodPriority/Preemption).
Slurm (muitas vezes para treinamento HPC) - pode ser misturado com K8s através de workers individuais.
Fair share e quotas: namespace quotas de GPU, CPU, memória; «bancos» GPU-relógio; limites de neymspace/projeto.

Particionamento de GPU

MIG (Multi-Instance GPU): corte o acelerador em slides isolados (para serving/multi-tenência).
MPS: sharing SM para tarefas menores (monitorar a interferência).
NVLink/PCIe - Considerar a topologia no pinning de poda (Topology Aware Scheduling).

yaml apiVersion: v1 kind: Pod metadata:
annotations:
scheduling. k8s. io/group-name: "ai-serving"
spec:
nodeSelector: { gpu-pool: serving }
tolerations: [{ key: "gpu", operator: "Exists", effect: "NoSchedule" }]
priorityClassName: ai-serving-critical

3) Rede e desempenho entre nós

RDMA (RoCEv2) para NCCL-all-rews; Configurações ECN/PFC, isolamento das classes de tráfego.
Localização: Treinamento dentro de uma única «fábrica» (pod/host/ótica), serving mais próximo do usuário (edge/região).
Controle Congest: perfis tuned, jumbo frames, interfaces pin-ning.

4) Armazenamento e dados

Armazenamento de balanças/artefatos: objeto (versionização, imutabilidade).
Datasets/fichas: Lakehouse (Delta/Iceberg/Hudi) + offline-fitchistor; fichestor online (SLA milissegundos).
BB vetoriais (ANNE): Faiss/SaNN/aceleradores, ou motores vetores vendedores; charding, HNSW/IVF, replicação.
NVMe-cash local: balança aquecida/embeddings para partida a frio.

5) Modelos Serving

Quadros

Triton Inference Server (multi-model, multi-taim, batching dinâmico).
KServe (K8s nativo, autoscaling HPA/KPA, canários).
vLLM/TGI para Tocenização LLM e decodificação de alto desempenho (paged-attence, KV-Cet Offlood).
ONX Runtime/ TensorRT-LLM - para compilação e aceleração.

Otimização

Quantificação: INT8/FP8/INT4 (Percentili/Calibragem, AWQ/GPTQ) - em linha, cuidado para medir a qualidade.
Compilação de grafo: TensorRT, TorchInductor/XLA, fused-kernels.
Batching/microatching: dinâmico e estático; для LLM — continuous batching.
KV KV: Sharing entre solicitações, off para CPU/NVMe em contextos longos.
Decodificação especulativa: modelo draft + verificador para acelerar a linguagem de token.
Limites de token/contexto, paragem precoce, pares-palavras, time-budet para consulta.

Políticas de deploy

A/B, canários, shadow - comparação latência/qualidade/métricas de negócios.
Blue Green, sem downthame.
Rollback por SLO/erro.

6) Treinamento/fintuning

DDP/FSDP/ZeRO: memória/gradiente distribuída, contabilidade NVLink/topologia.
Checkpoints: incessantes/completos, frequência vs I/O.
Mixed Precision: bf16/fp16 + loss scaling; perfilar a estabilidade.
Dataset-charding: Iterador uniforme, replicação por nós.
Prioridades: jobs intermitentes (preemptible) a favor do serving.
Pypline autônoma: data → → eval → minúscula → promoção no PROD com critérios gate.

7) MLOps e plataforma

Registro de modelos: versões, assinaturas, dependências, licenças/permissões de balança.
I/CD modelos: testes de compatibilidade, performance-regressão, quality-gate, deplom seguro.
Composição offline/online (função parity), TTL e backfill.
Data/Modelo Lineage: rastreamento do dataset até o relatório/experiência.
Diretório de prompt/modelo para LLM (versioning).

8) Observabilidade e SLO

• Latitude p50/p95/p99, tocens/s, batch ocupance, queue wait, GPU-util/SM ocupance, memória, erros.
• Especificação LLM: tokens de entrada/saída, comprimento médio de resposta, proporção de falhas de limite, dinheiro-hit KV.
• Qualidade: testes de regressão automáticos (offline), telemetria online (conteúdo-bandeiras, toxicidade, precisão de emissão em amostras de ouro).
• Negócio SLO: conversão de personalização, precisão de antifrode, retenção.

Alerts: crescimento de p99/fila, queda de tocens/s, degradação de batch-fill, esgotamento de VRAM/PCIe-throttle, crescimento de rate-limit falhas.

9) Segurança, Complacência e Privacidade

PII/finded: segmentação de computação e dados por região, criptografia em paz/transito, toquenização.
Segredos/chaves: KMS/Secret Gerente; excluir armazenamento em imagens/código.
Políticas de saída LLM: filtros de segurança, red-teaming, registro de prompt/respostas (com anonimato).
Licenças: conformidade com as licenças de dataset/peso; «no-redistute «/restrições comerciais.
Isolamento dos tenentes: namespace-RBAC, redes, slides MIG, limites e quotas.

10) Custo e finopes

Planeamento de capaciti: perfis de carga (RPS, tokens/segundos), caudas de torneios e campanhas.
Reserva/Spot: Poulas mistas (reserved + spot/preemptil) com tarefas e checkpoint repetidas.
Scale automático: HPA/KPA por RPS/queue depth/GPU-util; «Início quente» com balanças aquecidas.
Zoológico modelo: reduza o número de opções; use a adaptação (LoRA/PEFT) em vez da duplicação completa.
Cash: embeddings/resultados de consultas caras, sharing KV KV para LLM.
Otimização de tokens: compressão de prompt, retrieval-augmented generation (RAG), rerank antes da geração.

11) Multiregião, HA e DR

Ativo/Ativo serving mais próximo do usuário, routing global (latency-based).
Replicar balanças e fichas com verificação de integridade; O raio de dinheiro nos lançamentos.
Plano DR.: perda de AZ/região, evacuação de pool de reserva, controle de dependência de catálogo centralizado.
Dias Chaos: testes de falha GPU-nod/domínios de rede/armazenamento.

12) Modelos de configuração (conceitos)

text dynamic_batching {
preferred_batch_size: [4, 8, 16, 32]
max_queue_delay_microseconds: 2000
}
instance_group { count: 2 kind: KIND_GPU }

yaml spec:
predictor:
canaryTrafficPercent: 20 model:
modelFormat: { name: triton }
resources:
limits: { nvidia. com/gpu: "1" }

--tensor-parallel-size 2
--max-num-seqs 512
--gpu-memory-utilization 0. 9
--enforce-eager

13) especificação LLM: RAG e circuito de busca

Indexação: chanking, embeddings, ANN-charding por 'tenant/local'.
Ranank: modelo leve em um slide CPU/GPU para melhorar a precisão.
Cash prompt/contextos: Dedup, canonalization.
Políticas de citação/responsabilidade para domínios sensíveis (CUS/regras).

14) Folha de cheque de implementação

1. Fixe SLO (p95 latency/tocens/s, disponibilidade) e perfis de carga.
2. Divida o cluster em pool (serving/train/R & D) e digite quotas/prioridades.
3. Inclua RDMA/NCCL e planejamento topologicamente consciente.
4. Configure a balança, o dataset, o fichestor (online/offline), a base de dados vetoriais.
5. Selecione a pilha de serving (Triton/KServe/vLLM) e adicione a batching/KV-dinheiro/quantificação.
6. Execute o registro de modelos, CI/CD, canários/shadow.
7. Coloque observabilidade em sistemas + métricas de negócios, qualidade, rastreamento.
8. Digite as políticas de segurança/PII, licenças, auditorias.
9. Otimize o TCO: reserved + spot, scale automático, cachê, PeFT em vez de clones completos.
10. Prepare a HA/DR. e realize o game-day.

15) Antipattern

«Um GPU grande para tudo», sem pool ou prioridade.
A falta de batching dinâmico e de cachê KV para o LLM → uma explosão de p99 e custo.
Treinamento e serving em uma bala sem preempção → SLO incidentes.
Telemetria qualidade/segurança zero → degradação e riscos imperceptíveis.
Monólito centralizado sem fichador/registro de modelos → sem reprodução.
Ignorar licenças de balança/dados.

Resumo

A bem-sucedida infraestrutura AI é um pool de GPU com planejamento inteligente, alta rede e armazenamento correto, serving eficiente (batching, dinheiro, quantificação, compilação), MLOs maduro e SLO rigoroso. Combinada com segurança/PII, HA/DR. multiregional e finops elaborados, a plataforma oferece um p99 estável, monitorado $/pedido e implementação rápida de novos modelos, desde antifrode até personalização e assistentes LLM.