Como o EU AI Act afeta o fine-tuning de LLMs no Amazon SageMaker AI

O que mudou com o EU AI Act em agosto de 2025

Em 2 de agosto de 2025, o EU AI Act passou a vigorar com novos requisitos para organizações que trabalham com modelos de inteligência artificial de propósito geral — os chamados modelos GPAI (Inteligência Artificial de Propósito Geral). Uma das exigências centrais afeta diretamente quem realiza fine-tuning de grandes modelos de linguagem (LLMs, na sigla em inglês): é preciso rastrear o consumo computacional do treinamento, medido em operações de ponto flutuante, ou FLOPs (Operações de Ponto Flutuante).

O motivo é simples: a regulação precisa distinguir quem apenas usa um modelo existente (o chamado usuário downstream) de quem efetivamente cria um novo modelo — e, portanto, assume as responsabilidades legais de um provedor GPAI. Essa distinção depende diretamente de quanto processamento computacional foi consumido durante o fine-tuning.

A regra de um terço e os limiares de FLOPs

O EU AI Act adota a chamada “regra de um terço”: se o fine-tuning consumir mais de um terço do processamento computacional usado no pré-treinamento original do modelo, a organização passa a ser tratada como provedora GPAI — com todas as obrigações que isso implica.

A lógica regulatória por trás desse limite de 30% é que modificações que consomem mais de um terço do processamento original tendem a alterar significativamente o comportamento do modelo, criando efetivamente um novo modelo com riscos distintos.

Na prática, existem três cenários e limiares aplicáveis:

  • Processamento de pré-treinamento conhecido e ≥ 10²³ FLOPs: o limiar é 30% do processamento real de pré-treinamento.
  • Processamento de pré-treinamento desconhecido ou < 10²³ FLOPs: aplica-se o limiar padrão de 3,3×10²² FLOPs.
  • Modelos de Risco Sistêmico (pré-treinamento ≥ 10²⁵ FLOPs): o limiar é 3,3×10²⁴ FLOPs (se o processamento base for desconhecido).

Como os provedores de modelos raramente publicam os FLOPs exatos de pré-treinamento, a maioria das organizações se enquadra no segundo cenário — o limiar padrão de 3,3×10²² FLOPs.

Para orientar a tomada de decisão, vale seguir este fluxo:

  • Você conhece os FLOPs de pré-treinamento do modelo base? Se não, aplique diretamente o limiar padrão de 3,3×10²² FLOPs.
  • Se sim: o pré-treinamento é ≥ 10²⁵ FLOPs? Use o limiar de Risco Sistêmico (3,3×10²⁴ FLOPs).
  • Se não: o pré-treinamento é ≥ 10²³ FLOPs? Use 30% do valor real.
  • Se também não: aplique o limiar padrão de 3,3×10²² FLOPs.

Como exemplo prático: o fine-tuning do Llama-3-70B — cujo pré-treinamento estimado é de pelo menos 1,5×10²⁴ FLOPs — define o limiar em 4,5×10²³ FLOPs. Superar esse valor significa assumir as obrigações completas de provedor GPAI, que incluem divulgar detalhes da arquitetura e do processo de treinamento, publicar a lista de fontes de dados utilizadas e demonstrar conformidade com a legislação europeia de direitos autorais. O descumprimento pode resultar em multas de até €15 milhões ou 3% do faturamento global anual, o que for maior.

Por que o rastreamento manual de FLOPs é um problema

Calcular FLOPs manualmente apresenta três desafios concretos. Primeiro, as fórmulas são complexas e variam dependendo do método de treinamento: fine-tuning completo ou métodos eficientes em parâmetros, como LoRA (Adaptação de Baixo Posto), que atualizam apenas um subconjunto dos parâmetros do modelo. Segundo, determinar o limiar aplicável é difícil porque os valores de processamento de pré-treinamento raramente são publicados pelos provedores. Terceiro, manter um histórico de auditoria — um registro permanente das métricas de conformidade para revisão regulatória — ao longo de múltiplos jobs de treinamento gera sobrecarga operacional considerável.

Erros nesse cálculo podem mudar completamente a classificação regulatória da organização, com consequências legais e financeiras significativas.

O Fine-Tuning FLOPs Meter: solução open source da AWS

Para resolver esses desafios, a AWS disponibilizou o toolkit open source Fine-Tuning FLOPs Meter, integrado ao Amazon SageMaker AI. A ferramenta está disponível no repositório Amazon SageMaker Generative AI recipes e se integra a fluxos de treinamento baseados em Hugging Face.

O toolkit cobre três estágios do ciclo de fine-tuning:

  • Estimativa pré-treinamento (opcional): um utilitário independente permite comparar os FLOPs esperados entre diferentes métodos (LoRA, Spectrum e fine-tuning completo) antes de lançar o job. Útil para planejamento e para verificar o quão próxima uma configuração está do limiar regulatório.
  • Rastreamento em tempo real (funcionalidade principal): usa um TrainerCallback do Hugging Face para calcular FLOPs durante o treinamento, combinando análise baseada na arquitetura do modelo e monitoramento de hardware via NVML (Biblioteca de Gerenciamento NVIDIA).
  • Trilha de auditoria pós-treinamento: ao final do treinamento, gera automaticamente um arquivo JSON com as métricas completas de conformidade, que pode ser persistido no Amazon Simple Storage Service (Amazon S3) ou no Amazon DynamoDB.

A ativação do rastreamento exige apenas uma linha no arquivo de configuração YAML da receita:

compute_flops: true

Como os FLOPs são calculados

O toolkit implementa dois métodos de cálculo, ambos executados automaticamente:

Método analítico (baseado em arquitetura)

É o método primário para fins de conformidade regulatória. O EU AI Act (Seção A.2.1) descreve a fórmula padrão para transformers densos:

C ≈ 6 × P × D

Onde P é o número de parâmetros e D é o número de tokens de treinamento. Essa fórmula assume fine-tuning completo. Para métodos eficientes em parâmetros como LoRA ou Spectrum, o toolkit usa uma fórmula aprimorada:

F_ft = (4 × N_total + 2 × N_trainable) × tokens_processed

O detalhamento é o seguinte: 4 × N_total representa o passo forward (2×) mais o cálculo do gradiente no passo backward por todas as camadas (2×), incluindo as congeladas; 2 × N_trainable representa o cálculo do gradiente apenas para os pesos treináveis. Para fine-tuning completo, onde todos os parâmetros são treináveis, a fórmula se reduz a 6 × N × D, equivalente à fórmula da regulação europeia.

Método baseado em hardware (limite superior conservador)

Usa monitoramento de GPU via NVML com a fórmula:

C = N_gpus × L × H × U

Onde N_gpus é o número de GPUs, L é a duração do treinamento em segundos, H é o desempenho teórico de pico (FLOPs) e U é a utilização. O toolkit usa U = 1.0 (100% de utilização) para produzir um limite superior conservador.

Lógica de limiar

A função determine_compliance_threshold() implementa a lógica do EU AI Act:

EU_AI_ACT_GPAI_THRESHOLD = 1e23 # 10²³ FLOPs
EU_AI_ACT_DEFAULT_THRESHOLD = 3.3e22 # Um terço de 10²³

if pretrain_flops is None or pretrain_flops < EU_AI_ACT_GPAI_THRESHOLD:
    threshold = EU_AI_ACT_DEFAULT_THRESHOLD # "default_3.3e22"
else:
    threshold = 0.30 * pretrain_flops # "30pct_of_actual_pretraining"

Integração com jobs de treinamento no SageMaker AI

O FLOPs Meter funciona como um TrainerCallback do Hugging Face. Ao iniciar o treinamento, o script verifica o flag compute_flops e, se ativado, inicializa o FlopsMeterCallback com a contagem de parâmetros do modelo e a variável de ambiente opcional PRETRAIN_FLOPS. Um TokenCountingSFTTrainer customizado substitui o SFTTrainer padrão para contar tokens não-padding a cada passo de treinamento.

Veja o trecho de código de inicialização do callback:

n_total = sum(p.numel() for p in model.parameters())
n_trainable = sum(p.numel() for p in model.parameters() if p.requires_grad)

flops_cb = FlopsMeterCallback(
    pad_token_id=tokenizer.pad_token_id,
    pretrain_flops=pretrain_flops,  # from PRETRAIN_FLOPS env var
    sample_nvml=True,
    n_total=n_total,
    n_trainable=n_trainable,
    model_name=model_args.model_name_or_path,
    num_epochs=training_args.num_train_epochs,
)

Ao final do treinamento, o callback grava um arquivo flops_meter.json em /opt/ml/output/. O pipeline então faz o upload para o Amazon S3 e persiste os dados no Amazon DynamoDB, criando uma trilha de auditoria permanente.

Exemplo prático: Llama-3.2-3B no SageMaker AI

O walkthrough demonstrado pela AWS utiliza o modelo meta-llama/Llama-3.2-3B-Instruct (3,21 bilhões de parâmetros). Como a Meta não publicou os FLOPs exatos de pré-treinamento desse modelo, o caminho do limiar padrão se aplica automaticamente: 3,3×10²² FLOPs.

A configuração de receita para Llama-3.2-3B com LoRA e rastreamento de FLOPs ativado é:

model_name_or_path: meta-llama/Llama-3.2-3B-Instruct
dataset_id_or_path: your-dataset.jsonl
use_peft: true
compute_flops: true
per_device_train_batch_size: 8
num_train_epochs: 10
learning_rate: 2e-5
peft_config:
  r: 8
  lora_alpha: 16
  target_modules: ["q_proj", "v_proj"]

Para lançar o job de treinamento via SDK Python do SageMaker:

from sagemaker.modules.configs import Compute, SourceCode
from sagemaker.modules.train import ModelTrainer

training_instance_type = "ml.g5.4xlarge"

pytorch_image_uri = sagemaker.image_uris.retrieve(
    framework="pytorch",
    region=sess.boto_session.region_name,
    version="2.7.1",
    instance_type=training_instance_type,
    image_scope="training",
)

source_code = SourceCode(
    source_dir="./sagemaker_code",
    command="bash sm_accelerate_train.sh --config hf_recipes/meta-llama/Llama-3.2-3B-Instruct--vanilla-peft-qlora.yaml",
)

compute = Compute(
    instance_type=training_instance_type,
    instance_count=1,
    volume_size_in_gb=300,
)

model_trainer = ModelTrainer(
    training_image=pytorch_image_uri,
    source_code=source_code,
    compute=compute,
    role=role,
    environment={
        "FLOPS_METER_NVML": "1",
    },
)

model_trainer.train()

Como os FLOPs de pré-treinamento não são conhecidos para esse modelo, a variável de ambiente PRETRAIN_FLOPS é omitida e o limiar padrão é aplicado automaticamente.

Documentação de conformidade gerada

Ao término do treinamento, o toolkit gera um arquivo flops_meter.json com as métricas necessárias para documentação regulatória:

{
  "Flops_architecture": "1.45e+13",
  "Flops_hardware": "1.52e+15",
  "Flops_original": null,
  "N_total": 1585294704,
  "N_trainable": 680094720,
  "threshold_type": "default_3.3e22",
  "threshold_value": "3.30e+22",
  "pct_of_pretrain": 0.000000439,
  "exceeds_30pct": false,
  "tokens_processed": 2150,
  "model_name": "meta-llama/Llama-3.2-3B-Instruct",
  "num_epochs": 10,
  "training_duration_seconds": 245.30,
  "gpu_name": "NVIDIA A10G",
  "instance_type": "ml.g5.4xlarge",
  "training_job_name": "pipelines-abc123-TrainingStep-xyz789",
  "recipe_config": "hf_recipes/meta-llama/Llama-3.2-3B-Instruct--vanilla-peft-qlora.yaml"
}

O campo Flops_architecture deve ser usado como métrica primária de conformidade — ele reflete com precisão a configuração real do treinamento. O campo Flops_hardware fornece um limite superior conservador, útil como margem de segurança para relatórios mais cautelosos. O campo exceeds_30pct é o indicador booleano para avaliação rápida de conformidade.

O que fazer se o limiar for ultrapassado

Se o relatório de conformidade mostrar exceeds_30pct: true, a organização é classificada como provedora GPAI sob o EU AI Act. Os próximos passos incluem: documentar a arquitetura do modelo e o processo de treinamento; preparar uma lista pública das fontes de dados de treinamento; demonstrar conformidade com a legislação europeia de direitos autorais; e considerar a consulta a assessoria jurídica especializada em regulações de IA da União Europeia.

Vale notar que existem obrigações adicionais caso o modelo GPAI seja classificado como de Risco Sistêmico. Uma alternativa técnica é reduzir o escopo do treinamento — menos épocas, dataset menor ou migração para LoRA — para permanecer abaixo do limiar.

Escala para cargas de trabalho em produção

O exemplo de demonstração utilizou um dataset pequeno (2.150 tokens). Em produção, o processamento típico envolve milhões de tokens. Para referência: o fine-tuning do Llama-3.2-3B em 1 milhão de tokens com LoRA resulta em aproximadamente 6,7×10¹⁸ FLOPs — bem abaixo do limiar de 3,3×10²². Já o fine-tuning completo no mesmo dataset consome aproximadamente 1,9×10¹⁹ FLOPs, aproximando-se mais do limiar.

Como regra prática, a preocupação com conformidade começa quando os FLOPs atingem 10²¹ ou mais — cerca de 3% do limiar padrão. A partir desse ponto, recomenda-se executar o utilitário de estimativa pré-treinamento antes de cada job. Para a maioria dos jobs de fine-tuning com LoRA em modelos abaixo de 10 bilhões de parâmetros, o resultado permanece bem abaixo do limiar mesmo com milhões de tokens de treinamento.

Fonte

Navigating EU AI Act requirements for LLM fine-tuning on Amazon SageMaker AI (https://aws.amazon.com/blogs/machine-learning/navigating-eu-ai-act-requirements-for-llm-fine-tuning-on-amazon-sagemaker-ai/)

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *