The hardest problem in tactical AI isn't the model. It's the building.
A modern frontier model serves fine from a Tier-III data center in Northern Virginia, with a 10 ms round trip to Capitol Hill. Take that same model and deploy it to a Forward Operating Base 14 time zones away over a contested microwave link, and you get nothing back. Not a slow answer. None. The link drops, the prompt times out, and the operator who was about to use generative inference to triage a contact report goes back to a paper notebook.
People want to treat that as a software bug. It isn't. The model worked yesterday in the lab. The failure is in the infrastructure, and infrastructure is harder to fix than code, because you can't push a hotfix to a steel container sitting in a desert.
For the last decade the defense community has poured money into cloud-first architectures. Joint Warfighting Cloud Capability, the Mission Partner Environment, the Combined Joint All-Domain Command and Control roadmap. All of that matters. But every one of those programs assumes something the operational reality keeps contradicting, which is that a usable network exists between the warfighter and the data center. In DDIL environments (Disconnected, Denied, Intermittent, Limited) that assumption falls apart. And DDIL isn't some rare edge case anymore. It's becoming the median.
So here's the question worth asking. What does compute look like when you can't rely on the link back?
The "tactical edge" lie
The phrase "edge AI" has been worn down to mean almost nothing. In commercial markets it usually means a Raspberry Pi running a tiny vision model inside a security camera. None of that helps a Combined Forces Land Component Commander. The CFLCC needs a model big enough to do real planning, available enough to be trusted in a fight, and tough enough that an artillery round in the next valley doesn't silence half a brigade's analytic capability.
The options on the table today are all unsatisfying:
-
Pull the model down to a laptop. A 7-billion-parameter model on a hardened laptop is a parlor trick. Fine for spell-check. Useless for serious planning.
-
Push compute up to the JWCC region. Excellent capacity, as long as the network holds. The network is the part that fails.
-
Build a fixed forward data center. This is what MILCON has historically meant. It runs $40-200 million, takes three to seven years, needs a Status of Forces Agreement, and vanishes the moment the front line moves.
None of those covers the middle ground. What's missing is a transportable facility. A building that arrives by C-17 or HET, plugs into whatever 480 VAC three-phase you can scrounge, and starts serving a real frontier-class workload to soldiers within hours.
Hostile-edge infrastructure as a category
I've started thinking about this as hostile-edge infrastructure, and the constraints that define it are unsentimental:
-
Thermal. Modern accelerators throw off heat at densities 19-inch rack air cooling simply can't keep up with. A single H100 server dumps 700 watts of rejected heat in under a cubic foot. An eight-GPU node is a 5-kilowatt space heater. In a Saudi summer at 50 °C ambient, air-cooled approaches just fail.
-
Logistical. A 40-foot ISO container won't move from a port to a forward area on the roads that actually exist out there. A 10-foot footprint will. Mass matters too. Anything over 60,000 lbs starts losing road and rail mobility.
-
Power. You won't get clean utility power. On a bad day you get a B-1 generator; on a good day, local 380-volt 50-Hz. The unit has to auto-range and ride out brownouts that would trip a commercial colocation.
-
Adversarial. EMP, RF jamming, kinetic effects, supply-chain compromise. These are real threats, not corner cases, and the mechanical and electrical design has to treat them as part of the operating environment rather than anomalies.
-
Disconnected. The model has to stay useful when the satellite link is gone. Which means the whole thing (weights, embeddings, tools, fine-tuning data) lives on the metal in the box.
Every one of these has a known answer on its own. The trouble is that the answers fight each other. More thermal capacity adds mass, which costs you mobility. EMP shielding degrades power efficiency. Pre-loading full model weights blows up your storage and key-management complexity.
A real hostile-edge platform has to compose a non-obvious set of compromises across all of those axes at once. You don't ruggedize a server to get there. You re-engineer a building around the AI workload.
Why immersion cooling, not air
Thermal management is the biggest single design choice in this space. The mainstream answer in commercial AI clouds is direct-to-chip liquid cooling: cold plates on the hot components, row-level CDUs, chilled-water plant outside the data hall. It works at scale. It doesn't work in a transportable box.
Two-phase immersion cooling does. The principle is dead simple. You dunk the entire compute node in a dielectric fluid whose boiling point sits above the GPU's idle temperature but below its thermal-throttle threshold. As the silicon heats up, it boils the fluid right there at the surface. The vapor rises, condenses on a heat exchanger overhead, and falls back as liquid. Heat-of-vaporization moves roughly 25 times the energy per kilogram that air does at the same temperature delta.
Two things fall out of that math. You can dissipate around 250 kW from a single 10-foot container with a passive secondary loop. And you can do it with no spinning fans, so dust never enters the compute chamber, so MTBF in a desert jumps by an order of magnitude over anything forced-air.
The trade is fluid mass and supplier discipline. Engineered Coolant 130 (EC-130 in NATO parlance, or 3M Novec 7100/7200 derivatives on the commercial side) is no commodity. You can't pull it off a Saudi Aramco shelf. So the platform has to be engineered around fluid-loss tolerance and a known-good replenishment supply chain.
What the model can't be: a 13-billion-parameter compromise
There's always a temptation to size the model down so it fits the box. Resist it. A frontier model serving an O-6 in the field needs to be roughly as capable as the frontier model serving an O-6 back in the rear. Otherwise the field user notices the regression inside fifteen minutes and stops trusting the tool.
This is the harder constraint, and it cascades. It forces the platform to host a 70-billion-parameter or larger model in a container that still fits the C-17. It forces the developer to take two-phase immersion seriously instead of as a slide-deck adjective. It forces the integrator to ship full weights, not inference-time downloads.
It also raises a question nobody likes. What if the right answer isn't LLM-as-a-service from the cloud, but model-as-an-equipment-item, accountable to the same property-book discipline as a radio or a generator? Framed that way, the AI compute platform stops being a cloud service. It becomes a piece of equipment with a National Stock Number, a planned maintenance schedule, and an organic O-level support concept.
Most of the friction in DoD AI procurement today comes from trying to buy AI like a service when the operational requirement is a piece of equipment. The contract vehicles don't match. The accreditation pathways don't match. The training pipelines for the soldiers who have to run the thing don't match either. Infrastructure type matters because it dictates every one of those downstream choices.
The next twelve months
Three things have to happen in 2026 if hostile-edge AI is going to graduate from PowerPoint to property book.
First, an authoritative reference architecture for transportable AI compute has to exist. Not vendor-specific, not classified, not aspirational. Something built like the way Tactical Operations Centers are described in field manuals: a known set of tradeoffs, documented in unclassified channels, that any integrator can build to.
Second, the accreditation pathway has to shorten. The current ATO timeline for a forward-deployed AI capability runs 18-30 months. GPU silicon goes obsolete on a 36-month cycle. Either the ATO process gets faster, or the field is stuck with two-generation-old hardware permanently. There's reform underway here. It has to accelerate.
Third, the operational concept has to be named and trained. "AI at the edge" is not a doctrine. It's a marketing line. Combat developers need to write down which units field these systems, who operates them, what those operators are responsible for, and what happens when the link to the rear comes back. That doctrinal work barely exists today.
The compute can go to the warfighter. The physics works. The engineering is hard but tractable. The institutional work is what's actually hard, and it comes down to convincing a force that grew up cloud-first to also be ready when the cloud isn't there.
The alternative is pretending the link will always be up, and that isn't a strategy. It's a wish.