Check in this order: the startup message in the log, the response from the health endpoint, and the container status “healthy.”
docker logs mesh-clustering | head -20
curl -k https://localhost:<aussen>/clustering/health
docker inspect --format='{{.State.Health.Status}}' mesh-clusteringThe most common startup problems:
Certificate material is missing or incorrectly named → the service responds via HTTP instead of HTTPS.
Share not mounted → Jobs report that the catalog CSV cannot be parsed.
An old container—even a stopped one—is taking up the name → remove it.
GPU is in use by another process → the service continues to run on the CPU; this is correct, but significantly slower.
A request or preset requires the language_model "gemma3," but the default image no longer includes it → the run fails at runtime. The error message is misleading (“couldn’t connect to huggingface.co”); switch to gemma4 or use an opt-in image that includes gemma3.
When booting a gemma4 image for the first time, the smoke test also includes recording the actual peak VRAM value using nvidia-smi, as long as that value has not yet been measured (see open item in Chapter 4).
As soon as the service is running, the application server calls the four endpoints in the order specified in Chapter 4—see Section 2.2 for setup instructions.