2xB60+GRR perf is much lower than that of Xeon-SP for DeepSeek-R1-Distill-Qwen-14B 2xB60 1K-512 FP8

[dukelee111]

Hi sir：
We encountered an issue where the performance of the Grandridge CPU with the B60 card is significantly lower compared to that on the Xeon-SP. Could you please help look into it? Thank you very much~

The detailed configuration as bellow：

Grandridge CPU(GRR): Intel Atom(R) P6962 processor CPU @ 2.6GHz
Xeon-SP CPU: Intel(R) Xeon(R) Gold 6438N CPU @ 2.0GHz （Has locked the CPU freq to 2.6GHz）
GPU: 1xDual-core B60（as 2 B60 Device）
llm-scaler docker image：intel/llm-scaler-vllm:0.10.0-b2
OS/Kernel: Ubuntu25.04/6.14.0

We have tested with ze_peer , 1ccl allreduce , Torch level P2P test on the 2 different platform. Please see attachment for the performance differences and test result. Thanks~

2xB60+GRR perf is much lower than that of Xeon-SP.pdf

[liu-shaojun]

Thank you for the details. The performance difference between Grandridge (Atom P6962) and Xeon-SP (Gold 6438N) with the B60 card is primarily due to hardware factors that limit CPU → GPU data transfer and processing:

• Memory bandwidth: Grandridge has 4 memory channels (~80–100 GB/s) vs Xeon-SP’s 8 channels (~250 GB/s)
• PCIe lanes: Grandridge provides fewer/lower-speed PCIe lanes (48 lanes, Gen4) compared to Xeon-SP (80 lanes, Gen5)

These factors together reduce throughput for allreduce, P2P, and Torch copy operations, explaining the lower performance observed.

[dukelee111]

Hello shaojun：
Regarding these two differences, we initially also thought they might be the gap points affecting performance. Therefore, we conducted verifications targeting these two aspects: we kept only two memory channels for Xeon-SP (consistent with Grandridge) and configured the PCIe of Xeon-SP from Gen5 to Gen4. All results in the attachment are based on Xeon-SP with 2 channels and PCIe Gen4. From the results, the P2P latency obtained by ZE Peer is actually lower on Grandridge; however, in terms of torch-level and 1CCL allreduce results, the latency observed on Grandridge is relatively high. The latency results at the torch level and 1CCL allreduce are quite consistent with the final LLM results. We apologize for the slight lack of explanation in the previously provided information; the above serves as a supplement. Thank you~

[liu-shaojun]

As discussed with Dekun on Teams and ran additional tests. We tried removing the all-reduce operation to compare performance. After removing all-reduce, TPOT improved from 46 → 37, but it's still far behind the 26 observed on Xeon-SP. This suggests that the all-reduce overhead is not the major bottleneck.

We also set CCL_LOG_LEVEL=debug for further inspection. The logs showed p2p_access = 1, confirming that P2P is being used. Therefore, the performance gap is likely still due to CPU differences rather than communication overhead.