AI compute brief — October 26, 2026

1. NVIDIA released a runtime architecture close to the eVM entity model

NVIDIA released OpenShell v0.1.5 on October 20 and announced its broader OpenShell reference architecture on October 21. OpenShell places autonomous workloads inside isolated sandboxes and applies policies to filesystem access, processes, networking, and credentials. It supports containers, Kubernetes and MicroVMs; Windows support through WSL2 remains experimental.

OpenShell also keeps credentials outside the entity and inserts them only into approved requests. Its recent release corrected MicroVM persistence and recovery problems, tightened network-policy enforcement, and hardened VM startup.

Implications for Enumium:

• Use this as a reference implementation for eVM entity containment, capability policies and provider-bound credentials.
• Each entity should receive a signed policy describing allowed tools, paths, endpoints and compute engines.
• Keep identity and persistent state in the eVM while executing tools through verified MSCAN/VM1 interfaces.
• Evaluate the architecture in an isolated prototype before incorporating code. OpenShell is Apache-2.0 licensed, but its Windows path is still experimental.

2. A 64GB local inference appliance became commercially available

The DGX Spark 64GB configuration became available October 23, starting at $4,999. It includes unified memory, ConnectX-7 networking and support for Ollama, llama.cpp, vLLM and PyTorch. NVIDIA says it supports models up to 100 billion parameters.

NVIDIA also demonstrated two units connected over 200GbE and reported up to 1.7× performance on Qwen 3.8 27B compared with one unit. That is a vendor result on one workload. Two systems do not automatically become one GPU for every application; the inference software must explicitly distribute the model or workload.

Implications for sourcing:

• Spark is now a useful reference system, especially for testing large models that exceed consumer GPU memory.
• Existing RTX 5060 Ti, RTX 3060 and RTX 3070 machines may remain more economical for small and medium models and multiple specialized entities.
• A Spark purchase becomes defensible when an IRIS/Nova model or fine-tuning workload demonstrably requires more coherent memory.
• Add DGX Spark’s “power-on to available inference service” workflow to the comparison targets for the Nova USB assembly kit.

3. AMD and Intel are combining their CPU inference paths

On October 20, AMD and Intel announced that AMD’s ZenDNN optimization work will be integrated into oneDNN, creating a common PyTorch CPU path across AMD and Intel x86 processors. AMD also joined the UXL Foundation as a steering member. No delivery date or new performance measurements accompanied the announcement.

Implications for aging PCs and portable eVMs:

• CPU inference should become easier to deploy consistently across mixed Intel and AMD machines.
• The Nova USB kit should detect CPU instructions and select an optimized backend during assembly.
• Build one CPU qualification suite covering latency, memory use, tool-call accuracy and thermal behavior.
• Keep Ollama/llama.cpp as the lightweight compatibility route while evaluating PyTorch/oneDNN for workloads that benefit from it.

4. Mixed GPU scheduling is now a shipping enterprise capability

HPE says its Private Cloud AI platform can now combine NVIDIA H200 and RTX Pro 6000 Blackwell Server Edition GPUs in one cluster. NVIDIA KAI Scheduler support for quotas, priorities and workload placement is also generally available. HPE’s governed APIs and MCP controls are rolling out later, across late 2026 and 2027.

This means heterogeneous clustering is being productized, but it does not combine the cards’ VRAM into a universal shared pool.

Implications for MSCAN:

• Register each accelerator independently with memory, supported precision, locality, bandwidth, utilization and compatible runtimes.
• Route each request to a suitable device instead of treating every GPU as interchangeable.
• Add per-entity quotas, job priorities and reservations.
• Report aggregate fleet capacity separately from the memory available to one model instance.

This supports using mixed 20-, 30- and 50-series systems as a coordinated inference fleet once compatibility is measured.

5. Google’s Vera Rubin cloud instances arrive next month

Google Cloud announced that A5X bare-metal instances based on NVIDIA Vera Rubin NVL72 are scheduled for general availability in November 2026. The design includes GPUDirect Storage, topology-aware scheduling and storage-tier KV-cache offloading. These are announced platform capabilities rather than results from customer-independent benchmarks.

Implications:

• Treat A5X as potential overflow capacity for model training, large evaluations and temporary high-demand inference.
• Preserve provider-neutral model and job interfaces so an eVM entity can move between local GPUs, Enumium servers and rented cloud acceleration.
• Google’s cache hierarchy further validates separating persistent entity memory from model KV-cache state.
• Do not build eSlot marketing around “extending VRAM.” Describe it as a managed memory/storage tier with measured latency and bandwidth.

Decisions for this week

• Prototype an eVM entity policy manifest covering tools, files, network destinations, credentials and VM1 engines.
• Add CPU backend qualification to the Nova portable installer for both AMD and Intel hosts.
• Modify MSCAN’s accelerator inventory to distinguish physical GPU memory, system memory, pooled capacity and storage-backed capacity.
• Benchmark the existing GPU fleet before purchasing DGX Spark: model load time, tokens per second, time to first token, concurrent sessions, power and successful tool calls.
• Keep Google A5X as an overflow option and DGX Spark as a comparison platform. This week did not produce a compelling reason to replace the current consumer-GPU sourcing strategy.