Delivering A.I. Super Compute On The Battlefield
The days of central command and control have ended - super compute at the fight
It has been said politics lies downstream from culture.
Perhaps.
Provably, technology lies downstream from warfare, weaponry, and the need to survive.
The list of mainstream technologies emanating from the need to win a war or protect a nation is endless - some are life-changing as in emergency medicine and wound management.
Since our team is engaged with the type of people whose business it is to win the next war, let’s review some of the approaches technology firms are using - nothing of course in any way classified.
A thesis is emerging - the speed of A.I., the introduction of hypersonic weaponry, drone warfare and a score of other war fighting technologies have made centralized command and control obsolete.
At least centralized command and control is obsolete on the battlefield - it is likely to survive forever in the purchasing department and HR.
It is said generals often fight the last war - endless examples of admirals, generals and presidents applying obsolete tactics or weaponry against a fleet of foot adversary who outruns them easily.
Look back at early World War 2 for the textbook example of the Maginot Line.
Does America have a Maginot Line mentality - we think it may in some circles, the Maginot Line today is centralized computing - supporting centralized command and control.
Centralized computing forms the central nervous system of the centralized command and control attack and response model.
In modern battles, both - centralized computing and centralized command and control - are obsolete.
Centralized computing is ancient in tech terms, starting with the first computers in World War 2.
Centralized computing is the backbone of virtually all computing today - not 100% but what is not centralized is a rounding error.
Even distributed computing and edge computing - are centralized.
What?
Distributed computing today, also called edge, is essentially building a mini data center at the edge - which can be a Walmart store, a shopping mall, a school - and that edge computer collects data and…….
That’s the centralized part.
Edge or current distributed computing uses conventional hardware thus is limited by the speed of such hardware. If you want to do more, add more hardware.
You haven’t really computed anything at the edge – you’ve just built a mini data center that collects data and stuck it out in a field.
The fatal limitation is that “edge” data centers, even micro ones, are utilizing centralized processing just like a conventional data center or a cloud.
So edge computing - from the back room of a Walmart or in a signal drone on a battlefield - must connect to the mother ship - for high performance processing, decisioning, targeting.
Why is that important?
It is important because we are talking to the guys building the weapons systems for the next 40 years - and they are telling us they cannot have centralized points of failure.
Thus no data center, cloud or otherwise - at least not on the battlefield.
Compute is different when you move from billing, CRM and social media stuff, whose data is tiny, albeit expensive and needs lots of hardware, to applications war fighters are building.
Here are the emerging requirements - nothing classified - we want to distill them for you.
Battlefields need computing capabilities CRM systems do not have.
Among them are:
No central point of control (cloud).
No central point of failure (it’s not the same thing as control) (Still the cloud or data center).
Ability to ingest immense amounts of IoT (sensor, meter, camera, satellite) data - Integrate it, process it, decision it - at quantum speed - during a fight.
Close to infinite scalability - at least scalable enough to handle trillions of real time transactions without degradation.
Communication among hundreds of thousands of entities (devices, drones, weapons, processors) with limited to close to non-existent bandwidth, often intermittent bandwidth.
Quantum speed, on ANY current hardware, in battlefield conditions.
A.I. models, created and run, on the battlefield, from battlefield data collected during the fight - at quantum speed on current hardware.
These capabilities have one characteristic war fighters cannot ignore - NONE can be delivered with conventional centralized, data center architecture.
The underlying reason is speed.
Current computer software technology is painfully slow - when compared with viable alternatives like quantum speed software - on current hardware - which Fractal delivers to the battlefield.
Slow is fatal in a fight. Latency is worse.
When a compute platform - a server, drone, device, chip, satellite, sensor - collects data and that data must go to a cloud - not anywhere near a battlefield - latency is inherent.
Latency kills.
Latency with intermittent communication is worse. We are going to come back to the communication thing in a bit.
The fight models Fractal covers in its ever increasing early morning presentations are drone SWARM and MESH applications.
They have much in common - and neither can be delivered - at scale - with conventional technology.
Both are, in their DNA, weapons systems which defy centralized command and control at scale.
You can have centralized command and control for those drone babies the size of airplanes, but you suffer the loss of scale.
You cannot have centralized command and control for 10,000 one hundred dollar drones, operating as a flock of birds - with centralized control.
Distributed is the key, and not just any distributed architecture will work
That is the single most significant finding Fractal’s engineers made - distributed is absolutely necessary - but not all distributed technologies can scale at the edge.
Let’s go to SWARM and MESH - both of which are explained in detail on TheSustainableComputingInitiative.com site.
For the sake of this article, we are defining SWARM and MESH as kind of opposites.
SWARM is the MOSAIC thing - making 10,000 drones, each costing $100 bucks, operate as a flock of birds - no central point of control - shoot down almost every one of them - the drones, not the birds - and the last one can still operate independently.
This SWARM can attack a target from N directions and adapt on the fly to that target’s response. Since the target is probably using conventional technology with a cloud - the SWARM destroys it on latency response alone.
The MESH concept is different - but with the same underlying tech.
You need to pay attention to this MESH thing.
Those 10,000 drones, or even a thousand of them - can instantly intelligently aggregate their compute resources - INTO AN INTELLIGENT, COMPUTING MESH - under battlefield conditions - and become a super computer - larger than many clouds - with almost zero latency - right in the fight.
So who needs a super computer in a fire fight?
You bought in on all that stuff about the world needing LLMs for A.I. with no questions.
So maybe, on a battlefield - with $40 million jet fighters overhead, soldiers with sensors in their backpacks, guided munitions, drones from both combatants flying around - perhaps it might be handy to be able to run the LLM equivalent - aggregated small language A.I. models, in seconds, with all that real time information ingested - used to optimally target an opponent - that opponent, the one in front of you - trying to kill you.
Thus the question - how do you deliver A.I. in a fight?
For sure it is not with a data center 8,000 miles away - if one can be MESHED on the battlefield - instantly - and is totally survivable.
No cell calls to ChatGPT.
MESH is a big deal – for example, Apple could take every Apple device in the Department of Health and Human Services, and with permission turn iPhones, laptops, tablets, Apple Studios - into a computing MESH which would enable Robert Kennedy to close a data center and save that energy.
It’s an idea that cannot be stopped - every time we show it to war fighters, the ability to deliver a super computer, with no additional hardware, no central point of control, no latency, not central point of failure - on the battlefield to bring A.I to the fight - they get it.
The Fractal team believes there are significant commercial applications for the MESH and SWARM technology - like making a $100 Raspberry Pi a super computer - placed in every UPS or Fedex truck, put a Fractal on every driver’s phone - and instantly any of those companies would have a super computer at Google scale - almost for free.
They would also be able to track every item in their entire supply chain - anywhere in the world.
Try to do that with the incumbent IT providers.
Back to the military stuff, this part is important because this newsletter is about disruption, and you are only going to read disruption stuff here - the Wall Street Journal will tell you to build data centers on the battlefield and Gartner will tell the guys ducking incoming to wait for quantum hardware.
Let’s review limitations which cannot be overcome - which can only prevail if there is NO ALTERNATIVE.
The ALTERNATIVE concept is key to disruption.
Today, war fighters, and we talk with a lot of them - came up the way we all did - big data centers, Oracle databases, VMware, security patches - so the issue is how to fight the next war with what we have - the relational stack.
Some do not know there is an alternative.
Like we tell you all the time, we are not the only guys minimizing I/O wait states in systems - but we have the best Substack - so keep sending it to your friends - our subscriber base is exploding.
Some Chinese companies are swinging at it too - because they know the next fight - which they might be in - will need VIRTUAL A.I. data centers on the battlefield.
You must be able to manage drones, not 25 but 25,000 or 100,000 as if they were a flock of birds.
Currently, drone guys are using conventional technology and smalling it - making it small enough to put on a board inside a drone.
You can make your conventional stuff small, but the constraint comes when you have to communicate among 25,000 devices - the communication hurdles are not to be overcome - at least not to allow them to SWARM.
Nobody can do it for more than a dozen drones - because we know the limitations of conventional software. We are getting near the NDA stuff so let’s move on.
That takes us to another key capability - which is Sine Qua Non stuff (like you gotta have it) for both MESH and SWARM - integrating massive amounts of data, from different sources, storing it, presenting it to A.I. models, and decisioning it - UNDER FIRE.
This is a very big deal and we invite any of you to try this with current database technology.
We know a bunch of hot, wildly overvalued startups in the war fighter space are unable to solve these issues - because they are stuck on conventional technology applied to an unconventional challenge.
Low I/O wait state technology has derivative benefits - the kind that come with the technology but you cannot see them, you can only experience them. One of these is real time ETL.
You tech guys know ETL is taking data in different formats, transforming it so it plays well together and loading it up for a program to use. You also know current ETL tech ain’t real time or close to it.
So here’s the battlefield problem:
War fighters need to use A.I. on the battlefield.
Optimize targeting, react to multiple possible outcomes, determine the best force distribution to repel an attacker - these and hundreds of never-thought-of-challenges need to be modeled and delivered to command instantly - or pretty close to it.
We will skip the A.I. part here since we covered it in other posts, but let’s get into the data collection part which makes A.I. possible.
Today, almost everything on the battlefield is instrumented - or will be pretty soon.
So every moving thing has an opinion - and it is streaming real time data somewhere.
Jet fighters, drones, targeting systems, satellites deliver phenomenal amounts of data - in photos, digital stuff, mapping - which need to be collected, aggregated, made to work together, put into models under fire, presenting alternatives to command.
Does anyone think this data is going into an Oracle Cluster - decisioned - and sent to the field commander in time to make a difference?
Low I/O wait state technology, due to its underlying architecture is wildly scalable and it’s ETL capabilities are purpose-built for data aggregation, under pressure, delivering almost instantaneous decisioning for A.I. in the field.
The problem is nobody can see it - ETL - merging all this data instantaneously - with almost infinite scalability - it can only be experienced.
More of our war fighter friends are coming to the realization that even with quantum speed on current hardware, the data collection - merging - the decisioning problem remains the Achilles Heel - and early tests show conventional technology cannot possibly address the challenge.
So making conventional tech smaller and sticking it on a drone is great for a couple of drones - but for the flock - never going to happen.
So the question becomes, do America’s war fighters and planners and techs continue to try to adapt 1980s technology - central command and control, central Oracle and Palantir data centers to problems they were never designed for, or do they apply truly distributed technology to distributed problems?
An easy comparison is centralized command and control = data center, cloud model - should be replaced by distributed computing.
Unfortunately, it’s not that easy, as some of our war fighter friends - and those high tech startups - learned - distributed comes in at least two flavors, and one of them is severely limited - to the point of failure.
This is one of the core defense problems EVERY country’s defense teams are wrestling with.
The general model of distributed computing for the last 40 years is “sort of distributed” not truly distributed - so it will not work on the battlefield challenges we discussed here.
“Sort of distributed” generally means that database access might be distributed but application functionality remains (mostly) back at a centralized point.
Fractals are fully distributed.
Every Fractal has the entire application that every other Fractal in that domain has – there is no centralized application or centralized application server.
The Fractal on a Raspberry Pi, the one in the jet fighter, the several on backpacks, the ones on each of the 10,000 drones - every Fractal has a full featured application embedded in it and it does not have to fall back to a centralized point to make decisions.
That means every Fractal in a battlefield domain is identical. It has inherent in its slender tech stack, vast wisdom on how data - specific to its domain - operates.
Fractals only differ in the data each manages. Here we could go really deep but it would not add to the story.
Because each Fractal contains the entire application, that application must be tiny - part of the innovation of Fractal was figuring out how to shrink the size of big-boy enterprise applications to a footprint small enough to load into edge compute platforms. It took decades of experimentation to develop the equivalent of Reduced Instruction Set Computing for enterprise applications – and this is at the core of the Fractal software stack.
Tiny = simple. Simple = scalable. Scalable = you can handle 25,000 drones to 250,000 drones as if they were a flock of birds.
Since every Fractal is tiny, and every Fractal is identical, but for its data, you can kill thousands of Fractal instances, you can kill hundreds of thousands of Fractal instances -- and as long as a single Fractal instance survives, it can be used to recreate the entire system.
That’s a pretty cool little feature in a fight. Survivability.
Conventional distributed computing is not scalable - as more of the DoD, now the DOW types are discovering.
In our demonstrations and early morning Zoomers, our engineers are showing how to solve the problem of making a flock of birds - drones, a weapon no current technology can protect against.
The key is obsessive simplicity of design - no feature sharing - yielding quantum speed on current hardware and delivering A.I. on the battlefield - with a huge super computer data center - which is VIRTUAL - it’s in the MESH.
These drone things are not just flying around, they are also under water and those have even more “interesting” communication challenges - which Fractal is conveniently demonstrating are NOT insurmountable.
War fighters and their technical staffs are concluding the next war is 100% distributed and the best distributed software brings VIRTUAL A.I. SUPER COMPUTE to the battlefield.
Super compute, in the fight - makes everything else work - drones, A.I., and instantaneous targeted response.
Fractal is pleased to be bringing it to our war fighters and the companies who build their weapons.
Subscribe at FractalComputing.Substack.com
Fractal Website: Fractal-Computing.com
Fractal Utility Site: TheFractalUtility.com
Fractal Government Site: TheFractalGovernment.com
Fractal Sustainable Computing: TheSustainableComputinginitiative.com
@FractalCompute
Portions of our revenue are given to animal rescue charities.
This technology is a national security asset. It should be appropriately guarded.