Four hands-on series for an Asus Ascent GX10 — text, speech, video and retrieval — written for one box on a home LAN, running one model family at a time, with everything staying on the machine.
An Asus Ascent GX10 is an NVIDIA GB10 Grace-Blackwell superchip in a 150 × 150 × 51 mm metal box: a 20-core Arm v9.2 CPU complex welded to a Blackwell GPU over a coherent fabric, with 128 GB of unified LPDDR5X that CPU and GPU share from a single pool. NVIDIA rates it at up to 1 petaFLOP of FP4 compute. It is the same silicon as an NVIDIA-badged DGX Spark, with Asus's own chassis, storage options and pricing.
That single specification — one big pool of memory, one accelerator, no PCIe wall between them — is what makes the box interesting and also what defines its limits. These four series are an attempt to be specific about both.
These come up in all four series. They are collected here once so the later articles can point back rather than repeat.
The 128 GB of LPDDR5X runs at roughly 273 GB/s. For comparison, a workstation RTX Pro 6000 Blackwell has around 1.8 TB/s. Token generation in an LLM is a bandwidth-bound operation — every generated token requires streaming the active weights through the memory system — so the Spark generates tokens at roughly a quarter the rate of a big discrete card, and no amount of software tuning changes the physics.
What the box has instead is capacity. A 120-billion-parameter model at 4-bit sits comfortably in memory here and does not fit on a 32 GB card at all. And because the bottleneck is bandwidth rather than arithmetic, the GPU is far from saturated on a single request: batching many concurrent requests multiplies aggregate throughput dramatically. Measured on this hardware, a single stream might give you 50 tok/s while the same model under load delivers over 1,400 tok/s aggregate.
This is the single largest time sink for newcomers, and it is worth internalising before you install anything. The GX10 is aarch64, and the GPU is compute capability sm_121, which is only supported from CUDA 13.0 onward. The system ships libcudart.so.13. The overwhelming majority of published ML wheels are built for x86_64 against CUDA 12.
The failure mode is nasty because it is usually silent. A project that pins torch==2.6.0 will look for an aarch64 + cu128 wheel, fail to find one, and quietly fall back to the CPU build. Everything installs. Everything runs. It is simply thirty times slower, with no error message pointing at the cause.
# The reflex to develop: check what you actually got, every time
python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())"
# Want: 2.9.x+cu130 13.0 True
# A '+cpu' suffix or 'False' means you are running on the Grace coresThe general repair for a project with hostile pins is to install it without dependency resolution and then supply the dependencies yourself from NVIDIA's CUDA 13 wheel index:
pip install -e ./the-project --no-deps
pip install --index-url https://download.pytorch.org/whl/cu130 torch torchaudio torchvision
pip install <the project's other deps, minus the torch/numpy pins>Where a purpose-built container exists for GB10, prefer it over building from source. The community has done this work repeatedly and the images are generally better than what you will assemble by hand in an evening.
There is no separate video memory to fill. CPU allocations, GPU allocations and the kernel's page cache all come out of the same 128 GB. Roughly 120 GB is realistically available to workloads once the OS has taken its share.
Applications written for discrete GPUs frequently mishandle this. The best-known example is ComfyUI appearing to cap out around 64 GB: memory-mapped model loading counts the weights against "CPU" memory before handing them to the GPU, and on a unified fabric that effectively halves what you can use. Two habits fix most of it:
# Reclaim page cache the kernel is holding after big model loads
sudo sh -c 'sync; echo 3 > /proc/sys/vm/drop_caches'
# Watch the single pool rather than hunting for a VRAM number
watch -n1 free -gFlags that help on a discrete card often hurt here. --gpu-only fights the unified allocator and breaks cache eviction; pinned host memory is pointless when host and device share the same DRAM. The video series covers the specific ComfyUI settings in detail.
These series assume you will run one large model at a time — an LLM, or a video model, or a speech stack — rather than trying to keep everything hot simultaneously. That is the sane way to use the box, and it means each workload gets the full memory pool rather than a slice of it.
The exception is RAG, which genuinely needs three models resident at once: a generation model, an embedding model and a reranker. The good news is that the latter two are small — an embedding model is around 1–2 GB and a reranker similar — so the arithmetic still works out with room to spare. Series 4 covers the orchestration.
The Ascent GX10 takes a single M.2 2242 drive — the short 42 mm form factor, not the common 2280 — on a PCIe 5.0 x4 root port. Asus sells 1, 2 and 4 TB configurations; only the 4 TB variant ships with a PCIe 5.0 drive, the smaller ones with PCIe 4.0.
Model libraries are large in a way that surprises people. One pre-built ComfyUI image for this hardware pulls roughly 285 GB of weights on its own, before you have downloaded a single LLM. A serious video setup plus an LLM collection plus a speech stack will pass 1 TB without much effort.
If your models live on external storage, the pattern that works is a single library root that every tool points into, rather than per-application model directories scattered across mount points:
# One canonical library, wherever it physically lives
export MODELS=/mnt/models
# Hugging Face downloads land there instead of ~/.cache
export HF_HOME=$MODELS/hf
# Ollama, llama.cpp, ComfyUI and friends get pointed at the same root
export OLLAMA_MODELS=$MODELS/ollamaKeep whatever you are actively iterating on — the checkpoint you reload twenty times an evening — on the internal PCIe drive, and let the archive live outside. Load time is the thing external storage costs you; inference speed is unaffected once weights are resident.
0.0.0.0 and that matters, it is called out.