Troubleshooting

Find your symptom below, then follow the linked fix. For CLI syntax, see Run a Benchmark.

Debug logging

Enable debug output to inspect request handling and worker startup:

GUIDELLM__LOGGING__CONSOLE_LOG_LEVEL=DEBUG guidellm run ... --disable-progress

Run guidellm env to confirm the settings are being applied. The --disable-progress call is optional, but the interactive progress console can overwrite console log messages. Alternatively, you can use a file log as mentioned in the logging guide .

For all logging options (file output, log levels), see Logging in the development guide.

Tokenizer: trust_remote_code

Symptom

You get an error that looks like:

The repository moonshotai/Kimi-K2.6 contains custom code which must be executed
to correctly load the model. You can inspect the repository content at
https://hf.co/moonshotai/Kimi-K2.6.
You can avoid this prompt in future by passing the argument `trust_remote_code=True`.

Fix

If you fully trust the model, pass trust_remote_code through --tokenizer load_kwargs:

--tokenizer '{"kind":"huggingface_auto","load_kwargs":{"trust_remote_code":true}}'

Do not use this if you do not trust the model, as this allows code execution on your machine.

See Datasets: Tokenizer for other tokenizer options.

Requests load after they are due

Symptom

A benchmark warns that data generation is slowing the run, that conversations were loaded late, or that a trace dataset was not fully loaded.

Fix

Load request graphs before the run clock starts with prefetch on --profile:

• 0 (the default) loads graphs as the run consumes them.
• A count loads that many request nodes first.
• start matches the strategy's startup concurrency when it defines one.
• all loads every request from a finite dataset. An infinite data source will fail unless --data-loader kind=pytorch,samples=<n> caps it.

All profiles accept the prefetch parameter. Here is an example of how to use it with a concurrent profile:

--profile kind=concurrent,prefetch=all

WEKA traces should use prefetch=all. Every session has requests that start at or near 0, so loading them during the run results in the data falling behind, causing conversations to start late.

macOS worker crash (signal 11)

Symptom

RuntimeError: Worker process group startup failed: Worker process <pid> died
unexpectedly (signal 11). Check system logs for details

You may also see repeated log lines such as:

Worker process <pid> died unexpectedly (signal 11)

Fix

GuideLLM defaults to fork multiprocessing, which can segfault on macOS. Use spawn instead:

GUIDELLM__MP_CONTEXT_TYPE=spawn guidellm run ...