Running LLMs Inside BIOS: Natural Language Interaction in the Pre-Boot Environment

I. Why Put an LLM into BIOS

The pre-boot environment is the first software layer that runs after a machine powers on, yet its human-machine interaction has long stagnated. Traditional UEFI firmware offers users two interfaces: the Setup configuration screen and the Shell command line. Neither is particularly friendly.

The Setup screen suffers from a “terminology wall”: ordinary users confronted with options like boot mode, memory frequency, or PCIe link speed often have no idea what will happen if they change something. The Shell suffers from a “memory wall”: querying memory topology, SMBIOS information, or driver lists requires memorizing a large number of commands and parameters—practically inaccessible to anyone without a firmware background. And when the system fails to POST or hardware anomalies occur, beep codes, diagnostic LEDs, and serial logs are professional-grade information that shuts ordinary users out entirely.

If a large model agent that “understands hardware, understands firmware, and understands human language” existed in the pre-boot stage, users could complete queries, diagnostics, and configuration in natural language without memorizing any commands. This is not a gimmick: the pre-boot environment is precisely the moment when users are most helpless and experts are most scarce.

II. Feasibility Analysis: What Scale of Model Can Run in the Pre-Boot Environment

The UEFI environment has several distinctive characteristics: a flat memory model, single-threaded entry points, pure C/C++, no standard C runtime, and only two sets of basic services—Boot Services and Runtime Services. It has no OS process scheduling and no mature driver ecosystem, but this does not mean models cannot run:

1. Model selection: Decoder models with 0.5B–3B parameters and a regular architecture are the most realistic choice. After INT8 quantization, a 1B-parameter model’s weights are roughly 1 GB, entirely acceptable within today’s memory budgets. A context window of 2K–8K is sufficient—pre-boot interaction typically involves only a few rounds of Q&A, so the focus is on KV-Cache memory footprint rather than long-text capability.

2. Inference framework porting: Operators such as embedding lookup, LayerNorm, quantized matrix multiplication, and KV-Cache management can be trimmed and ported into the firmware project, with memory managed through AllocatePool/AllocatePages. If the platform supports multiprocessor services, multi-core parallelism can further improve generation speed.

3. Weight storage: Embedding weights into the firmware volume is not recommended—Flash space is limited, and it bloats the image size and slows firmware updates. A more reasonable approach is to place weights on the ESP or a dedicated data partition and load them on demand, forming a two-tier structure of “small model built-in + large model external.”

4. Performance expectations: With pure CPU software inference, first-token latency is on the order of seconds, and generation speed ranges from single-digit to low-double-digit tokens per second. This suits short-output tasks like Q&A and command generation, not long-text generation.

The conclusion: running a small model in the pre-boot environment that “understands human language and can plan commands” is entirely feasible from an engineering standpoint. The key is setting reasonable goals rather than chasing desktop-application smoothness.

III. A Model Alone Is Not Enough: Input Is the First Hurdle

Many people underestimate the difficulty of input. The pre-boot environment has no OS input-method stack and no audio driver stack. The input experience directly determines whether this agent is “usable” or merely “demoable.”

1. Text input: UEFI reads key events through the Simple Text In protocol family, and the Human Interface Infrastructure (HII) can be used to build a basic input interface. The real challenge is Chinese: UEFI natively has only key events and no input method framework, so pinyin-to-candidate conversion logic and an external dictionary must be implemented from scratch—a workload comparable to porting the model itself.

2. Voice input: Letting users talk to the BIOS requires a much longer pipeline:

   • Capture: Without an existing audio driver, the onboard audio codec must be initialized directly, DMA channels established, and microphone signals captured as PCM streams;
   • Front-end processing: Voice activity detection (VAD), noise reduction, and framing must be implemented in firmware to avoid sending silence to the recognizer;
   • Recognition paths: First, establish a TLS connection through the UEFI network stack and send audio to a cloud speech recognition or multimodal service for transcription. Second, run a tiny streaming recognition model locally, targeting a limited command vocabulary—a severe test of firmware resources, but it works offline.
     The real value of voice is in keyboard-free scenarios: production-line engineers can execute diagnostic commands hands-free while disassembling a chassis; system builders can “speak without touching” when the motherboard is bare and peripherals are not connected.

3. Multimodal input is a more natural direction: Letting users photograph an error screen and hand it directly to a multimodal model is far friendlier than asking them to manually type an error code. This path depends on external multimodal capability calls; the firmware side only needs to handle image capture and upload.

IV. Agent Design: From Natural Language to Shell Commands

The model handles “understanding and planning,” while firmware handles “execution and fallback.” A pragmatic architecture has three layers:

• Intent layer: The large model parses user utterances into structured intents, labeling them as query, configuration, or diagnostic, and extracts parameters;
• Tool layer: The firmware side maintains a controlled tool table, where each tool encapsulates one or more Shell commands, SMBIOS/ACPI information reads, Setup variable reads/writes, and declares parameter constraints;
• Validation layer: All actions pass through whitelist and parameter legality checks first. High-risk operations involving variable writes or boot option changes force a second user confirmation.

Illustrative pseudocode (expressing the design concept only):

typedef struct {
  CHAR16     *Name;
  CHAR16     *Desc;
  EFI_STATUS (*Execute)(IN JSON_ARGS *Args, OUT CHAR16 **Report);
  BOOLEAN    Danger;
} AGENT_TOOL;
EFI_STATUS RunAgent(IN CHAR16 *Utterance)
{
  JSON_ARGS  *Intent = LlmParseIntent(Utterance);   /* Model outputs structured intent */
  AGENT_TOOL *Tool   = ToolTableMatch(Intent);
  if (Tool == NULL) {
    return EFI_UNSUPPORTED;                           /* No matching tool, refuse to execute */
  }
  if (Tool->Danger && !UserConfirmDialog(Tool)) {
    return EFI_ABORTED;                               /* High-risk operation requires confirmation */
  }
  return Tool->Execute(Intent, &Report);              /* Execute and return results */
}

Fuzzy queries are the highest-value scenario. When a user asks “which slot is the memory module in,” no single Shell command can answer. The agent’s execution plan should be: first call the SMBIOS tool to pull the memory device table, then cross-reference physical slot information, and finally translate the result into plain language—“Slots 1 and 3 each have a 16 GB module, Slot 2 is empty; for channel symmetry, consider moving the second module to Slot 2.” The model’s value is not in memorizing commands but in orchestrating multiple atomic capabilities into a single readable answer.

V. “Wish-Mode” BIOS: Possibilities and Boundaries of Declarative Configuration

The essence of “wish mode” is upgrading the configuration paradigm from procedural to declarative: the user simply states a goal (“I want to boot from this USB drive to install an OS”), and firmware derives the action chain (temporarily adjust boot order → enumerate USB storage devices → boot the installation media), then automatically restores the original state after execution.

To keep it from becoming a “mystery box,” three supporting capabilities are needed:

1. Configuration dependency graph: Setup options have explicit and implicit dependencies (for example, some power options depend on the current performance mode setting). Firmware needs to maintain a dependency and conflict graph so that model-generated configuration plans can be machine-verified, rather than “the model says change it, so it changes”;
2. Change impact analysis: Every proposed change must be able to answer “what will it affect, and how can it be rolled back”;
3. Snapshot and rollback: Before writing changes to NVRAM, snapshot the relevant variables so that a failed execution or a user change of mind can be restored with one action.

Calmly defining the boundary: “wish mode” suits high-frequency, low-risk operations such as boot options, fan policies, and performance/power preferences. For high-risk domains like Secure Boot, TPM clearing, and firmware updates, AI should only explain and guide—the final decision must remain with the user.

VI. Unavoidable Engineering and Security Red Lines

1. Boot time budget: POST is a stage where every millisecond counts. Model loading and inference must be asynchronous, skippable, and non-blocking by default for normal boot, taking effect only when the user explicitly invokes them. This is the baseline for productization.

2. Prompt injection risk: Diagnostic logs and device description strings are untrusted input. If spliced directly into prompts, crafted strings could induce the agent to execute high-risk operations. Countermeasures include strict isolation of input and instruction channels, tool whitelisting, mandatory human confirmation for high-risk actions, and keeping the authority over “what to execute” in code rather than in the model.

3. Supply chain security: External model weight files should be included in the firmware signing and measurement system. Hashes and signatures must be verified before loading to prevent substitution with a malicious model exhibiting abnormal behavior.

4. Online/offline trade-offs: A local small model is offline-capable and low-latency but limited in capability. Calling a cloud-based large model through the UEFI network stack offers stronger capability but requires a defined degradation path when the network is unavailable, plus desensitization of outbound hardware information to avoid uploading sensitive data such as serial numbers and MAC addresses indiscriminately.

VII. Do Users Really Need It?

A segmented view makes this clearer:

• Ordinary users: Low frequency but real. They may not use it even once a year, but “being able to ask a question in plain language when the computer won’t POST” is a genuine pain point. The value centers on fault diagnosis and build guidance, not daily configuration;
• Operations and production-line engineers: High frequency and essential. During batch deployments and hardware inspections, issuing diagnostic commands in natural language is far more efficient than flipping through command manuals. Voice input has its greatest value in this scenario;
• Firmware developers: An excellent debugging assistant. Fuzzy queries against SMBIOS, ACPI tables, and PCI configuration space are like having living documentation on call.

So the answer is not black and white: it will most likely not form a “revolution” the way graphical Setup replaced character interfaces. A more likely path is incremental—first proving value as a “diagnostic interpreter” and “command translator,” then gradually moving toward “wish-mode” configuration. For the general public it is a nice-to-have; for professional users it is a genuine necessity.

VIII. Conclusion

Putting a large model into BIOS has never been about the model itself. It is about the tedious engineering details of the pre-boot environment: no ready-made input method, so you write one; no audio driver stack, so you build one; memory must be budgeted page by page; and security boundaries must be redrawn where there is no OS guardrail. Precisely because these details form the barrier, whoever completes this “dirty work” first has the opportunity to define the next generation of firmware interaction. The direction can evolve slowly, but not a single engineering problem can be bypassed.