Integrating NVIDIA NIM into an open-source LLM-guided fuzzing project — request more RPM

Hi NVIDIA NIM team,

I’m a researcher working on an open-source LLM-guided fuzzing framework

and would like to ask whether my account’s rate limit could be raised

above the default 40 RPM — any headroom you can grant would be helpful,

and the higher the better.

About the project

==================

FuzzPilot --- Off-hot-path LLM control for AFL++ via recipe-guided

mutation and micro-campaign validation.

GitHub:  https://github.com/qiaozhiyi/fuzz_agent

License: see LICENSE in the repo (open source)

Paper:   arXiv preprint in preparation; targeting a software-engineering

         venue (ISSTA / FSE / TSE class)

The core idea is that the LLM never appears on the per-mutation hot

path of AFL++. Instead, a controller invokes the model only at

coverage-plateau boundaries to propose a structured "recipe" (op

weights + dictionary tokens + focus ranges). Each recipe is validated

empirically in a short isolated micro-campaign before it is promoted

to the main fuzz loop, and a native AFL++ custom mutator dispatches

on the promoted recipe at full native throughput.

The repo is fully reproducible: target binaries, AFL++ commit pin,

Ghidra extractor, manifest, run scripts, and decision logs are all

under version control.

Why NVIDIA NIM

===============

After evaluating several OpenAI-compatible providers, NIM is the

cleanest fit for an academic reproducibility story:

- One API surface across many open-weight model families

  (Llama 4, Nemotron, GLM, DeepSeek, Qwen3, GPT-OSS).

- No per-token billing --- researchers replicating my paper can use

  their own NIM account without surprise costs.

- No credit-card friction for academic users.

- OpenAI-compatible, so FuzzPilot's existing \`model_api\` schema

  works out of the box.

I'm standardizing the paper's reference configuration on

\`meta/llama-4-maverick-17b-128e-instruct\`, with

\`openai/gpt-oss-120b\` as a documented fallback. Both endpoints

resolve through integrate.api.nvidia.com/v1/chat/completions.

When the paper drops, NVIDIA NIM will be cited as the reference

model backend in the Evaluation and Reproducibility sections, and

the repo's README will include a "Powered by NVIDIA NIM" pointer

to build.nvidia.com plus the Llama 4 Maverick model card.

Why I’d benefit from more RPM

==============================

The paper's evaluation matrix is 11 runs × 4 h wall-clock, organized

as 4 parallel AFL++ campaigns per experiment. Steady-state load is

well under 40 RPM, but plateau bursts (multiple campaigns hitting a

plateau in the same window, each spawning a small set of specialized

agents --- coordinator, plateau-diagnosis, scheduler, dictionary,

format, mutator, corpus, crash-triage) regularly push above it.

Any increase would help. As a concrete data point, \~100 RPM lets the

4-parallel matrix run as designed without serializing campaigns and

doubling the wall-clock; \~200 RPM gives comfortable headroom for

future ablation runs and reproductions by other researchers.

Account info

Single user, non-commercial, results released alongside the paper.

I’m happy to share manifests, sample agent_decisions.jsonl traces, or

anything else useful. Thanks for considering the request.

best,

qiaozhiyi