Hi Everyone,
We are currently running two concurrent workloads on DGX Spark:
- PaddlePaddle OCR (PPStructureV3) — running on CPU (aarch64) due to absence of a paddlepaddle-gpu wheel for linux/aarch64
- Ollama LLM inference (LLaMA 3.1 8B) — running on GPU, consuming ~ 8–10 GB of the unified memory pool
During batch invoice processing, we are observing significantly degraded OCR extraction quality — specifically, multiple table rows merging into single rows. Single-invoice processing at idle shows occasional row merging, but batch processing with Ollama active on the GPU produces severe and consistent merging.
We believe this may be caused by the CPU and GPU competing for bandwidth on the shared 128 GB LPDDR5X pool via NVLink-C2C during batch runs. We would like to understand this better and are reaching out to get some clarity from the NVIDIA team.
Enquiries
1. Workload Isolation We would like to understand whether there is a recommended approach to isolate CPU and GPU workload memory bandwidth on the GB10 unified memory architecture. Specifically, we would like to know:
- Is memory affinity or any NUMA-like partitioning possible between CPU and GPU memory regions on GB10?
- Are there any numactl, cgroups, or CUDA memory policy settings applicable to NVLink-C2C bandwidth management?
- Is there a recommended scheduling strategy for mixed CPU+GPU batch workloads to prevent memory bandwidth contention?
2. Configuration Guidance We would also like to know if there are any DGX Spark-specific kernel parameters, CUDA environment variables, or system-level settings that are recommended for production batch processing environments where CPU and GPU inference run concurrently. Any documentation or best practices guidance specific to GB10 would be very helpful.
3. Memory Bandwidth Monitoring We noticed that nvidia-smi --query-gpu=memory.used returns [N/A] on GB10, which we understand is expected given the unified memory architecture. Could you point us to any official tool or API that allows us to monitor the following:
- Real-time NVLink-C2C bandwidth utilisation (CPU-side vs GPU-side)?
- Per-process memory bandwidth consumption on the unified pool?
- Any memory pressure indicators specific to the GB10 architecture?
4. PaddlePaddle aarch64 GPU Support We would also like to enquire whether NVIDIA has engaged with PaddlePaddle/Baidu regarding GPU support for the DGX Spark (GB10) platform. We confirmed that pip install paddlepaddle-gpu returns from versions: none on linux/aarch64, forcing us to run OCR on CPU — which is the root cause of the contention we are experiencing. Is there a documented path, such as building PaddlePaddle from source against the DGX Spark CUDA 13 .0 toolkit, that NVIDIA would recommend in the meantime?
We appreciate any guidance or documentation you can share on the above points. Please let us know if any additional system details or logs would be helpful.
Thank you.
Attachments
The following screenshots were captured directly from the DGX Spark (spark-e4ce) on 29–30 June 2026 and serve as evidence for the issues described above.
Attachment 1: System Conclusion — Architecture: aarch64, GPU hardware present but NOT usable by Paddle (no linux/aarch64 GPU wheel). lscpu confirms big.LITTLE CPU: Cortex-X925 (performance) + Cortex-A725 (efficiency) cores .
Thank You.