Logging: framework vs engine
Intel® Inference Microservices has two log-level knobs, both read once at startup: INFERENCE_LOG_LEVEL for the container's own startup and hardware-detection logs, and INFERENCE_LOG_LEVEL_ROOT for vLLM and other third-party libraries. Keeping them separate is the point — you can see what the runtime decided without vLLM's output burying it.
| Variable | Default | What it controls |
|---|---|---|
INFERENCE_LOG_LEVEL | INFO | This container: hardware detection, configuration selection, startup |
INFERENCE_LOG_LEVEL_ROOT | WARNING | The engine and other libraries, after vLLM takes over |
See what the runtime decided
Turn the framework up and leave the engine quiet:
docker run -e INFERENCE_LOG_LEVEL=DEBUG -e INFERENCE_LOG_LEVEL_ROOT=ERROR ...At DEBUG you get the detected hardware, which built-in configuration was selected and why, the resolved cache path, and the engine command that was generated. That is usually enough to explain an unexpected configuration without touching the engine's own logging at all.
What each level prints
| Level | Framework (INFERENCE_LOG_LEVEL) | Engine (INFERENCE_LOG_LEVEL_ROOT) |
|---|---|---|
DEBUG | Hardware detection, which built-in config was picked | vLLM internals |
INFO | Config applied, server starting | vLLM startup |
WARNING | Overrides and ignored values | vLLM warnings |
ERROR | Configuration errors | vLLM errors |
Watch for WARNING in particular: an invalid INFERENCE_ENGINE_ARGS JSON string and an unrecognized INFERENCE_ACCELERATOR_MODEL are warnings, not failures. The container keeps serving with that setting ignored, so a silent surprise shows up here rather than as an error. Falling back to a general configuration is not a warning — it is the INFO line Selected profile: ... (type=general), which the default level already prints.
Where the logs go
To the container's stdout and stderr — docker logs <container> with Docker, kubectl logs deployment/<name> in a cluster. Nothing is written to a file inside the container, so your existing log collector picks it up without extra configuration. For probe failures and OOM kills, which never reach the application log, use kubectl describe pod <name>.
Related pages
- Environment variables — both log-level knobs, and every other setting
- CLI —
dry-run— see the resolved configuration directly instead of reading logs for it - Troubleshooting — the errors these levels help you find