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。这个容量能装什么模型按参数和精度算一笔账就清楚了。模型规模FP32FP16/BF16INT8INT410M 参数40MB20MB10MB5MB30M 参数120MB60MB30MB15MB100M 参数400MB200MB100MB50MB从这个表能看出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 本身我认为最值得看的不是它有多大的参数规模而是它展示了一种非常不一样的部署形态模型推理可以像固件一样被固化、被启动、被分发。这个形态未来在边缘设备、教育硬件和离线演示上会有更多应用空间。不过真到自己上手时还是要稳一点。先按文档把官方镜像跑通再尝试替换模型或调整参数。裸机环境下排错手段有限与其跳到很复杂的功能不如先把启动、推理、输出这三件事确认稳定再往前走。真正踩过坑的人都会同意这种项目里最有价值的经验不是它能做什么而是你知道它不能做什么以及出问题时怎么快速定位。