# Qwen3.6 35B-A3B on two Intel Arc Pro B60 cards: 818 tokens a second in total > We tested a server with two Intel Arc Pro B60 cards. Running Qwen3.6 35B-A3B at 4 bits with one engine per card, it writes 818 tokens a second in total with 32 requests at once, and 558 with 16, where our GB10 writes 479. The GB10 stays faster for one request alone. This server will join our servers at CARouter Cloud. - Published: 2026-10-09 - Author: Flavien Berwick - Category: Research - Web page: https://carouter.ai/blog/qwen3-6-35b-a3b-on-two-intel-arc-pro-b60 - In French: https://carouter.ai/fr/blog/qwen3-6-35b-a3b-on-two-intel-arc-pro-b60.md ![Research: Qwen3.6 35B-A3B on two Intel Arc Pro B60 cards, 818 tokens a second in total. With 32 requests at once: 818 tokens a second, 409 from each card, about 26 for each request. With 16 at once: 558, about 35 each, against 342 for the GB10, or 479 with its helper. One request alone: 59 to 62, against 74.9 for the GB10, or 114.9 with its helper. A 12 000-token prompt is read at about 5 900 tokens a second, against about 6 400 on the GB10.](https://carouter.ai/blog/qwen3-6-35b-a3b-on-two-intel-arc-pro-b60/illustration.png) CARouter Cloud serves open models on its own hardware in Canada. Its first machine is built on an NVIDIA GB10, with 128 GB of unified memory. We have been testing a second kind of machine in Ottawa: a server with two Intel Arc Pro B60 graphics cards, 24 GB each. We ran on it the model the GB10 serves, Qwen3.6 35B-A3B, at 4 bits. [The previous article: this model and its built-in helper on the GB10.](https://carouter.ai/blog/qwen3-6-mtp-head-one-and-a-half-times-faster) ## The short version - **The result.** With 16 requests on each card, the two cards write 818 tokens a second in total. - **At equal load.** With 16 requests in all, they write 558 tokens a second, about 35 each. The GB10 writes 342, or 479 with the model's built-in helper. - **One request alone.** The GB10 stays ahead, at 74.9 tokens a second, or 114.9 with the helper, against 59 to 62 on a B60. - **Two cards as one pool.** The Linux kernel refuses it on this generation of processor. With that one check lifted for a test, the pool worked, ran slower than one card, and needed the model's size again in the server's own memory. - **The processor.** One processor thread paces each engine. Faster cores should speed up one request, which we have not measured. - **What comes next.** This server will join our servers at CARouter Cloud. ## Three engines on one card An engine is the software that loads a model and answers requests. We tried three on one card: llama.cpp with its SYCL backend (its Vulkan backend was 2.8 times slower), Intel's build of vLLM (llm-scaler) and OpenVINO Model Server. ![One request alone, in tokens written per second. On one Arc Pro B60: 67 to 70 for llama.cpp, 59 to 62 for Intel's vLLM and 53 for OpenVINO Model Server. On the GB10: 74.9, or 114.9 with the model's helper.](https://carouter.ai/blog/qwen3-6-35b-a3b-on-two-intel-arc-pro-b60/01-one-request-by-engine.png) One request alone gets 67 to 70 tokens a second from llama.cpp, 59 to 62 from Intel's vLLM and 53 from OpenVINO. The GB10 gives 74.9, or 114.9 with the model's helper, which drafts the next tokens for the model to check. Here the helper did not pay. On Intel's vLLM it gained 6% for one request and capped the total at 135 to 180 tokens a second. With many requests at once the order changes. llama.cpp does not batch: two requests in one server are slower in total than one. Intel's vLLM writes 300 tokens a second in total with 8 requests and about 410 from 16, and OpenVINO 212 and 256. llama.cpp accepts a request of up to 262 144 tokens, the model's whole window, one request at a time. Intel's vLLM shares its window between the requests in progress, and with the whole model loaded it has room for about 95 000 tokens. Memory is the tight side: of each card's 23.9 GiB, the 4-bit weights take 19.2. We continued with Intel's vLLM, which does the most work with many requests at once. ## Two cards, one engine each We ran one vLLM engine on each card and measured both at the same instant. Each card gives what it gives alone: 409 tokens a second with 16 requests, so 818 in all and about 26 for each request. ![Tokens written per second in total, by simultaneous requests. One B60: from 59 for one request to about 410 from sixteen. Two B60s: 113 for two requests, 558 for sixteen and 818 for thirty-two. The GB10 with sixteen requests: 342, or 479 with the model's helper.](https://carouter.ai/blog/qwen3-6-35b-a3b-on-two-intel-arc-pro-b60/02-total-by-requests.png) With 8 requests per card the total is 558, about 35 each. The GB10 writes 342 in total with 16 requests, or 479 with its helper, which is 21 and 30 each. So this machine is not faster than the GB10 for one request. It adds capacity: with many requests at once it does more work in total, and each request still gets about 35 tokens a second. ## What this generation of processor allows The server is built on a platform from 2018: an Intel Core i9-9900K, a 9th-generation processor with 8 cores and 16 threads, on an ASUS PRIME Z390-A motherboard with 32 GB of memory. It runs Ubuntu 24.04 on Linux kernel 7.0. Intel's vLLM can spread one model over two cards, which must then exchange memory directly (peer-to-peer DMA). Between two cards on separate root ports, as here, the Linux kernel only allows that when the platform's host bridge is on its list of known-good ones. The host bridge of this processor generation is not on that list, in kernel 7.0 as in the latest mainline we read. AMD Zen platforms and Xeon platforms are. So on a stock kernel, two cards here are two engines of 24 GB each, and not one pool of 48 GB. The B60 is a PCIe 5.0 card with 8 lanes, and on this motherboard each card links at PCIe 3.0. That did not limit generation speed in our tests. It would matter for loading the model and for any traffic between pooled cards. One processor thread paces each engine. From 1 to 16 simultaneous requests, each vLLM engine kept exactly one thread fully busy, while the 16 threads were 13% busy in all. Eight cores were enough for two engines. From 2 to 8 simultaneous requests, each request keeps the same speed, about 35 to 38 tokens a second. That is the signature of a fixed cost per step on the host, and not of work on the card, which only saturates at about 16 requests. ## Pooling the two cards anyway, as a test To learn whether the motherboard itself was the obstacle, we lifted that one check. A small test-only kernel module made the kernel accept this server's host bridge. It is not a rebuilt kernel, it needs Secure Boot off, and a reboot removes it. The pool then worked. A small model, Qwen3-0.6B, spread over both cards gave 6 of 6 answers identical to one card and ran a benchmark, with no fault in the kernel's log. The hardware carries the traffic. It was slower than one card, with the same model and settings: - One request alone: 36.8 tokens a second pooled, against 44.2 on one card. - Eight requests at once: 298.8 in total, against 356.6. - Reading a 12 000-token prompt: 16 555 tokens a second, against 25 793. The real limit is the server's own memory. Everything the two cards share, weights and cache alike, also takes its size there, and swap does not absorb it. A 29 GB model ran this machine's 32 GB out while it loaded. We have not pooled Qwen3.6 35B-A3B itself. ## What a newer platform would probably add None of what follows is measured. It is what the figures above lead us to expect. - A newer processor, with faster cores, should raise the speed of one request and of small batches. - A platform on the kernel's list would pool the two cards without a test module. - More memory would let the pool hold a large model: about as much again as what the two cards share. - PCIe 5.0 slots would link the cards at the speed they support, which should help loading and the traffic between pooled cards. ## Long prompts and images Intel's vLLM reads a 12 000-token prompt at about 5 900 tokens a second, against about 6 400 for the GB10 and 590 to 700 for llama.cpp. ![Left: a 12 000-token prompt is read at 590 to 700 tokens a second by llama.cpp on one B60, about 5 900 by Intel's vLLM on one B60 and about 6 400 by the GB10. Right: with Intel's vLLM on one B60, a prompt of 11 400 tokens is answered in 2.9 seconds, 55 216 tokens in 18.6 seconds, 87 923 tokens in 39.2 seconds and 132 606 tokens in 78.8 seconds.](https://carouter.ai/blog/qwen3-6-35b-a3b-on-two-intel-arc-pro-b60/03-reading-a-prompt.png) Reading slows as the prompt grows. On one card, one request alone with a prompt of 11 400 tokens is answered in 2.9 seconds, with 55 216 tokens in 18.6 seconds, with 87 923 tokens in 39.2 seconds and with 132 606 tokens in 78.8 seconds. Images work on Intel's vLLM: a 1024 by 1024 image is about 1 050 tokens and takes under a second. Loaded without the part of the model that reads images, the weights take 18.4 GiB instead of 19.2. That leaves just enough room on one card for the model's whole window of 262 144 tokens. ## Heat: test with many requests The second card arrived with a fan that did not turn, and it reached 93 to 96 °C under load. One request alone kept its speed, at 62.4 tokens a second against 61.5 once repaired. With 8 requests, the total fell from 298.8 to 98.2. With the fan repaired, the cards peak at about 68 to 74 °C with both under full load. A thermal problem does not show with one request, so test with many. ## What comes next This server will join our servers at CARouter Cloud. --- More articles: [CARouter Blog](https://carouter.ai/blog.md). What CARouter is and how to call it: [llms.txt](https://carouter.ai/llms.txt).