裸机LLM内核：41MB镜像中的无操作系统大模型推理

Nova-Quantum 这个项目，核心信息其实都在标题里：一个裸机 LLM 内核，把运行大模型所需的东西打包成 41MB 的 ISO，启动时不依赖任何操作系统。很多人看到“LLM”会下意识想到动辄几个 GB 的模型权重，但 41MB 意味着它不可能装下一个 7B 参数的大模型，真正值得琢磨的是它证明了“大模型推理”这件事可以脱离操作系统，变成一个接近固件形态的东西。

这类项目适合谁？三类人比较对口：一是做嵌入式或边缘设备的开发者，想看看 LLM 推理能不能像烧固件一样部署；二是对操作系统底层感兴趣，想理解内核启动、内存管理和推理运行时怎么协同的人；三是只想在一个干净、可控、不装一堆驱动的环境里测试小模型效果的研究者。如果你只是想在普通电脑上方便地调用大模型，那现有的桌面推理工具会更顺手，没必要折腾裸机。

下面我围绕这个主题，按“它解决什么问题、镜像里的空间怎么分配、怎么启动验证、遇到问题怎么排查、性能边界在哪里、还能往哪个方向继续玩”的顺序，拆开讲一遍。

1. 裸机 LLM 内核：到底解决什么问题

1.1 裸机、内核、无 OS：三个词怎么理解

常规跑一个 LLM 的链路很长。你要先装操作系统，再装 Python 或独立运行时，接着处理显卡驱动、CUDA 版本、Python 依赖、推理框架配置，最后才轮到模型加载。这个过程对开发机来说不算难，但对只想在一个固定硬件上跑固定模型的场景来说，明显太臃肿了。

裸机 LLM 内核的思路正好反过来：把操作系统这层完全裁掉。硬件上电后，BIOS 或 UEFI 固件直接加载 ISO 里的启动器，启动器再把内核和模型权重读进内存。内核负责初始化必要硬件、分配内存、处理键盘或串口输入，然后直接进入模型推理。没有后台服务，没有线程调度干扰，没有额外的驱动栈，整个系统的复杂度和攻击面都小很多。

这个思路在传统的嵌入式开发里很常见。以前我们做单片机程序，写完代码烧进去，上电就跑，没有系统。Nova-Quantum 把同样的思路搬到了 LLM 场景：大模型推理不再是应用层的事情，而是内核层的事情。

这不是说去掉操作系统后推理效果一定会更好。它的价值在于启动路径更短、环境更可控、部署方式更像“刷固件”，尤其适合演示机、终端设备、教育实验这类对简单和稳定性要求高于对功能丰富度要求的场景。

1.2 和常规部署形态的差异

从实用角度看，裸机 LLM 和常见的本地推理、服务化推理有本质差异。

• 本地桌面推理：依赖操作系统，有完整的图形界面、文件系统、网络栈，适合日常开发和调参。
• 服务化推理：把模型挂在后端，通过 API 对外提供能力，支持并发请求，适合生产项目。
• 裸机推理：没有操作系统，启动快、环境封闭，但功能也最受限。

这里有个很容易误解的点：裸机不等于性能更强。它只是少了一大堆中间层的开销，但如果 CPU 指令集优化、内存带宽、模型量化这些关键点没做好，实际推理速度可能还不如一个精心配置的 Linux 环境。所以真正适合裸机方案的场景，不是“为了更快”，而是“为了更简单、更可控”。

我建议第一次接触这类项目的人，先别想着一口气把它改成自己的生产工具，而是把它当成一个能跑起来的实验环境。先理解启动过程，再去看推理任务是怎么被组织起来的。

2. 41MB 镜像里，模型和运行时怎么分配

2.1 先算账：模型权重占多少空间

41MB 是整个 ISO 的体积，不是模型体积。一个可启动镜像里通常要包含引导文件、内核本体、运行时库或静态二进制、以及模型权重。七七八八扣掉启动器和内核的开销后，真正能留给模型的区间，乐观估计也就 25MB 到 35MB。

这个容量能装什么模型？按参数和精度算一笔账就清楚了。

从这个表能看出，41MB 的 ISO 里，比较现实的方案是一个 30M 到 100M 参数级别的模型，配合 INT8 或 INT4 量化。如果是 100M 参数还要塞进 41MB，那基本只剩 INT4 一条路，而且镜像其他部分必须压缩到很低。

所以听到“Bare-Metal LLM”这个说法时，不用下意识期待它能跑大语言模型。它更接近一个微型语言模型运行环境，或者一个强化的技术演示。如果你给它准备一台普通配置的电脑，它能启动并完成基础对话；但如果你指望它类 ChatGPT，那不符合容量规律。

2.2 精度、量化和推理质量之间的取舍

为什么镜像里要主动做量化？因为模型体积和推理速度都受权重精度影响。

FP32 精度最高，但占空间也最大。FP16 和 BF16 能把体积减半，而且如果 CPU 支持相关指令，速度通常比 FP32 更快，问题是低精度在极端情况下会造成梯度或推理数值不稳定，不过推理场景一般不像训练那么敏感。INT8 和 INT4 是明显压缩体积的手段，代价是模型表现可能下降。小模型本身能力就有限，量化后再掉一点效果，生成结果就会开始出现语义不连贯、重复词汇、格式混乱等问题。

处理这个问题，我自己的习惯是：不要只看模型名字，要看实际推理效果。同样是 INT4，有的模型损失很小，有的模型直接崩坏。原因和原模型训练方式、量化校准数据都有关。在 Nova-Quantum 这类项目里，如果你能自己决定权重文件，最好先分别跑 INT8 和 INT4，把同样的输入各测几遍，比较生成结果和耗时，而不是默认选最小的那个。

另外要注意低精度和 CPU 指令的关系。某些 CPU 对 BF16 或 INT8 有特殊加速，有些没有。裸机环境下缺少操作系统层面的驱动和调优，如果实现没有针对性优化，实际速度可能不如预期。这也是拿到镜像后先做一轮小规模测试，而不是直接上生产环境的原因。

3. 启动与交互：从插入镜像到看到提示符

3.1 先用虚拟机验证

拿到 ISO 之后，我最建议的第一次运行环境是虚拟机，不是直接写 U 盘烧到实体机。原因很简单：虚拟机可以快速调整内存、CPU 数量、固件模式，也能方便地收集日志，发现问题后重新启动的成本很低。

常见的 QEMU 启动命令大概是这个样子：

qemu-system-x86_64 \ -cdrom nova-quantum.iso \ -boot d \ -m 1G \ -cpu qemu64 \ -smp 2 \ -serial stdio

这段命令做了几件事：把光盘镜像挂到虚拟光驱，从光驱启动，给虚拟机分配 1GB 内存，模拟一颗兼容性较好的 CPU，开两个核心，同时把串口输出重定向到当前终端。

需要说明的是，这个命令只是一个通用示例，不同版本、不同镜像对硬件参数的要求不一样。比如有的裸机镜像强制要求 UEFI 启动，那 QEMU 就要加-bios参数，或者改用 VirtualBox 的 UEFI 模式；有的镜像干脆不支持多核，那你把-smp调到 1 反而更稳定。

如果第一次启动黑屏，先别急着怀疑镜像损坏。先确认你看到的是图形输出还是串口输出。有些镜像把日志直接打到 VGA 上，有些只走串口。用-serial stdio以后，如果终端里能看到启动日志，说明输出通道选对了。

3.2 一次典型启动过程会看到什么

虽然不同项目的实现细节会有差异，但裸机 LLM 镜像的启动过程通常可以拆成四个阶段。

第一阶段是固件加载。QEMU 模拟的 UEFI 或 BIOS 找到光盘，加载引导程序。这个阶段很短暂，多数时候只能看到一段提示信息。

第二阶段是内核初始化。内核开始设置内存布局、中断描述符、串口控制器，可能还会初始化时钟。正常情况会输出一些系统信息，比如内存大小、CPU 类型、控制台设备等。如果这个阶段卡住，通常问题出在硬件兼容性和中断配置。

第三阶段是模型加载。内核把权重从镜像里读出，搬到特定内存地址。模型越要大，这个阶段越慢。如果你看到一段长等待，不要急着关闭虚拟机，先观察 CPU 占用和磁盘活跃度。

第四阶段是交互提示符。模型就绪后，终端会打印一个提示符，比如>>>或者Ready>。这时候你输入文字，按下回车，模型就开始推理。推理过程一般能看到 token 一个接一个输出，速度取决于模型大小、量化精度和模拟 CPU 的性能。

这里有一个容易忽略的点：裸机环境没有文件系统给你临时挂载模型，没有网卡驱动让你远程调用，输入输出通常就靠键盘和串口。所以在设计测试用例时，尽量准备短一点的输入。长文本意味着更大的上下文，更大的上下文意味着更多内存和更慢的生成速度。

4. 常见故障：启动卡住、软死锁、无输出

4.1 启动阶段的排查顺序

裸机环境没有操作系统日志，排查问题会更依赖启动输出的最后一段信息。遇到启动失败，我一般按下面的顺序走。

先看有没有任何输出。如果完全黑屏，检查输出通道是否匹配。图形界面下你要看 VGA 窗口，命令行下你要确认串口重定向参数有没有加对。

再看卡住的位置。日志停在内存检测，大概率是内存参数问题；停在设备初始化，可能是模拟器不支持某个硬件；停在模型加载，可能是镜像里的权重文件不完整或读取失败。

接着检查固件模式。有的项目只做 UEFI 启动，有的兼容 BIOS。如果从 ISO 启动时报错类似“No bootable device”，先换一个固件模式。

最后是 CPU 和多核问题。某些裸机内核在 SMP 多核环境下会出问题，因为中断分配和内核自己的多核实现不够成熟。这种情况下，把-smp降到 1，或者换一个更简单的 CPU 型号，往往就能绕过。

4.2 运行阶段的软死锁和输入输出问题

运行阶段最容易遇到一类现象：系统没崩溃，但就是卡住不动，没有任何输出，日志里可能出现类似下面的信息：

kernel: watchdog: bug: soft lockup - cpu#2 stuck for 23s! [kworker/u32:3:2196]

这里说的 soft lockup，指 CPU 在某段代码里停留时间过长，触发了看门狗检测。看到这类信息，第一反应不应该是“代码写错了”，而是先排查底层环境。

排查顺序是：先确认 CPU 数量，多核环境先砍到单核试试；再查计时器和中断源，比如 HPET、ACPI 定时器是否被正确初始化；最后看任务来源，如果卡在一个工作队列里，很可能是驱动或延迟任务在等待某个设备响应。

如果是 QEMU 环境，可以尝试更换 CPU 型号，比如从默认型号换成-cpu qemu64，或者反过来换成-cpu host。不同虚拟 CPU 对时钟和指令集的支持不一样，很多软死锁问题其实就是虚拟硬件配置不匹配造成的。

输入输出问题也有固定的排查套路。如果键盘没反应，先确认是不是只支持 USB 键盘，而虚拟机没加载 USB 控制器；如果串口输出乱码，确认波特率是否匹配，比如 115200 还是 9600；如果模型输出中文变成乱码，那就是编码和 tokenizer 的匹配问题，通常和输入法、终端编码设置有关，不一定是模型能力问题。

5. 性能边界：能跑通，但不等于能扛所有场景

5.1 用哪些指标判断是否够用

看一个裸机 LLM 环境能不能用，不要只看“能启动”这一个结果。至少要看四个指标。

• 冷启动时间：从开机到出现提示符。
• 首 Token 延迟：输入完成后，到输出第一个 token 的时间。
• 生成速度：单位时间内生成多少个 token，也就是 tokens/s。
• 稳定输出长度：模型在多大上下文下还能保持正常生成，不会越写越乱或直接卡死。

这四个指标里，启动时间是最容易误导人的。很多裸机镜像把内核压缩得很小，启动确实很快，但模型加载之后，推理速度可能很一般，尤其在模拟器里，性能会进一步折扣。

如果你的目标是长期使用，还要额外测试连续多次会话的稳定性。比如连续跑 10 轮对话，看看模型会不会越跑越慢，内存会不会越吃越多，输出会不会开始错乱。裸机环境一般没有操作系统的内存回收机制，如果不小心处理，长时间运行后状态会变差。

5.2 和带操作系统的推理环境对比

裸机推理和带操作系统的推理环境，性能对比没有一个固定结论，但可以从几个维度做一个参考判断。

如果你的场景是单用户、固定模型、固定设备，裸机方案是够用的。如果模型需要频繁更换，或者需要好几个用户同时访问，那裸机环境就不是最优解。操作系统这层虽然显得“重”，但它提供的进程管理、并发调度、内存保护和网络能力，在真实业务里几乎是必需的。

所以我的态度是：不要神化裸机推理。它的独特价值是简单和可控，而不是全能。

6. 从实验到继续折腾：微调、重新打包与下一步

6.1 先选一个足够小的基础模型

如果你不满足于刷官方镜像，想自己做一版能跑的裸机 LLM，第一步不是调内核，而是选一个足够小的基础模型。

从 41MB 这个容量倒推，基础模型最好控制在 30M 到 100M 参数之间。这个规模的好处很明显：权重可以量化进镜像，推理时内存占用可控，普通 CPU 也能带得动，而且训练和微调的开销不大。Andrej Karpathy 提出过一个叫 “LLM wiki” 的学习范式，核心思路就是从一个小而完整的模型训练链路入手，把数据、训练、评测、推理都能自己控制住。这种思路放在 Nova-Quantum 上也很合适：先在小模型上把流程跑通，再去研究大模型。

小模型的效果当然不能跟大模型比，但它有一个优势，就是足够透明。你可以清楚地看到权重文件怎么变，量化前后差异有多大，输入长度对速度的影响有多明显。这些手感是在大模型上很难获得的。

6.2 把微调结果做进新镜像

如果你想让模型在某个特定领域表现更好，比如只回答嵌入式开发问题，或者只处理固定格式的日志分析，可以考虑对小模型做微调，再把权重打包进 ISO。

流程大致是：先在普通电脑上用少量领域数据做微调，常用手段包括 LoRA 或 QLoRA；微调完成后把权重导出成推理格式，再做 INT8 或 INT4 量化；最后把量化后的权重替换进 Nova-Quantum 镜像的对应位置，重新制作 ISO。

这一步比想象中要麻烦。因为模型格式、量化工具、镜像目录结构、启动加载逻辑必须完全匹配。如果镜像里用的是某种自定义格式，那你需要先搞清它的打包方式，不能只靠“把文件替换进去”就行。

我自己的建议是，先不急着动内核代码。先把小模型微调好，让它在普通推理工具里跑通，确认效果满意后，再研究镜像打包。这样问题就被拆成两个独立部分：模型本身的问题和容器/启动镜像的问题。如果混在一起排查，你会分不清输出变差到底是微调问题还是量化问题。

6.3 长期能玩的方向

Nova-Quantum 这类裸机 LLM 项目，往深了走其实有几个方向都很有意思。

第一个方向是极简部署。你可以把一颗小芯片配上少量内存，做成一个只会回答特定问题的设备。比如现场演示机、展台问答机器人，甚至是一个教学用的“上电即用”AI 模块。这类场景追求的不是模型多聪明，而是部署简单、环境封闭、不容易被乱改。

第二个方向是系统底层学习。通过裸机内核跑 LLM，你能实际体会到内存布局、引导协议、中断处理和推理运行时的协作关系。很多做了一年 Web 开发的工程师，对“模型在电脑上到底怎么跑起来”并没有太多感知，这种项目恰恰能补上这块拼图。

第三个方向是极小的本地推理工具链。当模型足够小时，你可以把训练、微调、量化、打包、测试全部放进一条本地流水线。这个思路很像开发嵌入式固件：改模型、编镜像、跑测试、看日志，不断迭代。

回到 Nova-Quantum 本身，我认为最值得看的不是它有多大的参数规模，而是它展示了一种非常不一样的部署形态：模型推理可以像固件一样被固化、被启动、被分发。这个形态未来在边缘设备、教育硬件和离线演示上会有更多应用空间。

不过真到自己上手时，还是要稳一点。先按文档把官方镜像跑通，再尝试替换模型或调整参数。裸机环境下排错手段有限，与其跳到很复杂的功能，不如先把启动、推理、输出这三件事确认稳定，再往前走。真正踩过坑的人都会同意，这种项目里最有价值的经验不是它能做什么，而是你知道它不能做什么，以及出问题时怎么快速定位。