Fix Docker deployment#30
Conversation
There was a problem hiding this comment.
Pull request overview
Updates the project’s Docker packaging to make deployments reproducible and runnable via docker compose, with explicit GPU-related defaults.
Changes:
- Pin the Docker base image and force amd64 builds in the Dockerfile; add GPU env vars and an executable ENTRYPOINT.
- Add a
docker-compose.ymlservice definition requesting NVIDIA GPUs. - Add
.dockerignoreand document Docker build/run steps in the README.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| docker/Dockerfile | Pins base image, sets NVIDIA env vars, installs package, and defines ENTRYPOINT. |
| docker-compose.yml | Adds a compose service intended to request NVIDIA GPU access. |
| README.md | Documents docker compose build and docker compose run usage. |
| .dockerignore | Reduces Docker build context size by ignoring caches/artifacts. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| RUN pip install --no-cache-dir . | ||
|
|
||
| ENTRYPOINT ["python3", "-m", "mmirage.shard_process"] |
There was a problem hiding this comment.
The container ENTRYPOINT runs mmirage.shard_process, but the current config loading relies on ProcessorRegistry being populated via importing processor modules (e.g., the llm processor registers itself at import time). shard_process.py/load_mmirage_config() don’t import mmirage.core.process (or the processor modules), so --config runs are likely to fail with Processor llm not registered. Consider ensuring processor registration happens before calling load_mmirage_config (e.g., import mmirage.core.process in the CLI/module or add explicit registration in config loading).
| ENTRYPOINT ["python3", "-m", "mmirage.shard_process"] | |
| ENTRYPOINT ["python3", "-c", "import mmirage.core.process, runpy; runpy.run_module('mmirage.shard_process', run_name='__main__')"] |
| The container requires an NVIDIA GPU. The `docker-compose.yml` handles GPU access automatically. | ||
|
|
There was a problem hiding this comment.
The README implies GPU access will work automatically via docker-compose.yml, but users still need host-side prerequisites (NVIDIA drivers + NVIDIA Container Toolkit / nvidia-container-runtime) for the container to see GPUs. Consider adding a short prerequisite note (and any minimum Docker/Compose versions) so docker compose run failures are easier to diagnose.
| The container requires an NVIDIA GPU. The `docker-compose.yml` handles GPU access automatically. | |
| The container requires an NVIDIA GPU. The `docker-compose.yml` is configured to request GPU access, but the host must have: | |
| - NVIDIA GPU drivers installed | |
| - NVIDIA Container Toolkit / `nvidia-container-runtime` configured for Docker | |
| - A recent Docker Engine and Docker Compose version with GPU support enabled | |
| Without these host-side prerequisites, `docker compose run` may fail to detect or use the GPU. |
|
@fabnemEPFL The repetitive To fix this, I updated the workflow to safely skip the login-action and push steps when I also applied the Copilot suggestions for the |
| @@ -1,5 +1,11 @@ | |||
| FROM docker.io/lmsysorg/sglang:latest | |||
| FROM --platform=linux/amd64 lmsysorg/sglang:v0.5.8.post1-runtime | |||
There was a problem hiding this comment.
and why not keep the latest image?
There was a problem hiding this comment.
- Tested on a local AMD system and forgot to remove the platform flag before pushing, my
bad 😅 removed it now. - Pinned the version for reproducibility since latest keeps changing. Switched back to
latest now.
| docker compose run --rm mmirage --config configs/your_config.yaml | ||
| ``` | ||
|
|
||
| The container requires an NVIDIA GPU. The `docker-compose.yml` is configured to request GPU access, but the host must have: |
There was a problem hiding this comment.
there should also be a CPU-only image (there will soon be support for API-based LLMs that do not require GPUs)
There was a problem hiding this comment.
i have created the Dockerfile.cpu using python:3.11-slim but sglang is a hard dependency in the pyproject.toml. so its fails because it needs CUDA headers doesnt exist in CPU image.
one thing we can do is move sglang and realted dependencies to project.optional-dependencies in project.toml
or we can wrap the SGlang import in the llm_processor.py with try/except
how would you like me to proceed?
There was a problem hiding this comment.
you can take inspiration from mmore's dependencies, with rules separated depending on CPU/GPU
fix/docker-deployment branch
restore image name
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 9 out of 9 changed files in this pull request and generated 7 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| """ | ||
| super().__init__(engine_args, **kwargs) | ||
| if not SGLANG_AVAILABLE: | ||
| raise RuntimeError("SGLang is not installed. Install with: pip install '.[gpu]'") |
| @@ -14,14 +14,43 @@ To install the library, you can clone it from GitHub and then use pip to install | |||
|
|
|||
| ```bash | |||
| git clone git@github.com:EPFLiGHT/MMIRAGE.git | |||
| pip install -e ./MMIRAGE | |||
| pip install -e './MMIRAGE[gpu]' | |||
| ``` | |||
|
|
||
| RUN pip install --no-cache-dir .[gpu] | ||
|
|
||
| ENTRYPOINT ["python3", "-c", "import mmirage.core.process, runpy; runpy.run_module('mmirage.shard_process', run_name='__main__')"] |
|
|
||
| RUN pip install --no-cache-dir . | ||
|
|
||
| ENTRYPOINT ["python3", "-c", "import mmirage.core.process, runpy; runpy.run_module('mmirage.shard_process', run_name='__main__')"] |
| FROM lmsysorg/sglang:latest | ||
|
|
||
| ENV NVIDIA_VISIBLE_DEVICES=all | ||
| ENV NVIDIA_DRIVER_CAPABILITIES=compute,utility |
There was a problem hiding this comment.
updated the description
| ${{ secrets.DOCKERHUB_USERNAME }}/${{ matrix.name }}:latest-${{ matrix.tag_base }} | ||
| ${{ secrets.DOCKERHUB_USERNAME }}/${{ matrix.name }}:${{ github.sha }}-${{ matrix.tag_base }} |
| @@ -26,6 +29,14 @@ jobs: | |||
| path: docker/Dockerfile | |||
| tag_base: arm64 | |||
| name: mmirage-git | |||
There was a problem hiding this comment.
Thanks @HarshaSatyavardhan for your contribution!
I will most likely address the comments I made in a subsequent PR, so no need to make any changes
| - platform: ubuntu-latest | ||
| path: docker/Dockerfile.cpu | ||
| tag_base: amd64 | ||
| name: mmirage-git-cpu | ||
| - platform: ubuntu-24.04-arm | ||
| path: docker/Dockerfile | ||
| path: docker/Dockerfile.cpu | ||
| tag_base: arm64 | ||
| name: mmirage-git | ||
| name: mmirage-git-cpu |
There was a problem hiding this comment.
It's a bit weird to not use the same base image depending on the target platform, aditionnallyubuntu-latest does support linux/arm64 as per the documentation
As a future improvement we could have a workflow that reuse ubuntu-latest with several target platforms
|
|
||
| RUN pip install --no-cache-dir .[gpu] | ||
|
|
||
| ENTRYPOINT ["python3", "-m", "mmirage.shard_process"] |
There was a problem hiding this comment.
it's wrong to use this entrypoint, this means you can only run the mmirage.shard_process and not MMIRAGE's CLI
| ENTRYPOINT ["python3", "-m", "mmirage.shard_process"] | |
| ENTRYPOINT ["mmirage"] |
This way if you can directly call the CLI command run specifically designed to call mmirage.shard_process, and you can easily call the other CLI commands without workaround
There was a problem hiding this comment.
After discussing with Fabrice, to be coherent with the documentation we will drop the entrypoint so that we just prefix each command by mmirage as said everywhere
| ```bash | ||
| docker compose build | ||
| ``` |
There was a problem hiding this comment.
This means you build both the GPU and CPU images while only actually using one of the two in the end
On my computer the build takes >10min, we could make it more optimized
| @@ -1,5 +1,11 @@ | |||
| FROM docker.io/lmsysorg/sglang:latest | |||
| FROM lmsysorg/sglang:latest | |||
There was a problem hiding this comment.
After testing on RCP, lmsysorg/sglang:latest is based over CUDA 13 but dependency sgl_kernel requires a CUDA 12 lib, so we'll have to fix the base image to an older version under CUDA 12
|
|
||
| [project.optional-dependencies] | ||
| gpu = [ | ||
| "sglang>=0.5.2", |
There was a problem hiding this comment.
| "sglang>=0.5.2", | |
| "sglang==0.5.10", |


Fixes #22
lmsysorg/sglang:latest--platform=linux/amd64to fix arm64 CI buildNVIDIA_VISIBLE_DEVICESandNVIDIA_DRIVER_CAPABILITIESenv vars for GPU visibilityENTRYPOINTto make the container executabledocker-compose.ymlwith NVIDIA GPU support