NightRunとは？OSを入れずにローカルLLMを起動するUEFIアプリ｜Raspberry Pi 5とx86 PC対応

NightRunとは、OSを起動せずローカルLLMだけを直接立ち上げるUEFIアプリケーション。

ローカルLLMを動かすには、まずOSを入れる。この前提そのものを外したプロジェクトが公開されました。NightRunは、USBメモリやmicroSDカードから起動して、Linuxカーネルもスケジューラもネットワークスタックも持たないまま、いきなりLLMのチャット画面まで到達する実験的なオープンソースプロジェクトです。OSが抱えていたメモリと処理時間を、推論側に回す。発想としては極端です。ただしローカルLLMの動作可否は「モデルをRAMにどれだけ載せられるか」で決まる場面が多く、そこを空けにいく設計ではあります。

この記事では、NightRunがどういう仕組みで動いているのか、OSを外して実際に何が得られて何が得られないのか、ご自身の手元のハードで再現できるのかを順に整理していきます。仕組み → 対応ハード → 対応モデル → 量子化 → 起動シーケンスの順で、途中から読んでも判断材料が拾える構成。先に結論を書いておくと、GPUでローカルLLMを回している環境をNightRunが速度で置き換えることはありません。狙っている場所が違い、隔離や学習といった別の用途に向いた構成です。

NightRunはOSを載せずにLLMだけを起動する

NightRunは、SBC（シングルボードコンピュータ）やミニPCでローカルLLMを動かす際の「OSがメモリを食う」という問題に正面から向き合った実験的なオープンソースプロジェクトです。USBドライブまたはmicroSDカードから起動し、通常のOSをロードすることなく、そのままローカルLLMの対話環境まで到達します。ランタイムはRustで記述されている、というのが公開情報として示されている実装上の特徴。

体験としてはこうなります。電源を入れる。UEFIファームウェアが起動媒体を見つける。NightRunが読み込まれ、量子化済みのモデルがRAMへ読み込まれる。そしてチャット画面が現れる。この間、Linuxディストリビューションのインストールもデスクトップ環境の起動も、ターミナルを開いてコマンドを打つ工程も存在しません。ログイン画面すら通らずにLLMと対話できる状態へ到達する、というのが公開情報で説明されている動作。

ここで誤解されやすいのが、「メモリ節約のために削ぎ落としたLinuxディストリビューションなのだろう」という受け取り方です。そうではありません。NightRunはUEFIアプリケーションであり、その下にLinuxカーネルもプロセススケジューラもネットワークスタックも存在しない構造になっています。一方で、キーボード入力の受け取り、ディスプレイのフレームバッファ制御、ストレージへのアクセスは、UEFIファームウェアが提供するブートサービスをそのまま使います。ドライバ相当の機能がすべて消えるのではなく、その担い手がOSからファームウェアへ移る、という理解が正確です。

通常のローカルLLM環境と何が違うのか

一般的なローカルLLM環境を層で描くと、下から順に「ハードウェア → ファームウェア → OS → デバイスドライバ → ランタイム（Ollama、llama.cpp、LM Studio等）→ モデル」という積み重ねになります。OSがハードウェアを抽象化し、ドライバがGPUやストレージを扱い、その上にランタイムが乗り、ランタイムがモデルを読み込む。この積層のおかげで、幅広いハードウェアと機能に対応できるわけです。

NightRunの層構造はこれと違います。「ハードウェア → UEFIファームウェア → NightRun（ランタイム＋UIを内包）→ モデル」で終わり。一般的なOSカーネルとユーザー空間、そしてOS側のデバイスドライバ層がなくなります。ただしハードウェアをすべて自前で直接制御する純粋なベアメタル実装ではありません。公式はExitBootServices()を呼ばずにUEFI Boot Services上へ留まる設計だと明記しており、画面描画（GOP）、USBキーボード（USB HID）、FATファイルシステム、マルチコアの起動（MP Services）はファームウェア側の機能を使います。抜けた分だけメモリと処理時間が空き、抜けた分だけできなくなることもある。この記事の残りは、その「空いたもの」と「できなくなったもの」を切り分ける作業に費やします。

OSを外すとAI推論に何が起きるのか

「OSを外せば速くなる」という表現は、そのまま受け取ると誤解を招きます。実際に何が起きているのかは、次のように分解できます。

OSを起動している状態では、実装メモリの一部が常にOS自身とその周辺に占有されています。カーネル本体、ファイルシステムのキャッシュ、デスクトップ環境を使っていればウィンドウマネージャとコンポジタ、常駐サービス、ブラウザやセキュリティソフトなどの各種プロセス。これらが積み上がった残りが、LLMのモデルとKVキャッシュに使える分になります。NightRunがOSを外すことで真っ先に取り戻すのが、この「占有されていた分」。

次に消えるのが競合です。OS上では複数のプロセスがCPU時間を取り合います。推論スレッドが回っている最中にバックグラウンドのインデックス作成が走る、ウイルススキャンが動く、自動更新がダウンロードを始める。CPUコアの割り当てはスケジューラが調停しますが、調停が発生している時点で推論に使えるCPU時間は減っています。ディスクI/Oも同様で、他プロセスの読み書きが混ざればストレージの帯域を分け合う形になる。

さらに、実装メモリが不足するとOSはスワップを使います。モデルの一部がストレージへ追い出されると、推論のたびに読み戻しが発生して速度は極端に落ちる。搭載RAMがモデルサイズに対して余裕のない機体では、この現象が実用性を左右します。

一方で、変わらないものもあります。CPUの演算性能そのものは変わりません。同じCPUなら1秒あたりに実行できる積和演算の回数は同じです。メモリの物理的な帯域幅も変わらない。DDR5がDDR5であることに変化はありませんし、SBC搭載のLPDDRがOSを外したから速くなるわけでもない。NightRunが取り戻すのは「占有」と「競合」であって、ハードウェアの素の性能を引き上げているわけではありません。

効きやすい条件と効きにくい条件を整理すると、こうなります。効きやすいのは、搭載RAMが少なくモデルが辛うじて収まるかどうかという機体、常駐プロセスが多い環境、ストレージが低速でスワップが致命傷になる構成。効きにくいのは、RAMに十分な余裕がある機体、もともとクリーンな最小構成のOSで運用している環境、そしてGPUのVRAMに載せて推論している構成です。最後のケースは特に注意が必要で、GPUで回している場合はシステムRAMの空き具合と推論速度の関係が薄れます。この点はGPU推論との住み分けの節で改めて扱います。

対応ハードウェア — x86_64 UEFI PCとRaspberry Pi 5

NightRunが対応するハードウェアは、64ビットのx86_64 UEFI PC（Secure Boot無効が条件）と、Raspberry Pi 5です。起動媒体はx86側がUSBドライブ、Raspberry Pi 5側がmicroSDカードです。この2系統に絞られている点が、導入を検討する際の最初の分岐になります。

x86_64側の条件で見落とせないのがSecure Bootの扱い。NightRunを動かすにはSecure Bootを無効化する必要があります。手持ちのPCがUEFIブートに対応していても、Secure Bootが有効なままでは起動しません。ここはファームウェア設定画面（多くの機種でBIOSセットアップと呼ばれる画面）に入って変更する工程が発生します。

Secure Bootを無効にするとはどういうことか

Secure Bootは、UEFIファームウェアが起動しようとするプログラムの署名を検証し、信頼された署名が付いているものだけを実行する仕組みです。ベンダー署名の入ったブートローダーは検証を通りますが、署名を持たない独自のブートアプリケーションは弾かれる。NightRunはベンダー署名を持つ形では配布されていないため、署名検証というゲートを外した状態でなければ起動できません。裏返せば「ファームウェアが検証していないコードを実行する状態にする」ということでもあり、試す対象を選ぶべきという判断はここから来ます。

無効化の手順はマザーボードやPCメーカーごとに異なります。起動時に指定キーを押してファームウェア設定へ入り、Boot または Security のカテゴリにある Secure Boot 項目を Disabled にするのが一般的な流れで、項目名や階層はメーカーのマニュアルで確認することになります。

Raspberry Pi 5側の起動媒体

Raspberry Pi 5では、microSDカードから起動する形になります。x86 PCのようなSecure Bootの設定項目は関係しませんが、代わりにブートの経路そのものがx86とは別系統です。Raspberry Piは伝統的に独自のブートフローを持っており、UEFI環境で動かすにはそれ用のファームウェアを起動媒体側に用意する必要があります。公式リポジトリには、ピン留めしたソースからこのファームウェアを一度だけビルドするスクリプト（scripts/build-rpi5-firmware.sh）が同梱されており、これが正規の手順です。任意のサードパーティ製UEFIファームウェアで代替する前提にはなっていません。

起動媒体を分けられるのが、Raspberry Piで試す際の実務的な利点です。普段使いのRaspberry Pi OSが入ったmicroSDと、NightRun用の媒体を別々に用意しておけば、差し替えるだけで環境を切り替えられます。常用機のブート設定に手を入れずに済む点はx86 PCより気楽ですが、ファームウェアのビルド工程が一度必要になるぶん、手数そのものが少ないわけではありません。

ストレージについては、書き込み速度よりも読み出し速度が体感に効きます。起動時にモデルをRAMへ読み込む工程があるため、低速なmicroSDでは起動完了までの待ち時間が伸びる。ロードが終わってしまえば推論中にストレージへ触れる構造ではないので、影響は起動時に集中します。

動くモデルと.nrm形式

NightRunが対応するモデルは、Llama 3.2 1B、Llama 3.2 3B、Granite 4.1 3B、そしてQwen3 4B Instruct 2507です。ただし、これらをそのまま置けば動くわけではありません。いずれも.nrmという専用形式へ変換したものを使う設計になっています。

必要な実装メモリは、公式がモデルごとに数値で公表しています。

Raspberry Pi 5で使う場合、RAM要件上は4GBボードで1B級が候補になり、3B級以上は8GBボードが前提です。ただし公式が実機検証を示しているのはD0ステッピングの8GBボードで、4GB版での動作確認は示されていません。手元の搭載RAMがこの線に届くかどうかで、載るモデルが決まります。

対応モデルのラインナップを眺めると、1B〜4B級の小型モデルに寄っているのが分かります。これはNightRunがGPUを使わずCPUで推論する構成であること、そしてSBCを含むメモリの限られた機体を対象にしていることの両方から来る帰結。数十Bクラスのモデルを想定した設計ではありません。

変換前提であることの意味

.nrm形式への変換が必要という点は、利便性の面ではっきりとしたトレードオフになります。GGUFのような広く流通している形式をそのまま読み込む設計であれば、Hugging Faceで公開されている膨大なモデル群からその場で選べます。LM StudioがHugging Faceへ直接アクセスして検索ウィンドウからモデルを引っ張ってこられるのは、まさにその積層の恩恵。

NightRunはそこを切り離しました。ただし持ち込みの道が閉じているわけではありません。公式はGGUFを.nrmへ変換するnrconvertを同梱しており、テンソルがQ8_0・Q4_K・Q6_K・F32のいずれかで構成されたGGUFであれば、各テンソルの型を保ったまま変換できると説明されています。Hugging Faceなどで入手したGGUFを自前で変換して持ち込む運用は成立する、ということ。制約として残るのは、変換の一手間が挟まることと、対応アーキテクチャの範囲外のモデルは扱えないことです。読み込む形式をランタイム側で定義しているからこそ、ゼロコピーでの直接実行やCRC-32による検証を組み込めている、という関係になっています。

判断材料としては、こう整理できます。思い付いたモデルをその場で落としてすぐ試す手軽さを求めるなら、変換工程のない既存ランタイムのほうが素直。対応アーキテクチャと対応量子化の範囲で使うモデルを決め打ちできるなら、変換の一手間を払ってでもOSを介さない環境で動かす選択肢が成立します。

ゼロコピー設計と量子化 — Q8_0 / Q4_K / Q6_K

NightRunが対応する量子化形式として挙げられているのはQ8_0、Q4_K、Q6_K。そしてこれらを、F32へ全面展開したコピーを作らずに、RAM上の量子化ブロックをそのまま専用カーネルから参照して演算します。公式が「64バイト境界に整列したテンソルをゼロコピーのビューとして使う」と説明している設計で、ここでいうゼロコピーは、ロード済みモデルのテンソルを別の重みバッファへ複製しないという意味です。量子化ブロックのスケールを演算に反映する処理まで無くなるわけではありません。

量子化とは、モデルの重みを表現する数値の精度を落として、データ量と演算負荷を減らす手法です。低スペックなPCでもモデルを動かせるようになる一方、過度に量子化すれば推論精度の低下を招くというトレードオフがあります。

ロードの段階で中間バッファを挟まない分、起動時のピークメモリと待ち時間に効く作りです。ただし重みを量子化されたままRAMに置くこと自体は既存のランタイムでも一般的で、ここがNightRun固有の容量的な優位になるわけではありません。

量子化形式ごとの傾向を整理すると、次のようになります。

同じパラメータ数のモデルでも、Q8_0とQ4_Kではメモリ占有が大きく変わります。Q8_0は元の重みに近い精度を保つ代わりに1つの重みあたりのデータ量が大きい。Q4_Kはデータ量を大きく削れる代わりに、表現できる数値の粒度が粗くなります。粒度が粗くなると、モデルが出力する確率分布が本来のものからずれる。この「ずれ」が実用上どこまで問題になるかは、タスクの性質とモデルの規模で変わってきます。

パラメータ数の大きいモデルほど量子化の影響を受けにくい、という傾向が報告される場合もありますが、例外も多く一律には言えません。量子化を選べる場面では、メモリに余裕があるほど精度側を採り、収まらない場合にQ4_Kへ落とす順序になります。ただし公式配布の4モデルは量子化が固定されているため、この選択が発生するのは自前で変換して持ち込む場合です。「RAMが足りないから一番小さい形式を選ぶ」のは正しい対処ですが、それは精度を差し出した結果だという理解を伴わせておきたいところ。

起動シーケンスとストレージの「封印」

NightRunの起動プロセスは、通常のOS起動とは性質が違います。電源投入後、UEFIファームウェアがNightRunをロードすると、ブート中に量子化済みモデルがRAMへ直接読み込まれ、その際にモデルデータのCRC-32チェックサムを検証する工程が入ります。

そしてロードが完了した後、ストレージは「封印」されます。以降にディスクから読み出そうとする試みは、ハードフォールト（回復不能なエラーとして処理が停止する状態）を引き起こす構造。ロードが終わったらもう外部記憶には触らない、という前提が実行時のルールとして固定されるわけです。

この設計は、性能最適化というより隔離設計として読むのが妥当です。ただし封印されるのはNightRun自身のストレージアクセス経路で、ランタイムのレベルで以降の要求を止める仕組みです。ストレージ機器やUEFI側の機能が物理的に無効化されるわけではなく、ファームウェアのコードやイベント、タイマーは引き続き動いています。通常のOS環境では推論中でもファイルシステムへのアクセスが常に可能で、スワップも発生しうるし他プロセスがディスクを触ることもある。そこと比べたときの差が、この設計の意味です。

用途として噛み合うのは、外部と切り離した単機能端末です。隔離端末の設計を研究・検証する実験機、展示・デモ用の固定構成、ブート挙動を観察する学習用マシン。ただし「そのまま運用上の保証になる」とまでは言えません。Secure Bootを無効にして署名のないイメージを起動する構成であり、第三者によるセキュリティ監査も示されていない、公式自身が実験的だとしている若いプロジェクトです。機密性の要件が高い用途に充てるなら、設計の検証と実機での監査を別途行う前提になります。

通信面についても公式は明示しています。公式リポジトリのREADMEには、カーネルもブラウザもネットワークスタックもホストプロセスも存在しないと記載があり、ネットワークスタックの不在は設計上の仕様として公表されています。ただしこれは開発側の設計上の言明であって、第三者による通信監査の結果ではありません。機密性の要件が高い運用に置くなら、実機での通信確認を工程として残すのが妥当です。

CRC-32検証が担保するもの／担保しないもの

CRC-32は巡回冗長検査と呼ばれる誤り検出手法の一種で、データから32ビットの検査値を計算し、期待値と一致するかを見ることでデータの破損を検出します。ストレージの読み出しエラー、書き込み時のビット反転、転送中のデータ化けといった偶発的な破損には有効に働く仕組み。

一方で、CRC-32は暗号学的なハッシュ関数ではありません。悪意を持ってデータを改変しつつ検査値を一致させることは、計算上難しくない。つまりCRC-32が担保するのは「偶然の破損が起きていないこと」であって、「モデルファイルが改ざんされていないこと」ではありません。この違いは、隔離端末として運用する際の脅威モデルに直結します。

実務上は、USBメモリの劣化やmicroSDカードの読み取り不良で壊れたモデルを気付かないまま推論に使う事故は防げます。真正性については別の層に仕組みがあり、公式インストーラはモデルをHugging Faceの特定リビジョンに固定したうえで使用前にSHA-256を検証し、媒体へ書き込んだ後も読み戻してSHA-256を突き合わせます。ただしこれはリポジトリとマニフェストを信頼する前提の仕組みであって、署名された供給網全体を保証するものではありません。

CPU推論の最適化 — AVX2/FMA/F16CとNEON

ここから先は、実際に推論を回す部分の話。NightRunはGPUドライバスタックを持たない構成なので、行列演算はすべてCPUが担当します。x86側ではAVX2・FMA・F16Cを使ったカーネル、Raspberry Pi側ではNEONカーネルで最適化されている、というのが公開されている仕様。

用語を整理しておきます。AVX2はIntel/AMDのx86 CPUが持つSIMD命令セットで、SIMDとは1つの命令で複数のデータをまとめて処理する仕組みのこと。整数量子化された重みの内積は、このAVX2の整数命令（sign・maddubs・madd）を使う専用カーネルが担当します。F16Cは16ビット浮動小数点数と32ビット浮動小数点数を相互変換する命令で、KVキャッシュのアテンション計算に使われる。FMAは浮動小数点の積和演算を1命令にまとめる拡張です。NEONはArm系CPUのSIMD拡張で、役割としてはAVX2に相当するもの。Arm側にはq8の内積について、実行時に検出して使うsdotの高速経路も用意されています。命令セットが違う以上それぞれに専用カーネルが要るため、対応ハードを2系統掲げている以上は両方を持つことになります。

GPUを使わないCPU推論で速度を決めるもの

トークンを1つずつ生成する局面では、演算そのものよりメモリ帯域がボトルネックになりやすい、という構図があります。トークンを1つ生成するたびに、モデルの重み全体をメモリから読み出す必要があるためです。1B級のモデルと4B級のモデルでは読み出すデータ量が数倍違い、そのぶん1トークンあたりの所要時間も伸びる。

ここでSIMD命令が効いてくるのは、読み出したデータをどれだけ効率よく計算に投入できるか、という部分。メモリから流れてくるデータを1個ずつ処理していたら、演算器が遊んでいる時間が発生します。まとめて処理できれば、メモリ帯域を使い切るところまで演算側が追いつける。AVX2やNEONが「効く」というのは、こういう意味合いです。

注意しておきたいのが、AVX2の対応状況。近年のx86 CPUでは広く使えますが、古い世代のCPUや、一部の省電力向けコアでは前提が崩れる可能性があります。公式はAVX2非対応のCPU向けにスカラー実装も残しているため、AVX2の有無が起動可否を決めるわけではありません。ただし無い場合は速度が大きく落ちるため、事前にCPUの仕様表で確認しておく意味はあります。Windows環境なら、CPU-Z等のツールで対応命令セットを一覧できます。Linuxなら次のコマンドで確認できます。

grep -o -m1 -E 'avx2|fma|f16c' /proc/cpuinfo

Raspberry Pi 5側は、Arm Cortex系のコアでNEONが標準的に使える構成なので、この点で悩む場面は少ない。ただしx86のハイエンドCPUと比べれば、演算能力もメモリ帯域も水準が異なります。同じモデルを載せても、体感速度は機体ごとに変わると考えておくべきでしょう。

フレームバッファのチャットUIで何ができるか

OSが無いなら画面はどうなるのか。ここがNightRunの見どころのひとつです。組み込みのUIとして、フレームバッファに直接描画するチャットインターフェースを備えている、と公開情報では説明されています。ライブ統計の表示、プロンプト編集、会話履歴に対応。

フレームバッファ（framebuffer）とは、画面に表示するピクセルデータをそのまま格納しているメモリ領域のこと。通常のOSでは、ウィンドウマネージャやグラフィックドライバが何層も挟まった先にこの領域があります。NightRunはUEFI Boot Servicesが提供する機能を使って、その領域へ直接書き込む形。ウィンドウもマウスカーソルもタスクバーも存在しない、素の画面にテキストが描かれます。

キーボード入力も同じくUEFI Boot Services経由で、ファームウェアのキーボードサービスをそのまま使います。インプットメソッド（IME）は存在しません。ライブ統計の表示は実用面で効いていて、通常の利用では画面に出る情報が動作を確認する主な手掛かりになる。開発・診断用には、x86ではCOM1、Raspberry PiではPL011へシリアル出力する経路も用意されています。

使えるもの／使えないものの線引き

裏を返せば、できないことも明確です。ブラウザで開くWeb UIは前提に置かれていません。他のアプリケーションからAPI経由で叩く使い方も前提にない。OllamaのようにHTTPサーバを立てて外部から接続する構成とは、そもそも設計の向きが違います。

つまり、実際の使い方は「その機体の画面の前に座って、キーボードで打ち込んで、画面で結果を読む」という単体利用に集約されます。生成した文章を別のマシンへ渡す手段も、公開されている機能の説明範囲には含まれていません。組み込みUIに保存の導線が無く、ロード後はストレージが封印される設計のため、生成結果をファイルへ残す運用は前提にありません。

この制約をどう捉えるかで、NightRunの評価は分かれます。作業の効率を求めるなら明らかに不便。一方で、外部への出口を意図的に持たない端末として見れば、この不便さは仕様通りの帰結です。展示用のデモ機、ネットワークから切り離した閲覧専用の端末、ブートスタックの学習用マシン。こうした用途では、機能が少ないことがそのまま扱いやすさになります。

Ollama・llama.cppとの運用コストの違い

ローカルLLMを動かす手段としては、Ollama、llama.cpp、LM Studioといった選択肢が既に定着しています。NightRunとこれらの違いは、機能の多寡ではなく、そもそもどの層に乗っているかという構造の差。

既存のランタイムは、OSの上に乗り、GPUドライバやベンダーのSDKを呼び出すことで、幅広いハードウェアと機能を拾う設計になっています。この方針の利点は明白で、NVIDIAのGPUでもAMDのGPUでもApple Siliconでも、対応が入れば同じソフトが動く。反面、対応を維持するコストはランタイム側が背負い続けることになります。

その実例が、各プロジェクトの更新履歴に残っています。Ollamaのv0.31.2では、CUDA Compute Capability 6.x世代のGPUでFlash Attentionを有効化する変更と、非UTF-8文字を含むパスからのモデル読み込みの修正が入りました。llama.cppのb10188には、Apple Silicon向けMetalバックエンドのメモリ解放まわりの修正が入っています。GPUの世代差、内蔵GPUのメモリ制約、ファイルパスの文字コードといった環境差が、そのまま修正項目として並ぶ。メモリ管理はOSとランタイムの境界で今も直され続けている領域です。

層を厚くする設計と、層を削る設計

表を眺めると、NightRunだけが逆方向を向いています。層を厚くする方針では、ユーザーはハードウェアに合わせて選ぶ必要がほとんどない代わりに、GPUの世代やドライバの版が変わるたびランタイム側が追随を続ける。更新履歴に環境依存の修正が並び続けるのは、この方針のコストです。層を削る方針では対応ハードもモデル形式も限定される代わりに、OSの版もドライバの版もSDKの構成も判断材料から消えます。ただし変数がまるごと減るわけではなく、代わりにUEFIファームウェアの実装差（設定項目の位置、フレームバッファの扱い、ブートの制限）が前面に出てくる。判断材料の中身が入れ替わる、と捉えるのが近い。

読者側の判断としては、こう整理できます。日常的にローカルLLMを使いたいならOllamaやLM Studioで何も問題ない。NightRunが視野に入るのは、OS層そのものを外したい理由がある場合に限られます。

モデル規模と量子化の選び方

NightRunが対応するモデルは1B級から4B級。ローカルLLMの中では小さい部類で、精度を最大化する方向ではなく、OSレスの環境で確保できるRAMに収まり、CPU推論でも実用的な速度が出る範囲へ動作条件を合わせた規模帯だと読めます。

小型モデルが得意な仕事・苦手な仕事

規模帯が小さいモデルで何ができるのか、用途別に見ておく。

傾向として扱いやすいのは「入力が手元にあって、出力が短く、知識に依存しない」タスクです。逆に文脈の保持や多段の推論が要る仕事では制約が出やすい。ただしパラメータ数と知識量やコード性能が単純に比例するわけではなく、学習データ、蒸留、ファインチューニング、アーキテクチャ、タスク適性によって、小型のコード特化モデルが大型の汎用モデルを上回ることもあります。なお当サイトでは、NightRunで動かした場合のタスク別の品質を実測していません。

GPU推論との住み分け

生成速度だけを見れば、GPU推論のほうが有利な場面が多い。ただし両者は、生成速度という同じ軸で優劣を付けられる関係ではありません。

NightRunはGPUドライバスタックを持たない前提で作られています。UEFI Boot Servicesが提供するフレームバッファへ描画はしますが、GPUの演算ユニットを推論に使う構成ではない。一方、一般的なローカルLLM環境はVRAMにモデルを載せて回す方向です。両者は、そもそも使っている演算資源が違う。

比較するなら、こういう軸の違いになります。GPU側はより大きいモデルをより速く回す方向。NightRunは単機能・隔離という方向で、消費電力の水準は載せるハード側（Raspberry Pi 5のような低消費電力機を選ぶかどうか）で決まります。同じ「ローカルLLM」という言葉で括られていても、解こうとしている問題が別物です。

速度について、当サイトでの実測はありません。以下はすべて公式リポジトリが公開している値で、測定条件も公式の記載に従います。

公式のx86側の測定は実機ではなく仮想環境です。QEMU q35・KVM・-cpu max -smp 8・OVMFという構成で、ホストは12スレッド（AVX2）・RAM 15GB。2026年7月7日の更新でプロンプト処理がバッチ化された後の値として、Llama 3.2 1B（Q8_0）がプロンプト処理52〜56 tok/s・起動から対話開始まで5.6秒、Granite 4.1 3B（Q4_K_M）が23〜27 tok/s・9.5秒、Qwen3 4B（Q4_K_M）が約23 tok/s・11.5秒と記載されています。

実機で測られた値はRaspberry Pi 5の1件です。D0ステッピングの8GBボードにSDブート、ピン留めソースからビルドしたファームウェアという条件で、Granite 4.1 3B（Q4_K_M）がプロンプト処理6.2 tok/s・初回トークンまで1.9秒・生成3.0 tok/s。ただし公式はこのPi 5の数値について、現在ツリーに入っているArmのドット積（sdot）カーネル導入前の測定だと注記しています。

整理すると、公表されている数値からはOSレス設計そのものの速度効果は分かりません。分かるのは生成処理（decode）の速度がllama.cppと同水準だということまでで、同一ハードでOSあり・なしを突き合わせた測定は公式にも当サイトにも存在しない。前段で整理した「空くのは占有と競合であって、CPUの演算性能とメモリの物理帯域は変わらない」という切り分けは、この空白と矛盾しない読み方です。なお公式は、x86については64ビットUEFI機でSecure Boot無効という条件を示しつつ検証はQEMU/OVMFで行ったとし、実機の広いカバレッジは未解決の課題だと明記しています。手元のx86実機で同じように起動する保証は、ここには含まれません。

どちらを選ぶかの判断材料

選択の分岐点はいくつかあります。まず、GPUを持っているかどうか。手元にVRAMに余裕のあるGPUがあるなら、Ollamaなどで動かすほうが素直です。より大きなモデルを高速に回せて、他のアプリからAPI経由で使える。

次に、その端末で他のことをするかどうか。日常的にブラウザやエディタを使うマシンなら、OSレス環境を選ぶ理由はありません。NightRunの利点である「OSが無い」は、そのマシンでOSを使わないと決められる場合にだけ意味を持ちます。

最後に、外部への出口をどう扱いたいか。生成結果をファイルへ保存したり、他のアプリへ渡したりする運用が必要なら、既存のランタイムを使うべき。逆に、単体で完結する端末を作りたいなら、NightRunの制約はそのまま設計上の特徴になります。

用途を先に決めて、それに合うほうを選ぶ。生成速度だけを並べても判断材料にはならない、という意味です。

導入前に確認すべきことと想定用途

実験的なオープンソースプロジェクトである、という前提を最初に押さえておく必要があります。日常業務のマシンに導入するものではなく、試したい人が試す段階のもの。そのうえで、実際に動かすなら確認すべき項目を整理します。

確認する順に並べると、まず対応ハードの条件。x86_64のUEFI PCならSecure Bootの無効化というファームウェア設定の変更が要り、Raspberry Pi 5ならmicroSDカードから起動する構成になります。次に起動媒体で、常用しているOSのストレージとは別に専用の1本を確保しておけば、合わなければ媒体を外すだけで元に戻せます。最後にモデルで、公式が配布対象として挙げている4モデル以外を使う場合は、同梱のnrconvertでGGUFから変換する形になります。

向く用途・向かない用途

用途の適合を整理すると、線引きははっきりしています。

向く用途: – ネットワークから切り離した端末の設計を検証する実験機として使う – 展示やデモで「LinuxもWindowsも入れずにLLMが動く」ことを見せる – 条件を満たす余剰PCやRaspberry Pi 5を実験機として再利用する – UEFIやブートスタックの仕組みを学ぶ教材にする

向かない用途: – 日常の作業マシンとして常用する – 他のアプリケーションと連携させる – 大型モデルを動かして精度を求める – 生成結果をファイルへ保存して蓄積する

隔離の検証用途が筆頭に来るのは、ストレージ封印という設計と噛み合うため。ロード後にディスクへの読み出しがハードフォールトになる構造は、ランタイムの側に読み出し経路が残らないことを意味します。ただしこれは監査済みの隔離保証ではありません。通信経路についても、公式はランタイムにネットワークスタックを持たないと明記しています。設計上の言明であって第三者監査ではないため、要件の厳しい運用では実機での確認工程が残ります。

学習用途も選択肢に入ります。UEFIアプリケーションがどう起動し、Boot Servicesでキーボードとフレームバッファをどう扱うのか。普段OSが隠している層を動くソフトウェアとして観察でき、Rustで書かれている点も実装を読む側の手掛かりになります。

試す前のチェックリスト

手を動かす前に確認しておく項目をまとめます。

1. 手元の機体がx86_64のUEFI PCか、Raspberry Pi 5か（Pi 5で実機検証が報告されているのは8GBボード。4GB版はRAM要件上1B級までで、動作確認は示されていない）
2. x86の場合、ファームウェアでSecure Bootを無効化できるか（企業管理端末では変更できない場合がある）
3. ディスク暗号化を使っているなら、回復キーが手元にあるか
4. 常用環境と分離できる起動媒体（USBメモリまたはmicroSDカード）を用意できるか
5. イメージを書き込む際に、書き込み先のドライブ名を確認したか（公式も誤ったディスクへの書き込みは復旧不能と警告している）
6. 搭載RAMがモデル規模に対して足りているか（規模が上がるほど要求は上がる）
7. CPUのSIMD命令対応状況を仕様表で確認したか（x86の場合）
8. 試した後にファームウェア設定を元に戻す手順を把握しているか

このうち2番目は環境によって詰まる点で、企業から貸与されたPCではファームウェア設定にロックがかかっていることが珍しくありません。設定画面に入れない、Secure Bootの項目がグレーアウトしている、といったケースでは、そのマシンは対象外になる。常用機ではなく、設定を自由に変えられる検証機が前提です。

まとめ

GPUを持っているかどうかが最初の分岐です。VRAMに載せて回せる環境があるなら、大きなモデルを速く動かせて他アプリからAPI経由でも叩ける既存ランタイムのほうが素直で、わざわざOS層を外す必要はありません。次に、その機体でOSを使うかどうか。ブラウザもエディタも動かす常用機なら、OSレスの利点は打ち消されます。最後に、生成結果の出口をどうしたいか。ファイルへ保存して蓄積する運用が必要なら噛み合いません。この3つとも「外してよい」と答えられるときに、はじめて候補に入る構成。

得られるものと得られないものは分けて数えておきたいところ。空くのはOSが抱えていた実装メモリと、他プロセスに取られていたCPU時間・ディスク帯域です。OSを外しても、CPUの演算性能やメモリ帯域のハードウェア上限そのものが引き上げられるわけではありません。理屈のうえでは搭載RAMが小さい機体ほど差が出やすく、RAMに余裕がある機体やGPUで回している構成では効きが薄い。ただし同一ハードでOSあり・なしを比べた公表値は無く、当サイトでも実測していないため、ここは機構からの推定です。

実際に試すなら、常用機ではなく検証機を1台決めるところから。Secure Bootの項目を変更できるか、ディスク暗号化の回復キーが手元にあるか、設定を元へ戻す手順を控えたか。この3点を通過したら専用の媒体を1つ確保し、搭載RAMに収まる配布モデルを選ぶ。公式の目安は1Bが4GB、3B級が6GB、4B級が8GBです。

隔離の検証に使う場合、留保が3つ残ります。実行時のCRC-32が担保するのは偶発的な破損の検出までで、真正性はインストーラ側のSHA-256検証が受け持つものの、それもリポジトリとマニフェストを信頼する前提の仕組みです。通信挙動は公式がネットワークスタック不在と明記しているものの第三者監査ではないため、実機での確認工程は運用側に残る。そしてストレージの封印はランタイムのレベルの措置で、監査済みの隔離保証ではありません。生成速度も当サイトでは測っていないので、数値が要るなら手元の機材で計測するのが早道です。

よくある質問

Q. 常用しているPCの環境を壊さずに試せる？

起動媒体を分ければ、常用OSの入ったストレージに触れずに試せます。ただしx86 PCではSecure Bootの無効化が必要で、これはPC全体のブート方針を変える操作です。ディスク暗号化を有効にしている環境では回復キーを求められる場合があるため、設定前の状態を控え、回復キーを用意してから進めることになります。

Q. AVX2に対応していない古いPCでも動く？

x86側の推論カーネルはAVX2・FMA・F16Cを使う前提で最適化されていますが、公式はAVX2非対応のCPU向けにスカラー実装も残していると説明しています。つまりAVX2は絶対的な起動条件ではなく、無い場合はスカラーカーネルに落ちて速度が大きく下がる可能性がある、という関係です。加えて古い実機ではUEFIファームウェアとの相性が未検証のため、実用的に動くことが保証されるわけではありません。対応命令セットは、Windows環境ならCPU-Z等のツール、Linuxなら/proc/cpuinfoの内容から確認できます。

Q. Raspberry Pi 5以外のSBCでも動く？

対応ハードとして挙げられているのは、64ビットのx86_64 UEFI PCとRaspberry Pi 5の2つだけです（Pi 5側で検証が示されているのは8GBボード）。他のシングルボードコンピュータについては情報が確認できないため、動くとも動かないとも言えません。SBCはブート方式もSoCの構成も機種ごとに異なり、Raspberry Pi 5向けの実装がそのまま通用する保証はありません。

Q. ネットワークから完全に切り離された状態になる？

公式リポジトリのREADMEには、カーネル・ブラウザ・ネットワークスタック・ホストプロセスのいずれも存在しないと記載があります。設計としてはネットワークに出る経路を持ちません。ただし開発側の言明であって第三者による通信監査ではないため、要件の厳しい隔離運用では実機での確認工程が残ります。ストレージ側については、ロード完了後に封印され、以降のディスク読み出しがハードフォールトになる構造だと説明されています。

Q. 生成した文章を保存したり別のPCへ渡したりできる？

ファイルへ保存する経路は前提に置かれていません。組み込みのUIはチャット表示・プロンプト編集・履歴の範囲で、保存機能は説明されていない。加えてロード後はストレージが封印される設計のため、生成結果は画面で読む形になります。別マシンへ渡す手段も、公開されている機能の説明範囲には含まれていません。出力を蓄積して再利用したい用途には向かない構成だと理解したうえで選んでください。

Q. 日本語で使える？

画面表示に制限があります。組み込みのUIが使うSpleenビットマップフォントはCJKのグリフを持たず、公式のアーキテクチャ資料は絵文字とCJKのコードポイントを空白として描画すると説明しています。トークナイザーと履歴には元の文字列が残るため内部の処理は進みますが、結果を画面で読めません。OSの日本語入力システムも無いため、日本語での対話を前提にする使い方は現状では成立しない構成です。

参考資料

• NightRun 公式リポジトリ（github.com/hardrave/NIGHTRUN）
• Ollama Releases: v0.31.2
• llama.cpp Releases: b10188