As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Inferência e orquestração de CPU
## Visão geral do
As instâncias de CPU são uma opção de computação de primeira classe para uma ampla variedade de cargas de trabalho de IA no Amazon EKS. De modelos de linguagem pequena (SLMs) e inferência clássica de ML a pipelines de dados e orquestração de agentes, as CPUs oferecem excelente relação preço-desempenho, ampla disponibilidade de capacidade e semântica familiar de agendamento do Kubernetes.
A CPU e a GPU são complementares, não competitivas. À medida que os pipelines de IA agentes aumentam em complexidade, a superfície da carga de trabalho da CPU cresce com eles: cada chamada de inferência é cercada pela execução de ferramentas, montagem de contexto, pesquisa vetorial, grades de proteção e lógica de orquestração, todas executadas na CPU. Recomendamos criar arquiteturas que usem os dois tipos de computação deliberadamente, colocando cada carga de trabalho no nível em que ela oferece o melhor custo-desempenho.
Nem toda carga de trabalho precisa de uma GPU. Roteamento, classificação, recuperação, incorporação, orquestração e uma parcela crescente da inferência de modelos de linguagem são executados com eficiência na CPU. Current-generation As instâncias de CPU em arm64 e x86 oferecem uma excelente relação preço-desempenho para inferência de ML. Combinado com a consolidação de nós da Karpenter, o escalonamento orientado por eventos da KEDA e o fornecimento de modelos quantizados, isso fornece uma pilha pronta para produção que as equipes da plataforma podem operar sem uma profunda experiência em GPU.
**Este guia é para:**
+ **Engenheiros de plataforma projetam** clusters EKS multilocatários para cargas de trabalho de IA.
+ **Profissionais de ML** avaliando back-ends de inferência para modelos abaixo de 30B de parâmetros.
+ **FinOps equipes** que buscam alavancas de custo concretas sem sacrificar os SLOs.
**O que você aprenderá:**
+ Quais cargas de trabalho de IA pertencem às CPUs e onde as GPUs ou o Trainium são necessários.
+ Como aplicar uma estrutura de decisão quadridimensional a qualquer nova carga de trabalho.
+ Dois padrões de produção: pré-filtragem SLM agente e fazendas modelo de alta densidade.
+ Melhores práticas de otimização: quantização, empacotamento em compartimentos, agendamento spot e escalonamento automático.
**Atenção**
Cada recomendação neste guia deve ser validada empiricamente. A família de instâncias certa (arm64, x86, GPU ou Trainium) depende do modelo, dos dados e do orçamento de latência. Use este guia como um ponto de partida informado e, em seguida, faça um benchmark antes de se comprometer.
## Por que usar CPUs para cargas de trabalho de IA?
Os pipelines de IA de produção distribuem o trabalho em vários níveis de computação. As CPUs lidam com roteamento, classificação, recuperação, orquestração e uma parcela crescente de inferência. Current-generation As instâncias de CPU oferecem uma excelente relação preço-desempenho e um agendamento familiar do Kubernetes, o que as torna uma opção prática para muitas cargas de trabalho de IA.
Três fatores tornam a CPU atraente para essas cargas de trabalho:
### Disponibilidade de capacidade
As instâncias de GPU geralmente exigem reservas de capacidade com semanas de antecedência. As instâncias de CPU estão amplamente disponíveis em todas as regiões da AWS sem plug-ins de dispositivos especializados, sem configuração de DRA e sem particionamento MIG. Quando você precisa escalar rapidamente, a capacidade da CPU é a opção mais disponível.
### Economia
Current-generation As instâncias de CPU oferecem uma excelente relação preço-desempenho para inferência de ML. Para equipes que realizam FinOps análises ou gerenciam clusters multilocatários, a diferença de custo entre CPU e GPU é significativa, especialmente para SLMs quantizados em que a aceleração da GPU fornece retornos decrescentes. Recomendamos o benchmarking entre as famílias de instâncias disponíveis (Graviton, AMD, Intel) para encontrar o melhor custo por token para sua carga de trabalho.
### Simplicidade operacional
Os pods de CPU usam o agendamento padrão do Kubernetes (`requests`, afinidade de nós`limits`, dispersão de topologia). Sem plug-ins de dispositivo, sem agendadores personalizados, sem tipos `nvidia.com/gpu` de recursos. As equipes que desejam executar cargas de trabalho de IA sem um profundo conhecimento em GPU podem alcançar a produção mais rapidamente na CPU.
### Superfície crescente da CPU em pipelines agênticos
Em pipelines de IA agentes, cada chamada de inferência de GPU é cercada pelo trabalho da CPU: execução de ferramentas, montagem de contexto, pesquisa vetorial, pesquisas de incorporação, grades de proteção, validação de respostas, gerenciamento de memória e lógica de orquestração. À medida que os agentes se tornam mais complexos (mais ferramentas, cadeias mais longas, raciocínio em várias etapas), essas cargas de trabalho de CPU crescem de forma superlinear. Protocolos como o MCP (Model Context Protocol) amplificam isso ainda mais: cada chamada de ferramenta MCP aciona a recuperação, transformação e formatação de dados que são executadas inteiramente na CPU.
## CPU vs GPU /Trainium: quando escolher cada um
| Factor | Escolha CPU | Escolha GPU/Trainium |
| --- | --- | --- |
| Tamanho do modelo | SLMs 1-8B (quantizados); incorporações; classificadores | Mais de 8 bilhões para inferência on-line de baixa latência; mais de 70 bilhões em geral |
| SLO de latência | p95 100-500ms aceitável | p95 < 50 ms necessários |
| Simultaneidade | < 100 req/s por endpoint | > 100% req/s sustentado |
| Tipo de workload | Orquestração, recuperação, ETL, pontuação em lote | Inferência, ajuste fino e treinamento on-line |
| Capacity | Disponibilidade imediata, sem reservas | Freqüentemente, requer capacidade reservada |
| Sensibilidade ao custo | A CPU oferece o melhor $/token para cargas de trabalho qualificadas | A GPU amortiza em alta utilização |
| Experiência da equipe | Operações padrão do Kubernetes | Requer conhecimento de operações de GPU |
| Soberania de dados | Inferência de SLM em VPC; trilha de auditoria completa; os dados nunca saem da sua conta | O mesmo se for autogerenciado; não disponível com APIs externas |
**dica**
Esses limites são pontos de partida. Recomendamos executar seu mecanismo de inferência de destino em famílias de instâncias candidatas (arm64 e x86) com seu modelo e padrão de tráfego reais antes de se comprometer com um nível de computação.
## Estrutura de decisão de carga de trabalho
Escolher a computação certa para uma carga de trabalho de IA se resume a quatro dimensões:
1. **Tamanho e precisão do modelo**: a quantização mantém a qualidade dentro de sua faixa aceitável?
1. **SLOs de latência e taxa de transferência**: quais são suas p50/p95 metas e taxas máximas de solicitação?
1. **Tipo de carga de trabalho**: inferência on-line, pontuação em lote, recuperação ou orquestração?
1. **Restrições de custo e capacidade**: FinOps orçamento, disponibilidade regional, estratégia de reserva?
Use a tabela abaixo como uma matriz de decisão.
| Workload | CPU | GPU/Trainium | Observações |
| --- | --- | --- | --- |
| SLMs (parâmetros de 1 a 8B, quantizados) | Escolha padrão. Excelente relação preço-desempenho com latência de 100-500 ms, QPS moderado. Compare todas as famílias de instâncias. | Quando p95 <50ms or concurrency >100 req/s. | Quantização Q4\_K\_M ou Q8\_0 recomendada |
| Modelos médios (parâmetros 8-30B) | Pontuação em lote, assíncrona e offline. Teste a quantização Q4. | Inferência on-line, contextos longos, latência reduzida. | Compare o quarto trimestre em todas as famílias de instâncias |
| LLMs grandes (mais de 70 bilhões de parâmetros) | Non-real-time somente, quantização pesada | Padrão para inferência on-line de produção | Até 70B podem ser executados na CPU; espere alta latência |
| ML clássico//Incorporações/CV | High-density servindo; compartimento em todos os nós. | Visão pesada ou multimodal em grande escala. | TorchServe, o Triton on CPU lida com milhares de modelos. |
| Pipelines de dados//ETL/Dados sintéticos | Ray e Spark na CPU para preparação de dados e engenharia de recursos. | N/A | As CPUs ancoram todo esse estágio de preparação de dados |
| Orquestração de agentes/recuperação de RAG | Network-bound serviços: gateways de API, camadas de proxy, recuperadores, fragmentos. | N/A | Benefícios das instâncias de CPU de alta largura de banda. |
| Fine-tuning /Treinamento | Preparação de dados e orquestração de pipeline. | Treinamento e destilação de modelos. | Híbrido: preparação da CPU, treinamento da GPU, inferência da CPU. |
| Compliance-sensitive inferência (FSI, saúde, governo) | SLMs em VPC na CPU. Os dados permanecem na conta, trilha de auditoria completa. | O mesmo se for autogerenciado na GPU. | A CPU ganha em termos de custo para modelos sub-8B em ambientes regulamentados. |
**Atenção**
Embora seja tecnicamente possível executar mais de 70 bilhões de modelos em CPU com grande quantização (quarto trimestre ou inferior), isso só é viável para cargas de trabalho não em tempo real, off-line ou em lote. Espere taxas de geração de tokens na faixa de um dígito baixo (1 a 5 tokens/sec), requisitos de memória superiores a 40 GB mesmo no quarto trimestre e latência medida em minutos por resposta para saídas mais longas. Para qualquer caso de uso interativo ou sensível à latência, os modelos 70B\+ pertencem à GPU ou ao Trainium.
### Fluxo de trabalho rápido de benchmark
Antes de se comprometer com uma família de instâncias, recomendamos executar um benchmark estruturado comparando suas famílias de CPU candidatas (arm64 e x86) com a GPU em uma única métrica comparável: **custo por** 1.000 consultas na latência p95 desejada. Implante um nó por família com configuração de modelo idêntica (mesma quantização, tamanho de contexto, contagem de threads), teste a carga de cada um e compare. Se uma instância de CPU atender ao seu SLO p95, ela provavelmente ganhará em termos de custo. Se falhar por uma pequena margem, experimente a última geração dessa família antes de mudar para a GPU. Se a latência ainda for muito alta em sua meta de simultaneidade, esse é o sinal para mover a carga de trabalho para a GPU.
## Padrões de produção
### Padrão 1: IA agente — SLM Pre-Filter na CPU com escalonamento de LLM
A maioria dos fluxos de trabalho do agente executa os mesmos padrões estreitos repetidamente: classificar a solicitação, escolher uma ferramenta, extrair dados estruturados e validar uma resposta. Essas tarefas não exigem um modelo de parâmetros 70B.
Pesquisas sobre SLMs ([ar Xiv:2506.02153](https://arxiv.org/abs/2506.02153)) demonstram que modelos abaixo dos parâmetros de 10B, quando especializados em um domínio, podem igualar ou exceder grandes LLMs em subtarefas restritas e, ao mesmo tempo, serem executados com eficiência na CPU a um custo e latência significativamente menores. Quando um modelo é ajustado para um domínio específico, seu tamanho menor pode torná-lo mais preciso e barato do que invocar um LLM de uso geral.
Nesse padrão, um SLM na CPU processa a maioria das solicitações de ponta a ponta. Uma camada de roteamento (também executada na CPU) encaminha somente casos genuinamente complexos para um LLM. GPU-hosted
**Componentes em execução na CPU:**
+ Gateway de API/camada de proxy — lida com autenticação, roteamento e limitação de taxa
+ Orquestrador de agentes — gerencia as chamadas e o estado da ferramenta
+ [https://ollama.com](https://ollama.com)
+ Recuperação vetorial — OpenSearch em nós de CPU
**Componentes em GPU/Trainium:**
+ Grande LLM para síntese complexa, raciocínio de longo contexto
**Por que esse padrão funciona:** em muitos fluxos de trabalho de agentes, 60 a 80% das solicitações podem ser classificadas ou extraídas por um SLM. Para cada chamada de LLM que você evita, você também evita o trabalho envolvente da CPU de montar uma grande janela de contexto, executar proteções em uma resposta longa e gerenciar estados complexos. O nível da CPU é dimensionado independentemente do nível da GPU.
As categorias de carga de trabalho de CPU em um pipeline agente típico incluem: execução de ferramentas (chamadas de servidor MCP, chamadas de API, consultas de banco de dados), montagem de contexto, pesquisas de pesquisa e incorporação de vetores, lógica de orquestração e planejamento, grades de proteção e filtragem de segurança, validação e formatação de respostas, gerenciamento de memória e estado do agente e. logging/observability
Esse padrão também se encaixa em um ciclo de vida de ajuste fino: coletar dados de domínio nos nós da CPU, ajustar a GPU e, em seguida, implantar o modelo quantizado de volta na CPU para inferência a um custo substancialmente menor do que um endpoint LLM. Uma pesquisa da LoRa Land ([ar Xiv:2405.00732](https://arxiv.org/abs/2405.00732)) mostra que os modelos 7B ajustados superam o desempenho GPT-4 na maioria das tarefas específicas de domínio testadas, tornando o caminho de “ajustar um modelo pequeno e executá-lo na CPU” viável para muitos casos de uso de produção.
### Padrão 2: High-Density CPU Model Farm
Os pipelines de produção de ML implantam rotineiramente centenas ou milhares de modelos menores: incorporações, recomendadores, classificadores, BERT-based pontuadores e modelos de visão computacional. Individualmente leves, esses modelos se tornam caros quando cada um recebe seus próprios recursos de GPU.
Recomendamos o fornecimento de CPU de alta densidade (agrupando vários modelos por nó usando TorchServe ou Triton na CPU), com o Karpenter gerenciando o ciclo de vida do nó e escalando o KEDA na carga observada.
Esse padrão se estende naturalmente às arquiteturas RAG: a geração de incorporação, a fragmentação de documentos e a recuperação de OpenSearch todos são executados de forma econômica nos nós da CPU, fornecendo resultados a um GPU-hosted LLM somente na etapa final da geração. O farm de CPUs lida com o volume; a GPU lida com a complexidade.
Para setores regulamentados (serviços financeiros, saúde, governo), esse padrão é especialmente atraente: centenas de modelos especializados executados em VPC em CPU, com trilhas de auditoria completas e dados que nunca saem da conta. O requisito de conformidade para inferência autogerenciada se alinha naturalmente à vantagem de custo da CPU para modelos sub-8B.
## Melhores práticas de otimização
### Quantização
Executar um modelo 7B com BF16 completo na CPU é impraticável; executá-lo na quantização do quarto trimestre é viável e econômico. Entender por que a quantização ajuda na CPU é fundamental para tomar boas decisões de infraestrutura.
**Por que a quantização é importante para a inferência da CPU.** A inferência da CPU é limitada à largura de banda da memória, não à computação. Durante a fase de decodificação (gerando tokens um por vez), todos os pesos do modelo são lidos da RAM para cada token produzido. A CPU passa a maior parte do tempo esperando que os dados cheguem da memória, sem fazer contas. Um modelo 7B no BF16 tem aproximadamente 14 GB; no Q4\_K\_M, ele diminui para cerca de 4 GB. Como o gargalo é mover bytes da RAM para os núcleos da CPU, um modelo 3,5x menor lê 3,5x mais rápido, o que se traduz quase diretamente em geração de tokens 3,5x mais rápida. É por isso que a quantização é a otimização mais impactante para inferência de CPU e por que novas gerações de CPU com mais canais de memória produzem inferências mais rápidas, mesmo com a mesma velocidade de clock.
Recomendamos criar seu mecanismo de inferência com back-ends otimizados para arquitetura (ARM NEON/SVE2 para arm64, AVX-512/AMX para x86), definir a contagem de threads igual à contagem de vCPUs e selecionar os formatos de quantização Q4\_K\_M ou Q8\_0.
| Quantização | Impacto na qualidade | Taxa de transferência versus BF16 | Caso de uso |
| --- | --- | --- | --- |
| Q4\_K\_M | Baixo (delta de perplexidade de 1-3%, dependente do modelo) | \~ 4-5 vezes mais rápido | Padrão de produção para SLMs |
| Q8\_0 | Insignificante | \~2x mais rápido | Quality-sensitive tarefas |
| Q5\_K\_M | Muito baixo | \~3,5x mais rápido | Equilíbrio entre qualidade e velocidade |
| BF16 | Nenhum | 1x (linha de base) | Evite usar CPU para modelos 7B\+ |
Para modelos sub-2B, a CPU vence em preço-desempenho versus GPU. Esses modelos são pequenos o suficiente para que a aceleração da GPU ofereça benefícios mínimos, enquanto o custo por hora é significativamente maior. Se sua carga de trabalho puder usar um modelo sub-2B, a CPU é o padrão recomendado.
**Architecture-specific otimizações:** no arm64, as instâncias do Graviton da geração atual oferecem suporte ao SVE2. Crie seu mecanismo de inferência com o `-march` sinalizador apropriado para seu alvo. No x86, as instâncias AMD EPYC oferecem suporte AVX-512, e as instâncias Intel Xeon adicionam AMX para aceleração de matriz. Como a inferência está limitada à largura de banda da memória, as novas gerações de CPU com mais canais de memória DDR5 produzem inferências mais rápidas, mesmo com a mesma velocidade de clock. Ao escolher os tipos de instância, priorize a largura de banda da memória em relação à contagem de núcleos.
**Dimensionamento da janela de contexto:** para cargas de trabalho de classificação e roteamento, as entradas geralmente têm menos de 200 tokens e as saídas são de 2 a 3 tokens. Definir uma pequena janela de contexto (por exemplo, 512 tokens) em vez do padrão 2048 reduz o uso da memória cache em KV e melhora a latência por solicitação. Só aumente a janela de contexto se suas entradas forem realmente longas.
**Flash Attention:** ative o Flash Attention se seu mecanismo de inferência for compatível. O Flash Attention reduz o uso de memória para o cálculo da atenção, evitando a materialização da matriz de atenção completa. Na CPU, o benefício é menor do que na GPU, mas ainda ajuda em entradas mais longas.
**dica**
A degradação da qualidade do Q4\_K\_M varia de acordo com o modelo e a tarefa. Sempre avalie em seu próprio conjunto de dados antes de implantar na produção.
### Bin-packing para uma porção densa
Para modelos clássicos de ML e incorporação (normalmente <500 MB cada), a meta é a **densidade máxima de pods por nó com latência final estável**. Duas coisas determinam se você conseguirá isso: solicitações de recursos precisas e segmentação controlada.
Baseie `requests` seu uso observado de p50-p90 sob carga realista. Use Goldilocks, recomendações de VPA ou histogramas de Prometheus de um teste de carga. Os padrões quase sempre estão errados nas duas direções.
As bibliotecas de ML (PyTorchONNX Runtime, MKL, OpenBLAS) geram o máximo de threads que conseguem ver as vCPUs no nó, não as CPUs alocadas ao pod. Em um nó denso com 20 pods, cada pod tenta gerar 32 threads. O nó falha na troca de contexto e nos picos de latência p99. Corrija isso explicitamente:
```
env:
- name: OMP_NUM_THREADS
value: "2" # match your cpu request (2000m = 2 threads)
- name: MKL_NUM_THREADS
value: "2"
- name: OPENBLAS_NUM_THREADS
value: "2"
- name: INTRA_OP_NUM_THREADS # PyTorch / ONNX Runtime
value: "2"
- name: NUM_INTER_THREADS
value: "1" # keep inter-op parallelism minimal
```
Defina cada valor igual ou inferior à sua solicitação de CPU. Para pods com mais de 4 núcleos, faça um benchmark a partir de 2 a 4 threads. Muitos modelos pequenos têm melhor desempenho com menos threads devido à eficiência do cache. Se você usa o HPA com muitos pods finos, 1-2 threads por cápsula quase sempre vencem.
### Programação e otimização de custos
Duas práticas se combinam para reduzir significativamente os custos de inferência de CPU: instâncias spot com consolidação do Karpenter e imagens de contêiner com várias arquiteturas.
A consolidação do Karpenter funciona bem para inferência de CPU porque os pods de inferência sem estado atrás de uma fila ou balanceador de carga toleram interrupções normalmente. Configure a consolidação para atuar em nós subutilizados com um orçamento que limite a interrupção simultânea (por exemplo, 20% dos nós por vez) para evitar quedas de capacidade durante a redução. A `nodePool` especificação do Karpenter permite que você misture Spot e On-Demand capacidade em um único pool, com o Spot como opção preferida e On-Demand como alternativa.
Construir imagens em vários arcos (`arm64`e`amd64`) desbloqueia isso ainda mais. Com as duas arquiteturas disponíveis, a Karpenter pode selecionar uma variedade completa de famílias de instâncias (Graviton, AMD, Intel) com base no preço e na disponibilidade em tempo real. Isso é especialmente valioso para cargas de trabalho Spot, nas quais a diversificação entre tipos e arquiteturas de instância reduz a frequência de interrupção. Use um pipeline `docker buildx` de CI com compilações multiplataforma para produzir um único manifesto que cubra as duas arquiteturas.
### Otimização da inicialização do contêiner
Quando o Karpenter provisiona um novo nó (ampliação, substituição do Spot), o tempo de execução do contêiner precisa extrair a imagem de inferência antes que o pod possa ser iniciado. Para imagens de inferência de vários GB, isso pode adicionar de 30 a 60 segundos à inicialização do pod.
[Recomendamos usar o [Bottlerocket](https://bottlerocket.dev) como sistema operacional de nó para cargas de trabalho de inferência, combinado com o snapshotter SOCI em modo paralelo.](https://github.com/awslabs/soci-snapshotter) pull/unpack O SOCI substitui a extração sequencial padrão da camada por downloads paralelos baseados em blocos, reduzindo significativamente o tempo de extração de imagens para imagens grandes. Nenhuma alteração nas imagens do contêiner é necessária.
Para obter orientações detalhadas sobre configuração, consulte a seção [Desempenho](aiml-performance.md) deste guia, que aborda a configuração do SOCI, a pré-extração de instantâneos do EBS e as estratégias de cache de tempo de execução do contêiner.
### Observabilidade
Sem observabilidade na camada do modelo, você está escalando cegamente. Recomendamos expor as métricas do Prometheus para cada serviço de inferência e usá-las para impulsionar o dimensionamento e os painéis operacionais do KEDA.
A maioria dos servidores de inferência (llama.cpp, vLLM, Triton TorchServe) expõe Prometheus-compatible métricas em um endpoint. `/metrics` Os nomes das métricas variam de acordo com o servidor, mas os conceitos são os mesmos.
**Principais métricas a serem instrumentadas:**
| Categoria métrica | Description | Limite de alerta |
| --- | --- | --- |
| Processamento de solicitações//em voo | Número de solicitações que estão sendo tratadas atualmente pelo servidor. | Use para escalonamento (consulte a seção de escalonamento automático abaixo) |
| Solicitações enfileiradas/adiadas | Número de solicitações aguardando um slot de processamento. | Gatilho de escala. Qualquer fila sustentada significa que a latência está prestes a diminuir. |
| Taxa de transferência de tokens | Tokens gerados por segundo. | Alerta se a produtividade cair abaixo de 50% da linha de base sob carga |
| Latência da solicitação | End-to-end histograma de latência (processamento imediato \+ geração de tokens). | Alerta sobre p95 excedendo seu SLO |
| Utilização do cache KV | Quão cheio está o cache de valores-chave (0,0 a 1,0). Aproximar-se de 1.0 significa que o servidor começará a rejeitar ou enfileirar solicitações. | Alerta em 85% \+ |
| Memória de contêiner | Memória RSS por pod (`container_memory_working_set_bytes`). | Alerta a 85% do limite |
### Escalonamento automático: escale com base na profundidade da fila, não na utilização da CPU
A utilização da CPU é uma métrica de saturação. Ele aumenta *depois que a* latência já diminuiu. Quando o escalonamento automático baseado na utilização reage, os usuários já estão esperando.
A profundidade da fila (solicitações deferred/waiting) é um indicador importante. Ela aumenta *antes* que a latência diminua, porque as solicitações começam a ser enfileiradas quando todos os slots de processamento estão ocupados. A escalabilidade da profundidade da fila significa que novas réplicas são provisionadas enquanto as existentes ainda estão respondendo normalmente.
O KEDA suporta a combinação de várias métricas em uma única fórmula de escala usando `scalingModifiers` (requer KEDA 2.12\+). O padrão recomendado para cargas de trabalho de inferência é combinar solicitações em andamento com solicitações em fila, ponderando muito a métrica da fila:
```
advanced:
scalingModifiers:
formula: "running + (waiting * 10)"
target: "25"
activationTarget: "5"
```
A fórmula `running + (waiting * 10)` significa que até três solicitações em fila elevam a métrica combinada para 55, bem acima da meta de 25. O escalonamento entra em ação antes que a latência diminua. O `activationTarget` de 5 evita que o ruído acione eventos desnecessários de escala a partir de zero.
## Avaliação da qualidade do modelo para cargas de trabalho CPU-First
Implantar um SLM quantizado na CPU é uma decisão de custo e latência. Só faz sentido se o modelo ainda produzir resultados corretos e úteis para sua carga de trabalho.
Modelos menores ou quantização reduzem os custos de computação, mas podem reduzir a qualidade. O impacto varia. As cargas de trabalho que funcionam bem na CPU (classificação, extração, roteamento, resumo, incorporações) geralmente mantêm boa qualidade na B-7B faixa 3 com quantização e solicitação adequadas.
### O que avaliar
Cargas de trabalho diferentes se degradam de maneiras diferentes:
| Workload | O que pode degradar | O que medir |
| --- | --- | --- |
| Intenção ou classificação do ingresso | Erros em entradas ambíguas | Precisão, F1 por classe |
| Extração estruturada (JSON) | Campos ausentes ou esquema errado | Correspondência exata, validade do esquema |
| Respostas do RAG | Alucinações ou ignorando o contexto | Fidelidade, relevância da resposta |
| Resumo | Fatos ausentes ou cobertura deficiente | ROUGE-L, BertScore, avaliação humana |
| Roteamento de agentes | Selecionar a ferramenta errada | Precisão da ferramenta |
| Incorporações | Pior qualidade de recuperação | Lembre-se de @K, NDCG |
### Um fluxo de trabalho prático de avaliação
Recomendamos criar uma verificação de qualidade antes da produção, semelhante à forma como você executaria um teste de carga antes de escolher um tipo de instância. O fluxo de trabalho tem quatro estágios:
1. **Crie um conjunto de dados de** avaliação — Crie um pequeno conjunto de dados de avaliação (100-300 exemplos rotulados) a partir de sua carga de trabalho real. Evite benchmarks genéricos como o MMLU, que medem o raciocínio geral em vez de sua tarefa real.
1. **Estabeleça a linha de base** — execute o conjunto de dados em um modelo confiável (por exemplo, um grande LLM que você sabe que produz resultados corretos).
1. **Teste o modelo de CPU** — execute o mesmo conjunto de dados em seu SLM quantizado e compare.
1. **Avalie** — defina seu limite de qualidade antes de testar, por exemplo, “Precisão do SLM dentro de 5 pontos percentuais da linha de base”. O limite certo depende da tarefa: um classificador revisado por humanos pode tolerar mais erros do que um sistema que toma decisões automáticas.
### Como recuperar a qualidade
Se o modelo tiver um desempenho ruim, experimente estes em ordem de esforço:
+ **Adicione alguns exemplos breves no prompt**: custo zero, imediato. Incluir de 3 a 5 exemplos rotulados no prompt geralmente preenche a lacuna nas tarefas de classificação e extração.
+ **Use um formato de quantização de maior qualidade**: mudar do quarto para o quarto trimestre geralmente restaura grande parte da qualidade perdida, ao custo de aproximadamente 2x mais memória e menor taxa de transferência.
+ **Use roteamento híbrido**: deixe o SLM lidar com casos simples e enviar entradas difíceis para um modelo maior. Essa é uma mudança de arquitetura, mas mantém o custo da CPU baixo para a maior parte do tráfego.
+ **Fine-tune o modelo em seu domínio**: a opção mais cara, mas a mais eficaz. Uma pesquisa da LoRa Land ([ar Xiv:2405.00732](https://arxiv.org/abs/2405.00732)) descobriu que os modelos 7B ajustados superam o desempenho GPT-4 na maioria das tarefas específicas de domínio testadas.
## Referências
+ [Documentação do Amazon EKS](https://docs.aws.amazon.com/eks/)
+ [Guia do desenvolvedor do AWS Graviton](https://github.com/aws/aws-graviton-getting-started)
+ [Documentação do Karpenter](https://karpenter.sh/docs/)
+ [Documentação da KEDA](https://keda.sh/docs/)
+ [llama.cpp](https://github.com/ggerganov/llama.cpp)
+ [Documentação do vLLM](https://docs.vllm.ai)
+ [Ollama](https://ollama.com)
+ [Documentação do Ray Server](https://docs.ray.io/en/latest/serve/)
+ [ OpenSearch Serviço Amazon](https://docs.aws.amazon.com/opensearch-service/)
+ [Melhores práticas do AWS Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html)
+ [LoRa Land: Fine-Tuned Open-Source LLMs que superam GPT-4](https://arxiv.org/abs/2405.00732)
+ [Especificação do Model Context Protocol (MCP)](https://modelcontextprotocol.io)
+ [Modelos de linguagem pequena para Agentic AI (NVIDIA)](https://arxiv.org/abs/2506.02153)
+ [Snapshotter SOCI](https://github.com/awslabs/soci-snapshotter)
+ [Sistema operacional Bottlerocket](https://bottlerocket.dev)
+ [IA no EKS: otimização de inicialização de contêineres](https://awslabs.github.io/ai-on-eks/docs/guidance/container-startup-time/accelerate-pull-process)