# Sharing GPUs between LLM inference and server rendering

A GPU that passes separate LLM and render tests may still fail a mixed workload. Schedule by memory, latency and supported isolation rather than peak utilisation alone.

Author: Retrivium team
Updated: 2026-11-02
Canonical URL: https://retrivium.ai/journal/gpu-llm-rendering-workload-scheduling/
Language: en

## Separate capability from simultaneous service

A workstation or server GPU can be useful for more than one workload without being able to execute both at their independent benchmark results. An LLM service keeps model weights and caches resident, while a renderer may allocate a large scene and temporary buffers. Their peaks can overlap. The first planning question is whether jobs will run concurrently, on separate devices or in different time windows. State that choice before comparing hardware, because a successful isolated test does not establish mixed-workload capacity or stable request latency.

## Budget resident memory before chasing utilisation

Use the serving engine's actual allocations for weights, KV cache and workspaces rather than a checkpoint file size. The [vLLM installation reference](https://docs.vllm.ai/en/stable/getting_started/installation/gpu/) establishes a supported software route, not an entitlement to every free byte. Rendering has a separate scene budget described in the [Cycles GPU manual](https://docs.blender.org/manual/en/latest/render/cycles/gpu_rendering.html), including geometry, textures and acceleration structures. Reserve headroom for the combined peak where concurrency is intended. High GPU utilisation can coexist with allocation failures or long queues, so it is not by itself an operational success criterion.

## Use partitioning only where the exact product supports it

[NVIDIA MIG documentation](https://www.nvidia.com/en-us/technologies/multi-instance-gpu/) describes supported products and profiles; it should not be assumed for every RTX, GeForce or L-series card. A supported compute partition also does not automatically provide the graphics feature path required by a renderer. Record the actual profile, visible device and supported workload for each tenant. If separate physical GPUs are assigned instead, retain that distinction. Application-level scheduling, a container boundary and a hardware partition are different mechanisms and must not be presented as equivalent guarantees.

## Define queueing and preemption behaviour

Latency-sensitive inference and a long render batch have different completion objectives. A practical scheduler needs explicit admission limits and a defined response when memory is unavailable. Time-window scheduling may require unloading one workload, releasing contexts and warming the next; those transitions consume time and should be measured. Do not promise that a render job can be interrupted instantly or that all memory returns immediately after a process exits. Validate cancellation, failure cleanup and restart on the exact engine versions used by the node.

## Report mixed results as mixed results

A useful test compares isolated and concurrent operation under the same model, request distribution and render scene. Record completed work, inference tail latency, frame completion time, memory peaks, errors and thermal behaviour. Keep whole-server power measurements if discussing efficiency. Repeat only the affected cases after a scheduler, driver or engine change. A product with both graphics and inference positioning is a candidate for such evaluation, not evidence of guaranteed simultaneous performance. Retrivium's catalogue explains these assessment methods without claiming measured mixed-workload results for all listed hardware.

Related articles: [GPU VRAM, board totals and shared memory: how to read specifications](/journal/gpu-vram-board-module-shared-memory/), [A GPU inference benchmark you can trust](/journal/inference-benchmark-method/). [GPU catalogue](/journal/nvidia-amd-gpu-catalog/).