@analogalok: Stop blindly trusting the default multi GPU settings for your Local LLMs. You are literally leaving 25% performance on …

X AI KOLs Timeline Tools

Summary

Benchmark results comparing layer vs. tensor parallelism in llama.cpp for dual GPU setups: layer mode is 25% faster for prefill (RAG pipelines), while tensor mode is 16% faster for decode (interactive chat).

Stop blindly trusting the default multi GPU settings for your Local LLMs. You are literally leaving 25% performance on the table. I spent the last 3 hours melting free dual Nvidia T4 GPUs to finally settle the Llama.cpp debate: Layer vs Tensor split. The results completely flip how you should architect RAG vs. Chat pipelines. Here is the raw data: If you’re running models that exceed a single GPU’s VRAM, llama.cpp gives you two ways to split the weights: Layer Mode (Pipeline Parallelism) and the experimental Tensor Mode (Tensor Parallelism). The docs give you the theory, but I wanted the empirical data. I loaded up the unsloth's Q4_K_XL quant of Gemma 4 26B QAT (MoE) on a dual T4 GPU rig. Crucially, this setup uses standard PCIe interconnects. NO high speed NVLink. I wrote a script to scale the context window from 10k up to a brutal 50k tokens, clearing the VRAM between runs to see exactly where the hardware chokes. Here is what the benchmarks actually prove: # THE BEST for RAG: Layer Mode llama.cpp flag: llama-server -m gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf -ngl 99 -c 60000 -fa on --split-mode layer --host 127.0.0.1 --port 8080 If you are building document summarization, RAG pipelines, or processing massive payloads, --split-mode layer is your god tier flag. At the 50,000 token mark: - Layer Mode Prefill: 1,223 tokens/sec - Tensor Mode Prefill: 979 tokens/sec The Verdict: Layer mode is 25% faster at eating massive prompts. WHY?: Layer mode splits the network sequentially. GPU 0 does its math, then hands the baton to GPU 1. It minimizes cross GPU traffic. If your GPUs are communicating over standard PCIe lanes, this prevents your interconnect from bottlenecking the prefill. # THE BEST for CHAT: Tensor Mode llama.cpp flag: llama-server -m model.gguf -ngl 99 -c 60000 -fa on --split-mode tensor --host 127.0.0.1 --port 8080 If you are building an interactive Chat UI or an AI coding assistant, human perceived latency (Decode Speed) is everything. This is where --split-mode tensor shines. Across the entire benchmark matrix: - Tensor Mode Decode: 52 to 57 tokens/sec - Layer Mode Decode: 44 to 52 tokens/sec The Verdict: Tensor mode generates output tokens roughly 16% faster. The "Why": Tensor Parallelism splits the individual matrix multiplications across the GPUs. Both GPUs work simultaneously to predict the next token, speeding up generation. I packaged the entire 50k stress test code and data visualization scripts into a fully reproducible Kaggle Notebook. The notebook is completely plug and play. it automatically pulls the Gemma 26B GGUF from huggingface, fetches the prebuilt llama.cpp CUDA binaries, and runs the entire multi GPU matrix so you don't have to compile a thing. Fork the code, run it on your own hardware, and see the bottleneck for yourself. Or run the same notebook with different models and post your results. Link to the Notebook with free 2x Nvidia T4 GPUs in the comments.
Original Article
View Cached Full Text

Cached at: 07/09/26, 11:53 PM

Stop blindly trusting the default multi GPU settings for your Local LLMs. You are literally leaving 25% performance on the table.

I spent the last 3 hours melting free dual Nvidia T4 GPUs to finally settle the Llama.cpp debate: Layer vs Tensor split.

The results completely flip how you should architect RAG vs. Chat pipelines. Here is the raw data:

If you’re running models that exceed a single GPU’s VRAM, llama.cpp gives you two ways to split the weights: Layer Mode (Pipeline Parallelism) and the experimental Tensor Mode (Tensor Parallelism).

The docs give you the theory, but I wanted the empirical data.

I loaded up the unsloth’s Q4_K_XL quant of Gemma 4 26B QAT (MoE) on a dual T4 GPU rig.

Crucially, this setup uses standard PCIe interconnects. NO high speed NVLink. I wrote a script to scale the context window from 10k up to a brutal 50k tokens, clearing the VRAM between runs to see exactly where the hardware chokes.

Here is what the benchmarks actually prove:

THE BEST for RAG: Layer Mode

llama.cpp flag: llama-server -m gemma-4-26B-A4B-it-qat-UD-Q4_K_XL.gguf -ngl 99 -c 60000 -fa on –split-mode layer –host 127.0.0.1 –port 8080

If you are building document summarization, RAG pipelines, or processing massive payloads, –split-mode layer is your god tier flag.

At the 50,000 token mark:

  • Layer Mode Prefill: 1,223 tokens/sec
  • Tensor Mode Prefill: 979 tokens/sec

The Verdict: Layer mode is 25% faster at eating massive prompts.

WHY?: Layer mode splits the network sequentially. GPU 0 does its math, then hands the baton to GPU 1. It minimizes cross GPU traffic. If your GPUs are communicating over standard PCIe lanes, this prevents your interconnect from bottlenecking the prefill.

THE BEST for CHAT: Tensor Mode

llama.cpp flag: llama-server -m model.gguf -ngl 99 -c 60000 -fa on –split-mode tensor –host 127.0.0.1 –port 8080

If you are building an interactive Chat UI or an AI coding assistant, human perceived latency (Decode Speed) is everything. This is where –split-mode tensor shines.

Across the entire benchmark matrix:

  • Tensor Mode Decode: 52 to 57 tokens/sec
  • Layer Mode Decode: 44 to 52 tokens/sec

The Verdict: Tensor mode generates output tokens roughly 16% faster.

The “Why”: Tensor Parallelism splits the individual matrix multiplications across the GPUs. Both GPUs work simultaneously to predict the next token, speeding up generation.

I packaged the entire 50k stress test code and data visualization scripts into a fully reproducible Kaggle Notebook. The notebook is completely plug and play. it automatically pulls the Gemma 26B GGUF from huggingface, fetches the prebuilt llama.cpp CUDA binaries, and runs the entire multi GPU matrix so you don’t have to compile a thing.

Fork the code, run it on your own hardware, and see the bottleneck for yourself. Or run the same notebook with different models and post your results. Link to the Notebook with free 2x Nvidia T4 GPUs in the comments.

Kaggle notebook with all the code. free dual t4 GPUs

The model used in the test

yup tried both and published the results. check the graph

yup layer performs better in prefill and tensor did better in decode

Similar Articles

Dual GPU llama.cpp speedup

Reddit r/LocalLLaMA

A fork of llama.cpp fixes the --split-mode tensor issue with quantized KV caches, achieving up to 40% speed improvement on dual GPU setups without quality loss.