opção
LarLar Skill Ciência de dados e ML tao-finetune-huggingface-model

tao-finetune-huggingface-model

NVIDIA/skills NVIDIA/skills

Ajuste fino de modelos CV, VLM ou LLM do HuggingFace em GPUs NVIDIA locais usando um contêiner PyTorch do NGC, com suporte para treinamento completo ou LoRA, manipulação de conjuntos de dados e envio opcional do modelo para o Hub.

...Expandir tudo
1
Tempo atualizado 29 de Setembro de 2026

tao-finetune-huggingface-model

Ajuste fino de GPU NVIDIA local para modelos do HuggingFace, fundamentado em documentação obtida em tempo real, com referências curadas como rede de segurança. Um contêiner NGC, alguns scripts focados, um envio para o HF Hub. Siga as regras deste arquivo; não improvise.

Ordem de autoridade (da mais alta para a mais baixa):

  1. Entrada do usuário — model_id, dataset_id, training_method, substituições de config.yaml explícitos.
  2. Pesquisa em tempo real — cartão do modelo, exemplo do repositório HF, script de ajuste fino do autor, documentação de tarefas do HF, artigo; sempre obtido (Passo 3 + references/research-priorities.md).
  3. Referências curadas (references/*.md) — fallback quando a pesquisa em tempo real está silenciosa/ambígua.
  4. Memória de dados de treinamento — último recurso; suspeito, verifique contra (2)/(3).

A resolução de conflitos entre (2) e (3) e a nota de discrepância na linha de origem estão em references/research-priorities.md.

Entradas

Obrigatorios:

  • model_id — ID do modelo do HuggingFace, por exemplo, google/vit-base-patch16-224

Credenciais condicionais (lidas do ambiente da sessão, exportadas antes de iniciar quando presentes):

  • HF_TOKEN — apenas quando o modelo/dataset é gated (leitura) ou push_to_hub está ativado (escrita); público + público + push_to_hub: false não precisa. O valor nunca é lido — presença apenas via [ -n "$HF_TOKEN" ].
  • WANDB_API_KEY, WANDB_PROJECT — apenas quando o WandB está habilitado; WANDB_MODE=disabled opta por não participar.

Dataset — exatamente um:

  • dataset_id — ID do dataset do HuggingFace (fonte: hf)
  • local_dataset_path — pasta ou arquivo local (fonte: local); local_dataset_format opcional ∈ {auto, imagefolder, coco, voc, jsonl, arrow, parquet, csv} (padrão: detecção automática).
  • (omitir) — o agente recomenda datasets populares (fonte: recommend)

Opcionais (possuem padrões):

  • task_type — detectado automaticamente a partir do config + cartão do modelo
  • n_train=10000, n_eval=1000, n_epochs=3, lora_r=16
  • output_dir=./output/<model_short_name></model_short_name>
  • hf_model_repo — destino do envio; se não definido e o HF_TOKEN tiver acesso de escrita, derivado automaticamente como <whoami>/<model_short_name>-finetuned</model_short_name></whoami>.
  • push_to_hub=True — defina como False para pular
  • skip_baseline=False — pular avaliação de linha de base zero-shot

Entregáveis opcionais (desativados por padrão):

emit_progress_log: false   # output_dir/PROGRESS.md (diário por etapa)
emit_report:       false   # reports/report.{pdf,html} com curvas e amostras
emit_unit_tests:   false   # tests/ com testes de lote heterogêneo com dados falsos

Todos os valores vivem em output_dir/config.yaml. Nunca codifique no Python.

Plataforma de execução

Esta habilidade orquestra o que executar; as habilidades de plataforma possuem como executá-lo em um host de GPU — leia-as primeiro.

PreocupaçãoHabilidade autoritativa
Tempo de execução do host GPU (driver 580, CUDA Toolkit 13.0, NVIDIA Container Toolkit 1.19.0)`tao-skill-bank:tao-setup-nvidia-gpu-host`
flags `docker run`, autenticação NGC, montagens, passagem de env`tao-skill-bank:tao-run-on-docker`
Pré-verificação de trabalho Docker local (daemon, teste de fumaça da GPU)`tao-skill-bank:tao-run-on-local-docker`

Plataforma padrão: local-docker — construa uma imagem única (run-<short>:latest</short>) e execute-a no daemon Docker local. Pergunte apenas quando o usuário precisar explicitamente de um backend diferente (GPU remota Brev, SLURM/Kubernetes); então execute a Pré-verificação dessa plataforma primeiro e roteie os comandos docker run dos Passos 4–5 através dela. As pré-verificações de tempo de execução da GPU e presença apenas de credenciais (valores nunca lidos), o conjunto canônico de flags docker run, o comando de seleção list_tao_platforms.py e as flags específicas do fluxo (--entrypoint /bin/bash -lc, PYTORCH_CUDA_ALLOC_CONF, --name hft_train) estão em references/workflow-intake-preflight.md.

Referências — rede de segurança de fallback

Consultadas apenas quando a pesquisa em tempo real está silenciosa, ambígua ou indisponível; a documentação em tempo real sempre vence para o modelo específico e a API atual. Cada etapa vincula as referências que precisa; catálogo completo em references/detailed-workflow.md.

Sempre ativo: core-rules.md, error-playbook.md, compat-workarounds.md, model-discovery.md, dataset-recommendations.md, dataset-sources.md, dataset-patterns.md, hardware-container.md, research-priorities.md, cv-scripts.md, vlm-scripts.md, docker-runs.md, hub-push.md, pipeline-skill-template.md, deliverables.md. Opt-in (quando sua flag/necessidade se aplica): progress-tracking.md, testing.md, reporting.md, workflow-intake-preflight.md, workflow-generate-train.md, workflow-push-rerun.md.

Regra: antes de recorrer ao fallback, registre a fonte em tempo real que você tentou e por que foi insuficiente (config.yaml notes:, e PROGRESS.md se habilitado). Os marcadores [FETCH LIVE] em cv-scripts.md / vlm-scripts.md são uma lista de verificação de pesquisa, não código para embutir — refaça o fetch da URL listada se um bloco não tiver uma descoberta do Passo 3.

Regras principais

Comportamentos não negociáveis. Versão curta (enumeração completa — lista de imports alucinados, lista nunca-sem-aprovação, tabelas completas de recuperação de erros e dimensionamento de hardware — em references/core-rules.md, consulte antes de qualquer decisão em tempo de treinamento):

  • Seu conhecimento da biblioteca HF está desatualizado. Busque documentação em tempo real (cartão do modelo, exemplo do repositório HF, documento de tarefa) antes de escrever qualquer código ML — não gere args do treinador / collator / transforms da memória (Passo 3).
  • Teste de fumaça em dados reais com --max_steps 1 antes de qualquer execução completa; nenhum lançamento em lote sem um teste de fumaça verificado.
  • Nunca substitua silenciosamente model_id, dataset_id ou training_method — se o que o usuário pediu não carregar, pare e pergunte.
  • Recuperação de erros é de mudança mínima. OOM → reduza o lote pela metade, dobre grad_accum, habilite o checkpointing de gradiente (sem troca de LoRA sem aprovação); NaN → reduza a LR 10×; perda plana → inspecione o collator; mesmo erro 3× → pare e pergunte. Não faça loop.
  • Colunas do dataset verificadas ANTES do collator — renomeie em prepare_data.py; reestruturação necessária → pare e pergunte.
  • Dica de dimensionamento de hardware (bf16): ≤3B → 24 GB, 7–13B → 80 GB, 30B+ → multi-GPU ou LoRA em 1× 80 GB, 70B+ → 8× 80 GB ou LoRA. Ajuste fino completo não caberá e nenhuma LoRA solicitada → pergunte antes de alternar.

Fluxo de trabalho — 6 etapas

Passagem única, sequencial; cada etapa tem uma porta clara antes que a próxima comece.

Passo 1 — Inspecionar e qualificar

Objetivo: decidir se prossiga. Explore modelo + dataset, aplique aceitar/rejeitar, registre correções de compatibilidade aplicáveis, escreva o config.yaml inicial.

Pré-requisitos: MODEL_ID, DATASET_ID opcional / local_dataset_path, HF_TOKEN opcional, OUTPUT_DIR (padrão ./output/<model_short_name></model_short_name>). As explorações são executadas em um contêiner Docker python:3.12-slim apenas de CPU (.probe/scratch montado em bind) para que o host não precise de virtualenv — o Docker deve existir primeiro. A guarda de presença do Docker, o env do contêiner, a invocação completa da exploração e os scripts de exploração do modelo/dataset estão em references/workflow-intake-preflight.md, references/model-discovery.md e references/dataset-sources.md.

Requisitos da exploração:

  • Modelo: carregue AutoConfig, leia as tags do cartão do modelo, detecte a tarefa a partir de architectures + tags + exemplos do cartão (fallback registrando em model-discovery.md).
  • Dataset: para datasets recomendados, apresente primeiro 3-5 opções de dataset-recommendations.md; para dados locais, monte em bind apenas leitura e use a detecção de formato de dataset-sources.md.
  • Rejeite cedo se a configuração do modelo falhar, a tarefa estiver fora do escopo, não existir fonte de receita ou o dataset não puder carregar / corresponder ao esquema da tarefa.
  • Avalie compat-workarounds.md contra o modelo/tarefa; adie regras dependentes de hardware para o Passo 2.

Escreva o config.yaml inicial (model_id, task, dataset_id ou local_dataset_path, research_sources: [] preenchido no Passo 3, applicable_workarounds: do Passo 1, notes: [] para fallbacks de referência, push_to_hub: true padrão — modelo anotado em references/workflow-intake-preflight.md). Opcionalmente rm -rf "$OUTPUT_DIR/.probe"uma vez que a porta seja atendida.

Porta: config.yaml existe com modelo, dataset, tarefa, applicable_workarounds; não prossiga se algum campo estiver ausente.

Passo 2 — Auditoria de hardware e imagem NGC

Objetivo: verificar Docker + GPU + disco, escolher a imagem PyTorch NGC em tempo real, finalizar regras de compatibilidade dependentes de hardware.

2a. Auditoria (porta rígida) — três verificações (comandos em references/workflow-intake-preflight.md):

  1. Tempo de execução do host GPU — setup-nvidia-gpu-host.sh --backend docker --check-only de tao-setup-nvidia-gpu-host; em falha, peça aprovação e execute novamente com --install --yes.
  2. Aviso de disco livre — substitua via MIN_DISK_GB (padrão 100 GB); recomende ≥ 100 GB para base NGC (~20 GB) + cache HF + checkpoints + dados.
  3. Presença de credenciais condicionais (do ambiente da sessão, valores nunca lidos) — HF_TOKEN apenas quando gated ou push_to_hub está ativo; WANDB_* apenas quando o WandB está ativo.

Não prossiga para o Passo 4 em uma falha rígida — o docker build do Passo 4 puxa uma base NGC de 20+ GB, e a ausência de nvidia-container-toolkit só aparece mais tarde como could not select device driver "" with capabilities: [[gpu]]. Registre gpu_count, gpu_name, driver_major, vram_gb_per_gpu em config.yaml.

2b. Escolha imagem NGC (em tempo real): da matriz de suporte do NVIDIA Deep Learning Frameworks (https://docs.nvidia.com/deeplearning/frameworks/support-matrix/index.html), seção de contêiner PyTorch NGC, escolha a imagem de versão mais alta onde Min driver ≤ driver_major detectado e CUDA do contêiner ≤ CUDA Toolkit do host (corresponda de perto para que cuDNN / TensorRT se alinhem). Não rejeite uma imagem por uma tag PyTorch aN/bN/rcN — o NGC valida a imagem completa; escolha a mais nova alinhada com CUDA e deixe compat-workarounds.md lidar com problemas por versão. Se a matriz for inacessível, use os fallbacks em references/hardware-container.md; padrão nvcr.io/nvidia/pytorch:24.09-py3 (driver ≥ 545; bug SDPA+GQA — se num_key_value_heads , definaattn_implementation: "eager").Registrengc_imageemconfig.yaml.

2c. Reavalie regras de compatibilidade dependentes de hardware: execute novamente a caminhada compat-workarounds.md para entradas cujo detect precisa de hw; atualize applicable_workarounds: no local.

2d. Verificação de ajuste do modelo: estime param_bytes ≈ 2×param_count (bf16); se

60% de vram_gb_per_gpu × 1e9, recomende LoRA no resumo voltado ao usuário.

Porta: config.yaml tem ngc_image, gpu_count, gpu_name, driver_major, vram_gb_per_gpu; correções de compatibilidade dependentes de hardware registradas.

Passo 3 — Pesquisar a receita

Objetivo: buscar a receita em tempo real — o conhecimento de dados de treinamento de transformers/trl/peft é suspeito, portanto o Passo 3 é não negociável. Percorra references/research-priorities.md em ordem de prioridade (Prioridade 1 → 6); pare assim que tiver, para a tarefa detectada:

  • Classe AutoModel / processador
  • Transformações de treinamento + avaliação
  • Collator
  • compute_metrics
  • Dicas de hiperparâmetros (LR, tamanho do lote, épocas, agendador)

Registre as descobertas em meta/recipe.md, anexe URLs de origem a config.yaml: research_sources:. Um slot sem descoberta em tempo real recorre ao scaffold correspondente (cv-scripts.md / vlm-scripts.md), registrado como "fallback para scaffold — nenhuma fonte em tempo real para " sob notes:. As regras de resolução de conflitos estão em references/research-priorities.md.

Porta: todos os slots obrigatórios preenchidos, com uma URL de origem ou nota de fallback de scaffold.

Passo 4 — Gerar projeto e teste de fumaça

Objetivo: escrever todos os scripts, construir a imagem, preparar dados, executar um teste de fumaça de 1 etapa em dados reais (um docker build, dois docker runs).

4a. Gerar arquivos do projeto em output_dir/: config.yaml, Dockerfile, requirements.txt, prepare_data.py, train.py, run_eval.py, infer.py, merge_lora.py opcional, tests/ opcional, .gitignore. A pesquisa do Passo 3 em tempo real é a autoridade; cv-scripts.md / vlm-scripts.md dão apenas a forma do scaffold. Aplique cada entrada de applicable_workarounds como um bloco Dockerfile, pin de requisito, substituição de config ou var de env de runtime. Regras rígidas: run_eval.py mantém esse nome de arquivo exato (evita colidir com o pacote HF evaluate); todo .py gerado começa com o cabeçalho de direitos autorais Apache-2.0 da NVIDIA e qualquer emissor falha quando está ausente; emit_unit_tests: true gera e executa testes por references/testing.md. Os corpos dos scripts, a forma do Dockerfile e o contrato do emissor estão em references/workflow-generate-train.md.

4b. Construir, preparar, teste de fumaça — docker build -t run-<short>:latest .</short>, depois prepare_data e a execução --smoke --max_steps 1 (references/docker-runs.md§1-3). Critérios de passagem do teste de fumaça (em logs/smoke.log):

  • Sem exceção
  • A perda é finita (não 0.0, não NaN)
  • grad_norm > 0 na etapa 1

Se emit_unit_tests: true, execute também pytest tests/ no contêiner. Qualquer falha → PARE.

4c. Resumo de pré-verificação — antes do treinamento completo, imprima e verifique: URL de referência, colunas do dataset, destino do Hub, destino de monitoramento, imagem NGC, hardware, perda/teste de fumaça/grad norm.

Porta: arquivos do projeto escritos, imagem construída, teste de fumaça PASSOU, pré-verificação não tem campos em branco.

Passo 5 — Treinar, avaliar, inferir

Objetivo: avaliação de linha de base, treinamento completo, avaliação pós-treinamento, mesclagem opcional de LoRA, 5 amostras de inferência (todos os comandos: references/docker-runs.md §4-8).

Sub-etapadocker-runs.mdPular se
5a. Avaliação de linha de base (zero-shot)§4`skip_baseline: true`
5b. Treinamento completo (desanexado)§5—
5c. Mesclagem LoRA§6não VLM+LoRA
5d. Avaliação pós-treinamento§7—
5e. Inferência (5 amostras)§8—

Multi-GPU: preceda torchrun --nproc_per_node=$gpu_count a python train.py.

Enquanto o treinamento transmite, observe docker logs -f hft_train: a perda deve cair dentro de 10-20 etapas; perda plana (bug de collator/mascaramento de rótulo), NaN (LR muito alta) e OOM interrompem a execução — recuperação em references/core-rules.md. Se emit_report: true, execute report.py após o Passo 5e por references/reporting.md.

Porta: todos de:

  • checkpoints/final/ (ou checkpoints/merged/ para LoRA) existe
  • reports/eval_results.json tem uma métrica primária numérica
  • reports/baseline_results.json existe (a menos que pulado)
  • reports/inference_samples/ tem 5 amostras
  • URL do wandb mostra perda descendente

Passo 6 — Enviar e emitir habilidade de reexecução

Objetivo: publicar a execução e torná-la reproduzível sem nova pesquisa.

Envie por references/hub-push.md (pesos, cartão do modelo, JSONs de avaliação/linha de base, config.yaml, Dockerfile, requirements.txt, amostras de inferência, relatórios quando emitidos) a menos que push_to_hub: false seja explícito. Emita <output_dir>/skills/run-<short>/SKILL.md</short></output_dir> de references/pipeline-skill-template.md — substitua cada placeholder, inclua metadados YAML completos + o comentário HTML de direitos autorais da NVIDIA, e faça qualquer emissor falhar se esses estiverem ausentes.

Porta (critérios de conclusão): todos de:

  • Porta do Passo 5 atendida
  • Repositório HF Hub existe na URL resolvida com pesos + cartão + results/ (a menos que push_to_hub: false)
  • <output_dir>/skills/run-<short>/SKILL.md</short></output_dir> existe, sem <placeholder></placeholder> restante, com metadados + comentário HTML de direitos autorais por pipeline-skill-template.md

Mensagem final: URL do wandb, URL do HF Hub, linha de base -> métrica primária de ajuste fino, reports/inference_samples/ e o caminho da habilidade de reexecução.

Jogo de erros

Em um erro de runtime conhecido, consulte a tabela sintoma → correção mínima em references/error-playbook.md (entrypoint NGC, regressões PyTorch/Transformers, numpy ABI, bbox Albumentations, PEFT/checkpointing, largura de alvo LoRA, lacunas de augmentação CV, OOM na etapa 0) antes de redesenhar qualquer coisa. Quando uma linha lá disparar duas vezes entre execuções, eleve-a para compat-workarounds.md com uma regra detect — aplicada automaticamente no Passo 1 antes que o erro possa disparar.

Estilo de comunicação

  • Conciso. Sem preenchimento, sem repetir a solicitação; respostas de uma palavra quando apropriado.
  • Sempre inclua URLs diretas do Hub e wandb ao referenciar artefatos.
  • Em erro: declare o que deu errado, por que, o que você mudou — sem menus.
  • Nunca apresente "Opção A/B/C" para uma solicitação com uma resposta clara. Aja.

Exemplos de pipelines

  • tao-rerun-convnext-cifar10
  • tao-rerun-detr-cppe5
  • tao-rerun-segformer-foodseg103
  • tao-rerun-smolvlm-vqav2
Ver no GitHub
---
name: tao-finetune-huggingface-model
description: Fine-tune HuggingFace CV, VLM, or LLM models on local NVIDIA GPUs using an NGC PyTorch container, with support for full or LoRA training, dataset handling, and optional model push to the Hub.
license: Apache-2.0
---
<!-- Copyright (c) 2026, NVIDIA CORPORATION. All rights reserved. Licensed under the Apache License, Version 2.0; see http://www.apache.org/licenses/LICENSE-2.0 -->

# tao-finetune-huggingface-model

Local NVIDIA GPU fine-tuning for HuggingFace models, grounded in live-fetched
documentation with curated references as a fallback safety net. One NGC container,
a few focused scripts, one push to HF Hub. Follow the rules in this file; don't
improvise.

**Order of authority (highest first):**

1. **User input** — explicit `model_id`, `dataset_id`, `training_method`, `config.yaml` overrides.
2. **Live research** — model card, HF repo example, author finetune script, HF task docs, paper; always fetched (Step 3 + `references/research-priorities.md`).
3. **Curated references** (`references/*.md`) — fallback when live research is silent/ambiguous.
4. **Your training-data memory** — last resort; suspect, cross-check against (2)/(3).

Conflict resolution between (2) and (3) and the source-line discrepancy note are
in `references/research-priorities.md`.

---

## Inputs

**Required:**
- `model_id` — HuggingFace model ID, e.g. `google/vit-base-patch16-224`

**Conditional credentials (read from the session environment, exported before launching when present):**
- `HF_TOKEN` — only when the model/dataset is **gated** (read) or `push_to_hub` is on (write); public + public + `push_to_hub: false` needs none. Value never read — presence-only via `[ -n "$HF_TOKEN" ]`.
- `WANDB_API_KEY`, `WANDB_PROJECT` — only when WandB is enabled; `WANDB_MODE=disabled` opts out.

**Dataset — exactly one:**
- `dataset_id` — HuggingFace dataset ID *(source: `hf`)*
- `local_dataset_path` — local folder or file *(source: `local`)*; optional
  `local_dataset_format` ∈ {auto, imagefolder, coco, voc, jsonl, arrow, parquet,
  csv} (default: auto-detect).
- *(omit)* — agent recommends popular datasets *(source: `recommend`)*

**Optional (have defaults):**
- `task_type` — auto-detected from config + model card
- `n_train=10000`, `n_eval=1000`, `n_epochs=3`, `lora_r=16`
- `output_dir=./output/<model_short_name>`
- `hf_model_repo` — push target; if unset and HF_TOKEN has write access,
  auto-derived as `<whoami>/<model_short_name>-finetuned`.
- `push_to_hub=True` — set to `False` to skip
- `skip_baseline=False` — skip zero-shot baseline eval

**Optional deliverables (off by default):**
```yaml
emit_progress_log: false   # output_dir/PROGRESS.md (per-step journal)
emit_report:       false   # reports/report.{pdf,html} with curves & samples
emit_unit_tests:   false   # tests/ with fake-data heterogeneous-batch tests
```

All values live in `output_dir/config.yaml`. Never hardcode in Python.

---

## Execution platform

This skill orchestrates *what* to run; the platform skills own *how* to run it on
a GPU host — read them first.

| Concern | Authoritative skill |
|---|---|
| GPU host runtime (driver 580, CUDA Toolkit 13.0, NVIDIA Container Toolkit 1.19.0) | [`tao-skill-bank:tao-setup-nvidia-gpu-host`](../../platform/tao-setup-nvidia-gpu-host/SKILL.md) |
| `docker run` flags, NGC auth, mounts, env passthrough | [`tao-skill-bank:tao-run-on-docker`](../../platform/tao-run-on-docker/SKILL.md) |
| Local Docker job preflight (daemon, GPU smoke) | [`tao-skill-bank:tao-run-on-local-docker`](../../platform/tao-run-on-local-docker/SKILL.md) |

**Default platform:** `local-docker` — build a one-off image (`run-<short>:latest`)
and run it on the local Docker daemon. Ask only when the user explicitly needs a
different backend (Brev remote GPU, SLURM/Kubernetes); then run that platform's
Preflight first and route the Steps 4–5 `docker run` commands through it. The
GPU-runtime and presence-only credential preflights (values never read), the
canonical `docker run` flag set, the `list_tao_platforms.py` selection command, and
the workflow-specific flags (`--entrypoint /bin/bash -lc`, `PYTORCH_CUDA_ALLOC_CONF`,
`--name hft_train`) are in `references/workflow-intake-preflight.md`.

---

## References — fallback safety net

Consulted **only** when live research is silent, ambiguous, or unavailable; live
docs always win for the specific model and current API. Each step links the
references it needs; full catalog in `references/detailed-workflow.md`.

Always-on: `core-rules.md`, `error-playbook.md`, `compat-workarounds.md`,
`model-discovery.md`, `dataset-recommendations.md`, `dataset-sources.md`,
`dataset-patterns.md`, `hardware-container.md`, `research-priorities.md`,
`cv-scripts.md`, `vlm-scripts.md`, `docker-runs.md`, `hub-push.md`,
`pipeline-skill-template.md`, `deliverables.md`. Opt-in (when their flag/need
applies): `progress-tracking.md`, `testing.md`, `reporting.md`,
`workflow-intake-preflight.md`, `workflow-generate-train.md`, `workflow-push-rerun.md`.

**Rule:** before falling back, log the live source you tried and why it was
insufficient (`config.yaml` `notes:`, and PROGRESS.md if enabled). `[FETCH LIVE]`
markers in `cv-scripts.md` / `vlm-scripts.md` are a research checklist, not code to
inline — refetch the listed URL if a block has no Step 3 finding.

---

## Core rules

Non-negotiable behaviors. **Short version** (full enumeration —
hallucinated-imports list, never-without-approval list, full error-recovery and
hardware-sizing tables — in `references/core-rules.md`, consult before any
training-time decision):

- **Your HF-library knowledge is outdated.** Fetch live docs (model card, HF
  repo example, task doc) before writing any ML code — don't generate trainer
  args / collator / transforms from memory (Step 3).
- **Smoke-test on real data with `--max_steps 1`** before any full run; no batch
  launches without a verified smoke.
- **Never silently substitute** model_id, dataset_id, or training_method — if
  what the user asked for doesn't load, stop and ask.
- **Error recovery is minimal-change.** OOM → halve batch, double grad_accum,
  enable gradient checkpointing (no LoRA switch without approval); NaN → reduce
  LR 10×; flat loss → inspect collator; same error 3× → stop and ask. Don't loop.
- **Dataset columns verified BEFORE the collator** — rename in `prepare_data.py`;
  restructuring needed → stop and ask.
- **Hardware-sizing thumb (bf16):** ≤3B → 24 GB, 7–13B → 80 GB, 30B+ → multi-GPU
  or LoRA on 1× 80 GB, 70B+ → 8× 80 GB or LoRA. Full finetune won't fit and no
  LoRA requested → ask before switching.

---

## Workflow — 6 steps

Single pass, sequential; each step has a clear gate before the next begins.

### Step 1 — Inspect & qualify

**Goal:** decide whether to proceed. Probe model + dataset, apply accept/reject,
register applicable compat fixes, write the initial `config.yaml`.

Prerequisites: `MODEL_ID`, optional `DATASET_ID` / `local_dataset_path`,
optional `HF_TOKEN`, `OUTPUT_DIR` (default `./output/<model_short_name>`). Probes
run in a CPU-only `python:3.12-slim` Docker container (bind-mounted `.probe/`
scratch) so the host needs no virtualenv — Docker must exist first. Docker-presence
guard, container env, full probe invocation, and the model/dataset probe scripts
are in `references/workflow-intake-preflight.md`, `references/model-discovery.md`,
and `references/dataset-sources.md`.

Probe requirements:

- Model: load `AutoConfig`, read model-card tags, detect task from
  `architectures` + tags + card examples (fallback logging in `model-discovery.md`).
- Dataset: for recommended datasets, first present 3-5 choices from
  `dataset-recommendations.md`; for local data, bind-mount read-only and use
  `dataset-sources.md` format detection.
- Reject early if the model config fails, the task is out of scope, no recipe
  source exists, or the dataset cannot load / match the task schema.
- Evaluate `compat-workarounds.md` against the model/task; defer hardware-dependent
  rules to Step 2.

Write the initial `config.yaml` (`model_id`, `task`, `dataset_id` or
`local_dataset_path`, `research_sources: []` filled in Step 3,
`applicable_workarounds:` from Step 1, `notes: []` for reference fallbacks,
`push_to_hub: true` default — annotated template in
`references/workflow-intake-preflight.md`). Optionally `rm -rf "$OUTPUT_DIR/.probe"`
once the gate is met.

**Gate:** `config.yaml` exists with model, dataset, task, applicable_workarounds;
do not proceed if any field is missing.

---

### Step 2 — Hardware audit & NGC image

**Goal:** verify Docker + GPU + disk, pick the NGC PyTorch image live, finalize
hardware-dependent compat rules.

**2a. Audit (hard gate)** — three checks (commands in
`references/workflow-intake-preflight.md`):
1. GPU host runtime — `tao-setup-nvidia-gpu-host`'s
   `setup-nvidia-gpu-host.sh --backend docker --check-only`; on fail, ask approval
   then re-run with `--install --yes`.
2. Free-disk soft-warn — override via `MIN_DISK_GB` (default 100 GB); recommend
   ≥ 100 GB for NGC base (~20 GB) + HF cache + checkpoints + data.
3. Conditional credential presence (from the session environment, values never
   read) — `HF_TOKEN` only when gated or `push_to_hub` is on; `WANDB_*` only when
   WandB is on.

**Do not proceed to Step 4 on a hard-fail** — Step 4's `docker build` pulls a
20+ GB NGC base, and a missing `nvidia-container-toolkit` only surfaces later as
`could not select device driver "" with capabilities: [[gpu]]`. Record `gpu_count`,
`gpu_name`, `driver_major`, `vram_gb_per_gpu` in `config.yaml`.

**2b. Pick NGC image (live):** from the NVIDIA Deep Learning Frameworks support
matrix (<https://docs.nvidia.com/deeplearning/frameworks/support-matrix/index.html>),
PyTorch NGC container section, pick the highest-versioned image where
`Min driver ≤ detected driver_major` and container CUDA `≤` host CUDA Toolkit
(match closely so cuDNN / TensorRT line up). Do **not** reject an image for an
`aN`/`bN`/`rcN` PyTorch tag — NGC validates the full image; pick the newest
CUDA-aligned one and let `compat-workarounds.md` handle per-version issues. If the
matrix is unreachable, use the fallbacks in `references/hardware-container.md`;
default `nvcr.io/nvidia/pytorch:24.09-py3` (driver ≥ 545; SDPA+GQA bug — if
`num_key_value_heads < num_attention_heads`, set `attn_implementation: "eager"`).
Record `ngc_image` in `config.yaml`.

**2c. Re-evaluate hardware-dependent compat rules:** re-run the
`compat-workarounds.md` walk for entries whose `detect` needs `hw`; update
`applicable_workarounds:` in place.

**2d. Model-fit check:** estimate `param_bytes ≈ 2×param_count` (bf16); if
> 60% of `vram_gb_per_gpu × 1e9`, recommend LoRA in the user-facing summary.

**Gate:** `config.yaml` has `ngc_image`, `gpu_count`, `gpu_name`, `driver_major`,
`vram_gb_per_gpu`; hardware-dependent compat fixes recorded.

---

### Step 3 — Research the recipe

**Goal:** fetch the live recipe — training-data knowledge of
`transformers`/`trl`/`peft` is suspect, so Step 3 is non-negotiable. Walk
`references/research-priorities.md` in priority order (Priority 1 → 6); stop once
you have, for the detected task:

- `AutoModel` / processor class
- Train + eval transforms
- Collator
- `compute_metrics`
- Hyperparameter hints (LR, batch size, epochs, scheduler)

Record findings in `meta/recipe.md`, append source URLs to
`config.yaml: research_sources:`. A slot with no live finding falls back to the
matching scaffold (`cv-scripts.md` / `vlm-scripts.md`), logged as "fallback to
scaffold — no live source for <slot>" under `notes:`. Conflict-resolution rules
are in `references/research-priorities.md`.

**Gate:** every required slot filled, with a source URL or scaffold-fallback note.

---

### Step 4 — Generate project & smoke-test

**Goal:** write all scripts, build the image, prepare data, run a 1-step smoke on
real data (one `docker build`, two `docker run`s).

**4a. Generate project files** in `output_dir/`: `config.yaml`, `Dockerfile`,
`requirements.txt`, `prepare_data.py`, `train.py`, `run_eval.py`, `infer.py`,
optional `merge_lora.py`, optional `tests/`, `.gitignore`. Live Step 3 research is
authority; `cv-scripts.md` / `vlm-scripts.md` give scaffold shape only. Apply every
`applicable_workarounds` entry as a Dockerfile block, requirement pin, config
override, or runtime env var. Hard rules: `run_eval.py` keeps that exact filename
(avoids colliding with the HF `evaluate` package); every generated `.py` starts
with the NVIDIA Apache-2.0 copyright header and any emitter fails when it is
missing; `emit_unit_tests: true` generates and runs tests per
`references/testing.md`. Script bodies, Dockerfile shape, and the emitter contract
are in `references/workflow-generate-train.md`.

**4b. Build, prepare, smoke** — `docker build -t run-<short>:latest .`, then
`prepare_data` and the `--smoke --max_steps 1` run (`references/docker-runs.md`
§1-3). Smoke pass criteria (in `logs/smoke.log`):
- No exception
- Loss is finite (not `0.0`, not `NaN`)
- `grad_norm > 0` at step 1

If `emit_unit_tests: true`, also run `pytest tests/` in the container. Any failure → STOP.

**4c. Preflight summary** — before full training, print and verify: reference URL,
dataset columns, Hub target, monitoring target, NGC image, hardware, smoke loss/grad norm.

**Gate:** project files written, image built, smoke PASSED, preflight has no
blank fields.

---

### Step 5 — Train, evaluate, infer

**Goal:** baseline eval, full training, post-train eval, optional LoRA merge, 5
inference samples (all commands: `references/docker-runs.md` §4-8).

| Sub-step | docker-runs.md | Skip if |
|---|---|---|
| 5a. Baseline eval (zero-shot) | §4 | `skip_baseline: true` |
| 5b. Full training (detached) | §5 | — |
| 5c. LoRA merge | §6 | not VLM+LoRA |
| 5d. Post-train eval | §7 | — |
| 5e. Inference (5 samples) | §8 | — |

Multi-GPU: prepend `torchrun --nproc_per_node=$gpu_count` to `python train.py`.

While training streams, watch `docker logs -f hft_train`: loss should drop within
10-20 steps; flat loss (collator/label-masking bug), NaN (LR too high), and OOM
all stop the run — recovery in `references/core-rules.md`. If `emit_report: true`,
run `report.py` after Step 5e per `references/reporting.md`.

**Gate:** all of:
- `checkpoints/final/` (or `checkpoints/merged/` for LoRA) exists
- `reports/eval_results.json` has a numeric primary metric
- `reports/baseline_results.json` exists (unless skipped)
- `reports/inference_samples/` has 5 samples
- wandb URL shows descending loss

---

### Step 6 — Push & emit rerun skill

**Goal:** publish the run and make it reproducible without re-research.

Push per `references/hub-push.md` (weights, model card, eval/baseline JSONs,
`config.yaml`, `Dockerfile`, `requirements.txt`, inference samples, reports when
emitted) unless `push_to_hub: false` is explicit. Emit
`<output_dir>/skills/run-<short>/SKILL.md` from
`references/pipeline-skill-template.md` — substitute every placeholder, include
full YAML metadata + the NVIDIA copyright HTML comment, and make any emitter fail
if those are missing.

**Gate (Done criteria):** all of:
- Step 5 gate met
- HF Hub repo exists at the resolved URL with weights + card + `results/`
  (unless `push_to_hub: false`)
- `<output_dir>/skills/run-<short>/SKILL.md` exists, no `<placeholder>` left,
  with metadata + copyright HTML comment per `pipeline-skill-template.md`

Final message: wandb URL, HF Hub URL, baseline -> fine-tuned primary metric,
`reports/inference_samples/`, and the rerun skill path.

---

## Error playbook

On a known runtime error, consult the symptom → minimal-fix table in
`references/error-playbook.md` (NGC entrypoint, PyTorch/Transformers regressions,
numpy ABI, Albumentations bbox, PEFT/checkpointing, LoRA target breadth, CV
augmentation gaps, OOM at step 0) before redesigning anything. When a row there
fires twice across runs, lift it into `compat-workarounds.md` with a `detect` rule
— auto-applied in Step 1 before the error can fire.

---

## Communication style

- Terse. No filler, no restating the request; one-word answers when appropriate.
- Always include direct Hub and wandb URLs when referencing artifacts.
- On error: state what went wrong, why, what you changed — no menus.
- Never present "Option A/B/C" for a request with a clear answer. Act.

## Example pipelines

- [tao-rerun-convnext-cifar10](references/tao-rerun-convnext-cifar10.md)
- [tao-rerun-detr-cppe5](references/tao-rerun-detr-cppe5.md)
- [tao-rerun-segformer-foodseg103](references/tao-rerun-segformer-foodseg103.md)
- [tao-rerun-smolvlm-vqav2](references/tao-rerun-smolvlm-vqav2.md)

Todos os arquivos

69 arquivos
SKILL.md 17.6k
Ver

Instalar tao-finetune-huggingface-model

Baixe e extraia os arquivos de habilidade para o diretório .claude/skills/.

Baixar ZIP

Clone o repositório e copie os arquivos da habilidade para o seu projeto.

git clone https://github.com/NVIDIA/skills/tree/main/skills/tao-finetune-huggingface-model # Copy SKILL.md to your .claude/skills/ directory

Copiar Copiar
Configuração rápida: Copie a pasta de habilidades para .claude/skills/ O Claude detectará e usará automaticamente a habilidade
Repositório NVIDIA/skills

Habilidades relacionadas

web-search
Tempo atualizado 29 de Junho de 2026
webapp-testing
Tempo atualizado 29 de Junho de 2026
lark-base
Tempo atualizado 5 de Julho de 2026
agentmail
Tempo atualizado 29 de Junho de 2026
OR