Why enterprise AI should match compute to the task.
In brief
- Most enterprise AI work does not need a frontier model at every step.
- An inference hierarchy sends each task to the smallest resource that meets the standard and escalates only when needed.
- WiCi’s open-source InferSSD engine shows how far one GPU can stretch, and where throughput limits remain.
- Efficiency must be measured, not assumed: cost, energy, quality and governance together.
AI infrastructure is growing in capability, capital investment and electricity use at once, as enterprises weigh advanced GPUs, high-bandwidth memory and ever larger data centers. That raises a question that deserves more attention: how much of that capacity must actually be engaged to deliver the intelligence a specific business process requires? At Redrock Systems, we treat it as fundamental, because the answer shapes capital spending, operating cost, performance, governance and sustainability.
Lessons From Computing History
Early commercial systems such as UNIVAC needed enormous installations to deliver what later became commonplace. Progress came from more than miniaturization: integrated circuits, instruction-set evolution, specialized execution engines and better software changed how much infrastructure a given capability required.
The Apollo Guidance Computer made the point under pressure. Its designers had to deliver reliable navigation and control within strict limits on memory, power, size and weight, so they allocated resources to the functions essential to the mission. RISC and CISC design, hardware acceleration, virtualization and workload-specific processing carry the same principle forward: the best architecture matches execution resources precisely to the workload. AI should be no exception.
The Frontier-Model Imbalance
Frontier AI systems can require substantial GPU memory, high-performance interconnects and significant power and cooling. For centralized training, large concurrent inference and highly complex reasoning, that is often appropriate. Enterprise AI, however, covers a much broader range of work. Document processing, retrieval, classification, structured extraction, operational automation and tightly scoped reasoning rarely need full frontier-model execution. Routing every step to a large general-purpose model adds avoidable cost in GPU time, tokens and latency, and that cost compounds as AI shifts from occasional queries to persistent agents.
The International Energy Agency’s 2026 report Key Questions on Energy and AI projects data center electricity consumption roughly doubling, from 485 TWh in 2025 to 950 TWh in 2030. Hardware and software efficiency will decide whether enterprise AI stays sustainable as adoption grows.
Storage-Backed Inference
WiCi builds wireless access to shared GPUs and publishes its open-source InferSSD engine, which streams mixture-of-experts (MoE) weights from NVMe storage while frequently used components stay in faster memory. Because sparse MoE models activate only a few experts per token, the storage a model needs is partly separated from the GPU memory it needs to run.
The numbers are concrete. DeepSeek V4.1 Flash has about 748B total parameters, with 16B active per token during decode. On one RTX 5090 with a PCIe 5.0 SSD, the InferSSD README reports 7.27 tokens per second for decode, against 0.867 for stock llama.cpp. Prefill runs at 164.5 tokens per second, so a 4,000-token prompt waits about 25 seconds for its first token.
Making a very large model run on one workstation is not the same as delivering production-scale throughput. The opportunity lies in pairing advances like this with better orchestration.
Governance needs the same attention. WiCi’s privacy notice says connections to a local box “may use HTTP on the local network.” Redirecting applications’ AI calls to a local box creates a new network service, and in an enterprise that service needs segmentation, pairing control and logging.
The Inference Hierarchy
We expect enterprise AI to select execution resources by workload complexity, security requirements, latency sensitivity and acceptable cost. In practice, that is a hierarchy:
- A lightweight local model classifies the request.
- A retrieval system finds the relevant enterprise information without bloating the prompt.
- A specialized model handles extraction, translation or domain analysis.
- A local or departmental GPU service runs heavier processing inside an approved network boundary.
- A frontier model is called only when the problem needs general-purpose reasoning beyond those resources.
- Validation and policy checks run before the application accepts a result.
Expensive resources are not spent on work cheaper ones can complete to the required standard, and the design reduces repeated inference, reuses context and raises utilization of existing compute. It can mix cloud services, on-premises GPUs, local accelerators and smaller models. The right mix should come from workload evidence, not an assumption that one deployment model is always superior.
Measuring Sustainable AI
Moving workloads from the cloud into local facilities does not by itself reduce environmental impact. Distributed architectures can add duplicated hardware, idle power and operational complexity, so any advantage has to be demonstrated. Redrock Systems evaluates these architectures across six dimensions:
- Compute efficiency: processing and energy per accepted result, including retries, routing and verification.
- Data movement: memory residency, storage access, context reuse and network transfers.
- Workload placement: what belongs on centralized infrastructure and what on local or distributed resources.
- Total cost: acquisition, utilization, licensing, energy, maintenance and support.
- Environmental impact: energy, carbon intensity, equipment lifecycle, and demand growth that offsets efficiency gains.
- Governance and reliability: model quality, data protection, access policies and escalation paths when smaller models fall short.
These belong in the architecture as measurable requirements, not as later optimizations.
The Enterprise Opportunity
Capable local inference is a reason to revisit AI deployment strategy. Find where workloads use far more capability than the outcome requires. Test specialized models, routing, quantization, caching, shared GPUs and local inference against established performance and quality benchmarks, while keeping the option to escalate demanding work to frontier services. The objective is simple: deliver the required intelligence with the least practical compute, cost and environmental impact.
Our Perspective
The next gains in enterprise AI will come from semiconductors, distributed systems, model architecture and orchestration advancing together. Large GPU installations will remain important, but more capacity should not be the default answer to every new requirement. As computing history shows, progress often comes from rethinking where complexity resides. At Redrock Systems, we see that discipline as central to responsible AI adoption.
Want to know which of your AI workloads use more compute than they need? Book a scope call with our architects: calendly.com/consult-redrocksystems
Further reading
- NetworkChuck, WiCi local inference demo (video sponsored by WiCi): https://www.youtube.com/watch?v=cFdoXn6yvE4
- WiCi, InferSSD (open source, GitHub): https://github.com/wici-ai/inferssd
- International Energy Agency, Key Questions on Energy and AI (2026), Executive summary: https://www.iea.org/reports/key-questions-on-energy-and-ai/executive-summary
#RedrockSystems #EnterpriseAI #AIInfrastructure #AIArchitecture #SustainableTechnology
