Browsing: Guides & Tutorials

TL;DR NVIDIA NeMo Guardrails should sit in the controlled request path between the application and the production LLM endpoint, not beside it as an optional validation service. The application sends requests through an authenticated gateway to the guardrails service. Input rails inspect the request, retrieval rails inspect RAG context, execution rails constrain tool use, the main request is sent to NVIDIA NIM, and output rails validate the model response before it reaches the caller. A production implementation also needs controls that do not appear in a basic demo: no direct application path to NIM, explicit fail-open and fail-closed decisions, separate…

TL;DR MCP and A2A solve different integration problems. MCP standardizes how an agent discovers and invokes tools, APIs, resources, and data services. A2A standardizes how independent agents discover one another, exchange messages, delegate work, manage long-running tasks, and return artifacts. A durable enterprise design does not choose one protocol and force it to do both jobs. It uses A2A across agent boundaries and MCP inside each agent’s execution boundary. Identity, discovery, gateways, policy enforcement, approval controls, and observability surround both. The result is a layered architecture where agents can collaborate without exposing their internal tools, and tools remain governed without…

TL;DR Traditional logs tell operators what individual components recorded. Agent observability must answer a harder question: did an autonomous system remain inside its declared task, authorization boundaries, and approved methods across the complete sequence of actions? The required unit of detection is the trajectory. Prompts, tool calls, shell commands, identities, network destinations, package retrieval, privilege changes, policy decisions, resource consumption, and human approvals must be correlated against a versioned task contract. The system must then detect sequence-level divergence and invoke controls outside the agent runtime before a harmful sequence completes. A useful implementation combines distributed tracing, security telemetry, identity events,…

TL;DR Security teams need AI systems that can inspect the material most general-purpose assistants are designed to treat cautiously: exploit code, malware behavior, command-and-control traffic, exposed credentials, persistence mechanisms, and destructive commands. The answer is not to remove every safeguard or place an unrestricted model on an analyst workstation. The safer pattern is a governed forensic AI enclave that separates permission to analyze dangerous evidence from authority to execute dangerous actions. Such a platform should use approved case-based access, isolated compute, deny-by-default network controls, no production write access, local evidence retention, immutable audit logging, version-pinned models, controlled exports, and mandatory…

Introduction An enterprise inference service can look busy while its GPU remains nearly idle. The application may be accepting requests, retrieving documents, validating permissions, tokenizing prompts, waiting on storage, retrying dependencies, or building responses. None of those activities prove that enough executable work is reaching the accelerator. This is why GPU troubleshooting often goes wrong. Teams begin with the last dashboard in the chain, see low utilization, and immediately change batch sizes, add model instances, or blame the hardware. They optimize the GPU before proving that the GPU is the bottleneck. A more reliable method starts with the expected demand…

TL;DR An agent tool is not merely an API endpoint with a JSON wrapper. It is a contract between a nondeterministic decision-maker and a deterministic system. Reliable tools have distinct names, narrow responsibilities, constrained input schemas, useful descriptions, predictable output structures, retry-safe side effects, actionable errors, server-side validation, and evaluations built around realistic tasks. The most important design test is not whether a developer can call the tool successfully. It is whether an agent can consistently select the right tool, construct valid arguments, recover from mistakes, interpret the result, and avoid unsafe duplicate actions. This tutorial builds that contract around…

Introduction The phrase “import an existing vCenter” sounds safer than it really is. It suggests that VMware Cloud Foundation reads an inventory, registers a few objects, and leaves the underlying environment largely untouched. That description is incomplete. In VMware Cloud Foundation 9.1, brownfield adoption is a change in platform ownership, lifecycle control, management topology, networking dependencies, storage governance, and recovery responsibility. The virtual machines may continue running, but the environment around them is being absorbed into a different operating model. That is why the right question is not simply whether the VCF 9.1 import workflow can discover the current vCenter.…

Introduction Enterprise GPU design becomes confused when several different decisions are compressed into one question: “How should we share the GPU?” That question mixes hardware assignment, virtualization, Kubernetes scheduling, tenant isolation, business priority, and service-level commitments. The result is often a platform that advertises many GPU “slices” but cannot explain what each slice guarantees. A whole GPU assigned to a Kubernetes pod is not the same thing as a whole GPU passed through to a virtual machine. A standard NVIDIA vGPU profile reserves framebuffer but generally time-slices GPU engines. Multi-Instance GPU, or MIG, partitions supported hardware into defined compute and…

VCF 9.1 creates a familiar operational trap: a platform team can complete a release-note review and still not be ready to upgrade. The reason is that support changes do not arrive as one clean class of event. Some capabilities remain functional but are deprecated. Some hardware operates under restricted support. Some components have already been removed. Other configurations remain active until an upgrade precheck identifies them as blockers. Those conditions require different responses. A deprecated feature needs an owner and an exit plan. A restricted device needs a risk decision. A removed component needs remediation before the change window. An…

TL;DR An expected workload count is not a GPU requirement. Thirty concurrent notebooks, RAG services, inference endpoints, fine-tuning jobs, or distributed training runs can create radically different demands for GPU memory, accelerator time, CPU, system memory, storage throughput, metadata operations, network bandwidth, scheduling policy, and failure reserve. Capacity planning should begin by defining workload service classes and service-level objectives. For each class, measure arrival rate, runtime, queue tolerance, completion-time objective, GPU memory footprint, compute intensity, allocation model, cold-start behavior, and supporting infrastructure demand. Then calculate both a service-capacity floor and a placement-capacity floor. The larger floor governs the design. In…