This week, Cisco announced a significant expansion of the Cisco Secure AI Factory with NVIDIA, adding Supermicro rack-scale GPU systems to an architecture designed to support increasingly large and demanding AI workloads. The expansion takes the Secure AI Factory further into the world of high-density AI infrastructure, supporting everything from enterprise inference to trillion-parameter model training.
There is plenty to consider in the announcement, particularly around the sheer scale of compute now being brought into the architecture. Cisco is combining its networking, security and management technologies with NVIDIA accelerated computing and networking, Supermicro high-density systems, AI software, observability and an expanding ecosystem of infrastructure technologies.
What is equally interesting is what it takes to make all of that infrastructure useful.
Getting a rack of high-performance infrastructure into a data center is obviously important, but it is only the beginning. The infrastructure still has to be configured, connected, secured and integrated with the software and services that will use it. More importantly, all of those things have to happen in the context of the complete AI environment being delivered.
This is an area Cisco and Quali have been working on together. Stack Automation by Quali, co-developed with Cisco and offered exclusively by Cisco, provides deployment automation for full-stack infrastructure, including the Cisco Secure AI Factory with NVIDIA. As the AI Factory expands, it provides a useful example of why that full-stack approach to automation matters.
The AI Factory is a stack, not a server
It is easy to talk about AI infrastructure primarily in terms of GPUs. They are expensive, increasingly powerful and central to the performance of AI workloads, so naturally they receive much of the attention. A GPU cluster, however, doesn’t operate in isolation.
The compute needs the right network connectivity, and at this scale that can mean separate front-end and back-end fabrics with specific topology, bandwidth and configuration requirements. Storage has to be available and correctly connected, while operating systems, firmware, drivers and network software all have versions and dependencies that need to work together.
Once the physical infrastructure is ready, there is still a considerable amount to do. AI frameworks and software need to be installed and configured for the available GPU resources, security controls need to be applied across the environment, telemetry has to reach the appropriate observability systems, and applications and models ultimately need somewhere to run.
None of this will be particularly surprising to an experienced infrastructure engineer. The challenge is that it all has to work together.
A server can be correctly configured while the environment remains unusable. The same is true of a switch, storage platform or Kubernetes cluster. A firmware mismatch, incorrect network configuration, unavailable resource or software dependency can prevent the overall environment from becoming operational even though most of its individual components are working perfectly well.
This is why deploying an AI Factory is about more than provisioning individual pieces of infrastructure. It requires coordinating the infrastructure and the automation around the environment that needs to be delivered.
There is already plenty of automation
Most organizations aren’t starting this journey without automation. Quite the opposite. Ansible may already be configuring operating systems and network devices, Terraform may be provisioning infrastructure, Helm may be deploying software onto Kubernetes, and Cisco, NVIDIA and other infrastructure vendors provide their own management and automation capabilities.
Those tools remain important. Stack Automation isn’t intended to replace them.
The problem is that automating the individual components doesn’t automatically provide automation for the complete environment. Something still has to understand which infrastructure is available, determine which resources are required, invoke the appropriate automation in the correct sequence and pass information between those different processes. It also needs to understand whether the end result is actually the environment that was requested.
This is the role Stack Automation plays within Cisco’s approach. Existing Ansible, Terraform, Helm and other automation assets can become part of a broader deployment workflow rather than being replaced by another set of scripts or tools. Stack Automation provides the context that connects those automation activities to the full-stack environment being delivered.
That distinction is particularly relevant to AI infrastructure because the application doesn’t care that a collection of individual automation jobs completed successfully. What matters is whether the environment it needs is available and working.
From a validated architecture to a running environment
Cisco and NVIDIA have invested heavily in validated architectures so customers don’t have to determine every aspect of these complex systems themselves. The expanded Secure AI Factory continues that approach, combining validated infrastructure with Cisco networking, security, management and an ecosystem of technology partners.
Validation removes a significant amount of uncertainty about what should be deployed and how the pieces should fit together. There is still a practical difference, however, between knowing what an environment should look like and being able to create it repeatedly.
This is where Stack Automation’s blueprint model becomes useful. A blueprint describes the environment and associates it with the resources, configuration and automation needed to create it. The knowledge contained in the validated architecture can therefore become part of a repeatable deployment process rather than something that has to be interpreted and manually assembled each time.
The underlying automation continues doing what it does well. Ansible can configure something, Terraform can provision something, Helm can install something, and vendor-specific automation can perform the tasks for which it was designed. Stack Automation coordinates those activities around the outcome Cisco is trying to deliver, a complete, usable environment.
It changes the level at which automation can be considered. Instead of building a process around configuring a particular server, switch or software component, the process can be built around delivering the environment that needs those components.
Knowing what you actually have
There is another part of the problem that becomes increasingly important as AI infrastructure grows, which is understanding what is really available before a deployment starts.
A design or inventory may say that a particular collection of compute, networking and storage exists, but that doesn’t necessarily mean those resources are available in the expected state when somebody requests an environment. Some may already be allocated, configurations may have changed, firmware may have been updated, new equipment may have been installed, or infrastructure that was previously available may now be in use elsewhere.
With AI infrastructure, this isn’t a minor consideration. GPU capacity is expensive, the supporting network is highly engineered, and many of the resources may be shared across workloads. Discovering halfway through a deployment that something required isn’t available wastes both infrastructure capacity and engineering time.
Stack Automation can discover and inventory infrastructure resources, then normalize them so that resources from different infrastructure types can be understood and used as part of the same deployment process. This gives the automation a current view of the infrastructure it is working with rather than relying entirely on an assumption about what should be there.
The heterogeneous nature of the Secure AI Factory makes this especially relevant. Cisco’s latest announcement brings Supermicro rack-scale compute into an architecture already spanning Cisco and NVIDIA technologies, with other infrastructure and software partners contributing additional parts of the stack. Each of those technologies can have its own management model and configuration requirements, but those vendor boundaries are much less important to the person who needs an AI environment. They need the right resources assembled into something they can use.
The first deployment isn’t the real test
There is usually a way to get the first complex infrastructure deployment working. Put experienced engineers together with the equipment, automation and documentation they need, give them enough time to work through the dependencies, and eventually the environment can be brought online.
The more interesting question is what happens when another one is needed.
If the knowledge required to build the first environment remains spread across scripts, documentation, tickets and the engineers who assembled it, the next deployment is another integration project. It may be faster because the team learned from the first one, but it still depends heavily on the same expertise and manual coordination.
Capturing the environment in a blueprint provides a different approach. The infrastructure requirements, dependencies and automation used to create it can be reused, while changes to the underlying technology can be incorporated into the blueprint as the architecture evolves.
For an enterprise deploying a small number of AI clusters, that repeatability can reduce considerable operational effort. For the neocloud and sovereign cloud providers Cisco is specifically addressing with this latest expansion, it becomes even more important. They aren’t building an AI environment once. Delivering and scaling AI infrastructure is part of the service they provide.
From rack-scale infrastructure to something useful
One of the things Cisco’s announcement makes very clear is just how quickly the scale of AI infrastructure is changing. The addition of high-density Supermicro systems and support for NVIDIA’s latest rack-scale architectures brings extraordinary amounts of computing capability into the Secure AI Factory.
Cisco is also addressing what happens around that compute. The expanded architecture includes networking, security, observability, infrastructure management and validation services intended to help customers get these increasingly complex systems into production more quickly.
Stack Automation is part of that broader operational story. Cisco describes the platform as moving Day 0-1 infrastructure away from manual, component-by-component configuration towards automated rack-to-application deployment, using Cisco-validated blueprints while continuing to work with automation such as Ansible and Terraform that customers already have.
For Quali, this is also a good example of what we set out to accomplish through our work with Cisco. The underlying infrastructure will continue to change, particularly in AI where the pace of innovation is extraordinary. The objective of Stack Automation is not to hide that innovation or replace the specialist tools used to manage it. It is to make sophisticated infrastructure easier to consume by coordinating the resources, automation and expertise required to turn it into a usable environment.
Cisco’s expansion of the Secure AI Factory with NVIDIA raises the ceiling considerably on what organizations can build. The next challenge is getting that infrastructure into productive use and being able to do it repeatedly as requirements continue to change.
That is where the combination of validated architecture and full-stack deployment automation becomes particularly interesting. The rack may contain the computing power, but the value only starts when somebody can use it.
If you would like to learn more, visit the Quali Stack Automation page to see how Stack Automation helps turn complex infrastructure into repeatable, ready-to-use environments, from rack to application.
