TL;DR

In this guide, you will deploy:

• MiniMaxAI/MiniMax-M3-MXFP8
• on a Fluence GPU VM powered by:
• 8 × NVIDIA H200 SXM
• 141GB VRAM per GPU
• 1,128GB aggregate GPU memory

You will use:

• Fluence GPU Cloud to provision the multi-GPU VM
• vLLM to run MiniMax M3 through an OpenAI-compatible API
• Open WebUI to provide a browser-based chat interface
• SSH tunneling to access the interface without exposing it publicly

This is a heavyweight deployment. MiniMax M3 has approximately 428 billion total parameters and 23 billion activated parameters, so it is not a single-GPU model. The official MXFP8 checkpoint reduces the memory requirement substantially compared with BF16, while an 8× H200 server gives the model enough memory for the weights, runtime overhead, multimodal encoder, and a useful KV cache.

Why MiniMax M3?

For this deployment, we will use:

• MiniMaxAI/MiniMax-M3-MXFP8
• MiniMax M3 is a native multimodal Mixture-of-Experts model designed for:
• Long-context reasoning
• Coding and software-engineering agents
• Tool calling
• Document and repository analysis
• Image and video understanding
• Collaborative productivity workflows

Its main specifications are:

Specification	MiniMax M3
Architecture	Mixture of Experts
Total parameters	Approximately 428B
Activated parameters	Approximately 23B
Native context	1,048,576 tokens
Inputs	Text, image, and video
Output	Text
Reasoning modes	Enabled, adaptive, and disabled
Quantization used here	MXFP8
Serving API	OpenAI-compatible through vLLM

MiniMax M3 is trained multimodally from the beginning rather than adding vision support to a text-only model afterward. The model uses MiniMax Sparse Attention, or MSA, to make million-token context more practical. Compared with M2 at a one-million-token context, MiniMax reports a 9× prefill speedup, more than a 15× decode speedup, and per-token compute reduced to approximately one-twentieth.

Why use the MXFP8 checkpoint?

The full model is also available in BF16:

MiniMaxAI/MiniMax-M3

However, BF16 is not the right starting point for this Fluence configuration.

vLLM describes MiniMaxAI/MiniMax-M3-MXFP8 as an NVIDIA-quantized checkpoint requiring roughly half the VRAM of the BF16 release. It retains the same model architecture, multimodal capabilities, context length, tool parser, and reasoning parser while leaving substantially more GPU memory available for runtime state and the KV cache.

The practical difference is:

Checkpoint	Main advantage	Main disadvantage
MiniMax M3 BF16	Highest native precision	Extremely tight fit even across 8× H200
MiniMax M3 MXFP8	Much smaller memory footprint	Quantized weight execution
MiniMax M3 NVFP4	Smaller still and optimized for Blackwell	Requires compatible Blackwell hardware and newer support

The earlier Fluence catalog does not list B200 or B300 servers. Therefore, the MXFP8 checkpoint on H200 is the strongest currently available combination from that catalog.

vLLM supports the MXFP8 model on Hopper GPUs through its Marlin MXFP8 path, while Blackwell systems use a native DeepGEMM MXFP8 backend. MiniMax M3 has been verified by vLLM on H200 hardware.

Why eight NVIDIA H200 GPUs?

The selected catalog configuration contains:

• 8 × NVIDIA H200 SXM
• 141GB HBM3e per GPU
• 1,128GB aggregate GPU memory

The H200 provides 141GB of HBM3e memory, up to 4.8TB/s of memory bandwidth, and high-speed NVLink support. It is designed for memory-intensive generative-AI and large-model workloads.

For Minimax imported-model compatibility, the recommended configuration is either H200_X8 or B200_X8 for MiniMaxAI/MiniMax-M3-MXFP8.

The vLLM MiniMax M3 recipe also uses eight-way tensor parallelism and identifies 8× H200 as a verified NVIDIA configuration.

Why not use eight H100 GPUs?

The earlier Fluence catalog includes less expensive 8× H100 options. The lowest listed H100 SXM configuration was approximately:

• 8 × H100 80GB
• 640GB aggregate VRAM
• $20.59/hour

This costs significantly less than the selected H200 node. However, MiniMax M3 MXFP8 has a very large model footprint. An 8× H100 node may leave comparatively little space for:

• The KV cache
• CUDA and vLLM runtime state
• Multimodal preprocessing
• Long outputs
• Concurrent requests
• Long-context workloads

The H200 configuration provides approximately 76% more aggregate GPU memory:

• H100 node: 640GB
• H200 node: 1,128GB

For a model whose main differentiators include one-million-token context and native multimodality, that additional headroom is valuable.

Why not use RTX PRO 6000 Blackwell GPUs?

The catalog also includes 8× RTX PRO 6000 Blackwell Server Edition configurations with 96GB per GPU. These provide:

• 768GB aggregate GPU memory
• Lower listed hourly pricing
• Blackwell-generation tensor cores

However, those catalog configurations use the PCIe interface. Large tensor-parallel models need frequent communication between GPUs, and PCIe-only communication is generally less suitable than an SXM system with high-speed GPU interconnects.

The official model compatibility guidance specifically identifies 8× H200 and 8× B200—not 8× RTX PRO 6000—as tested MiniMax M3 configurations. For a first deployment, the H200 node is therefore the lower-risk choice.

The selected Fluence configuration

The lowest-priced suitable 8× H200 VM row in Fluence is:

• Region: helsinki-finland-2
• Workload type: VM
• GPU model: NVIDIA H200
• GPU interface: SXM
• GPU count: 8
• VRAM per GPU: 141GB
• vCPU: 176
• System RAM: 1,450GB
• Storage: 6,000GB
• Price: $29.5152/hour

Estimated costs are:

Duration	Cost
Three-hour Fluence reserve	$88.55
24 hours	$708.36
730 hours (1 month)	$21,546.10

Note: Actual price and availability may differ in the Fluence Console.

The 6TB disk is particularly useful because MiniMax M3 is a very large checkpoint. It also leaves space for the Hugging Face cache, vLLM image, Open WebUI, temporary files, and logs.

Important license note

MiniMax M3 is best described as open-weight, not as an unrestricted open-source model.

Its MiniMax Community License allows non-commercial use. Commercial deployments must prominently display: Built with MiniMax M3

Commercial users below $20 million in annual product or service revenue must send MiniMax a one-time notice. Products or services generating more than $20 million annually require prior written authorization from MiniMax. Review the complete license before using the model commercially.

Why use a Fluence VM?

Fluence GPU Cloud supports:

• Containers
• Virtual machines
• Bare-metal instances

This guide uses a VM because it provides a complete operating system, GPU passthrough, direct SSH access, and control over Docker, NVIDIA Container Toolkit, storage, and networking. Fluence’s VM images are available with CUDA drivers and GPU support already configured.

A VM is useful here because you need to:

• Verify eight GPUs
• Inspect the GPU topology
• Install Docker
• Configure the NVIDIA container runtime
• Store hundreds of gigabytes of model files
• Run a custom vLLM image
• Operate Open WebUI

What this deployment stack looks like

Your laptop → Encrypted SSH tunnel → Fluence GPU VM → 8 × NVIDIA H200 SXM GPUs → vLLM tensor-parallel inference → MiniMax M3 MXFP8 → OpenAI-compatible API → Open WebUI → Browser at localhost:3000

The vLLM endpoint will run on the VM at: http://127.0.0.1:8000/v1

Open WebUI will run at: http://127.0.0.1:8080

Your laptop will access Open WebUI through: http://localhost:3000

The model API and interface will not be directly exposed through the VM’s public IP.

What you need before starting

You need:

• A Fluence account with GPU Cloud access
• At least $88.55 of available Fluence balance
• An SSH key registered in Fluence
• A terminal application on your laptop
• A modern web browser

Fluence reserves three hours of rent when an instance is launched. One hour is charged immediately and the other two hours remain in the instance reserve. Unused reserved balance is returned when the instance is terminated.

Step 1: Create an SSH key

Skip this step when you already have an SSH key registered with Fluence.

On your laptop, open a terminal and run:

ssh-keygen -t ed25519 -C "fluence-minimax"

Press Enter to accept the default location.

The command normally creates:

~/.ssh/id_ed25519

~/.ssh/id_ed25519.pub

Display the public key:

cat ~/.ssh/id_ed25519.pub

Copy the entire line.

Open the Fluence Console and go to:

Settings → SSH Keys

Add the public key. Fluence supports ED25519, RSA, and ECDSA SSH keys.

Step 2: Launch the 8× H200 VM

Open:

Fluence Console → GPU Cloud

Select:

Workload type: VM

GPU model: NVIDIA H200

GPU interface: SXM

VRAM: 141GB

GPU count: x8

Choose the catalog configuration closest to:

Location: helsinki-finland-2

vCPU: 176

RAM: 1,450GB

Storage: 6,000GB

Price: $29.51/hour

Use an identifiable instance name, for example:

minimax-m3-h200-vllm

Choose an Ubuntu or Linux CUDA-ready image and select your SSH key.

Fluence’s VM launch flow lets you choose the GPU model, GPU count, interface, region, CPU, system memory, storage, OS image, and SSH keys. SXM is intended for higher-bandwidth multi-GPU workloads, while multi-GPU configurations are suitable for large-model inference.

Review the three-hour upfront amount and launch the VM.

Provisioning normally takes approximately two to three minutes on Fluence. When the status changes to Active, connection details become available.

Step 3: Connect to the VM over SSH

Open the VM’s details page.

Fluence shows:

• Public IP address
• Associated SSH key
• Hardware configuration
• Hourly price
• Ready-to-use SSH command

The command will resemble:

ssh -i ~/.ssh/id_ed25519 \

  -o IdentitiesOnly=yes \

  ubuntu@YOUR_GPU_IP

Replace:

YOUR_GPU_IP

with the IP shown in Fluence.

Run the command on your laptop. The first connection may ask whether you trust the server fingerprint. Enter: yes

Fluence provides the IP address and ready-to-use SSH command on the VM details page.

Step 4: Verify all eight NVIDIA H200 GPUs

Inside the VM, run:

nvidia-smi -L

You should see eight GPUs:

GPU 0: NVIDIA H200

GPU 1: NVIDIA H200

GPU 2: NVIDIA H200

GPU 3: NVIDIA H200

GPU 4: NVIDIA H200

GPU 5: NVIDIA H200

GPU 6: NVIDIA H200

GPU 7: NVIDIA H200

Check the memory and driver:

nvidia-smi \

  --query-gpu=index,name,memory.total,driver_version \

  --format=csv

Each GPU should show approximately:

NVIDIA H200

141GB memory

Do not continue if fewer than eight GPUs are visible.

Step 5: Verify the GPU topology

Tensor parallelism splits the model across all eight GPUs, so GPU-to-GPU connectivity matters.

Run:

nvidia-smi topo -m

Look at the cells connecting GPU 0 through GPU 7.

A suitable SXM system should show high-speed NVIDIA interconnect paths, typically represented by values beginning with: NV

Connections such as SYS, PHB, or PIX indicate paths involving CPU sockets or PCIe components.

Step 6: Find the large storage volume

Run:

df -h

Then:

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS

Look for the mount point associated with the large disk.

Possible mount points include:

/data

/mnt/data

/ephemeral

For the rest of this guide, /data is used as the example.

Set the model storage path:

export MODEL_ROOT=/data

Check the available space:

df -h "$MODEL_ROOT"

You should have substantially more than 600GB free.

Persist the value:

echo 'export MODEL_ROOT=/data' >> ~/.bashrc

When the large disk is mounted somewhere else, replace /data with the actual mount point in every later command.

Do not format or repartition an unknown disk. When the 6TB volume is not mounted, check the Fluence instance configuration or ask the infrastructure provider how it should be mounted.

Step 7: Install the required system tools

Update the package index:

sudo apt-get update

Install the required utilities:

sudo apt-get install -y \

  curl \

  git \

  jq \

  ca-certificates \

  gnupg2 \

  openssl \

  ufw

These tools provide:

Tool	Purpose
curl	Download installers and test APIs
git	General development utility
jq	Format JSON API responses
openssl	Generate local API secrets
ufw	Basic firewall rules
gnupg2	Verify package repositories

Step 8: Configure the firewall

Allow SSH before enabling the firewall:

sudo ufw allow OpenSSH

Block direct public access to the model and UI ports:

sudo ufw deny 8000/tcp

sudo ufw deny 8080/tcp

Enable the firewall:

sudo ufw --force enable

Check the rules:

sudo ufw status

The later Docker commands will also bind ports 8000 and 8080 specifically to 127.0.0.1, which prevents them from listening on the VM’s public interface.

Step 9: Install Docker

Check whether Docker is already installed:

docker --version

sudo docker ps

When Docker is not installed, run:

curl -fsSL https://get.docker.com -o get-docker.sh

sudo sh get-docker.sh

Enable and start Docker:

sudo systemctl enable --now docker

Confirm that it is running:

sudo docker version

For a long-lived production environment, install Docker through its official package repository and pin the versions used by your deployment.

Step 10: Install NVIDIA Container Toolkit

Docker needs NVIDIA Container Toolkit to pass the H200 GPUs into the vLLM container.

Configure NVIDIA’s package repository:

curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \

  | sudo gpg --dearmor \

  -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

Add the repository:

curl -s -L \

  https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \

  | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' \

  | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

Install the toolkit:

sudo apt-get update

sudo apt-get install -y nvidia-container-toolkit

Configure Docker to use the NVIDIA runtime:

sudo nvidia-ctk runtime configure --runtime=docker

Restart Docker:

sudo systemctl restart docker

These steps follow NVIDIA’s official Ubuntu/Debian installation and Docker-runtime configuration process.

Step 11: Test GPU access from Docker

Run:

sudo docker run --rm \

  --gpus all \

  nvidia/cuda:12.8.1-base-ubuntu22.04 \

  nvidia-smi -L

The output should list all eight H200 GPUs.

If Docker reports that it cannot select an NVIDIA device driver, repeat:

sudo nvidia-ctk runtime configure --runtime=docker

sudo systemctl restart docker

Then run the test again.

Step 12: Create the model cache and Docker network

Create a Hugging Face cache on the large storage volume:

sudo mkdir -p "$MODEL_ROOT/huggingface-cache"

sudo chown -R "$USER:$USER" "$MODEL_ROOT/huggingface-cache"

Create a private Docker network:

sudo docker network create minimax-net

This network lets Open WebUI connect to vLLM by container name without exposing the model API publicly.

If Docker says that the network already exists, continue to the next step.

Step 13: Create a local vLLM API key

Generate a random API key:

openssl rand -hex 24 > ~/vllm_api_key.txt

Restrict access:

chmod 600 ~/vllm_api_key.txt

Display it:

cat ~/vllm_api_key.txt

Copy the value temporarily. You will add it to Open WebUI later.

This is a key for your own vLLM server. It is not a MiniMax API key, Fluence API key, or Hugging Face token.

Step 14: Pull the dedicated MiniMax M3 vLLM image

Run:

sudo docker pull vllm/vllm-openai:minimax-m3

The vLLM recipe currently recommends this dedicated image because MiniMax M3 support had not yet been included in a normal stable vLLM release when the recipe was published.

Step 15: Start MiniMax M3 with vLLM

Load the API key into your shell:

export VLLM_API_KEY=$(cat ~/vllm_api_key.txt)

Remove a previous container with the same name:

sudo docker rm -f minimax-vllm 2>/dev/null || true

Start the server:

sudo docker run -d \

  --name minimax-vllm \

  --network minimax-net \

  --gpus all \

  --ipc=host \

  -p 127.0.0.1:8000:8000 \

  -v "$MODEL_ROOT/huggingface-cache:/root/.cache/huggingface" \

  vllm/vllm-openai:minimax-m3 \

  --model "MiniMaxAI/MiniMax-M3-MXFP8" \

  --served-model-name "MiniMaxAI/MiniMax-M3-MXFP8" \

  --host 0.0.0.0 \

  --port 8000 \

  --tensor-parallel-size 8 \

  --block-size 128 \

  --max-model-len 131072 \

  --kv-cache-dtype fp8 \

  --gpu-memory-utilization 0.90 \

  --tool-call-parser minimax_m3 \

  --reasoning-parser minimax_m3 \

  --enable-auto-tool-choice \

  --mm-encoder-attn-backend FLASHINFER \

  --mm-processor-cache-type shm \

  --mm-encoder-tp-mode data \

  --api-key "$VLLM_API_KEY"

The command:

• Uses all eight H200 GPUs
• Splits the model with tensor parallelism
• Downloads and caches MiniMax M3 MXFP8
• Starts with a 128K context limit
• Uses an FP8 KV cache
• Enables MiniMax’s tool-call parser
• Enables MiniMax’s reasoning parser
• Supports text and multimodal requests
• Binds the API only to the VM’s loopback address

The –block-size 128 option is mandatory for MiniMax Sparse Attention. vLLM’s official MiniMax M3 guidance also uses eight-way tensor parallelism, the minimax_m3 parsers, FlashInfer for the multimodal encoder, and shared-memory preprocessing.

vLLM’s Docker guidance recommends GPU passthrough, a persistent Hugging Face cache, and –ipc=host or an enlarged shared-memory allocation for tensor-parallel inference.

Step 16: Monitor the initial model download and startup

Follow the logs:

sudo docker logs -f minimax-vllm

The first startup downloads hundreds of gigabytes of model data to:

$MODEL_ROOT/huggingface-cache

The logs will then show the model being distributed across the eight GPUs.

Look for messages indicating that:

• All eight tensor-parallel workers started
• The MXFP8 checkpoint was detected
• The model finished loading
• The API server started on port 8000

Press:

Ctrl + C

to stop following the logs. This does not stop the container.

[SCREENSHOT PLACEHOLDER: Dark-mode terminal showing MiniMax M3 MXFP8 checkpoint files downloading]

[SCREENSHOT PLACEHOLDER: Dark-mode terminal showing the model loading across eight H200 GPUs]

[SCREENSHOT PLACEHOLDER: Dark-mode terminal showing the vLLM server listening on port 8000]

Check the container state:

sudo docker ps

Step 17: Confirm GPU memory allocation

Run:

nvidia-smi

You should see vLLM or Python processes on all eight GPUs.

For continuous monitoring:

watch -n 1 nvidia-smi

Send a prompt later and watch GPU utilization increase.

Exit with:

Ctrl + C

[SCREENSHOT PLACEHOLDER: Dark-mode terminal showing vLLM memory allocated across all eight H200 GPUs]

Step 18: Test the models endpoint

Load the API key:

export VLLM_API_KEY=$(cat ~/vllm_api_key.txt)

Run:

curl -s http://127.0.0.1:8000/v1/models \

  -H "Authorization: Bearer $VLLM_API_KEY" \

  | jq

The response should contain:

MiniMaxAI/MiniMax-M3-MXFP8

vLLM exposes an OpenAI-compatible API, including the model-list and chat-completions endpoints.

Step 19: Test MiniMax M3 in adaptive reasoning mode

Run:

curl -s http://127.0.0.1:8000/v1/chat/completions \

  -H "Authorization: Bearer $VLLM_API_KEY" \

  -H "Content-Type: application/json" \

  -d '{

    "model": "MiniMaxAI/MiniMax-M3-MXFP8",

    "messages": [

      {

        "role": "system",

        "content": "You are a clear and helpful AI assistant."

      },

      {

        "role": "user",

        "content": "Explain MiniMax Sparse Attention in three simple bullets."

      }

    ],

    "temperature": 1.0,

    "top_p": 0.95,

    "max_tokens": 1200,

    "chat_template_kwargs": {

      "thinking_mode": "adaptive"

    }

  }' | jq '.choices[0].message'

MiniMax recommends:

temperature: 1.0

top_p: 0.95

for inference. Adaptive mode lets the model decide whether additional reasoning is useful for the request.

[SCREENSHOT PLACEHOLDER: Dark-mode terminal showing a successful MiniMax M3 chat-completions response]

Step 20: Test the three reasoning modes

MiniMax M3 supports:

enabled

adaptive

disabled

Enabled reasoning

Use this for difficult analysis, coding, or agent tasks:

curl -s http://127.0.0.1:8000/v1/chat/completions \

  -H "Authorization: Bearer $VLLM_API_KEY" \

  -H "Content-Type: application/json" \

  -d '{

    "model": "MiniMaxAI/MiniMax-M3-MXFP8",

    "messages": [

      {

        "role": "user",

        "content": "Explain step by step why tensor parallelism is needed for very large models."

      }

    ],

    "temperature": 1.0,

    "top_p": 0.95,

    "max_tokens": 2000,

    "chat_template_kwargs": {

      "thinking_mode": "enabled"

    }

  }' | jq '.choices[0].message'

Disabled reasoning

Use this when response speed matters more than extended reasoning:

curl -s http://127.0.0.1:8000/v1/chat/completions \

  -H "Authorization: Bearer $VLLM_API_KEY" \

  -H "Content-Type: application/json" \

  -d '{

    "model": "MiniMaxAI/MiniMax-M3-MXFP8",

    "messages": [

      {

        "role": "user",

        "content": "Define tensor parallelism in two sentences."

      }

    ],

    "temperature": 1.0,

    "top_p": 0.95,

    "max_tokens": 300,

    "chat_template_kwargs": {

      "thinking_mode": "disabled"

    }

  }' | jq '.choices[0].message'

vLLM passes thinking_mode through chat_template_kwargs and uses the same value to separate MiniMax’s reasoning output from its final answer.

Step 21: Create an Open WebUI secret

Generate a persistent secret:

openssl rand -hex 32 > ~/openwebui_secret.txt

chmod 600 ~/openwebui_secret.txt

Load it:

export WEBUI_SECRET_KEY=$(cat ~/openwebui_secret.txt)

Keeping the same secret across container restarts helps preserve consistent session behavior.

Step 22: Start Open WebUI

Remove an old container with the same name:

sudo docker rm -f open-webui 2>/dev/null || true

Start Open WebUI:

sudo docker run -d \

  --name open-webui \

  --network minimax-net \

  -p 127.0.0.1:8080:8080 \

  -e WEBUI_SECRET_KEY="$WEBUI_SECRET_KEY" \

  -e AIOHTTP_CLIENT_TIMEOUT_MODEL_LIST=60 \

  -v open-webui:/app/backend/data \

  --restart unless-stopped \

  ghcr.io/open-webui/open-webui:v0.10.1

Check that it is running:

sudo docker ps

Test it from the VM:

curl -I http://127.0.0.1:8080

Open WebUI recommends Docker for most installations and supports connecting to vLLM through its OpenAI-compatible API. Pinning an explicit Open WebUI version makes the setup more reproducible than using a floating main tag.

[SCREENSHOT PLACEHOLDER: Dark-mode terminal showing minimax-vllm and open-webui running in docker ps]

Step 23: Create an SSH tunnel from your laptop

On your laptop, open another terminal.

Run:

ssh -i ~/.ssh/id_ed25519 \

  -o IdentitiesOnly=yes \

  -L 3000:127.0.0.1:8080 \

  ubuntu@YOUR_GPU_IP

Replace:

YOUR_GPU_IP

with the Fluence VM’s public IP.

Leave this terminal open.

The tunnel forwards:

Your laptop: http://localhost:3000

to:

Fluence VM: http://127.0.0.1:8080

Closing the tunnel stops browser access, but it does not stop Docker, the VM, or billing.

Step 24: Open Open WebUI

On your laptop, open:

http://localhost:3000

Create the initial account and sign in.

[SCREENSHOT PLACEHOLDER: Open WebUI account creation page at localhost:3000]

Step 25: Connect Open WebUI to vLLM

Inside Open WebUI, go to:

Admin Settings

→ Connections

→ OpenAI

→ Manage

→ Add New Connection

Enter:

API URL: http://minimax-vllm:8000/v1

API Key: the value from ~/vllm_api_key.txt

Because Open WebUI and vLLM are on the same Docker network, Open WebUI can reach the API using the container name:

minimax-vllm

To display the API key again on the VM:

cat ~/vllm_api_key.txt

Save and verify the connection.

Open WebUI’s official vLLM instructions use the OpenAI-compatible connection settings under Admin Settings → Connections → OpenAI.

[SCREENSHOT PLACEHOLDER: Open WebUI connection screen showing http://minimax-vllm:8000/v1 and a masked API key]

Step 26: Select MiniMax M3

Return to the main chat page.

Open the model selector and choose:

MiniMaxAI/MiniMax-M3-MXFP8

Try:

Explain the difference between tensor parallelism and expert parallelism in four simple bullets.

MiniMax should respond through Open WebUI while vLLM distributes inference across all eight H200 GPUs.

[SCREENSHOT PLACEHOLDER: Open WebUI model selector showing MiniMaxAI/MiniMax-M3-MXFP8]

[SCREENSHOT PLACEHOLDER: Finished Open WebUI chat showing MiniMax M3 explaining tensor and expert parallelism]

Step 27: Optional—test image understanding

MiniMax M3 is natively multimodal and vLLM supports its image and video preprocessing path.

In Open WebUI:

1. Start a new MiniMax M3 conversation.
2. Attach an image.
3. Enter:

Describe the important objects, text, and relationships visible in this image.

[SCREENSHOT PLACEHOLDER: Open WebUI chat showing an attached image and MiniMax M3 describing it]

Large images and video inputs require extra CPU preprocessing and GPU memory. Start with a single moderate-resolution image before testing video.

Increasing the context window

MiniMax M3 supports a native context length of 1,048,576 tokens. This guide starts with 131,072 tokens.

The smaller initial value reduces KV-cache allocation and gives the first deployment more headroom. vLLM explicitly recommends capping –max-model-len when the full one-million-token window is not required.

After confirming that the 128K deployment is stable, you can test a larger value such as 262,144 or 524,288.

Stop the current container:

sudo docker stop minimax-vllm

sudo docker rm minimax-vllm

Then change:

--max-model-len 131072

to the desired limit and run the container again.

For the full model context, add:

-e VLLM_ALLOW_LONG_MAX_MODEL_LEN=1

to the Docker options and use:

--max-model-len 1048576

The full context requires a very large KV cache. Actual capacity depends on concurrency, output length, multimodal inputs, prefix caching, and the exact vLLM image. Test your real workload rather than assuming every request can use the entire native context simultaneously.

Troubleshooting

1. Docker cannot access the GPUs

Test:

sudo docker run --rm \

  --gpus all \

  nvidia/cuda:12.8.1-base-ubuntu22.04 \

  nvidia-smi -L

When it fails, run:

sudo nvidia-ctk runtime configure --runtime=docker

sudo systemctl restart docker

Then test again.

NVIDIA documents nvidia-ctk runtime configure –runtime=docker as the command that updates Docker to use NVIDIA Container Runtime.

2. Fewer than eight GPUs are visible

Run:

nvidia-smi -L

When fewer than eight H200 GPUs appear, the VM does not match the required configuration.

Fluence does not currently support changing the hardware configuration of a running VM. Terminate it and deploy a new x8 H200 VM.

3. The model download fills the root disk

Check:

df -h

Inspect the cache mount:

sudo docker inspect minimax-vllm \

  --format '{{json .Mounts}}' | jq

Confirm that the host cache points to the large disk:

/data/huggingface-cache

When it incorrectly points to the root disk:

1. Stop and remove the vLLM container.
2. Move or delete the incomplete cache.
3. Set MODEL_ROOT to the 6TB mount.
4. Run the container again.

The cached Hugging Face files will be reused after a restart.

4. vLLM reports an out-of-memory error

Stop the container:

sudo docker rm -f minimax-vllm

Restart it with a smaller context:

--max-model-len 65536

You can also reduce:

--gpu-memory-utilization 0.88

A conservative server configuration is:

sudo docker run -d \

  --name minimax-vllm \

  --network minimax-net \

  --gpus all \

  --ipc=host \

  -p 127.0.0.1:8000:8000 \

  -v "$MODEL_ROOT/huggingface-cache:/root/.cache/huggingface" \

  vllm/vllm-openai:minimax-m3 \

  --model "MiniMaxAI/MiniMax-M3-MXFP8" \

  --served-model-name "MiniMaxAI/MiniMax-M3-MXFP8" \

  --tensor-parallel-size 8 \

  --block-size 128 \

  --max-model-len 65536 \

  --kv-cache-dtype fp8 \

  --gpu-memory-utilization 0.88 \

  --tool-call-parser minimax_m3 \

  --reasoning-parser minimax_m3 \

  --enable-auto-tool-choice \

  --mm-encoder-attn-backend FLASHINFER \

  --mm-processor-cache-type shm \

  --mm-encoder-tp-mode data \

  --api-key "$VLLM_API_KEY"

5. vLLM reports that block size is invalid

MiniMax M3’s sparse-attention implementation requires:

--block-size 128

Do not remove or change that argument. vLLM identifies it as mandatory for MiniMax M3’s MSA sparse and index cache.

6. One or more tensor-parallel workers fail

Check the container logs:

sudo docker logs --tail 200 minimax-vllm

Confirm the GPU count:

nvidia-smi -L | wc -l

Expected result:

8

Check the topology:

nvidia-smi topo -m

For more communication diagnostics, restart the container with:

-e NCCL_DEBUG=INFO

added before the image name.

7. The API is not responding

Check the container:

sudo docker ps -a

Read the logs:

sudo docker logs --tail 200 minimax-vllm

Confirm the port:

sudo ss -lntp | grep 8000

The expected binding is:

127.0.0.1:8000

Test the models endpoint:

curl -v http://127.0.0.1:8000/v1/models \

  -H "Authorization: Bearer $(cat ~/vllm_api_key.txt)"

8. Open WebUI shows no model

Confirm that vLLM works from the VM:

curl -s http://127.0.0.1:8000/v1/models \

  -H "Authorization: Bearer $(cat ~/vllm_api_key.txt)" \

  | jq

Confirm both containers use the same network:

sudo docker network inspect minimax-net | jq

The output should include:

minimax-vllm

open-webui

Restart Open WebUI:

sudo docker restart open-webui

Check its logs:

sudo docker logs --tail 100 open-webui

Verify the connection URL:

http://minimax-vllm:8000/v1

9. The browser cannot open localhost:3000

Confirm that the tunnel is still running on your laptop:

ssh -i ~/.ssh/id_ed25519 \

  -o IdentitiesOnly=yes \

  -L 3000:127.0.0.1:8080 \

  ubuntu@YOUR_GPU_IP

On the VM, test Open WebUI:

curl -I http://127.0.0.1:8080

Check the container:

sudo docker ps

Then reload:

http://localhost:3000

10. MiniMax returns reasoning but not a final answer

Increase the output budget:

"max_tokens": 4096

Alternatively, use adaptive or disabled reasoning:

"chat_template_kwargs": {

  "thinking_mode": "adaptive"

}

or:

"chat_template_kwargs": {

  "thinking_mode": "disabled"

}

The reasoning parser separates the model’s reasoning block from its final content field.

11. Responses are too slow

First test disabled reasoning:

"chat_template_kwargs": {

  "thinking_mode": "disabled"

}

Also reduce:

max_tokens

prompt length

image resolution

number of simultaneous requests

Do not immediately enable every advanced optimization. First confirm correctness and stability with plain eight-way tensor parallelism.

12. The container exits after the VM reboots

The vLLM container in this guide does not automatically restart.

Start it again:

sudo docker start minimax-vllm

Follow the logs:

sudo docker logs -f minimax-vllm

For a longer-lived deployment, add:

--restart unless-stopped

to the vLLM Docker command after you have validated that the configuration starts reliably.

Shutdown and cleanup

Stop Open WebUI

sudo docker stop open-webui

Remove its container:

sudo docker rm open-webui

The persistent Open WebUI volume remains.

To permanently delete Open WebUI accounts and chats:

sudo docker volume rm open-webui

Stop MiniMax M3

sudo docker stop minimax-vllm

Remove the container:

sudo docker rm minimax-vllm

The downloaded model remains in:

$MODEL_ROOT/huggingface-cache

To remove the model cache after the container has stopped:

rm -rf "$MODEL_ROOT/huggingface-cache"

Only run that command when you are certain the cached files are no longer needed.

Terminate the Fluence VM

Return to:

Fluence Console

→ Running Instances

→ GPU Cloud

→ VM

Select the terminate action for the MiniMax VM.

Closing SSH, stopping Open WebUI, or stopping the vLLM container does not stop Fluence billing. Billing stops when the instance is terminated. Fluence provides a terminate action on active instance cards and returns unused reserved balance after termination.

[SCREENSHOT PLACEHOLDER: Fluence Running Instances page showing the terminate control for the 8× H200 MiniMax VM]

Why Fluence for this deployment?

MiniMax M3 requires a large, tightly connected GPU server. The selected Fluence catalog configuration places the entire deployment inside one VM:

• 8 × NVIDIA H200 SXM
• 1,128GB aggregate GPU memory
• 176 vCPU
• 1,450GB system RAM
• 6TB storage
• Direct SSH access
• CUDA-ready OS image

Keeping the eight GPUs inside one VM simplifies:

• Tensor-parallel configuration
• NCCL communication
• Model caching
• Storage management
• Network security
• Open WebUI connectivity

Fluence also provides hourly rental, direct VM access, GPU passthrough, public-IP SSH connectivity, and the ability to terminate the instance when the experiment is complete.

Cost-efficiency comparison across 8× H200 providers

Provider	Public pricing basis	Estimated 8× H200 cost/hour	Approx. 24-hour cost
Fluence	Exact uploaded 8-GPU VM configuration	$29.51	$708.36
Hyperstack	$3.99 per H200 GPU-hour	$31.92	$766.08
Crusoe	$4.29 per H200 GPU-hour	$34.32	$823.68
RunPod	$4.31 per H200 cluster GPU-hour	$34.48	$827.52
Nebius	$4.50 per H200 GPU-hour	$36.00	$864.00
CoreWeave	Exact 8× HGX H200 node	$50.44	$1,210.56

Hyperstack publishes an on-demand H200 SXM rate of $3.99 per GPU-hour. Crusoe lists H200 HGX at $4.29 per GPU-hour. RunPod’s cluster pricing lists H200 SXM at $4.31 per GPU-hour. Nebius lists H200 NVLink at $4.50 per GPU-hour. CoreWeave publishes an exact 8× HGX H200 node price of $50.44 per hour.

Compared with those public on-demand rates, the Fluence’s average cost (for this configuration) is approximately:

• 7.5% below Hyperstack
• 14.0% below Crusoe
• 14.4% below RunPod
• 18.0% below Nebius
• 41.5% below CoreWeave

These are headline comparisons rather than guaranteed cost-per-token results. For providers quoting per-GPU prices, confirm that all eight GPUs can be allocated in one high-speed NVLink or SXM server. Also check whether CPU, RAM, storage, public IPs, and network transfer are included.

Local hardware vs Fluence GPU Cloud

Factor	Local 8× H200 server	Fluence 8× H200 VM
Upfront hardware cost	Extremely high	None
Data-center power	Required	Included
Cooling	Required	Included
Eight-GPU server	Must be purchased	Rented as one VM
GPU maintenance	User responsibility	Provider responsibility
CUDA image	Must be configured	CUDA-ready images available
System RAM	Must be purchased	1,450GB in selected VM
Storage	Must be provisioned	6TB in selected VM
Remote access	Must be configured	SSH command supplied
Cost when unused	Hardware remains owned	Terminate the VM

A locally owned 8× H200 server may make sense for continuous, highly utilized production workloads. An hourly VM is more practical for evaluation, benchmarking, prototypes, temporary private inference, and short development projects.

Conclusion

The best MiniMax pairing for deployment on Fluence GPU Cloud is:

MiniMaxAI/MiniMax-M3-MXFP8

+

8 × NVIDIA H200 SXM

This selection is based on four factors:

1. MiniMax M3 is the latest general-purpose MiniMax open-weight model
2. The MXFP8 checkpoint is significantly smaller than BF16
3. Eight H200 GPUs are a tested and recommended hardware configuration
4. The Fluence catalog provides a complete 8-GPU SXM VM with 6TB storage

The selected Fluence VM provides:

• 1,128GB aggregate GPU memory
• 176 vCPU
• 1,450GB system RAM
• 6TB storage
• $29.51/hour listed price

The complete deployment flow is:

1. Register an SSH key
2. Launch the 8× H200 VM
3. Connect over SSH
4. Verify all GPUs and their topology
5. Identify the large storage volume
6. Install Docker and NVIDIA Container Toolkit
7. Pull the dedicated vLLM MiniMax M3 image
8. Serve MiniMax M3 MXFP8 across eight GPUs
9. Test its OpenAI-compatible API
10. Run Open WebUI
11. Connect through an SSH tunnel
12. Use MiniMax M3 in your browser
13. Terminate the VM when finished

The result is a current, documentation-aligned MiniMax M3 deployment with enough GPU memory for meaningful long-context, multimodal, reasoning, coding, and agentic experiments.