I’m running a 2x DGX Spark setup over the direct Spark-to-Spark link and I’m trying to understand whether anyone has found a
practical way to run a large local LLM while still leaving enough memory/headroom for ComfyUI image generation.
Current situation:
2x DGX Spark / GB10 systems
ComfyUI/Krea-2 works well on one Spark
Large vLLM cluster jobs work across both Sparks
The issue is memory pressure: vLLM tends to reserve so much unified memory/KV cache that running ComfyUI at the same time is not
really practical
I’m not tied to MiniMax specifically. I’m curious about any large model setup people have made work, for example:
DeepSeek variants
MiniMax / MoE models
Qwen3.5 / Qwen3.6 large models
SGLang instead of vLLM
TensorRT-LLM or other serving stacks
The question is:
Has anyone successfully run a larger LLM on one or more Sparks while still keeping enough memory free to run ComfyUI for photo/
image generation at the same time?
My working assumption is that true 200B+ cluster jobs probably need the whole two-Spark memory pool, so the practical solution may
be “LLM on Spark #2, ComfyUI on Spark #1,” or a 3+ Spark setup. But I’d love to hear if anyone has found a better approach,
especially with SGLang or more careful memory tuning.
Your working assumption is sound: separate Sparks for LLM and ComfyUI is the practical approach for your 2x DGX Spark setup.
Why vLLM + ComfyUI conflict
vLLM’s KV cache reservation is aggressive—it pre-allocates unified memory to avoid runtime fragmentation. On a single Spark, this leaves little headroom for ComfyUI’s image generation workloads. The memory pressure you’re experiencing is a known constraint, not a configuration bug.
Proven approaches from the community
1. Separate Spark allocation (recommended for your setup)
Dedicate Spark #1 to ComfyUI/Krea-2
Run vLLM cluster jobs on Spark #2 (or both, if you’re not running ComfyUI simultaneously)
This avoids memory contention entirely and is the pattern that works reliably
2. Memory management tips if you want to try co-location
Disable swap (sudo swapoff -a) before loading large models. When swap is active, massive allocations force the OS to thrash data onto storage, creating kernel lockups. This is documented in DGX Spark troubleshooting.
Reduce vLLM’s KV cache reservation: Use --gpu-memory-utilization (e.g., 0.7 instead of 0.9) to leave headroom for other workloads.
Use smaller quantized models: 4-bit or 8-bit quantization (via bitsandbytes or similar) reduces memory footprint significantly.
Alternative serving stacks
You mentioned SGLang, TensorRT-LLM, and others. The memory behavior depends on the model size and quantization, not the serving stack:
SGLang: Similar memory profile to vLLM; benefits from the same tuning (reduced utilization, quantization)
TensorRT-LLM: Can be more memory-efficient for specific model architectures, but still requires careful KV cache tuning
Smaller models: DeepSeek, Qwen variants—if you can fit a 13B or 34B model instead of 200B+, co-location becomes feasible
Practical next steps
If you want to maximize utilization: Add a third Spark. Two Sparks are tight for simultaneous large LLM + image generation.
If you want to stay with 2x Sparks: Partition by workload (LLM on #2, ComfyUI on #1) and accept that you can’t run both at full capacity simultaneously.
If you want to experiment with co-location: Start with a smaller model (13B-34B), disable swap, and use --gpu-memory-utilization 0.6 to leave 40% headroom for ComfyUI.
The community consensus is that 200B+ models need the full two-Spark pool, so your assumption is correct.
I haven’t tried to get ComfyUI up since installing/running DSV4 or MiMo-V2.5 across both nodes. I did have to reduce --gpu-memory-utilization to 0.8 for both in order to free up resources to run self-hosted firecrawl on the worker node (for my Hermes agents). Considering my previous ComfyUI environment was consuming about the same as firecrawl does on node2, I’m hoping to get Comfy up on node1 today. We’ll see if it works, I guess. If Comfy won’t load/run, I may bring down DSV4 and change --gpu-memory-utilization to 0.75 or 0.72 and see how that impacts agentic workflows.
As much as I hate to say it, @AakankshaS suggestion of a discreet, third node for creative inference may be where I end up. Honestly, Comfy was a side quest for me, not my main focus. I didn’t even know Comfy existed six weeks ago. But it can be fun generating images locally for web sites and whatnot. The learning curve was steep, but I have yet another skill, so there’s that.
EDIT: I was able to get ComfyUI running on node1 (head node for DSV4 cluster). Performance is slow, but output was fine.
Not quite what you are asking about, but I am currently set up with:
Node 1:
vllm (clustered) qwen3.6 27b
vllm (clustered) qwen3 coder next
ollama (small infrequently used models + infrequently used embedding model)
Node 2:
vllm (clustered) qwen3.6 27b
vllm (clustered) qwen3 coder next
ComfyUI (used infreqently)
Stable Diffusion (used infrequently)
I have ComfyUI configured for low memory use and to only load models when in use, so sacrificing some performance for low memory foot print. GPU memory utilization for both vllm clusters is set pretty low to give me memory headroom. I am running 256k context for both but am pretty much the only user. Yesterday I was doing some 1024x1024 image generations with SDXL sized models and no issues, but peaked at 114GB RAM used.
Since its just me, I tend to not do LLM stuff at the same time as SD or ComfyUI so they aren’t fighting over the GPU too much. If I was going to do video with ComfyUI, I’d turn down qwen3 coder next vllm cluster to free up RAM as much more is needed than images/audio.
With vllm it may be harder because its memory management stuff is really bad with unified memory (it is often does OOM just because buffers/cache memory filled with some crap). llama.cpp does better though not sure how it handles clustering. I was running qwen3.6-35b in llama.cpp at same time with comfyui without problem but image generation is quite slow (like 5-6 times slower if there is real load on LLM).