/bionemo-evo2-nim

name: evo2-nim
description: >
  Generate and analyze DNA sequences using NVIDIA's Evo 2 BioNeMo NIM microservice. Use for Evo2/Evo 2, DNA generation, genomic sequence generation, hosted generation, local Docker deployment, local forward passes, layer outputs, logits, sampled probabilities, and BioNeMo NIM workflows.
license: Apache-2.0 AND CC-BY-4.0
compatibility: "requests>=2.28; numpy>=1.24"
allowed-tools: Bash, Read, Write, AskUserQuestion

Evo 2 NIM

Use Evo 2 for DNA generation and, locally, layer-output extraction. Load supplemental files only when needed:

• `references/api.md`: exact schemas, layer names, Docker flags, hardware notes.
• `references/science.md`: genomic use cases, limits, and interpretation.
• `references/parameters.md`: generation/forward parameter effects.
• `references/validation.md`: DNA, probability, timing, and tensor checks.
• `references/examples.md`: compact hosted/local request patterns.

Instructions

For generation, use `scripts/generate.py` to execute the request, validate the response, and save its artifacts. Resolve the script path relative to this skill's directory and choose an output directory in the user's workspace. Use the user's sequence and requested parameters; the example below is only a smoke test.

1. Select the requested mode. For hosted generation, go directly to the generation example; Docker setup and local forward passes are separate tasks. 2. When the user asks to run generation, execute the client and inspect its exit status and result. Writing a script alone does not complete that request. 3. Report the generated DNA (or its file for long sequences), actual `elapsed_ms`, sampled-probability summary, seed, and artifact paths from the successful run. Read the saved response or metrics if any result is unclear.

If the request or validation fails, report the actual failure and any diagnostic files. Do not replace an unavailable API response with example values. For a code-only request, provide the command without making an inference call.

Choose Mode

Honor `NIM_API_MODE` when it is set. Accepted values are `hosted` and `local`. If it is unset, treat an explicit `EVO2_NIM_URL` as local; otherwise ask when the requested mode is unclear:

> Hosted NVIDIA API or local Docker Evo 2 NIM?

• Hosted generation: `https://health.api.nvidia.com/v1/biology/arc/evo2-40b/generate`
• Local base URL: `$EVO2_NIM_URL`, falling back to `http://localhost:8000`
• Local generation: `$EVO2_NIM_URL/biology/arc/evo2/generate`
• Local forward/layer outputs: `$EVO2_NIM_URL/biology/arc/evo2/forward`

Always resolve local health and inference routes from `EVO2_NIM_URL` when it is present. `localhost` works only when the caller and NIM share a network namespace; a caller in a separate container usually needs a service URL such as `http://evo2-nim:8000`. Do not silently switch modes when the selected endpoint is unavailable. Report the failed endpoint and fix its configuration.

The hosted docs expose generation. `/forward` is documented for local Docker; do not invent a hosted `/forward` endpoint. Hosted requests use `Authorization: Bearer $NGC_API_KEY`. Supported local Docker startup uses `NGC_API_KEY` (or `NVIDIA_API_KEY` via the preflight) for registry login, entitlement checks, and first-run model downloads; pass it into the container with `-e NGC_API_KEY`. Local inference requests use no auth header after readiness. Warm-cache key-free startup varies by image/version and should not be assumed.

Examples

Normalize prompts before sending. Use A/C/G/T unless ambiguous bases are a deliberate modeling choice and clearly reported.

For a hosted generation request, run the bundled client with the user's inputs (the script path below is relative to the skill directory):

python scripts/generate.py \
  --mode hosted \
  --sequence ACTGACTGACTGACTG \
  --num-tokens 64 --seed 1 \
  --temperature 0.7 --top-k 3 --top-p 0.0 \
  --output-dir /path/to/workspace/evo2-output

For an already-ready local NIM, use `--mode local`; the client resolves `EVO2_NIM_URL` and sends no Authorization header. It never switches endpoints after a failed request. Set `--timeout` for a longer read if the user requests a larger generation; failed requests are not automatically resubmitted.

The client saves `request.json`, the actual `response.json`, `generated.fasta`, and `metrics.json` in the chosen output directory. It also saves the exact response body in `response.raw` before checking HTTP status or parsing JSON, so diagnostics survive malformed JSON and non-finite probability/timing values. It validates the requested number of generated bases, A/C/G/T alphabet, finite sampled probabilities in `[0, 1]`, and nonnegative timing before printing a successful summary. Existing directories are never reused, even if empty. Choose an output directory that does not exist; the client creates it atomically so concurrent runs cannot overwrite each other's artifacts. The FASTA contains generated bases only, not the input prompt prepended again.

`sampled_probs` is requested by the client and summarized with count/min/max/mean; the full values stay in the saved response. A missing or malformed probability array is a validation failure, not permission to invent confidence values. Only request `enable_logits` in a custom request when needed; logits can make responses large. See `references/api.md` for custom payloads. `random_seed` supports development reproducibility, not biological certainty.

Local Docker Requirements

Evo 2 local deployment requires FP8-capable GPUs. Do not present A100 as compatible; A100 can pull the image but fails warmup because FP8 requires compute capability 8.9 or higher.

• Default 40B: 2x H100 80 GB or 1x H200 141 GB. Use `NIM_TEST_GPUS=0,1` for

2x H100, or `NIM_TEST_GPUS=0` for one H200.

• 7B fallback: set `NIM_VARIANT=7b`; supported GPUs include H100, H200,

RTX 6000 Ada, and L40S.

• Approximate disk: 110 GB for 40B, 50 G