A Large Language Model is a neural network, typically based on the transformer architecture, trained on very large volumes of text data to predict and generate coherent language sequences, enabling tasks such as summarization, translation, question answering, and free-text generation without task-specific retraining for each new use case.

Key Points

An LLM is a large-scale neural network specialized for language tasks — a subtype, not the whole of neural network technology or AI generally.
LLM inference is typically far more compute-intensive than traditional ML or smaller neural network inference, which is why most industrial LLM deployments today rely on centralized cloud serving rather than edge inference.
Query latency (inference latency) for cloud-hosted LLMs depends directly on the round-trip connectivity to the serving infrastructure, making LLM-backed applications sensitive to backhaul quality in remote operating environments.
Smaller, distilled, or quantized LLM variants are increasingly deployed at the edge for constrained-connectivity use cases, trading some capability for reduced latency and independence from continuous connectivity.
Data sensitivity — operational, defense, or proprietary industrial data sent to a third-party LLM API — raises data-sovereignty and network-path considerations distinct from traditional ML deployments.

Concept

LLMs differ from smaller, purpose-built neural networks primarily in scale — parameter counts in the billions, requiring specialized serving infrastructure (typically GPU or accelerator clusters) that is impractical to replicate at most edge sites. This makes the default LLM deployment pattern a client-server one: a field terminal, control room workstation, or mobile app sends a query over the network to a centrally hosted model and receives a generated response. The quality of that experience is bound directly to the connectivity path — round-trip latency, jitter, and available bandwidth all shape whether an LLM-backed application feels responsive. Where connectivity is denied, degraded, or must remain sovereign to a site (as in defense or classified industrial contexts), smaller on-premises or edge-deployed LLM variants become the only viable option, at the cost of reduced model capability.

Explainer

For ConnectedEarth's audience, LLMs are best understood as a new, connectivity-hungry application layer riding on top of existing network infrastructure rather than as a networking technology in themselves. A maritime operations team using an LLM-based assistant to summarize incident reports needs a reliable path back to a cloud-hosted model — a task well suited to VSAT or LEO backhaul with acceptable latency tolerance, since the interaction is not hard-real-time. A defense field unit using a similar assistant under denied-communications conditions cannot rely on that path at all, and must instead carry a smaller, on-device model with degraded capability but zero connectivity dependency. This tension — capability versus connectivity independence — is the central design trade-off ConnectedEarth tracks whenever an LLM is proposed for a remote, contested, or bandwidth-constrained operating environment.