# Palmetto Cpu Request Advisor

> Estimate and right-size Palmetto CPU requests before submitting CPU or GPU jobs. Use when choosing Slurm cpus-per-task/ntasks, interpreting low CPU utilization, or avoiding over-allocation for serial jobs, dataloaders, and GPU training runs.

- Skill: `kwongfuk/palmetto-cpu-request-advisor` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kwongfuk/palmetto-cpu-request-advisor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kwongfuk/palmetto-cpu-request-advisor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: KwongFuk (https://skillmd.com/u/kwongfuk)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/kwongfuk/palmetto-cpu-request-advisor

---


# Palmetto CPU Request Advisor

Use this skill before submitting or retuning Palmetto jobs when CPU sizing is unclear.

Goal:
- estimate how many CPU cores the workload can really use
- avoid serial jobs requesting many idle cores
- choose a conservative starting CPU count for GPU jobs
- re-check completed runs and shrink or raise CPU requests based on evidence

## When To Use

Trigger this skill when the user asks to:
- choose `#SBATCH --cpus-per-task` or `#SBATCH --ntasks`
- explain low `CPU-Util` from `jobstats`
- size CPUs for GPU training, inference, or dataloader-heavy jobs
- size CPUs for serial Python, MATLAB, R, shell, or single-process jobs
- decide whether a current CPU request is wasteful before `sbatch`

## Workflow

1. Identify the workload shape:
- `serial single-process`: one Python process, one script, no worker pool, no MPI
- `threaded`: OpenMP, BLAS, PyTorch intra-op threads, JVM threads, or similar
- `multi-process`: dataloader workers, multiprocessing pools, MPI ranks, task farms

2. Check prior evidence first when available:

```bash
jobstats <jobid>
```

- If `CPU-Util` is close to `100% / allocated CPU-cores`, treat the job as effectively single-core.
- Aim for about `90%+` of the allocated CPU capacity for sustained CPU-bound jobs.
- If the job used far less CPU than requested, lower the next submission.

3. If no prior run exists, choose a conservative starting point:
- CPU-only serial jobs: `--nodes=1`, `--ntasks=1`, `--cpus-per-task=1`
- CPU-only threaded jobs: start from the real thread count, not a guess
- 1-GPU jobs: start around `4-8 CPU / GPU`
- 2+ GPU single-node jobs: start around `4-8 CPU / GPU`, then cap to what the input pipeline can actually feed
- Dataloader-heavy jobs: count the actual worker processes and a small margin for the main process

4. Distinguish `ntasks` from `cpus-per-task` correctly:
- Use higher `ntasks` when the code launches multiple independent processes or MPI ranks.
- Use higher `cpus-per-task` when one task uses threads.
- Do not increase both unless the workload truly uses both processes and threads.

5. After the first run, re-check and retune:
- If GPUs are underutilized and CPU usage is high, increase CPUs modestly.
- If CPU usage is low, lower CPUs before the next run.
- If the job is serial, keep it at `1` CPU unless profiling proves otherwise.

## Heuristics

- Treat serial jobs as `1 CPU` by default.
- Treat extra CPUs as justified only by observed threads, worker processes, or measured throughput gains.
- For PyTorch jobs, remember that `num_workers`, tokenization, decoding, and data staging can need extra CPUs, but many training loops still do not need large CPU counts.
- Prefer smaller CPU requests first on busy partitions; they usually start sooner and waste less.
- If the user already knows the code is single-core, say so plainly and recommend `--cpus-per-task=1`.
- If the user also needs to know whether the reduced request can start now, switch to `$palmetto-slurm-fit-check`.

## Notes

- `CPU-Util` well below the allocated capacity is a resizing signal, not a success metric.
- One completed pilot run with `jobstats` is usually more reliable than guessing from the script alone.
- Keep the recommendation explicit: say what CPU count to request next and why.