Hugging Face Jobs
This skill should be used when users want to run any workload on Hugging Face Jobs infrastructure.
Content
Overview
Run any workload on fully managed Hugging Face infrastructure. No local setup required—jobs run on cloud CPUs, GPUs, or TPUs and can persist results to the Hugging Face Hub.
Common use cases:
- -Data Processing - Transform, filter, or analyze large datasets
- -Batch Inference - Run inference on thousands of samples
- -Experiments & Benchmarks - Reproducible ML experiments
- -Model Training - Fine-tune models (see
model-trainerskill for TRL-specific training) - -Synthetic Data Generation - Generate datasets using LLMs
- -Development & Testing - Test code without local GPU setup
- -Scheduled Jobs - Automate recurring tasks
For model training specifically: See the model-trainer skill for TRL-based training workflows.
When to Use This Skill
Use this skill when users want to:
- -Run Python workloads on cloud infrastructure
- -Execute jobs without local GPU/TPU setup
- -Process data at scale
- -Run batch inference or experiments
- -Schedule recurring tasks
- -Use GPUs/TPUs for any workload
- -Persist results to the Hugging Face Hub
Key Directives
When assisting with jobs:
1. ALWAYS use `hf_jobs()` MCP tool - Submit jobs using hf_jobs("uv", {...}) or hf_jobs("run", {...}). The script parameter accepts Python code directly. Do NOT save to local files unless the user explicitly requests it. Pass the script content as a string to hf_jobs().
2. Always handle authentication - Jobs that interact with the Hub require HF_TOKEN via secrets. See Token Usage section below.
3. Provide job details after submission - After submitting, provide job ID, monitoring URL, estimated time, and note that the user can request status checks later.
4. Set appropriate timeouts - Default 30min may be insufficient for long-running tasks.
Prerequisites Checklist
Before starting any job, verify:
✅ Account & Authentication
- -Hugging Face Account with Pro, Team, or Enterprise plan (Jobs require paid plan)
- -Authenticated login: Check with
hf_whoami() - -HF_TOKEN for Hub Access ⚠️ CRITICAL - Required for any Hub operations (push models/datasets, download private repos, etc.)
- -Token must have appropriate permissions (read for downloads, write for uploads)
✅ Token Usage (See Token Usage section for details)
When tokens are required:
- -Pushing models/datasets to Hub
- -Accessing private repositories
- -Using Hub APIs in scripts
- -Any authenticated Hub operations
How to provide tokens:
⚠️ CRITICAL: The $HF_TOKEN placeholder is ONLY auto-replaced by the hf_jobs MCP tool. When using HfApi().run_uv_job(), you MUST pass the real token via get_token(). Passing the literal string "$HF_TOKEN" results in a 9-character invalid token and 401 errors.
Token Usage Guide
Understanding Tokens
What are HF Tokens?
- -Authentication credentials for Hugging Face Hub
- -Required for authenticated operations (push, private repos, API access)
- -Stored securely on your machine after
hf auth login
Token Types:
- -Read Token - Can download models/datasets, read private repos
- -Write Token - Can push models/datasets, create repos, modify content
- -Organization Token - Can act on behalf of an organization
When Tokens Are Required
Always Required:
- -Pushing models/datasets to Hub
- -Accessing private repositories
- -Creating new repositories
- -Modifying existing repositories
- -Using Hub APIs programmatically
Not Required:
- -Downloading public models/datasets
- -Running jobs that don't interact with Hub
- -Reading public repository information
How to Provide Tokens to Jobs
#### Method 1: Automatic Token (Recommended)
How it works:
- -
$HF_TOKENis a placeholder that gets replaced with your actual token - -Uses the token from your logged-in session (
hf auth login) - -Most secure and convenient method
- -Token is encrypted server-side when passed as a secret
Benefits:
- -No token exposure in code
- -Uses your current login session
- -Automatically updated if you re-login
- -Works seamlessly with MCP tools
#### Method 2: Explicit Token (Not Recommended)
When to use:
- -Only if automatic token doesn't work
- -Testing with a specific token
- -Organization tokens (use with caution)
Security concerns:
- -Token visible in code/logs
- -Must manually update if token rotates
- -Risk of token exposure
#### Method 3: Environment Variable (Less Secure)
Difference from secrets:
- -
envvariables are visible in job logs - -
secretsare encrypted server-side - -Always prefer
secretsfor tokens
Using Tokens in Scripts
In your Python script, tokens are available as environment variables:
Best practices:
- -Don't hardcode tokens in scripts
- -Use
os.environ.get("HF_TOKEN")to access - -Let
huggingface_hubauto-detect when possible - -Verify token exists before Hub operations
Token Verification
Check if you're logged in:
Verify token in job:
Common Token Issues
Error: 401 Unauthorized
- -Cause: Token missing or invalid
- -Fix: Add
secrets={"HF_TOKEN": "$HF_TOKEN"}to job config - -Verify: Check
hf_whoami()works locally
Error: 403 Forbidden
- -Cause: Token lacks required permissions
- -Fix: Ensure token has write permissions for push operations
- -Check: Token type at https://huggingface.co/settings/tokens
Error: Token not found in environment
- -Cause:
secretsnot passed or wrong key name - -Fix: Use
secrets={"HF_TOKEN": "$HF_TOKEN"}(notenv) - -Verify: Script checks
os.environ.get("HF_TOKEN")
Error: Repository access denied
- -Cause: Token doesn't have access to private repo
- -Fix: Use token from account with access
- -Check: Verify repo visibility and your permissions
Token Security Best Practices
1. Never commit tokens - Use $HF_TOKEN placeholder or environment variables
2. Use secrets, not env - Secrets are encrypted server-side
3. Rotate tokens regularly - Generate new tokens periodically
4. Use minimal permissions - Create tokens with only needed permissions
5. Don't share tokens - Each user should use their own token
6. Monitor token usage - Check token activity in Hub settings
Complete Token Example
Quick Start: Two Approaches
Approach 1: UV Scripts (Recommended)
UV scripts use PEP 723 inline dependencies for clean, self-contained workloads.
MCP Tool:
CLI Equivalent:
Python API:
Benefits: Direct MCP tool usage, clean code, dependencies declared inline, no file saving required
When to use: Default choice for all workloads, custom logic, any scenario requiring hf_jobs()
#### Custom Docker Images for UV Scripts
By default, UV scripts use ghcr.io/astral-sh/uv:python3.12-bookworm-slim. For ML workloads with complex dependencies, use pre-built images:
CLI:
Benefits: Faster startup, pre-installed dependencies, optimized for specific frameworks
#### Python Version
By default, UV scripts use Python 3.12. Specify a different version:
Python API:
#### Working with Scripts
⚠️ Important: There are *two* "script path" stories depending on how you run Jobs:
- -Using the `hf_jobs()` MCP tool (recommended in this repo): the
scriptvalue must be inline code (a string) or a URL. A local filesystem path (like"./scripts/foo.py") won't exist inside the remote container. - -Using the `hf jobs uv run` CLI: local file paths do work (the CLI uploads your script).
Common mistake with `hf_jobs()` MCP tool:
Correct patterns with `hf_jobs()` MCP tool:
CLI equivalent (local paths supported):
#### Adding Dependencies at Runtime
Add extra dependencies beyond what's in the PEP 723 header:
Python API:
Approach 2: Docker-Based Jobs
Run jobs with custom Docker images and commands.
MCP Tool:
CLI Equivalent:
Python API:
Benefits: Full Docker control, use pre-built images, run any command
When to use: Need specific Docker images, non-Python workloads, complex environments
Example with GPU:
Using Hugging Face Spaces as Images:
You can use Docker images from HF Spaces:
CLI:
Finding More UV Scripts on Hub
The uv-scripts organization provides ready-to-use UV scripts stored as datasets on Hugging Face Hub:
Popular collections: OCR, classification, synthetic-data, vLLM, dataset-creation
Hardware Selection
> Reference: HF Jobs Hardware Docs (updated 07/2025)
| Workload Type | Recommended Hardware | Use Case |
|---|---|---|
| Data processing, testing | `cpu-basic`, `cpu-upgrade` | Lightweight tasks |
| Small models, demos | `t4-small` | <1B models, quick tests |
| Medium models | `t4-medium`, `l4x1` | 1-7B models |
| Large models, production | `a10g-small`, `a10g-large` | 7-13B models |
| Very large models | `a100-large` | 13B+ models |
| Batch inference | `a10g-large`, `a100-large` | High-throughput |
| Multi-GPU workloads | `l4x4`, `a10g-largex2`, `a10g-largex4` | Parallel/large models |
| TPU workloads | `v5e-1x1`, `v5e-2x2`, `v5e-2x4` | JAX/Flax, TPU-optimized |
All Available Flavors:
- -CPU:
cpu-basic,cpu-upgrade - -GPU:
t4-small,t4-medium,l4x1,l4x4,a10g-small,a10g-large,a10g-largex2,a10g-largex4,a100-large - -TPU:
v5e-1x1,v5e-2x2,v5e-2x4
Guidelines:
- -Start with smaller hardware for testing
- -Scale up based on actual needs
- -Use multi-GPU for parallel workloads or large models
- -Use TPUs for JAX/Flax workloads
- -See
references/hardware_guide.mdfor detailed specifications
Critical: Saving Results
⚠️ EPHEMERAL ENVIRONMENT—MUST PERSIST RESULTS
The Jobs environment is temporary. All files are deleted when the job ends. If results aren't persisted, ALL WORK IS LOST.
Persistence Options
1. Push to Hugging Face Hub (Recommended)
2. Use External Storage
3. Send Results via API
Required Configuration for Hub Push
In job submission:
In script:
Verification Checklist
Before submitting:
- -[ ] Results persistence method chosen
- -[ ] Token in secrets if using Hub (MCP:
"$HF_TOKEN", Python API:get_token()) - -[ ] Script handles missing token gracefully
- -[ ] Test persistence path works
See: references/hub_saving.md for detailed Hub persistence guide
Timeout Management
⚠️ DEFAULT: 30 MINUTES
Jobs automatically stop after the timeout. For long-running tasks like training, always set a custom timeout.
Setting Timeouts
MCP Tool:
Supported formats:
- -Integer/float: seconds (e.g.,
300= 5 minutes) - -String with suffix:
"5m"(minutes),"2h"(hours),"1d"(days) - -Examples:
"90m","2h","1.5h",300,"1d"
Python API:
Timeout Guidelines
| Scenario | Recommended | Notes |
|---|---|---|
| Quick test | 10-30 min | Verify setup |
| Data processing | 1-2 hours | Depends on data size |
| Batch inference | 2-4 hours | Large batches |
| Experiments | 4-8 hours | Multiple runs |
| Long-running | 8-24 hours | Production workloads |
Always add 20-30% buffer for setup, network delays, and cleanup.
On timeout: Job killed immediately, all unsaved progress lost
Cost Estimation
General guidelines:
Example calculations:
Quick test:
- -Hardware: cpu-basic ($0.10/hour)
- -Time: 15 minutes (0.25 hours)
- -Cost: $0.03
Data processing:
- -Hardware: l4x1 ($2.50/hour)
- -Time: 2 hours
- -Cost: $5.00
Batch inference:
- -Hardware: a10g-large ($5/hour)
- -Time: 4 hours
- -Cost: $20.00
Cost optimization tips:
1. Start small - Test on cpu-basic or t4-small
2. Monitor runtime - Set appropriate timeouts
3. Use checkpoints - Resume if job fails
4. Optimize code - Reduce unnecessary compute
5. Choose right hardware - Don't over-provision
Monitoring and Tracking
Check Job Status
MCP Tool:
Python API:
CLI:
Remember: Wait for user to request status checks. Avoid polling repeatedly.
Job URLs
After submission, jobs have monitoring URLs:
View logs, status, and details in the browser.
Wait for Multiple Jobs
Scheduled Jobs
Run jobs on a schedule using CRON expressions or predefined schedules.
MCP Tool:
Python API:
Available schedules:
- -
@annually,@yearly- Once per year - -
@monthly- Once per month - -
@weekly- Once per week - -
@daily- Once per day - -
@hourly- Once per hour - -CRON expression - Custom schedule (e.g.,
"*/5 * * * *"for every 5 minutes)
Manage scheduled jobs:
Python API for management:
Webhooks: Trigger Jobs on Events
Trigger jobs automatically when changes happen in Hugging Face repositories.
Python API:
How it works:
1. Webhook listens for changes in watched repositories
2. When triggered, the job runs with WEBHOOK_PAYLOAD environment variable
3. Your script can parse the payload to understand what changed
Use cases:
- -Auto-process new datasets when uploaded
- -Trigger inference when models are updated
- -Run tests when code changes
- -Generate reports on repository activity
Access webhook payload in script:
See Webhooks Documentation for more details.
Common Workload Patterns
This repository ships ready-to-run UV scripts in hf-jobs/scripts/. Prefer using them instead of inventing new templates.
Pattern 1: Dataset → Model Responses (vLLM) — scripts/generate-responses.py
What it does: loads a Hub dataset (chat messages or a prompt column), applies a model chat template, generates responses with vLLM, and pushes the output dataset + dataset card back to the Hub.
Requires: GPU + write token (it pushes a dataset).
Pattern 2: CoT Self-Instruct Synthetic Data — scripts/cot-self-instruct.py
What it does: generates synthetic prompts/answers via CoT Self-Instruct, optionally filters outputs (answer-consistency / RIP), then pushes the generated dataset + dataset card to the Hub.
Requires: GPU + write token (it pushes a dataset).
Pattern 3: Streaming Dataset Stats (Polars + HF Hub) — scripts/finepdfs-stats.py
What it does: scans parquet directly from Hub (no 300GB download), computes temporal stats, and (optionally) uploads results to a Hub dataset repo.
Requires: CPU is often enough; token needed only if you pass --output-repo (upload).
Common Failure Modes
Out of Memory (OOM)
Fix:
1. Reduce batch size or data chunk size
2. Process data in smaller batches
3. Upgrade hardware: cpu → t4 → a10g → a100
Job Timeout
Fix:
1. Check logs for actual runtime
2. Increase timeout with buffer: "timeout": "3h"
3. Optimize code for faster execution
4. Process data in chunks
Hub Push Failures
Fix:
1. Add token to secrets: MCP uses "$HF_TOKEN" (auto-replaced), Python API uses get_token() (must pass real token)
2. Verify token in script: assert "HF_TOKEN" in os.environ
3. Check token permissions
4. Verify repo exists or can be created
Missing Dependencies
Fix:
Add to PEP 723 header:
Authentication Errors
Fix:
1. Check hf_whoami() works locally
2. Verify token in secrets — MCP: "$HF_TOKEN", Python API: get_token() (NOT "$HF_TOKEN")
3. Re-login: hf auth login
4. Check token has required permissions
Troubleshooting
Common issues:
- -Job times out → Increase timeout, optimize code
- -Results not saved → Check persistence method, verify HF_TOKEN
- -Out of Memory → Reduce batch size, upgrade hardware
- -Import errors → Add dependencies to PEP 723 header
- -Authentication errors → Check token, verify secrets parameter
See: references/troubleshooting.md for complete troubleshooting guide
Resources
References (In This Skill)
- -
references/token_usage.md- Complete token usage guide - -
references/hardware_guide.md- Hardware specs and selection - -
references/hub_saving.md- Hub persistence guide - -
references/troubleshooting.md- Common issues and solutions
Scripts (In This Skill)
- -
scripts/generate-responses.py- vLLM batch generation: dataset → responses → push to Hub - -
scripts/cot-self-instruct.py- CoT Self-Instruct synthetic data generation + filtering → push to Hub - -
scripts/finepdfs-stats.py- Polars streaming stats overfinepdfs-eduparquet on Hub (optional push)
External Links
Official Documentation:
- -HF Jobs Guide - Main documentation
- -HF Jobs CLI Reference - Command line interface
- -HF Jobs API Reference - Python API details
- -Hardware Flavors Reference - Available hardware
Related Tools:
- -UV Scripts Guide - PEP 723 inline dependencies
- -UV Scripts Organization - Community UV script collection
- -HF Hub Authentication - Token setup
- -Webhooks Documentation - Event triggers
Key Takeaways
1. Submit scripts inline - The script parameter accepts Python code directly; no file saving required unless user requests
2. Jobs are asynchronous - Don't wait/poll; let user check when ready
3. Always set timeout - Default 30 min may be insufficient; set appropriate timeout
4. Always persist results - Environment is ephemeral; without persistence, all work is lost
5. Use tokens securely - MCP: secrets={"HF_TOKEN": "$HF_TOKEN"}, Python API: secrets={"HF_TOKEN": get_token()} — "$HF_TOKEN" only works with MCP tool
6. Choose appropriate hardware - Start small, scale up based on needs (see hardware guide)
7. Use UV scripts - Default to hf_jobs("uv", {...}) with inline scripts for Python workloads
8. Handle authentication - Verify tokens are available before Hub operations
9. Monitor jobs - Provide job URLs and status check commands
10. Optimize costs - Choose right hardware, set appropriate timeouts
Quick Reference: MCP Tool vs CLI vs Python API
| Operation | MCP Tool | CLI | Python API |
|---|---|---|---|
| Run UV script | `hf_jobs("uv", {...})` | `hf jobs uv run script.py` | `run_uv_job("script.py")` |
| Run Docker job | `hf_jobs("run", {...})` | `hf jobs run image cmd` | `run_job(image, command)` |
| List jobs | `hf_jobs("ps")` | `hf jobs ps` | `list_jobs()` |
| View logs | `hf_jobs("logs", {...})` | `hf jobs logs <id>` | `fetch_job_logs(job_id)` |
| Cancel job | `hf_jobs("cancel", {...})` | `hf jobs cancel <id>` | `cancel_job(job_id)` |
| Schedule UV | `hf_jobs("scheduled uv", {...})` | - | `create_scheduled_uv_job()` |
| Schedule Docker | `hf_jobs("scheduled run", {...})` | - | `create_scheduled_job()` |
FAQ
Discussion
Loading comments...