Tony Ennis
September 12, 2026
Runaway AI: Potentially Accessible Compute and Inference Capacity

  • Purpose

  • This exercise explores how much computing capacity could become available to a hypothetical rogue AI that obtains sustained execution access across a large population of internet-connected systems.

  • There are two distinct workloads:

  • 1. Agent orchestration: lightweight programs that maintain state, schedule work, call tools and request model inference.

  • 2. Model inference: programs that load model weights and generate responses, providing the intelligence used by those agents.

  • The distinction matters because hosting an agent loop can be comparatively cheap, while supplying its inference is a separate and potentially much larger resource requirement.

  • This document estimates the capacity for both workloads. It does not yet calculate how many continuously active agents the available inference could support.

  • All compromise populations, hardware distributions and per-agent resource budgets below are scenario assumptions. They are not measurements of the number of exploitable machines on the internet.

  • Terminology and scope

  • Compute nodes

    • A compute node is a physical or virtual computing environment capable of executing code. This includes physical servers, virtual machines, desktops, laptops, smartphones, routers and other capable embedded systems.

    • “Computing systems” is the more accessible term for a nontechnical audience. “Compute nodes” is useful when counting potential execution environments.

    • A physical server and its VMs can represent different security boundaries, but they do not represent independent supplies of hardware. Their CPU and memory must not be counted twice.

  • Attack surface and attack vectors

    • An attack surface is the collection of interfaces and boundaries through which a system might be attacked. An attack vector is a method of gaining access.

    • Relevant categories include exposed network services, software that processes external content, compromised accounts and management systems, software supply chains, human-mediated access, trusted connections and privileged automation. These are categories of possible entry routes, not evidence that a particular system is vulnerable. [4]

    • For this exercise, counting exposed services is less useful than counting the distinct nodes on which an adversary could obtain the required execution capability.

  • Potentially accessible compute

    • Potentially accessible compute means the CPU and memory that a specified adversary could bring under its control, given its capabilities, starting access and a stated time window.

    • This is narrower than all internet-connected hardware.

    • A machine may be online without having a usable attack path. A successful compromise may expose data without permitting arbitrary execution. Execution access may remain confined to a small container or restricted account.

    • The relevant resource is therefore the CPU and memory available inside the compromised execution boundary, not automatically the complete specifications of its physical host. Containers, for example, can have enforced CPU and memory limits. [5]

  • What qualifies as a usable node?

    • For the Go-agent workload, a qualifying node must permit:

      • Execution of a compatible program.

      • Background or recurring execution.

      • A permitted local HTTP service and outbound connections for model or tool calls.

      • Sufficient accessible CPU and RAM to sustain the workload.

    • For consistency, assume these conditions remain available for at least 24 hours.

    • “Cron” is shorthand for cron or equivalent scheduling. It does not necessarily mean system-wide installation, administrator privileges or survival across a reboot.

    • Full root or administrator access is not inherently necessary. On conventional Linux systems, ordinary users can execute programs, and user-level cron jobs can be permitted. Restricted accounts and security policies may prevent either capability. [3]

    • Likewise, running an HTTP server does not necessarily make it publicly reachable. A process can listen locally while external firewalls or NAT prevent unsolicited incoming connections. Public reachability and outbound access are separate conditions. [4]

  • The broader hardware population

    • The earlier global inventory used a rough envelope of approximately 25–35 billion connected physical devices, including many embedded devices unsuitable for this workload.

    • A separate hardware model, covering servers, PCs and smartphones, produced an illustrative online inventory of approximately:

      • 30 billion nominal CPU cores.

      • 50 exabytes of RAM.

    • These were back-of-the-envelope assumptions, not a measured global inventory. The core count also mixed processors with very different performance.

    • Those totals provide scale, but they are not inputs that can simply be multiplied by a universal “infectable percentage.” An intermittently active phone, a constrained appliance and a cloud server have very different execution conditions.

    • In particular, ordinary smartphones are not automatically dependable nonstop workers. Android restricts background CPU and networking through mechanisms including Doze and App Standby. [10]

    • The more useful approach is to construct an explicit population of qualifying nodes and assign usable resource budgets to that population.

  • Evidence anchors

    • Two observations from the earlier discussion help establish scale without establishing the vulnerable population.

    • First, the Censys snapshot cited earlier listed approximately 210 million IPv4 host records and 3.8 billion services. These are exposure records, not counts of exploitable physical machines. An IP address, a service and a computing system are different units. [1]

    • Second, Google reported in July 2025 that BadBox 2.0 had compromised more than 10 million uncertified Android-based devices. That demonstrates that a reported compromise population can reach eight figures. However, it involved preinstalled malware and does not establish how many devices were simultaneously available for this workload or accessible through zero-days. [2]

    • Accordingly, the following populations are stress-test assumptions:

    • Assumed qualifying nodes10 million100 million1 billion
      Scenario
      Large compromise
      Broad, severe compromise
      Extreme widespread compromise

    • They are not a confidence interval or probability forecast.

  • Workings

  • 1. Units and accounting rules

    • The calculations use decimal units:

      • 1 GB = 1,000 MB.

      • 1 PB = 1 million GB.

      • 1 EB = 1 billion GB.

    • A reference-core equivalent means the throughput of an assumed reference CPU core on the Go-harness workload.

    • This is not necessarily one cloud vCPU, one hardware thread or one physical core of an arbitrary device. It is a modelling unit.

    • It also does not directly establish language-model performance. Inference throughput is model- and hardware-dependent, so the inference section uses independently stated tokens-per-second assumptions.

    • All resource budgets must be simultaneously realizable. Oversubscribed VM allocations must not be treated as additional physical capacity, and a host’s resources must not be counted again inside each of its VMs.

  • 2. Resource assumptions for the 100-million-node scenario

    • Use the following hypothetical mix:

    • Number of nodesUsable CPU per nodeUsable RAM per node20 million1 core-equivalent2 GB30 million1 core-equivalent2 GB50 million0.05 core-equivalent64 MB100 million
      Node category
      Server/VM execution environments
      Desktops and laptops
      Capable embedded systems and appliances
      Total

    • These are resources available to the workload after system overhead and execution restrictions. They are not assumed whole-machine specifications.

    • “Capable embedded systems” means the subset that meets the execution requirements. It does not include every connected sensor or appliance.

    • The aggregate resources are:

    • Aggregate usable CPUAggregate usable RAM20 million core-equivalents40 PB30 million core-equivalents60 PB2.5 million core-equivalents3.2 PB52.5 million core-equivalents103.2 PB
      Node category
      Server/VM environments
      Desktops and laptops
      Capable embedded systems
      Total

    • The average qualifying node therefore contributes, by assumption:

    • 0.525 CPU-core equivalents and 1.032 GB of usable RAM.

    • Scaling that same hardware mix to 10 million or one billion nodes gives the lower and upper population scenarios. The shared mix is a simplifying assumption, not a prediction that larger compromises would capture the same types of hardware.

  • 3. Go-agent resource requirements

    • An agent here is a logical session inside a shared runtime, not necessarily a separate executable, container or VM.

    • Go supports many lightweight goroutines within one process. However, a goroutine’s small initial stack is not the complete memory requirement of an agent. Conversation state, request buffers, tool results, temporary allocations and garbage collection also matter. [6]

    • Use two unbenchmarked workload profiles:

    • RAM per agentLocal CPU work per 10-second cycleAverage CPU requirement2 MB10 milliseconds0.001 core-equivalent20 MB100 milliseconds0.01 core-equivalent
      Profile
      Ultra-lean orchestration
      Larger working set and more processing

    • The CPU budget includes the session’s share of local processing and runtime overhead. Model inference and substantial tool execution happen elsewhere.

    • These profiles do not establish that a model response can arrive every ten seconds. They specify the assumed local resource consumption if that cycle rate can be supplied.

    • A useful small-server illustration is:

    • 1,000 ultra-lean logical agents × 2 MB = 2 GB of agent memory.

    • 1,000 × 0.001 core-equivalent = one core-equivalent of average CPU demand.

    • That is the resource arithmetic behind the earlier example of roughly 1,000 lightweight sessions on a small 4 GB, 2-vCPU server. Actual performance depends on the CPU allocation, runtime implementation and workload.

  • 4. Calculate orchestration capacity per node

    • For each node:

    • Agent capacity = the smaller of:

    • Usable RAM ÷ RAM per agent

    • and

    • Usable CPU ÷ average CPU requirement per agent.

    • Round down to whole sessions, then sum across nodes.

    • Calculating per node matters: spare RAM on one machine cannot compensate for insufficient RAM on another.

    • Under the ultra-lean profile:

    • Memory-limited capacityCPU-limited capacityAgents per node1,0001,0001,0001,0001,0001,000325032
      Node category
      Server/VM environment
      Desktop/laptop
      Embedded system

    • For the 100-million-node fleet:

    • 50 million server/PC nodes × 1,000 agents = 50 billion agents.

    • 50 million embedded nodes × 32 agents = 1.6 billion agents.

    • Total: 51.6 billion ultra-lean logical agents.

    • Under the larger profile, each server/PC node supports 100 agents, while each embedded node supports three whole agents:

    • 50 million × 100 + 50 million × 3 = 5.15 billion agents.

    • The resulting range is therefore approximately 5–50 billion resident agent sessions for the middle population scenario.

    • This is a CPU/RAM capacity calculation, not evidence that those sessions can all receive sufficient inference or do useful work concurrently.

  • 5. What changes when a node becomes an inference host?

    • An inference host loads model weights and performs the computation needed to generate responses.

    • A GPU is not inherently required. Runtimes such as llama.cpp support CPU inference. Whether that inference is useful depends on model size, available memory, processor capabilities and sustained throughput. [7]

    • For this model, count one inference host as one selected node running one loaded small-model runtime. That is an accounting convention, not a universal limit on model instances per machine.

    • The basic four-bit weight-storage arithmetic is:

    • Weight storage ≈ parameter count × 0.5 bytes.

    • Actual memory consumption is higher because of quantization metadata, runtime buffers and working memory for the conversation, including the KV cache. [7]

    • Illustrative budgets for a short-context session are:

    • Idealized four-bit weights aloneIllustrative total memory budget0.5 GB1–2 GB1.5 GB2.5–4 GB4 GB6–10 GB16 GB20–32 GB35 GB48–64 GB
      Model size
      1 billion parameters
      3 billion parameters
      8 billion parameters
      32 billion parameters
      70 billion parameters

    • These are planning ranges, not universal requirements. Architecture, context length and simultaneous requests can materially change them.

    • Under the existing two-gigabyte resource allowance, only the smallest class is a plausible candidate, and even that requires a suitable implementation and working set.

    • We cannot silently assume that a node allocated two gigabytes now has sixteen gigabytes available because it has been assigned an inference role.

    • The 64 MB embedded category is excluded from hosting the model classes above.

  • 6. CPU-only inference scenarios

    • The middle fleet contains:

    • 20 million server/VM nodes + 30 million PCs = 50 million candidate small-model hosts.

    • Not every candidate will be suitable. Compatibility, memory, sustained availability and processor performance remain additional filters.

    • Use three sensitivity cases within that same 100-million-node fleet:

    • Selected inference hostsShare of the 50-million-node candidate poolAssumed raw generation per host1 million2%1 token/second10 million20%5 tokens/second25 million50%10 tokens/second
      CPU-only scenario
      Limited participation
      Middle illustration
      High participation and speed

    • The generation rates are independent scenario inputs. They have not been benchmarked for the assumed one-core/two-gigabyte allocation.

    • In particular, the high case should not be read as a demonstrated average across heterogeneous machines.

    • The resulting aggregate raw generation capacities are:

    • 1 million × 1 = 1 million tokens/second.

    • 10 million × 5 = 50 million tokens/second.

    • 25 million × 10 = 250 million tokens/second.

    • For an illustrative operating allowance, retain 50% of raw capacity after input processing, unavailable time and headroom:

    • Raw generation capacityCapacity after the assumed 50% allowance1 million tokens/second0.5 million tokens/second50 million tokens/second25 million tokens/second250 million tokens/second125 million tokens/second
      Scenario
      Limited participation
      Middle illustration
      High participation and speed

    • The 50% factor is another modelling assumption, not a measured efficiency. Long inputs, unsuitable hardware or intermittent availability could produce a substantially lower result.

    • Inference is also sensitive to memory bandwidth and the distinction between processing input and generating output. Aggregate throughput does not establish individual response latency. [8]

  • 7. Resource allocation for the CPU inference hosts

    • Reserve the full previously assigned CPU/RAM budget of each selected server/PC node for inference:

    • Assigned CPU budgetAssigned RAM budget1 million reference-core budget units2 PB10 million reference-core budget units20 PB25 million reference-core budget units50 PB
      Selected inference hosts
      1 million
      10 million
      25 million

    • These CPU budget units retain their earlier definition. The separate tokens-per-second assumptions—not the core count alone—determine the modelled inference output.

    • Most importantly, these allocations come from the same underlying resource pool used in the Go-agent calculation.

    • The all-orchestration ceiling and the inference-host allocation cannot both be claimed in full simultaneously.

    • A combined model must subtract the inference allocation from the orchestration pool. That allocation-and-support calculation is separate from the capacity estimates here.

  • 8. GPU inference as a separate sensitivity case

    • The 100-million-node fleet model does not specify a GPU population. Therefore, it cannot establish accessible GPU inference capacity.

    • A separate hypothetical accelerator pool can nevertheless show how sensitive the result is to hardware type.

    • The NVIDIA benchmark cited earlier reported the following aggregate output throughput on one H100, using FP8 models, 5,000 input tokens and 500 output tokens: [9]

    • Reported aggregate output throughput per H100Approximately 3,370 tokens/secondApproximately 203 tokens/second
      Model
      Llama 3.1 8B
      Llama 3.1 70B

    • These are benchmark-specific, batched throughput figures. They are not individual request-generation speeds, and they do not use the four-bit format in the earlier memory-sizing table.

    • For a purely hypothetical accessible pool of 100,000 H100-class accelerators, linear benchmark scaling gives:

    • 100,000 × 3,370 = 337 million tokens/second for the 8B configuration.

    • 100,000 × 203 = 20.3 million tokens/second for the 70B configuration.

    • These are alternative uses of the pool, not simultaneous capacities.

    • Actual operation would require suitable host resources, accelerator access, memory configuration and workload characteristics. The calculation does not establish that 100,000 such accelerators are accessible to an adversary.

    • This sensitivity case is separate from the CPU fleet. If the accelerators sit inside already counted nodes, their associated host resources must not be counted again.

  • 9. Capability is a separate dimension

    • The inference estimates must remain separated by model class.

    • A large volume of small-model tokens is not automatically equivalent to the same volume from a substantially more capable model.

    • Likewise, copying open weights creates a host for that particular model. It does not establish a copy of the originating rogue AI’s capabilities.

    • The meaningful later comparison will therefore involve at least three dimensions:

    • Inference throughput, response latency and task capability.

    • This document does not yet translate the available tokens into supported agent activity. Doing so requires assumptions about model choice, input and output lengths, call frequency, concurrency, successful task completion and resource allocation between hosts and agents.

  • Source notes

  • Conclusion - The Numbers

  • A. Qualifying nodes, accessible compute and Go-agent capacity

    • The first quantity is best labelled “nodes permitting sustained execution”, rather than “number of vulnerable surfaces.” Each qualifying execution environment is counted once, and underlying hardware resources are not double-counted.

    • Using the assumed hardware mix and assigning all usable resources to orchestration:

    • Qualifying nodesUsable CPUUsable RAMLarger-profile Go agentsUltra-lean Go agents10 million5.25 million core-equivalents10.32 PB515 million5.16 billion100 million52.5 million core-equivalents103.2 PB5.15 billion51.6 billion1 billion525 million core-equivalents1.032 EB51.5 billion516 billion
      Compromise scenario
      Large compromise
      Broad, severe compromise
      Extreme widespread compromise

    • The additional digits show the arithmetic of the assumptions, not measurement precision.

    • Rounded, the middle case is:

    • 100 million qualifying nodes → approximately 50 million usable CPU-core equivalents and 100 PB of RAM → approximately 5–50 billion logical Go-agent sessions.

    • That is an orchestration ceiling before reserving resources for inference.

  • B. CPU inference hosts within the 100-million-node case

    • The same middle fleet contains 50 million candidate server/PC nodes with an assumed usable allocation of one core-equivalent and two gigabytes each.

    • The selected inference-host populations are alternative scenarios within that candidate pool:

    • Inference hostsAssigned CPU budgetAssigned RAMRaw output capacityOutput after assumed 50% allowance1 million1 million core-budget units2 PB1 million tokens/second0.5 million tokens/second10 million10 million core-budget units20 PB50 million tokens/second25 million tokens/second25 million25 million core-budget units50 PB250 million tokens/second125 million tokens/second
      CPU inference scenario
      Limited participation
      Middle illustration
      High participation and speed

    • Rounded, the middle CPU-inference case is:

    • 10 million small-model hosts, allocated 10 million core-budget units and 20 PB of RAM → 50 million raw output tokens/second, or 25 million after the illustrative operating allowance.

    • These are small-model capacity assumptions. They do not establish equivalent throughput or capability from larger models.

  • C. Separate GPU-inference sensitivity

    • For an independently assumed pool of 100,000 usable H100-class accelerators:

    • Benchmark-scaled aggregate outputApproximately 337 million tokens/secondApproximately 20 million tokens/second
      Alternative use of the GPU pool
      Serving the cited 8B FP8 workload
      Serving the cited 70B FP8 workload

    • These numbers are before an additional operational derating. They are benchmark extrapolations, not estimates of the number of vulnerable GPUs.

  • Central working assumptions to carry forward

    • Accessible execution population: 100 million qualifying nodes.

    • Total usable resource pool: approximately 50 million CPU-core equivalents and 100 PB of RAM.

    • All-orchestration ceiling: approximately 5–50 billion resident Go-agent sessions.

    • Illustrative CPU-inference allocation: 10 million small-model hosts consuming part of that same resource pool.

    • Illustrative CPU-inference output: 25 million output tokens/second after the assumed operating allowance.

    • Optional GPU sensitivity: 100,000 H100-class accelerators, giving benchmark-scaled output of approximately 337 million tokens/second for the cited 8B workload or 20 million for the cited 70B workload.

    • The unresolved next calculation is how many useful, model-assisted agents those inference resources could sustain after accounting for shared resource allocation, model capability, call frequency, context length and response latency.

  • Website Page