{/* SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. SPDX-License-Identifier: Apache-2.0 */}
This page lists significant limitations, with what to expect and what to do about them. This is not a bug tracker. Report anything not listed here as an issue. Report vulnerabilities privately as described in Security.
The latest published fork build, 0.8.0, targets macOS arm64 only. It is
unsigned/unnotarized; its privileged helper and helper-based firewall setup are
unavailable. Downloading via curl or verifying its checksum does not change
those trust restrictions. Windows/Linux desktop and Intel Mac runtime validation
remain outstanding for that release. See the release notes
for the exact tested scope; source-platform support is not artifact certification.
nvpair-helper-ctl trust checks the host app and the tool against helper code-signing
requirements; when not satisfied, PAIR skips the helper explanation dialog and registration
entirely (avoiding repeated prompts). In the desktop application, navigate to
Settings → Service to view the Firewall setup: manual card, which provides
guidance on allowing inbound connections when macOS prompts appear so other nodes
can reach this machine.
Implemented in source, pending release testing. GPU memory now has an explicit
kind rather than labeling every capacity as VRAM. This does not certify the
published 0.7.0-rc.1 assets. Current behavior depends on the collector:
| System / source | Kind and displayed memory |
|---|---|
macOS Apple GPU (AGX class or Apple name) |
Unified memory: physical RAM capacity and GPU-mapped allocation (Alloc system memory), not whole-system RAM usage. |
macOS non-Apple Intel GPU (class, model, or entry name contains Intel, case-insensitive) |
Shared memory: VRAM,totalMB shared budget and dedicated-used counters only; Alloc system memory is never substituted for usage. |
| macOS other non-Apple GPU (AMD/NVIDIA discrete) | VRAM (dedicated): dedicated capacity and dedicated used counters only; system allocation is never substituted for VRAM usage. |
Linux NVIDIA with numeric memory.total |
VRAM (dedicated), from nvidia-smi. |
Linux NVIDIA with [N/A] / Not Supported total (including UMA systems such as DGX Spark) |
Unified memory: physical RAM capacity and system-used RAM. This is sentinel-based classification; used bytes are not GPU-only allocations. |
| Linux NVIDIA with malformed total | Memory unavailable; memory figures are omitted. Independently measured utilization can still appear. |
| Windows with dedicated video memory | VRAM (dedicated), plus a separate Shared memory budget and usage; these are never added together. |
| Windows with zero dedicated video memory | Shared memory: the shared-system-memory budget and measured shared usage, not dedicated VRAM or a claim of exclusive GPU capacity. |
| Linux AMD/Intel names-only inventory and other names-only platforms | Memory unavailable, without GPU utilization. Driver/collector support remains out of scope. |
Unified detail reads <used> used of <total> unified memory on every platform,
covering both macOS GPU allocation and Linux system-used RAM.
Missing readings display —, not 0; a measured idle 0 remains visible.
Unknown readings on one adapter do not hide measured readings on another. Memory
history breaks at missing samples rather than dropping to zero. Capacities and
usage are never summed across adapters, which may refer to the same system-memory
pool. Older peers without memory_kind display Memory unavailable, not
inferred VRAM.
The impact is display, not routing. Scheduling still uses pending work and the maximum measured GPU utilization across adapters, not memory kind or capacity. Invalid or stale telemetry retains neutral pressure. Use platform tools when assessing whether a model fits: system RAM or a shared budget is not reserved GPU memory. Windows runtime behavior is untested on this macOS verification host; see GPU memory semantics release testing.
The scheduler ranks by pending work plus smoothed GPU-utilization pressure, then pressure and stable UUID; stale/invalid telemetry gets neutral pressure. Proxies also apply engine/model eligibility and prefix-affinity hints. This is not a prediction based on GPU model, free memory, measured latency, or request cost. A mixed-hardware cluster may therefore assign work to a slower eligible node; a prefix-affinity preference does not prove an engine KV-cache hit.
The full list of gaps is in Scheduler Limitations. Improving this is on the roadmap, and knowing which signals matter on your hardware would help. Refer to Roadmap.
The broker probes all twelve workers, marks them degraded after two consecutive
failed probes, and restarts eight eligible workers after three. Engine-manager
and the three proxies are never auto-restarted on a hang: doing so could
orphan engines or interrupt inference streams. Their degraded desktop rows show
"Not responding — restart manually" under Settings → Service → Workers.
Restarting engine-manager may leave engines running or stop them; proxy restarts
interrupt inference. Desktop asks for confirmation for these four workers; TUI
Overview offers R with confirmation for any selected worker.
Optional initial spawn failures now use bounded retries shared with crashes and
eligible hangs. Exhausted workers need an explicit restart; missing default
binaries remain missing until an explicit retry finds them. Health proves
control-loop responsiveness, not domain progress or HTTP/inference readiness.
See Health and Failure Detection.
Cross-process hang tests use Unix signals and are Unix-only. Windows hang recovery remains unproven; unit tests are not cross-process Windows evidence.
The broker-client layer remains separate: a 15-second heartbeat and 45-second inbound-silence deadline support frontend-owned recovery with a readiness deadline. This is not a guarantee that every unexpected broker exit automatically reconnects.
On macOS, PAIR can stop answering connections from other machines on the network after it has been left unclustered for a while. Other nodes stop being able to discover or reach it, while the application itself looks healthy. Restarting PAIR restores it. This is a rarer problem than the others on this page, and it has only been seen on macOS.
Accepted and documented for this release, not fixed. A controlled second-machine reproduction is still needed before choosing a remedy; no speculative fix has been made. Until then, restart PAIR on the affected Mac. This remains open in release readiness.
Implemented in source, pending release testing. nvpair-tui now shows
workload destinations, lists models, offers supported model pull/delete and local
engine port/update operations, and controls supported operations on paired peers.
Actions follow the target engine-manager's reported capabilities; absent flags
from older peers disable capability-gated actions. This does not certify the
published release assets or live engine/cluster behavior.
It remains an operations tool for headless machines rather than a full replacement. It cannot:
- Send inference requests (use
curlor another inference client) - Uninstall, update or change the port of an engine on another node; these operations are local-only (peer restart is also not offered)
- Pull or delete oMLX models; the engine offers neither action
Use the owning host for local-only engine operations. Refer to What the Terminal Interface Cannot Do.
Implemented in source via nvpair engine, pending release testing. Engine
directories are intentionally not added to PATH. Use nvpair engine ollama list
or nvpair engine <engine> [args...]; the command resolves the executable and
required environment without starting a second broker or dashboard.
The residual limitation is that nvpair itself may not be on PATH:
headless/source builds and standalone service installers provide no wrapper,
and desktop first-run creation is best-effort (notably when macOS's
/usr/local/bin is unwritable). A Linux wrapper directory may also be outside
your shell's PATH. Run nvpair-tui by its full path with the same engine
subcommand, keeping engine-manager beside it, or use the
engine full-path table.
See wrapper availability.
Windows console/Ctrl-C behavior is not runtime-tested on this verification host.
An external HTTP service with no local executable cannot provide a CLI.
- The Linux desktop installer is a
.debonly. On RPM-based distributions, build from source. - Windows on ARM is experimental. Refer to What is supported.