One Foundation, Many Jobs: Runtime Adaptation on a Phone

Samsung's one-for-all language-model system tackles a different boundary problem from Palabrita's: it wants one mobile foundation model to support many tasks and languages without storing and compiling a separate full model for each one. The focus here is the interface that makes that breadth manageable—task-specific LoRA adaptations supplied to a shared, frozen inference graph. Understanding that interface lets the reader distinguish genuine runtime flexibility from the looser promise that a model can be adapted to anything at any time.

A LoRA, or low-rank adaptation, is a compact task-specific update applied alongside the foundation model's ordinary weights. The foundation model contains the broad language capability; an adapter nudges that capability toward a task such as correction, style transfer, or smart reply. In a server environment, adapters can be merged, loaded, or replaced with relatively few concerns about a fixed phone graph. On a phone, the central engineering question is how to change behavior while keeping memory layout, graph shape, and execution predictable.

The shared foundation and the task-specific layer

Samsung's system begins with a LLaMA-based foundation model and application-specific LoRAs covering eight use cases across nine languages. The foundation graph is the stable computational object. It contains the common sequence of operations that turns tokens into output. A selected LoRA contributes a small, task-oriented change to parts of that computation. The result is not eight unrelated models; it is one shared base with controlled specializations.

That separation changes what “switching tasks” means. The runtime does not ask the foundation model to redesign itself when a user moves from spelling correction to a style suggestion. It selects the adapter associated with the task and presents the compatible data to the same graph. The base graph and its memory arrangement remain the stable part of the system; task behavior is the variable part.

This is a different way to keep the model from owning the whole product. In Palabrita, deterministic data owned the word because word validity was a hard product rule. In Samsung's design, the runtime owns the selection and delivery of the task adaptation because the phone needs that transition to be predictable. The foundation model supplies language generation, but the product does not hand it an unrestricted choice of graph, adapter shape, or execution path.

The distinction is especially important for a multi-use-case product. If every task required a separately compiled copy of the foundation model, storage would grow with the number of tasks, and a change to the model pipeline would have to be repeated across those copies. Sharing the base computation avoids that duplication. But sharing does not erase task differences. The adapters preserve specialized behavior while the common graph preserves a stable deployment target.

Three ways to place multiple adapters

The reported design compares three approaches. The first prepares different graphs for different LoRA-enabled tasks while sharing weights for the parts where no adapter is applied. At runtime, the system triggers the graph associated with the chosen task.