# Asama vs NVIDIA Minerva: a component-by-component comparison for GPU and server fleets > NVIDIA Minerva 1.0.1 scored against Asama on 13 components, from NVIDIA's own docs: where Minerva fits, and where an alternative does. - URL: https://blog.asama.ai/blog/01-asama-vs-nvidia-minerva/ - Author: Manish Gautam - Published: 2026-11-03 - Tags: Comparisons NVIDIA launched Minerva on 22 October 2026 as the AIOps platform for its AI factories. If you are evaluating it, or looking for an alternative to it, this is the comparison: NVIDIA Minerva 1.0.1 against Asama on the thirteen components of the [comparison matrix](https://blog.asama.ai/blog/comparison-matrix), with every Minerva score taken from NVIDIA's own documentation. Minerva reads NVIDIA's fabric and GPUs, and reads them in depth: NVLink, Spectrum-X, RoCE, NCCL and Slurm jobs, folded into one incident when something slows a training run. Below the NIC it sees the server only through its logs: XIDs, PCIe AER, smartd and Lustre errors. The 1.0.1 documentation lists no collector for a BMC, a BIOS, firmware state, another vendor's switch, InfiniBand or Kubernetes, and shows Minerva executing no fix: it writes the steps and hands them to a person or to your automation. The ideas Minerva launched with are ones Asama already runs: learned baselines, detection of anomalies never seen before, a knowledge graph of infrastructure and workloads, topology-based correlation that folds an event storm into one incident, and an assistant grounded in live telemetry. Asama then goes below the NIC, across server vendors, and on to the fix. | | NVIDIA Minerva 1.0.1 | Asama | | --- | --- | --- | | Infrastructure State | **2.6** / 4 | **4.0** / 4 | | Detection | **2.8** / 4 | **4.0** / 4 | | Remediation | **0.7** / 4 | **4.0** / 4 | Every score on this page is out of 4. Minerva is scored as version 1.0.1, turnkey with its Sherlock assistant, on the stack its documentation lists: NVIDIA GPUs through DCGM, ConnectX NICs and BlueField DPUs through DOCA, Spectrum-X switches on Cumulus Linux, NVLink switches through NMX-T, Slurm and NCCL. Documentation supports a score of 3 at most, so no Minerva cell can reach 4 here. On InfiniBand, another vendor's Ethernet or Kubernetes, 1.0.1 lists no collector, and its state score falls to 2.2. Asama's 4s are our scoring of our own platform. The published results cover detection and root cause: across 50-plus induced failures on Dell, HPE and Lenovo hardware, detection took 8 to 50 seconds, and at a mid-market design partner 20 of 26 root-cause analyses were accepted on first read. A live comparison on your fleet tests the rest. Detection is the close race, 2.8 against 4. Remediation is not: 0.7 against 4, because Minerva leaves the change to you. Infrastructure State sits between, at 2.6, because Minerva knows what NVIDIA's parts report and little about how the server around them is set. Asama was founded in 2024 by people who ran infrastructure at Flipkart, and has published on this ground since October 2025, a year before Minerva shipped. --- ## The evaluation framework The framework is ours, set out in [The Four Levels of Detection Maturity](https://blog.asama.ai/blog/four-levels-of-detection-maturity) and scored with the comparison matrix: thirteen components in three parameters, each scored 0 to 4 on how much of the work the platform does and how much it leaves to your engineers. Correlation and plan count three times, because evidencing and choosing the right change are where the hours go. ## Part 1: Infrastructure State | Component | L1 | L2 | L3 | L4 | | --- | --- | --- | --- | --- | | Breadth | Major layers, one OEM | Major layers, across OEMs | A band of adjacent layers with depth, connected, across OEMs | Interconnect and components through firmware and BMC, BIOS, drivers, kernel and OS, to the hypervisor and Kubernetes, across OEMs | | Depth (cumulative) | Events | Adds live telemetry | Adds clustered inventory and golden baselines | Adds configuration and tuning state across BIOS, kernel, firmware, drivers and device config, with drift classified against an approved, evolving reference | | Normalisation | Industry-standard formats, or each vendor's values decoded separately | A few aspects of major components, across OEMs, within one layer | A few aspects of major components, across OEMs and a few layers | Every aspect of every component, across every layer and OEM, so one physical part is one object | | Topology | Relationships you declared | Relationships discovered within one domain | Relationships discovered across a band of adjacent layers, kept current | A live representation of assets, components, layers, change history and dependencies across the fleet | | History | Raw time series and events | History with reporting, and human-written records alongside | Indexed and searchable by query or chat | Prior faults, RMA history and firmware and configuration changes for this node and its cohort, surfaced into the current diagnosis | Minerva's record is what NVIDIA's parts report: the GPU, the NIC, the switch port and the job. Asama's is the whole server. ### Breadth: NVIDIA Minerva 3, Asama 4 Minerva collects from NVIDIA GPUs through DCGM, ConnectX NICs and BlueField DPUs through DOCA, Spectrum-X switches on Cumulus Linux, NVLink switches through NMX-T, Slurm and NCCL: a connected band of adjacent layers, read in depth. Level 3. Level 4 needs the band to run down through firmware and BMC, BIOS, drivers, kernel and OS to the hypervisor and Kubernetes, and 1.0.1 lists no collector for any of those, nor for InfiniBand or another vendor's switches. Asama reads every layer of every node, from the BMC and BIOS through firmware, drivers, kernel and OS to the hypervisor and Kubernetes, across Dell, HPE, Lenovo, Supermicro and NVIDIA hardware. **The gap costs you:** a fault that starts in the server's own management plane reaches Minerva as a symptom on a GPU or a port. ### Depth: NVIDIA Minerva 2, Asama 4 Events, logs and live telemetry: level 2. Level 3 needs a reference to compare against, clustered inventory and golden baselines. Minerva learns baselines for metrics but, beyond events such as a GPU driver version mismatch, holds no record of how each node is configured, so it can flag a GPU running hot without knowing that the fan policy changed. Asama holds configuration and tuning state across BIOS, kernel, firmware, drivers and device config, and classifies [drift against an approved reference](https://blog.asama.ai/blog/issue-02-asama-config-drift-is-the-silent-killer) that evolves with the fleet. **The gap costs you:** a setting that drifted shows up only once it has done damage. ### Normalisation: NVIDIA Minerva 2, Asama 4 Minerva joins NVIDIA's own records across layers: a host's NIC meets the leaf port it plugs into, and both meet the job. That join is real, and it is one vendor's. Another vendor's switch or GPU has no documented collector, so nothing is made comparable across OEMs; the cross-layer join earns level 2. Asama resolves the drive the kernel enumerates, the bay the controller reports and the chassis inventory entry to one object, [whichever vendor built it](https://blog.asama.ai/blog/issue-09-asama-the-heterogenous-problem-nobody-admits). **The gap costs you:** on a mixed fleet, the comparison across vendors is still a person's job. ### Topology: NVIDIA Minerva 3, Asama 4 A knowledge graph runs from data centre, pod, super spine, spine and leaf down to server and NIC, with its own hierarchy for NVLink and NVSwitch, filtered by job and kept current. Discovered across adjacent layers: level 3. Level 4 needs change history, and the server's own components, in the graph. Asama keeps a live model of assets, components, layers, change history and dependencies across the fleet. **The gap costs you:** the graph shows which links a job crosses, not what changed on the node at either end. ### History: NVIDIA Minerva 3, Asama 4 Sherlock answers questions over stored telemetry, anomalies and incidents in plain language, such as "Which hosts have been in a degraded state the longest this week?" Indexed and searchable by chat: level 3. Level 4 needs prior faults and firmware and configuration changes surfaced into the diagnosis without anyone asking, and the 1.0.1 docs show no record of firmware or configuration changes to surface. Asama surfaces prior faults, RMA history and firmware and configuration changes for the node and its cohort into the current diagnosis. **The gap costs you:** last week's firmware update reaches today's incident only if somebody remembers it. --- ## Part 2: Detection | Component | L1 | L2 | L3 | L4 | | --- | --- | --- | --- | --- | | Symptom detection | Limits and triggers somebody wrote | Each signal against its own history | Its own history, qualified by seasonality, change windows and workload phase | Comparable nodes under comparable conditions, firing before the node crosses any threshold of its own | | Correlation (×3) | Within one device, or along a declared relationship | Related metrics mapped by time window: signals grouped, evidence not assembled | Search across tools and domains that assembles the case | An end-to-end causal chain across the whole stack, BMC, BIOS, firmware, kernel and driver state included, with history, on a live topology | | Root cause and evidence | Orders the signals without asserting a cause | Orders and selects the signals that bear on this incident | Several probable causes, with the evidence for each | One declared cause with its evidence chain, a confidence level and the blast radius | | Detection learning | Records outcome signals by hand | Finds patterns in recorded failure confirmations and baselines | Folds your verdicts into what it detects and how it correlates | Keeps a live inventory of confirmations and baselines, recalled in later investigations | Detection is where Minerva comes closest. ### Symptom detection: NVIDIA Minerva 3, Asama 4 Minerva baselines every metric against its own history, and adds group anomalies: a GPU compared with peers running the same workload. NVIDIA's launch example is exactly that: "a GPU running hotter than its peers". On a working fleet that could earn level 4; documentation supports 3, so 3. Asama compares each node with comparable nodes under comparable conditions, before it crosses a threshold of its own, on [baselines that move with the fleet](https://blog.asama.ai/blog/normal-is-a-moving-target). **The gap costs you:** little on NVIDIA's fabric. The difference is what gets compared: Minerva compares GPU and link metrics, while Asama compares the whole node, settings included. ### Correlation: NVIDIA Minerva 3, Asama 4 Topology-aware correlation folds a spine anomaly and the pause frames it causes on the leaves below into one incident; one of NVIDIA's case studies folds 81 anomalies into a single report. Dimensional correlation groups by rack or job. Time, topology and cohort build the case: level 3. Level 4 needs state and change in the chain, from BMC, BIOS, firmware, kernel and driver. Asama builds the causal chain across the whole stack, state and change included, on a live topology and across the fleet, which is where [AI root cause analysis usually stalls](https://blog.asama.ai/blog/why_l3_stalls). **The gap costs you:** when the cause is a setting, the incident Minerva assembles is complete and still points at the wrong layer. ### Root cause and evidence: NVIDIA Minerva 3, Asama 4 Each incident names a root cause, the trigger linking its events, and a potential impact. Job failure analysis lines Slurm job states up against GPU XIDs, NVSwitch errors, switch counters and NVMe logs, to separate a code bug from a hardware fault. Level 3 on documentation, and the chain ends where the collectors end. Asama declares one cause with its evidence chain, a confidence level and the blast radius, [so you can check it](https://blog.asama.ai/blog/trust-is-the-real-interface). **The gap costs you:** a cause in the BIOS or BMC is named only as far as its first symptom. ### Detection learning: NVIDIA Minerva 2, Asama 4 Minerva learns baselines continuously and ships a library of known error signatures drawn from NVIDIA's production deployments. Level 2. Level 3 needs your verdicts folded into what it detects, and the 1.0.1 docs describe turning detectors on and tuning thresholds, not learning from a finding you marked wrong. Asama folds your verdicts in, and writes expected anomalies into the state so later investigations recall them. **The gap costs you:** the same false positive returns until someone retunes the detector. --- ## Part 3: Remediation | Component | L1 | L2 | L3 | L4 | | --- | --- | --- | --- | --- | | Plan (×3) | Suggestions for this kind of issue | Predefined runbooks or workflows, bound to the alert or device class that triggers them | Maps the problem to the right procedure from a library or your scripts, with a stated target outcome | Composes the plan at incident time against this node's exact hardware, firmware, BIOS and kernel, with preconditions and rollback | | Act | A single step on the target | Multi-step, with scheduling, change windows and audit, and reports failure | Multi-step with failure handling: halts cleanly and restores a prior known state | Runs its own plan in stages inside maintenance policy; a failure leaves the fleet at the last verified step | | Verification | Reports whether the command ran and exited clean | A defined post-change check against an expected outcome | Re-compares the node with its expected behaviour and state | Compares against the pre-incident baseline and re-validates the node against its peers | | Remediation learning | Keeps a retrospective a person wrote | Stores the resolution as content it can retrieve | Surfaces past resolutions inside a new incident of the same class | Updates the procedure library so the next plan is better | Remediation is where the two products part. NVIDIA's launch post promises recommended remediation, with automation through external systems. ### Plan: NVIDIA Minerva 1, Asama 4 Rare log anomalies come with an AI-generated guide: step-by-step commands to diagnose and fix the issue. That is a suggestion for this anomaly, level 1. Level 2 needs procedures bound to the alert that triggers them. A 1.0.1 view can send chosen events to a webhook for your automation, but Minerva holds no procedure of its own, so 1 stands. Count that webhook as binding and plan is 2 and remediation 1.2; act stays 0, because the playbook runs on your Ansible. Asama composes the plan at incident time against the node's exact hardware, firmware, BIOS and kernel, with preconditions and rollback. **The gap costs you:** an engineer still turns the guide into a change that is safe on this node. ### Act: NVIDIA Minerva 0, Asama 4 NVIDIA's product page promises closed-loop remediation, but the 1.0.1 docs describe no change Minerva makes to a device: remediation arrives as a guide, a ServiceNow ticket or a webhook to your automation. Its MCP server is read-only too and, in NVIDIA's words, "does not remediate issues or modify configurations". Fixes run by hand or on automation you license and run separately, which the matrix scores 0. Asama executes the plan it composed, in stages, inside your maintenance policy and [with your approval](https://blog.asama.ai/blog/the-automation-boundary); a failure leaves the fleet at the last verified step. **The gap costs you:** the change is your team's, every time. ### Verification: NVIDIA Minerva 0, Asama 4 With nothing executed, Minerva has nothing of its own to verify. An anomaly clearing afterwards is not a check of the fix; it is detection running again on the same signal. Asama compares the node with its pre-incident baseline and re-validates it against its peers before closing the incident. **The gap costs you:** "it went quiet" stands in for "it is fixed". ### Remediation learning: NVIDIA Minerva 1, Asama 4 Sherlock saves its conversations, so a fix worked out in one can be found again by scrolling back. Level 1. Nothing brings a past resolution into a new incident. Asama updates its procedure library with every resolution, so the next plan starts from what worked on your fleet. **The gap costs you:** the second occurrence is solved from scratch. --- ## A hot GPU, through Minerva and Asama Take a variant of the hot node from The Four Levels of Detection Maturity: a BMC firmware update resets a GPU server's fan profile, and six days later its GPUs run hotter than their peers and throttle under load. Minerva catches the symptom; it is NVIDIA's own launch example. Group anomaly detection flags the GPUs against their peers, and Sherlock can tell you which node and since when. Then the chain stops: the fan profile lives in the BMC, and so does the record of the firmware update, and the 1.0.1 docs list no collector for either. Its answer stops at the node: a cooling problem on that server, with the reason out of view. Asama reads the fan profile as state, compares fan speed with the node's peers, and joins the firmware update, the profile and the throttling into one chain. It finds the other nodes updated in the same window, plans the restore for their exact firmware, applies it, with your approval, inside your maintenance window, and closes the incident only when the GPUs hold their clocks under load as their peers do. ## Choosing, or running both Pick Minerva if your cluster is NVIDIA end to end, Spectrum-X and Slurm included, and your pain is the fabric: stragglers, RoCE retransmits, NVLink errors, and jobs that die for reasons no single dashboard shows. NVIDIA's automated hardware recovery sits in a separate product, Mission Control, which runs on DGX and NVL72 systems and is validated by Dell, HPE and Supermicro. Pick Asama if your fleet mixes server vendors, runs Kubernetes, or includes servers with no GPU at all, or if you want the fix carried out and verified rather than described. That covers fleets outside the AI factories Minerva launched with. Run both if you are on NVIDIA's stack and your faults keep starting below the NIC: Minerva on the fabric, Asama on the server and the fix. ## On the record since 2025 These posts went out before Minerva did, and each covers ground Minerva launched into. | Published | Asama post | What Minerva shipped on 22 October 2026 | | --- | --- | --- | | 7 Oct 2025 | [GPU health checks with NVIDIA DCGM](https://blog.asama.ai/blog/gpu-health--diagnostics----why-they-matter) | GPU health through DCGM, XID errors | | 18 Jan 2026 | [The correctable error trap](https://blog.asama.ai/blog/issue-07-asama-the-correctable-error-trap) | PCIe errors read as early warning of job failure | | 18 Mar 2026 | [Peer comparison is the baseline](https://blog.asama.ai/blog/issue-11-asama-peer-comparison-is-the-baseline) | A GPU compared with its peers | | 10 Jun 2026 | [Trust Is the Real Interface](https://blog.asama.ai/blog/trust-is-the-real-interface) | Incidents naming a root cause; anomalies with a confidence score | | 4 Jul 2026 | [Normal Is a Moving Target](https://blog.asama.ai/blog/normal-is-a-moving-target) | Baselines learned per component | ## Questions to take into the Minerva demo | Component | Ask | | --- | --- | | Breadth | Which collector reads our BMCs, and our switches from other vendors? | | Depth | What is this node supposed to be set to, BIOS and firmware included? | | History | What were this node's firmware and BIOS before the last maintenance window? | | Root cause | The GPU is hot. Why, five whys down, and what is the evidence for each? | | Act | What executes the change, on whose licence, and what happens if step three fails? | | Price | What does it cost per node after the 90-day evaluation licence? | Minerva is NVIDIA's view of NVIDIA's fabric, and it is a detailed one. Asama is an engineer for the whole fleet: Dell, HPE, Lenovo, Supermicro and NVIDIA, down to the BIOS, with the fix carried out and checked. *Minerva material is drawn from NVIDIA's product page, its launch post of 22 October 2026 and the Minerva 1.0.1 user guide, read on 2 November 2026. NVIDIA, Minerva, DGX, NVLink, NVSwitch, Spectrum-X, ConnectX, BlueField, Cumulus and DOCA are trademarks of NVIDIA Corporation. Other names belong to their owners. Asama is not affiliated with NVIDIA.* To put your own fleet through the same thirteen components, book a live comparison against your stack at [asama.ai](https://www.asama.ai), or write to contactus@asama.ai.