April 21, 2026 llama.cpp/SYCL results, build ec6f7a6a5c marked dirty, plus retained multi-GPU investigation notes. Technical interpretation, not a new hardware test or a current price recommendation.
What does a second card change?
Two 32 GB cards provide 64 GB of physical memory across two devices. Each allocation still belongs to a device; software must explicitly distribute a workload. Leave room on each card for cache and compute buffers.
CONCEPTUAL FLOW · NO TRANSFER-RATE OR SPEEDUP CLAIM
Capacity comes first
Intel specifies 32 GB of graphics memory per B70. Two cards therefore offer 64 GB of physical memory across two devices. Software still needs a supported way to place the workload on them. One allocation does not automatically see a transparent 64 GB pool.
Account for more than the weight file. KV cache, temporary compute buffers, runtime allocations, and workload-dependent overhead also consume device memory. A model whose weights nearly fill the card can fail when you increase context or concurrency.
Keep GB and GiB distinct when reading specifications and logs. The hardware capacity label and a weight-file size reported in binary units are not interchangeable. Prefer actual per-device allocation evidence when deciding whether a configuration has sufficient margin.
What the April measurements show
The reviewed April cohort used llama.cpp SYCL, commit ec6f7a6a5c marked dirty, F16 KV, and the pp512/tg128 workload. The per-result records say one CPU thread. The unrecovered local diff prevents exact reproduction from the commit alone.
| Model / quantization | Cards | Decode tok/s |
|---|---|---|
| Qwen 3.6 35B-A3B / UD-Q4_K_M | 1 | 54.65 |
| Qwen3-Coder-Next 80B-A3B / Q4_K_M | 2 | 43.35 |
| DeepSeek R1 Distill Llama 70B / Q4_K_M | 2 | 11.47 |
Open the full records for standard deviation and configuration. These are different models, including sparse and dense architectures. They do not establish a one-to-two-card speedup, equal output quality, or a best purchase.
The Coder-Next record has a separate weight-size problem: its JSON reports 14.46 GiB while the accompanying report describes approximately 45.1 GiB. The curated dataset leaves weight size unknown until that discrepancy is reconciled. Its recorded throughput remains an observation with that limitation attached.
Independent jobs
If each job fits one card, separate workers can use the devices independently. Examples include two separate model instances, a background batch worker alongside an interactive session, or two independent generation jobs.
This arrangement targets aggregate completed work. It does not inherently make one request faster. Shared CPU work, host memory, storage, and thermal conditions can still affect both workers, so test sustained throughput rather than assuming ideal doubling.
Record the physical device identity inside each worker. Environment-based device filtering can change local numbering: a process restricted to the second physical GPU may see its only visible GPU as index zero. Verify the mapping before drawing conclusions from utilization.
Splitting a model
Model splitting places parts of one workload on multiple devices. Its practical value can be capacity: making a larger model usable at all. Its cost includes communication and any sequential dependencies between those parts.
The current SYCL documentation should govern the options for your chosen build. The retained documentation also describes tensor splitting, so the old blanket advice that SYCL supports only layer splitting is stale. Support still depends on model and backend restrictions; a generic CUDA/NCCL recipe is not automatically applicable.
Evaluate a split against the workload you need: prompt length, generation length, concurrent users, and acceptable latency. Save each device’s memory use separately. A balanced weight split can still leave the device responsible for other buffers with less free space.
When host RAM fills
The historical multi-GPU investigation found a failure mode in which device allocations were accompanied by significant host-memory pressure. The key distinction was allocator scope and behavior, not merely where the model weights appeared to live.
llama.cpp PR #21597 introduced a direct Level Zero allocation path to address that problem. The contribution is present in the retained upstream history with a May 14, 2026 commit date. It is a historical fix, not a patch that every new installation should apply manually.
When investigating a similar symptom, retain process RSS, total system memory, device allocation evidence, and the exact backend/driver versions. Those measurements answer different questions. A change in one is not a substitute for observing the others.
Decide what you actually need
Use one card as the simplest baseline when the model and its working memory fit. Consider independent workers when separate jobs compete for GPU time. Investigate splitting when a required model exceeds one device’s practical capacity, or when you can measure a benefit for your exact workload.
The preserved hardware documents disagree about PCIe generation. This guide therefore makes no measured transfer-bandwidth claim. Nor does it repeat the old April price as a current quotation. A purchase comparison needs dated regional prices, availability, comparable work, and an explicit power methodology.
Before adding hardware, write down the bottleneck you want to remove and the measurement that would show success. That makes a second card a testable engineering decision.