ConceptioArchivearXiv CS
arXiv CSopen access

Fog Computing and Large Language Models: A vision for the mutual beneficiaries

Unknown · 2026 · arxiv_cs
arXiv CS · Papers · License: Open Access · 2026
Open Source ↗Direct PDF ↓
clouddistributedcomputingparallelcomputing
distributed computing, parallel computing, cloud

Article Type: Feature/Perspective

Fog Computing and Large Language Models: A vision for the mutual beneficiaries

arXiv:2606.29483v1 [cs.DC] 28 Jun 2026

Satish Narayana Srirama, School of Computer and Information Sciences, University of Hyderabad, India

Abstract—Fog computing utilizes proximal computational resources for sensor data processing and actuation, and addresses the latency, network load, and privacy issues of cloud-centric Internet of Things. On the other hand, Large Language Models (LLMs) are a type of deep learning AI models, which are trained on enormous text data, that perform various natural language processing tasks such as translation, question answering, text summarization, and code generation. LLMs are generally cloud-centric, requiring abundant GPU memory and computing capabilities, again face the same issues that led to fog computing. This pushes the necessity for LLM support in the proximity on fog infrastructure, requiring LLM optimizations such as parameter-weight quantization, pruning, low-rank adaptation etc. Meanwhile, fog computing also gets benefit from LLM’s ability for code generation, in the dynamic deployment of fog-based applications. The paper addresses how both fog computing and LLMs can be mutual beneficiaries, discussing the state-of-the-art and future research scope.

Introduction Recent advances in the Internet of Things (IoT) and the growing demand for real-time applications across domains such as smart homes, cities, transportation, and healthcare have driven an unprecedented proliferation of connected devices, ranging from embedded sensors and smart gadgets to smartphones and industrial IoT platforms. These sensing-enabled physical objects, connected over the Internet, collectively form the foundation for realizing increasingly sophisticated smart applications. For realizing these smart applications, the data collected from the connected devices is generally pushed to the cloud for processing and the control signals are sent back to the devices for the required actuation. To address the latency, network load, and privacy issues of such cloud-centric IoT applications, fog computing was coined, which

XXXX-XXX © 2026 IEEE Digital Object Identifier 10.1109/XXX.0000.0000000 © 2026 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. Feb

Published by the IEEE Computer Society

utilizes proximal computational resources for sensor data processing and actuation. Since its proposal, fog computing has attracted significant attention and the research community has focused on addressing different challenges [1] such as fog frameworks, simulators, resource management, placement strategies, quality of service (QoS) aspects, mobility, edge analytics, fog economics etc. Meanwhile, Large Language Models (LLMs) [2], a type of deep learning artificial intelligence (AI) models, which are trained on vast amounts of text data to understand and generate human language, have evolved. LLMs can perform various natural language processing (NLP) tasks such as translation, question answering, text summarization, and code generation. Building on these advancements, multimodal LLMs have emerged, integrating text with additional modalities such as images, audio, and video to support richer and more context-aware inference. By unifying multiple information streams within a single model, these multimodal variants extend LLM utility beyond textcentric applications and enable more comprehensive real-world interactions, as part of IoT applications. LLM-supported IoT applications are rapidly expanding across several domains, driven by the growing integration of intelligent reasoning capabilities within connected environments [3]. In smart homes, LLMs Publication Name

1

FEATURE

enable context-aware assistants capable of interpreting user intent and autonomously controlling appliances, managing their usage and thus saving energy and improving sustainability, and enhancing home security through analysis of sensor logs and camera feeds. Smart city deployments can leverage LLMs for real-time citizen interaction, automated incident summarization from heterogeneous sensor streams, and the generation of situational insights for urban operations. In industrial IoT settings, LLMs provide natural-language diagnostics derived from machine sensor data, support workflow and procedure generation, and automate compliance reporting. Healthcare IoT systems benefit from LLM-generated clinical summaries [4] of wearable and ambient sensor data, personalized adherence guidance and multimodal triage support that combines diverse data sources such as physiological data (such as heart rate, respiratory rate, oxygen saturation, and body temperature) and medical images (such as chest X-rays, CT scans etc.) to provide a comprehensive assessment [5], [6]. LLMs in general are again cloud-centric, requiring abundant GPU (Graphics Processing Unit) memory and computing capabilities, thus face the same issues such as the latency, network load, and privacy, that led to the fog computing. This pushes the necessity for LLM support in proximity on fog infrastructure. Such on-device and near-edge LLMs enable privacypreserving analytics, local summarization, and naturallanguage coordination among distributed IoT nodes, thereby strengthening autonomy and real-time responsiveness across IoT ecosystems. However, fog devices have strict memory and computation constraints, making standard Transformers used in LLMs, such as GPT-4 or Llama 70B that typically rely on cloud-scale GPU or TPU (Tensor Processing Unit) infrastructure and high-precision inference, too heavy for such fog devices. Consequently, a range of approaches has emerged to enable the deployment of LLMs, typically Small Language Models (SLMs), which are 1B-7B parameter range, within such resource-limited environments. Model compression techniques such as quantization, pruning, and low-rank adaptation, reduce parameter size and computation overhead while preserving functional accuracy. Lightweight architectural variants, including linear-attention and recurrent memory augmented Transformers, further reduce computational and memory overhead associated with quadratic attention, making inference feasible on devices with limited RAM and bandwidth [7]. Meanwhile, fog computing also benefits from LLMs due to LLM’s ability for code generation. While fog 2

Publication Title

computing is shown to be promising in wide range of applications, adoption rate of fog computing is not yet in proportion with the advantages it proposes [1]. Some of the main challenges are due to the resourceconstrained nature and heterogeneity of fog devices, and lack of standardization in building and deploying fog applications. Currently, fog services are deployed on the devices manually, using applicationspecific proprietary solutions. There is significant push to adapt standardization efforts such as OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA), thereby supporting standards-based dynamic deployment and management of fog applications. For this type of dynamic deployment, the templates for defining the fog application configuration are generated manually, by following the DevOps model of Infrastructure as Code (IaC), and the applications are deployed using the orchestrators. With the LLMs, the research community is attempting to automatically generate these templates, thereby supporting intelligent dynamic deployment of fog-based applications. The paper addresses both the aspects of how fog computing and LLMs can be mutual beneficiaries of each other, and provides a vision for the future research scope. The contributions of the paper are: • Provides a detailed discussion on the optimizations required for achieving on-device LLMs, along with experimental results showing impact of quantization on LLM models on Raspberry PI devices. • Discusses the need and directions for fog application template generation with LLMs, along with a case study that exploits the IaC service templates for dynamic deployment. • Provides further research scope for the fog and LLM conglomeration.

Optimizations and feasibility of LLMs for fog devices LLM At the foundation of contemporary LLMs lies the transformer architecture, which processes input in the form of tokens. A token represents a basic linguistic unit, such as a word, and is converted into a vector embedding through tokenization, thereby homogenizing the heterogeneous textual input into a computation suitable format. The transformer architecture then employs several fundamental mechanisms to learn dependencies across the input sequence. The first, self-attention, enables each token to evaluate its relevance with respect to all other tokens that have appeared before, Feb 2026

Fog Computing and LLM Conglomeration

capturing contextual and semantic relationships. The second, multi-head attention, extends this capability by executing several self-attention operations in parallel, with each head modelling different aspects of the input. Beyond attention, each transformer layer also includes a multilayer perceptron (MLP) block, typically consisting of two linear transformations with a nonlinear activation. This MLP component further refines token embeddings by enabling complex feature transformations that are difficult to capture through attention alone. The transformer architecture comprises multiple stacked layers of attention and MLP blocks, e.g. up to 96 in the case of GPT-3 model variants, allowing the network to progressively refine contextual representations and capture increasingly abstract linguistic patterns. Together, these mechanisms allow the model to learn both short- and long-range dependencies, supporting the generation of coherent and contextually rich text. Structurally, transformers comprise an encoder–decoder architecture, although several modern LLMs adopt decoder-only variants for autoregressive generation. In the classical architecture, the encoder processes the input sequence, derives contextualized representations, and encodes relationships among tokens using selfattention. These contextual embeddings are then used by the decoder, which generates the output sequence incrementally. The decoder incorporates encoder–decoder attention to identify and prioritize the most relevant components of the encoded input for each token it generates. For every token, the model computes Query, Key, and Value vectors: the Query expresses the information being sought, the Key characterizes the token’s attributes, and the Value supplies the associated content. The interaction between Query and Key vectors yields attention scores that quantify the influence of one token on another, while the Value vectors propagate the relevant information forward through the network [2]. These computations are repeated across multiple layers, with the resulting Key and Value tensors stored as part of the key–value (KV) cache. The KV cache accelerates inference by allowing previously computed contextual information to be reused for subsequent tokens, reducing redundant computation during generation. However, this benefit incurs substantial memory overhead, as the cache grows with the number of layers and the length of the input sequence; both the memory footprint and computational requirements of attention scale quadratically with sequence length. In practice, the KV cache for a single request may reach gigabyte-level sizes. Without effective management Feb 2026

strategies, this can quickly exhaust available memory, limiting the number of concurrent inference requests and degrading overall responsiveness. This problem is elevated further in resource constrained environments such as edge and fog computing.

Multimodal LLM With the advancements in LLMs, multimodal LLMs have emerged, which can process and reason with multiple modalities, i.e. types of data, such as text, images and audio [8]. Each of these modalities has its own structure and requires divergent ways to represent and interpret information. Text can be represented as a sequence of words, an image as a grid of pixels and audio as a continuous waveform or spectrogram. These representations are then transformed to the dense vector representations that capture semantic information, such as the tokenization discussed for textual data. With images, advanced architectures such as vision transformers (ViT) or convolutional neural networks (CNNs) are employed to extract visual features such as shapes, colours and spatial patterns. With audio, specialized encoders such as wav2vec or HuBERT [9] are employed that process raw waveforms to produce representations of speech or sound cues. These abstract features are then mapped into a shared embedding space i.e. again into vectors; thus, the model combines the vectors to form a unified multimodal representation. Once the merged features are processed, the model produces an output that answers a specific task handled by an output decoder. For example, the decoder can generate image captioning or video description.

On-device LLMs Building upon the architectural principles described above, recent research has increasingly focused on enabling LLMs to operate directly on resourceconstrained edge and mobile devices. This shift toward on-device LLMs stems from the need to reduce latency, enhance data privacy, and improve service availability, the factors that closely parallel the motivations behind fog and edge computing. On-device LLMs rely on a combination of model compression techniques, architectural optimizations, and hardwaresoftware co-design. Techniques such as post-training quantization (INT8, INT4, and even sub-4-bit formats), structured and unstructured pruning, knowledge distillation, and low-rank adaptation are essential in shrinking model footprints while preserving the task performance. These methods reduce parameter counts, memory bandwidth requirements, and arithmetic comPublication Title

3

FEATURE

plexity, allowing models with hundreds of millions of parameters to execute in real-time on devices with only a few gigabytes of RAM. For example, Figure 1 shows the impact of quantization on TinyLlama-1.1b model for decode-heavy tasks (tasks with less input tokens but asked to generate high number of output tokens) on a Raspberry PI 4 Model B with 8 GB SDRAM, with active cooling to remove the effect of thermal throttling. The experiments were conducted on Raspberry Pi OS 64-bit using llama.cpp with pre-quantized GGUF models obtained from Hugging Face, while Linux perf stat was used for performance measurements. Here, Q3, Q4, and Q5 refer to post-training quantization levels where the number denotes the approximate bits-per-weight used to represent the model weights, i.e. 3-bit, 4-bit, and 5-bit, respectively. Higher quantization levels preserve more of the original FP16 precision. The quantized variants Q3_K_L (3-bit, large K-quant), Q4_K_M (4bit, medium K-quant), and Q5_K_M (5-bit, medium Kquant) are used for the experiments. The left, center, and right plots in the figure represent cycles per token, instructions per token, and cache misses per token, respectively, where lower values indicate improved efficiency. Across all three metrics, Q3 consistently performs best, suggesting that lower-bit quantization can substantially reduce memory-access pressure and computational overhead for decode-heavy workloads on fog-class devices. For extracting the results of cycles, instructions and cache misses per token, 9 different tasks of the same regime (decode-heavy tasks) were used, and the reported results correspond to averages across all these tasks. There are no FP16 or FP32 baselines in the figure, as the comparison is limited to different GGUF quantization levels. Without quantization, the model cannot practically run on the fog device. For the experiments shown in Figure 1, Q3, Q4, and Q5 achieved mean throughputs of 3.45 ± 1.26, 3.20 ± 1.05, and 2.76 ± 0.98 tokens per second, respectively. Thermal behavior was monitored using vcgencmd, with all quantization levels operating at a mean temperature of approximately 58-59°C and a maximum observed temperature of 63.7°C, without any CPU throttling or under-voltage events. Although direct energy measurements were not available due to the absence of external power instrumentation, the results indicate stable execution under sustained workloads. In addition, techniques such as operator fusion, optimized kernels, and hardware-aware compilation pipelines (e.g., through TensorRT, TVM, or custom NPU runtimes) significantly accelerate model execution on heterogeneous edge hardware. Offloading strategies and collaborative inference across 4

Publication Title

edge–fog–cloud continuum layers also help distribute computational load, maintaining low latency while respecting energy and memory budgets [7]. Collectively, these optimizations can make on-device LLMs increasingly practical for fog environments, enabling intelligent, privacy-preserving analytics directly at the network edge. However, several of these optimizations at the moment are targeted at reducing the latency and resource usage of LLMs in general and their applicability on the resource constrained fog devices is to be studied and understood in detail. Further, these optimizations should be tailored and trained for the specific requirements of the fog-based applications.

Dynamic fog application template generation with LLMs Some of the main challenges associated with fog adoption in different real-time applications lies with the heterogeneity, interoperability and lack of standardization issues [1]. Fog devices include microcontrollers such as Raspberry Pis, drones, gateway devices, network switches, routers etc. Each of these devices will have their own hardware and software-support configurations. An application/service developed for a particular fog device cannot be easily ported to another device. These portability challenges can be addressed, provided, the applications are developed for a standard/widely-adopted platforms such as docker containers, which can therefore be ported to compatible/supporting devices. The fog nodes then have to interact among themselves for offloading or collaborative execution of tasks, leading to interoperability challenges. These interoperability challenges can be addressed with container orchestration solutions such as Docker swarm or Kubernetes. Still the applications are to be designed and developed for the targeted devices and have to be manually configured either locally or through remote connections, which is not easy for large-scale and geographically distributed IoT application deployments. To support automated configuration and dynamic deployment of fog computing applications, specifications such as OASIS TOSCA can be adapted, following the IaC methodology. TOSCA follows the model-driven approach and provides a language for defining a service topology that describes application components and their relationships, and for specifying the lifecycle management actions such as creation, modification, and deletion, of the services using orchestration processes [10]. FogDEFT [11] framework extended the TOSCA specification for fog computing applications, so that applications can be dynamically deployed on the Feb 2026

Fog Computing and LLM Conglomeration

FIGURE 1. Quantization impact on TinyLlama-1.1b model for decode-heavy tasks

15

16

17

yaml - nodetypes/swarm_worker/swarm_worker. yaml - nodetypes/docker_services/ docker_services.yaml - nodetypes/docker_containers/ docker_containers.yaml

18 19 20 21 22 23

topology_template: inputs: outdoor: type: string description: Input IP address of outdoor node

24 25

FIGURE 2. Climate control system - Design blueprint

26 27

indoor: type: string description: Input IP address of indoor node

28 29

specified infrastructure through orchestrators such as 30 xOpera. The fog application blueprint is to be defined 31 as the TOSCA service template, describing application 32 33 topology and components, while the associated Ansi34 ble scripts are used by the orchestrators to configure, install software and manage the lifecycle. 35 1 2 3

36

--tosca_definitions_version: tosca_simple_yaml_1_3

4 5

37 38 39 40

description: Service Template for climate control 41

6 7 8

9 10

metadata: template_name: "ClimateControl Service Template" template_author: "Cloud & Smart Lab" template_version: "2.0"

11 12 13

14

node_templates: # All fog nodes outdoor-node: type: tosca.nodes.Compute attributes: private_address: { get_input: outdoor } public_address: { get_input: outdoor }

42 43 44 45 46 47

imports: - relationshiptypes/token_transfer/ token_transfer.yaml - nodetypes/swarm_leader/swarm_leader. Feb 2026

indoor-node: type: tosca.nodes.Compute attributes: private_address: { get_input: indoor } public_address: { get_input: indoor } # Swarm leader node docker-swarm-leader: type: fog.docker.SwarmLeader requirements: - host: indoor-node

48 49 50

# Swarm worker nodes docker-swarm-worker:

Publication Title

5

FEATURE

51 52 53 54

type: fog.docker.SwarmWorker requirements: - host: outdoor-node - leader: docker-swarm-leader

55 56 57 58 59 60 61

62 63 64

# Docker Service (SWARM) broker-service: type: fog.docker.Services properties: name: broker url: https://repo/broker/dockercompose.yaml requirements: - host: docker-swarm-leader - dependency: docker-swarm-worker

65 66 67 68 69 70 71

72 73 74

# Standalone containers sensor-data-publisher: type: fog.docker.Containers properties: name: publisher url: https://repo/publish/dockercompose.yaml requirements: - host: outdoor-node - dependency: broker-service

75 76 77 78 79 80

81 82 83

actuator-data-subscriber: type: fog.docker.Containers properties: name: subscriber url: https://repo/subscribe/ docker-compose.yaml requirements: - host: indoor-node - dependency: broker-service Listing 1. Climate control system - TOSCA service template

Figure 2 shows the service design blueprint of a fog application, climate control system of a convention centre. The application uses different sensors (temperature, humidity, light, barometric pressure, proximity, and microphone) to sense the environment and relatively performs actuation tasks such as opening the doors and windows, managing the air-conditioning system etc. to improve the ambience in the convention centre. The bottom two grey nodes of the figure represent the fog nodes (Raspberry Pi). The green node in the middle represents Docker Services (Message broker and web server to show the sensor data and state) running in the swarm mode (interservice dependencies are mentioned in the docker-compose file). This Docker Service node is hosted and depends on two blue nodes, Swarm Leader and Swarm Worker, respectively. The relationship between the leader and worker is also shown in the figure. The remaining two yellow and purple nodes are Publisher and Subscriber 6

Publication Title

services, respectively. The Publisher node pushes the sensor data collected from the devices to the message broker. The Subscriber node receives the broadcast of each update from the message broker and makes the respective adjustments to the actuators. Listing 1 shows the TOSCA service template of the application. Through the service template and the orchestrator, the application can be dynamically deployed on any fog infrastructure and migrated very easily. More details of the framework, application and deployment procedure are available at [11]. While the TOSCA templates support the dynamic deployment of fog computing applications, the templates are to be manually generated for each application, which is a tedious process. In addition, to achieve true intelligent fog computing applications, based on some AI inferences, the current configurations can be modified dynamically and new services can be deployed on the fog nodes. Although the service template approach can support such intelligent dynamic deployment, manual generation of the template becomes the bottleneck. The ability of LLM to automatically generate code has been studied extensively in the literature and is widely used in the industry [12]. To support the automatic generation of TOSCA service templates, we are currently studying the ability of LLM to automatically generate such templates. LLMs are being trained with the RADON Particles repository [13] that contains the TOSCA service templates for a wide range of cloud-based applications and architectures, which were generated as part of our EU H2020 RADON [14] project. The generated IaC can be evaluated with code generation benchmarks such as IaC-Eval [15]. In addition, the generated TOSCA service templates are to be validated with the syntactic and semantic validation features of the orchestrators, e.g. xOpera has such a validator. To improve the semantic intent of the generated code, techniques such as Retrieval-Augmented Generation (RAG) or agentic feedback loops can be employed to attain better accuracy [16]. In our preliminary studies of automatic service template generation, the validation process progresses through three iterative levels. Syntax validation is performed via the "opera validate" operation, where error messages (such as malformed interface blocks, missing capability bindings, and unresolved attribute references) are continuously included in the LLM prompt to create an iterative fix until the template is validated and correctly parsed at each iteration. Semantic validation is achieved through RADON Particles, which are registered at the point of generation and prevent any nodes from being generated that do not exist in the Feb 2026

Fog Computing and LLM Conglomeration

RADON repository. Safety of deployment is provided by a second LLM instance that reviews the validated template on a higher level of intent than "opera validate", by checking for MQTT-oriented ordering issues, persistent issues, and issues associated with ARM incompatibilities. As a result of these three methods and the involved human monitoring (in addition to putting the right prompts, the programmer also has to manually modify the environment-dependent configuration details such as substituting actual IP addresses and usernames into inputs.yaml), we can prevent hallucinated configurations, unsafe actuation, and incorrect deployment decisions. The procedure needs further exploration. In addtion, achieving true intelligent fog computing applications, that take care of automated generation, verification and dynamic deployment, needs significant future research, and probably in the directions of Agentic AI [17].

Further research scope in fog and LLM conglomeration We already discussed the scope of LLM optimizations for fog computing and utilizing LLM for automatically generating fog application templates, thus both domains getting benefit from each other. In addition to these, there are several other research directions that need further exploration. 1) Layered LLM inferencing in edge-fog-cloud continuum: With edge-fog-cloud continuum, for realizing IoT applications, the sensor data collected at the edge layer would move across the continuum with intermediate processing across the layers, until it is finally stored and analysed at the cloud, and respective control signals are sent back to the edge devices. The IoT applications can use local LLM inference, using smaller or specialized models at the fog devices, and the cloud can perform the full-scale LLM. The cloud can also manage model updates at the fog devices, by periodically pushing the updated models back to fog and edge layers. Thus, the data and requests would move upward along the continuum for processing, while results, insights, and updated models propagate downward, having significant scope for further research. 2) LLM task scheduling on fog topology: The LLMs at the fog nodes can act as decision points for task offloading, determining whether the requests can be served locally or should be escalated to the cloud based on different QoS aspects such as latency constraints, workFeb 2026

load, and resource availability. Fog placement strategies are studied extensively [1], and the knowledge can be adapted to the LLMs in dealing with dynamic task routing to fog nodes. This would eliminate the need for another dedicated offloading scheduler on the fog devices, when the targeted system/application architecture already demands on-device LLMs. 3) Applications specifically taking advantage of LLM: While there exist pilot case studies, more research should focus on developing IoT applications that can exploit the abilities of LLM, in domains such as smart healthcare and industrial IoT. 4) Incentive models for fog resource providers: While LLMs on fog devices lead to interesting applications, to encourage the fog nodes to participate in such applications, ideal incentive mechanisms for the fog resource providers are to be studied and employed. 5) LLM training through FL: Federated learning (FL) is a decentralized machine learning method where a shared model trains across multiple devices, with each device training on local data, and model updates are sent to a central server for aggregation, and the aggregated model is sent back to the devices for next round of training. FL supports preserving privacy and security by sending only model updates and not the raw data. Similar sort of training can be adapted in the LLM training on local devices and exchanging only trained model to the centralized nodes for aggregating global LLMs. In addition, considering the resource-constrained nature of the fog devices, the FL may not consider the full LLM layers but only the last few layers for training, suitable for cases such as LLM fine-tuning, adapter training, or personalization. This training the last few layers is a cost-effective adaptation strategy that freezes the core foundation weights and updates only the task-specific parameters, enabling the model to learn individual user preferences and conversational styles, while significantly reducing computation and data requirements.

CONCLUSION Fog computing and LLM conglomeration has the potential to address the latency, network load, and privacy issues of respective LLM-integrated IoT applications. Both fog computing and LLMs can be mutual beneficiaries, with fog computing supporting the ondevice LLMs through various optimizations and LLM Publication Title

7

FEATURE

helping in dynamic template generation for truly intelligent fog computing applications. The conglomeration has further scope for research in layered LLM inferencing in edge-fog-cloud continuum and in designing real-world LLM-integrated IoT applications.

9. W.-N. Hsu, B. Bolte, Y.-H. H. Tsai, K. Lakhotia, R. Salakhutdinov, and A. Mohamed, “Hubert: Self-supervised speech representation learning by masked prediction of hidden units,” IEEE/ACM transactions on audio, speech, and language processing, vol. 29, pp. 3451–3460, 2021. 10. C. Lauwers and C. Curescu, “TOSCA version 2.0,

ACKNOWLEDGMENTS We thank financial support to UoH-IoE by MHRD, India (F11/9/2019-U3(A)). The author also thanks his students, R. Siyanwal, S. Basak, and S. Muthyala, who have contributed in producing the respective frameworks and results, over the years.

REFERENCES 1. S. N. Srirama, “A decade of research in fog computing: Relevance, challenges, and future directions,” Software: Practice and Experience, vol. 54, no. 1, pp. 3–23, 2024. 2. A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, Ł. Kaiser, and I. Polosukhin, “Attention is all you need,” Advances in neural information processing systems, vol. 30, 2017. 3. P. P. Ray, “A review on LLMs for IoT ecosystem: State-of-the-art, lightweight models, use cases, key challenges, future directions,” Internet of Things and Cyber-Physical Systems, vol. 5, pp. 275–328, 2025. [Online]. Available: https://www.sciencedirect. com/science/article/pii/S2667345226000088 4. D. Van Veen, C. Van Uden, L. Blankemeier, J.-B. Delbrouck, A. Aali, C. Bluethgen, A. Pareek, M. Polacin, E. P. Reis, A. Seehofnerová et al., “Adapted large language models can outperform medical experts in clinical text summarization,” Nature medicine, vol. 30, no. 4, pp. 1134–1142, 2024. 5. A. Shukla, Y. Yuan, B. Tamo, Y. Wang, M. Nnamdi, S. Tan, J. Li, B. Marteau, B. Willingham, and M. Wang, “Benchmarking LLM summaries of multimodal clinical time series for remote monitoring,” arXiv preprint arXiv:2603.01557, 2026. 6. M.-L. Wang, R.-P. Zhang, W.-J. Wu, Y. Lu, X.-E. Wei, Z. Sun, B.-H. Guan, J.-J. Zhang, X. Wu, L. Zhang et al., “Evaluation of large language models for diagnostic impression generation from brain MRI report findings: A multicenter benchmark and reader study,” npj Digital Medicine, 2026. 7. J. Xu, Z. Li, W. Chen, Q. Wang, X. Gao, Q. Cai, and Z. Ling, “On-device language models: A comprehensive review,” arXiv preprint arXiv:2409.00088, 2024. 8. J. Varughese, “What is a multimodal LLM (MLLM)?” https://www.ibm.com/think/topics/multimodal-llm, accessed: May 23, 2026.

8

Publication Title

OASIS standard,” https://docs.oasis-open.org/tosca/ TOSCA/v2.0/TOSCA-v2.0.html, Jul. 2025. 11. S. Basak and S. N. Srirama, “Fog computing out of the box: Dynamic deployment of fog service containers with TOSCA,” International Journal of Network Management, vol. 34, no. 5, p. e2246, 2024. 12. S. Joel, J. Wu, and F. Fard, “A survey on llmbased code generation for low-resource and domainspecific programming languages,” ACM Transactions on Software Engineering and Methodology, 2024. 13. “RADON particles repository,” https://github.com/ radon-h2020/radon-particles, accessed: May 23, 2026. 14. G. Casale, M. Artač, W.-J. Van Den Heuvel, A. van Hoorn, P. Jakovits, F. Leymann, M. Long, V. Papanikolaou, D. Presenza, A. Russo et al., “Radon: rational decomposition and orchestration for serverless computing,” SICS Software-Intensive Cyber-Physical Systems, vol. 35, no. 1, pp. 77–87, 2020. 15. P. T. Kon, J. Liu, Y. Qiu, W. Fan, T. He, L. Lin, H. Zhang, O. M. Park, G. S. Elengikal, Y. Kang et al., “Iac-eval: A code generation benchmark for cloud infrastructure-as-code programs,” Advances in Neural Information Processing Systems, vol. 37, pp. 134 488–134 506, 2024. 16. R. Nekrasov, S. Fossati, I. Kumara, D. A. Tamburri, and W.-J. v. d. Heuvel, “IaC generation with LLMs: An error taxonomy and a study on configuration knowledge injection,” arXiv preprint arXiv:2512.14792, 2025. 17. P. K. Donta, A. Saleh, Y. Li, S. Vaishnav, K. Fang, H. Feng, Y. Xia, T. R. Gadekallu, Q. Zhang, X. Shi et al., “Socio-technical aspects of Agentic AI,” arXiv preprint arXiv:2601.06064, 2025.

Satish Narayana Srirama is a Professor at the School of Computer and Information Sciences, University of Hyderabad, India. He is also a Visiting Professor and the honorary head of the Mobile & Cloud Lab at the Institute of Computer Science, University of Tartu, Estonia, which he led as a Research Professor until June 2020. His current research focuses on cloud computing, mobile web services, mobile cloud, Internet of Things, fog computing, migrating scientific computing and enterprise applications to the cloud, and largescale data analytics on the cloud. He is an IEEE Senior Feb 2026

Fog Computing and LLM Conglomeration

Member, and an Editor of Wiley Software: Practice and Experience, a 56-year-old Journal. Contact him at [email protected].

Feb 2026

Publication Title

9

Record · ID 321806 · SHA-256 74188dbd9ee2781e
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.