本機推論
KoboldCpp 1.120がDirectIO読み込みモードを追加、mmapとmlockの同時有効化も可能に
新版では大規模なGGUF重み向けに`--usedirectio`が追加され、mmapでモデルをマッピングする際に関連するメモリページをロックできるようになった。Qwen3.8-Flash-Next、Ling-3.0-flash、カスタムJavaScriptツールにも対応するが、公式から読み込み速度やメモリのベンチマークはまだ公表されていない。

KoboldCpp 1.120では、ローカル推論ユーザーが利用できるモデルファイル読み込み戦略がさらに拡充された。[公式リリースノート](https://github.com/LostRuins/koboldcpp/releases/tag/v1.120)では`--usedirectio`が追加され、対応プラットフォームでdirect I/Oを使用してGGUFを読み込めるようになった。もう一つの変更として、mmapとmlockの併用も可能になった。mmapはOSがモデルのページをオンデマンドでマッピングする仕組みで、モデルが利用可能な物理メモリを上回る場合や、複数のプロセスでファイルを共有する場合に適している。mlockは、マッピング済みのページをスワップアウトしないようシステムに要求するためのものだ。両者を組み合わせることで、推論中のページングによるレイテンシーの変動を抑えられる可能性がある一方、常駐メモリへの負荷が増し、OSのメモリページロック上限による制約も受ける。
Direct I/Oの主な利点は読み込み段階にある。通常のキャッシュ経路に依存しない読み込みオプションを提供するため、数十GBの重みを一度だけ読み込む際に、ほかのファイルキャッシュを追い出す事態を回避できる可能性がある。ただし、実際の効果はSSD、ファイルシステム、読み込みアライメント、GPU offload構成に大きく左右される。リリースノートにはコールドスタート時間、スループット、対応プラットフォームの一覧が示されていないため、mmapより必ず高速だとあらかじめ想定することはできない。エンジニアリングチームは同じGGUFを使用し、コールド読み込みとウォーム読み込みに加え、読み込み後のfirst-token latencyとシステムメモリのピーク使用量をそれぞれ測定すべきだ。
1.120ではQwen3.8-Flash-NextとLing-3.0-flashのサポートも追加され、誤った量子化ファイルがすでにコミュニティで流通していることについて警告している。Kobold Liteでは、ユーザーが設定したJavaScriptツールを読み込み、標準のtool callingインターフェースを通じてモデルに渡せるようになった。これは同時に、ツールのコードに付与されるファイル、ネットワーク、プロセスへのアクセス権限を別途隔離する必要があることも意味する。新版ではこのほか、assistant prefillが誤ってトリガーされる問題と、failsafeモードが誤って選択される問題も修正された。[LocalLLaMAでの議論](https://www.reddit.com/r/LocalLLaMA/comments/1w2c4el/koboldcpp_v1120_released/)によると、DirectIOとメモリページロックの併用がコミュニティで最も注目されている変更だが、現時点ではハードウェアを横断した結論を導けるほどの報告は集まっていない。