Running Local AI Alongside Media Services Without Fighting Your GPU

The short answer: one GPU can serve local AI and media workloads when you measure each service alone, reserve capacity for the highest-priority service, limit concurrency, and schedule bulk work. Separate hardware is the right answer when simultaneous peak demand cannot meet the acceptance tests.

This guide is for a Docker homelab operator sharing an NVIDIA GPU among Ollama, Plex or Jellyfin, Tdarr, and possibly Frigate. It assumes you can read service logs, stop a worker, unload an Ollama model, and reach the host console if the GPU stack fails.

Prerequisites and Safe Defaults

• Back up service configuration and databases, and preserve at least one known-good container image or package version for recovery.
• Record the GPU model, driver, NVIDIA Container Toolkit, host kernel, container images, codecs, and exact Ollama model artifact.
• Verify each service can use the intended GPU path by itself before combining workloads.
• Start with one Tdarr GPU worker, one loaded Ollama model, and direct play where clients support the source media.
• Choose a priority order and define measurable failure signals for playback, cameras, AI latency, and bulk jobs.

Plex hardware-accelerated streaming generally requires an active Plex Pass, subject to documented device exceptions and changing entitlement rules. Check the current Plex support page before relying on it. Jellyfin, Tdarr, Frigate, Ollama, NVIDIA drivers, and codec support also change; all product behavior here was fact-checked against documentation available July 15, 2026.

Lawful-use and privacy boundary: transcode and organize only media you own or are authorized to process. Camera footage can contain sensitive personal data; restrict access, retention, exports, and model use according to applicable law and household or organizational policy.

A lot of homelab builders want one box to do everything.

That one server might run:

• Ollama for local AI chat
• Plex or Jellyfin for movies and TV
• Tdarr for bulk video transcoding
• Frigate for security camera detection
• Docker for everything

That can work, but there is one big catch: these services may all want the same GPU.

The fix is not always "buy a bigger GPU." The fix is to understand which part of the GPU each service uses, leave memory headroom, and schedule heavy jobs so they do not collide.

The Shared GPU Problem

Interactive Media Server Coexistence Flow

Click each step to see what it means in a beginner-friendly local AI setup.

1Media Jobs2AI Jobs3Watch GPU4Schedule5Separate

Select a step

Choose a box above to view details.

NVENCTranscode

CUDAInference

VRAMShared

ScheduleAvoid conflict

Think of your GPU as a small workshop with several stations.

GPU resource	What uses it	Why it matters
VRAM	Ollama models, AI context, video buffers, desktop, containers	Running out can cause slowdowns, failed loads, or crashes
CUDA or compute cores	Local LLM inference, some AI detectors, some filters	Heavy AI can compete with other GPU work
NVENC	NVIDIA hardware video encoding	Plex, Jellyfin, and Tdarr may use it for transcoding
NVDEC	NVIDIA hardware video decoding	Media servers and Frigate may use it to decode video
Power and cooling	Everything	A hot or power-limited GPU may slow down
Driver stack	Everything	One driver problem can affect multiple apps

NVIDIA says NVENC and NVDEC are hardware-based encoder and decoder blocks. That means video encode/decode is not exactly the same as CUDA compute. However, they still share the same physical card, driver, power budget, cooling, and some memory pressure.

So yes, Plex transcoding and Ollama inference can run at the same time. But that does not mean they are isolated from each other.

What Each Service Usually Wants

Service	Common GPU use	Main risk	Beginner rule
Ollama/local LLMs	CUDA, ROCm, Vulkan, or CPU plus lots of memory	Large model or long context fills VRAM	Use one modest model and unload it when needed
Plex	Hardware decode/encode for live transcoding	Streams fail if GPU transcode is unavailable or overloaded	Prefer direct play and leave GPU headroom
Jellyfin	Hardware decode/encode through FFmpeg	Partial acceleration can raise CPU use	Use supported Jellyfin FFmpeg and verify playback
Tdarr	Bulk transcodes using CPU, NVENC, or VAAPI	Can monopolize encoder sessions for hours	Schedule it off-hours and limit workers
Frigate	Video decode and object detection depending on config	Camera service is always-on and sensitive to failures	Treat it as a priority service

The most important design choice is priority.

For many homes, the priority order is:

1. Frigate stays stable because cameras are continuous.
2. Plex or Jellyfin stays smooth when someone is watching.
3. Ollama runs interactively when needed.
4. Tdarr runs later because bulk transcoding is rarely urgent.

Your priorities may differ, but you should choose them on purpose.

NVENC, NVDEC, and CUDA in Plain English

NVIDIA GPUs commonly have special video blocks:

Name	Plain-English job	Example
NVDEC	Decodes compressed video into frames	Reading an H.265 4K movie or camera stream
NVENC	Encodes frames into compressed video	Converting a video stream to H.264 or H.265
CUDA	General GPU compute	Running local LLM inference or some AI workloads

This is why a media transcode can show encoder or decoder activity while an LLM shows compute and memory activity.

But do not oversimplify it. A video job can still use VRAM. Some filters, tone mapping, subtitles, or scaling paths can use extra GPU or CPU resources. Frigate can use video decoding plus a detector. Jellyfin and Plex behavior depends on codec, client, settings, drivers, and platform support.

The safe beginner statement is:

NVENC/NVDEC are separate video engines, but all GPU workloads still share the same card and can affect each other.

Monitor the GPU Before Changing Anything

On NVIDIA, start with:

watch -n 1 nvidia-smi

For a simple process view:

nvidia-smi pmon -s um

For encoder and decoder activity, try:

nvidia-smi dmon -s u

Depending on your driver and GPU, dmon output may include columns for SM, memory, encoder, and decoder utilization. If your output is different, run:

nvidia-smi dmon --help

For containers:

docker stats

For Ollama:

ollama ps

Watch these while doing real tasks:

• Ask Ollama a question.
• Start a Plex or Jellyfin transcode.
• Let Frigate process cameras.
• Start one Tdarr worker.

Do not tune based on an idle server. Tune based on the busiest normal hour in your home.

Evidence and Coexistence Test Method

This article is documentation-backed. TechGeeks did not independently run Ollama, Plex, Jellyfin, Tdarr, and Frigate together on a standardized GPU for this draft, so the article makes no original stream-count, tokens-per-second, camera-capacity, power, temperature, or VRAM guarantee.

1. Baseline each service alone. Record GPU memory and engine use, CPU, temperature, logs, and the service's own health or timing metrics.
2. For media, test direct play plus the hardest normal transcode, including the actual codec, resolution, subtitles, tone mapping, and client. Confirm playback mode in the dashboard and inspect FFmpeg or server logs.
3. For Frigate, record camera and detector health and verify there are no hardware-acceleration errors. For Tdarr, use copied test media and one worker before touching the library.
4. For Ollama, use a fixed model artifact, prompt, context, and output cap. Record cold and warm API timing fields plus ollama ps.
5. Combine the highest-priority continuous service with one other workload, then add the next. Stop when any acceptance criterion fails; that point defines a scheduling or separation boundary.

Example acceptance criteria are no playback buffering in the tested case, no camera or FFmpeg errors, no container restart or NVIDIA Xid event, AI latency within your stated limit, and successful recovery after pausing the lowest-priority job. Replace these with stricter criteria when cameras or media availability have safety, business, or contractual impact.

Prefer Direct Play When Clients Support It

Avoiding an unnecessary transcode removes one source of GPU and CPU demand.

Plex and Jellyfin are happiest when the client can direct play the file. Direct play means the server sends the file without converting the video. That usually uses far fewer CPU and GPU resources.

Beginner ways to reduce unnecessary transcoding:

• Use clients that support your common codecs.
• Set local network quality to original or maximum when possible.
• Avoid burning in subtitles unless required.
• Store common content in formats your devices can play.
• Check the Plex or Jellyfin dashboard to see whether playback is direct play, direct stream, or transcode.

If your family is watching a movie, that is usually not the time to test a giant LLM at maximum context.

Give Frigate a Stable Lane

Frigate is different from Plex and Tdarr because it usually runs all the time. Camera streams do not wait politely for your AI model to finish.

Frigate's docs recommend using integrated or discrete GPU hardware acceleration for video decoding. They also note that if hardware acceleration is specified in the config, verification is done by checking logs for errors, and there is no CPU fallback for that hardware acceleration path.

That matters. If Frigate is configured for hardware acceleration and the GPU path breaks, it may not simply fall back gracefully.

Basic Frigate log check:

docker logs --tail=100 frigate

Follow logs live:

docker logs -f frigate

If Frigate is important in your setup, avoid using the same GPU at 100% VRAM for local AI experiments. Leave headroom.

Keep Tdarr on a Schedule

Tdarr is powerful because it can process a whole media library. That is also why it can cause trouble.

If you allow several GPU workers during prime streaming time, Tdarr may compete with Plex, Jellyfin, or Ollama. A beginner-friendly setup is:

• Use one GPU worker at first.
• Run CPU workers only if you understand the heat and power cost.
• Schedule Tdarr for overnight.
• Pause Tdarr during movie night or heavy AI work.
• Keep a small test library before processing everything.

Emergency pause:

docker pause tdarr_node

Resume:

docker unpause tdarr_node

If you use Docker Compose:

docker compose stop tdarr_node
docker compose start tdarr_node

Tdarr's NVIDIA hardware transcoding docs show test commands using --gpus=all and NVIDIA_DRIVER_CAPABILITIES=all. That is a good reminder: GPU access has to work at the container level before Tdarr plugins can use NVENC.

Test whether Docker can see the NVIDIA GPU:

docker run --rm --gpus all ubuntu nvidia-smi

If that fails, fix Docker GPU access first.

Keep Ollama From Holding VRAM Forever

Ollama keeps models loaded for faster follow-up responses. That is convenient, but it can surprise you on a shared server.

Check loaded models:

ollama ps

Unload a model:

ollama stop llama3.2

Unload by API:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "keep_alive": 0
}'

For a shared AI and media server, start by limiting loaded models and parallel requests. Set an explicit context length only after the solo and combined tests establish what the host can keep within its measured headroom:

[Service]
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_NUM_PARALLEL=1"

Apply with:

sudo systemctl daemon-reload
sudo systemctl restart ollama

This keeps Ollama simpler and less memory-hungry. It is not the highest-performance multi-user AI setup, but it is easier to run alongside media services.

Suggested Schedules

Here are beginner-friendly schedules for a one-GPU homelab.

Time	Good workload	Avoid
Morning	Light Ollama use, Frigate, direct-play media	Bulk Tdarr if people are streaming
Workday	Ollama, Frigate, light media	Huge context tests if remote users need Plex
Evening	Plex/Jellyfin, Frigate, small AI model if needed	Tdarr bulk transcodes and giant LLMs
Overnight	Tdarr, backups, model downloads, heavier experiments	Anything that wakes people with fan noise

Example simple policy:

Situation	Action
Someone is watching Plex/Jellyfin	Stop large Ollama models and pause Tdarr if the measured playback budget requires it
Frigate is dropping frames	Stop Tdarr first, then reduce AI GPU load and inspect Frigate/FFmpeg logs
Ollama feels slow	Check active transcodes, model placement, context, and prompt timing fields
Tdarr queue is huge	Increase throughput only inside a tested off-hours window
Remaining VRAM falls below the tested headroom floor	Stop the lowest-priority workload before a user-facing failure

VRAM Crash Symptoms

When several GPU services collide, the symptoms can look unrelated.

Symptom	Possible cause
Ollama suddenly becomes slow	Model fell back to CPU or another job took VRAM
Plex stream buffers or fails	Transcode path is overloaded or unsupported
Jellyfin playback exits	FFmpeg transcode failure, driver issue, or unsupported codec path
Frigate restarts or logs FFmpeg errors	Decode path or camera processing is failing
Tdarr jobs fail immediately	Container cannot access GPU or plugin requires unsupported codec
nvidia-smi shows full VRAM	Too many loaded models, transcodes, or buffers
Kernel logs show NVIDIA Xid errors	Driver/GPU instability, power, heat, or workload crash

Good first response:

ollama ps
watch -n 1 nvidia-smi
docker stats

Then check logs:

journalctl -u ollama --no-pager -n 100
docker logs --tail=100 plex
docker logs --tail=100 jellyfin
docker logs --tail=100 frigate
docker logs --tail=100 tdarr_node

For NVIDIA driver errors:

sudo dmesg | grep -i -E 'nvrm|nvidia|xid'

Do not restart every container at once unless the server is already unusable. Stop the heaviest nonessential job first, then recheck.

Practical Recovery Order

When the GPU is out of memory or unstable, use a calm order:

1. Stop Tdarr workers.
2. Unload large Ollama models.
3. Let Plex/Jellyfin finish active streams if possible.
4. Check Frigate logs.
5. Check nvidia-smi.
6. Restart only the service that is failing.
7. Reboot only if the driver or GPU is stuck.

Commands:

docker compose stop tdarr_node
ollama ps
ollama stop gemma3:4b
watch -n 1 nvidia-smi

Restart one container:

docker compose restart jellyfin

Restart Ollama:

sudo systemctl restart ollama

If the GPU driver itself is wedged, a reboot is often the cleanest beginner fix:

sudo reboot

Hardware Planning Without Overpromising

No VRAM chart can promise coexistence. Model artifacts, context, codecs, resolution, bit depth, tone mapping, subtitle burn-in, detector configuration, encoder-session limits, drivers, and concurrent users all change the result. Plan from observed peak demand:

Question	Evidence to collect	Design response
What must run continuously?	Frigate camera FPS, detector latency, decode errors, or another priority-service health metric	Reserve its measured peak resources and test failover before adding batch work
What happens during viewing?	Direct play versus transcode, source/output codecs, subtitle and tone-mapping path, encoder/decoder use	Optimize clients and media compatibility; reserve the worst normal transcode case
What does the AI task require?	Exact model/quantization, context, model placement, warm/cold latency, VRAM and compute use	Choose the smallest validated artifact and unload policy that meets the task
Can bulk work wait?	Tdarr queue, job duration, worker resource use, and maintenance window	Schedule and cap workers instead of sizing every service for simultaneous peak
Do simultaneous peaks still pass?	Combined acceptance run and service logs	Use another GPU, iGPU, or host when scheduling cannot meet availability requirements

For media-heavy homes, codec support may matter more than raw VRAM. For AI-heavy homes, VRAM matters a lot. For Frigate-heavy homes, stable decode and detector support matter more than peak benchmark numbers.

A Conservative Shared-GPU Layout

For a typical one-GPU Docker homelab:

• Frigate runs 24/7.
• Plex or Jellyfin uses hardware acceleration, but clients are configured for direct play when possible.
• Tdarr has one GPU worker and runs overnight.
• Ollama uses one loaded model at a time.
• Ollama uses the smallest context length that passes the tested task while preserving the shared-GPU headroom.
• Big model tests happen when no one is streaming.
• nvidia-smi, ollama ps, and container logs are checked before changing settings.

This setup is not flashy, but it is much less annoying than a server that randomly fails during a movie.

Quick Checklist

Before running local AI and media services together:

• Confirm Docker GPU access with docker run --rm --gpus all ubuntu nvidia-smi.
• Confirm Ollama GPU use with ollama ps.
• Confirm media transcodes in Plex or Jellyfin dashboard.
• Confirm Frigate logs do not show hardware acceleration errors.
• Limit Tdarr workers.
• Schedule Tdarr away from prime streaming time.
• Keep measured headroom above the floor established by the combined acceptance test.
• Unload AI models when media services need the GPU.
• Change one setting at a time.

If you treat the GPU as shared infrastructure instead of a magic accelerator, local AI and media services can live together much more peacefully.

Risk, Recovery, and Separation Boundaries

Keep a known-good driver and container combination, configuration backups, and console access. Driver reloads and reboots interrupt every GPU consumer; drain streams and stop batch jobs first when possible. If the card or driver becomes unstable, preserve logs, stop Tdarr, unload Ollama, restore the priority service, and restart only the failing component before escalating to a host reboot.

Tdarr can rewrite a large library. Test on copies, retain originals until output validation and backup checks pass, and document how to stop workers without deleting evidence of failed jobs. A successful transcode is not proof that subtitles, audio tracks, metadata, HDR behavior, or every client remained correct.

Separate workloads when scheduling cannot protect the priority service, when a driver update required by one stack breaks another, when encoder or memory limits are routinely reached, or when camera and media availability cannot share the same failure domain. An integrated GPU for media decode/encode or a dedicated accelerator for detection may be more useful than moving every workload to a larger discrete GPU.

What This Evidence Does Not Prove

• Separate NVENC and NVDEC engines do not make video, CUDA, VRAM, power, cooling, or driver failures independent.
• nvidia-smi utilization and memory samples do not prove smooth playback, accurate detection, valid transcodes, or useful AI answers.
• One direct-play success does not cover every client, remote bitrate, subtitle, audio, HDR, or codec combination.
• One Ollama model fitting beside one transcode does not establish capacity for long context, cold loads, multiple users, or several streams.
• Vendor and project documentation describe supported paths; they do not benchmark this exact shared host.

Related TechGeeks Reading

• Plex + Tdarr GPU Strategy: Sharing NVIDIA GPUs Without Hurting Playback
• Monitoring and Health Checks for a Plex and Arr Homelab
• Backup and Disaster Recovery for Plex, Sonarr, Radarr, Tdarr, Prowlarr, and SABnzbd

References

• NVIDIA: Video Codec SDK Overview
• NVIDIA: nvidia-smi Documentation
• Plex: Using Hardware-Accelerated Streaming
• Jellyfin: Transcoding and Direct Play
• Jellyfin: NVIDIA Hardware Acceleration
• Tdarr: Docker Hardware Transcoding
• Frigate: Hardware-Accelerated Video Decoding
• Frigate: Object Detectors
• Ollama: Loaded Models, Concurrency, and Keep-Alive
• Ollama: GPU Troubleshooting
• Docker: GPU Access in Compose
• FFmpeg: Command and Processing Reference