> [!abstract] 概要(arXiv abstract の日本語訳) > オンライン OS チューニングは長時間稼働するサービスを改善しうるが、既存のコントローラは稼働中ホストとの相性が悪い。それらはスケジューラ・電力・メモリ・I/O の制御をブラックボックスの変数として扱い、スカラー報酬を最適化する。この見方はノブ間のポリシー構造を無視し、アプリケーションメトリクスが得られないときに破綻し、悪い設定を取り除いた後も持続する劣化領域へ稼働中のサービスを追い込みうる。本論文では、定常状態の OS チューニングを、境界づけられた言語モデルの助言によって行うホスト側フレームワーク TuxBot を提示する。TuxBot はノブスキーマ・テレメトリ・現在の設定・直近の行動-応答履歴・過去実行の検索結果を、コンパクトな意思決定コンテキストへと変換する。低遅延の更新を提案する高速ループと、探索戦略を定期的に見直す低速ループが対になっており、提案されたすべての変更はカーネルや sysctl インタフェースに到達する前に型付き検証を通過する。これにより、モデルコスト・遅延・権限を制約しつつ、コントローラが OS 制御の意味論と間接的な性能シグナルについて推論できるようにする。我々は 5 つのベンチマークスイートから 13 の稼働中ワークロードで、最大 41 の Linux パラメータをチューニングしながら TuxBot を評価した。このスイート全体で、TuxBot は安定フェーズの性能を default 設定比 72.5%、最強の非 LLM ベースライン比 153.3% 改善する。30 ウィンドウのセッションはモデル呼び出しにつき約 $0.20 のコストで済む。ホストレベルのメトリクスのみを用いた場合でも、TuxBot はアプリケーションの直接的な目的関数を与えられたベースラインを 93.7 パーセントポイント上回りつつ、構造を無視した探索が到達する深刻な劣化領域を回避する。 ## 論文情報 - タイトル: TuxBot: Semantic-Aware Online OS Tuning with Large Language Models - 著者: Georgios Liargkovas([[Columbia University]])・Mihir Nitin Joshi([[Columbia University]])・[[Hubertus Franke]]([[IBM Research]])・Kostis Kaffes([[Columbia University]]) - 媒体: arXiv プレプリント(cs.OS)。v1 投稿 2026-05-14、v2 改訂 2026-07-14 - arXiv ID: 2605.15026 - コード: https://github.com/Columbia-DAP-Lab/TuxBot(公開) ## 概要 TuxBot は、オンライン OS チューニングにおいて既存のベイズ最適化・強化学習ベースのチューナー(MLOS 等)が陥る「意味論的盲目性」を、LLM による意味論的推論で解決するホスト側フレームワークである。低遅延な Instant ループと低頻度・高推論予算の Reasoning ループから成る dual-loop 制御、セッション内・セッション横断のメモリ、型付き検証済みアクチュエーションの 3 点を組み合わせ、スケジューラ・電力・メモリ・I/O にまたがる最大 41 個の Linux ノブを安全かつ効果的に調整する。 ## 問題設定 - **入力**: チューニング目標(例: PID の p99 最小化、CPU 電力 60W 未満)、対象ノブ集合とそのスキーマ(型・範囲・依存関係)、稼働中ホストのテレメトリ(アプリケーションメトリクスが利用可能な場合はそれも含む)。 - **出力**: 各チューニング区間(5 秒程度のウィンドウ)ごとに提案される OS ノブの更新値。 - **前提条件**: チューナーはリクエスト単位でインラインに動くカーネル高速パス制御器(CPU スケジューラ・パケットスケジューラ・輻輳制御等)ではなく、数秒〜数分の時間スケールで定常状態の稼働アプリケーション性能を改善する「out of band」なオンライン制御器として動作する。 - **必要なデータ**: perf stat カウンタ・RAPL パッケージ/DRAM 電力・C-state 残留時間・CPU 負荷等のシステムメトリクスは TuxBot に組み込み済みで自動収集される。アプリケーションメトリクスは、ワークロード種別ごとに一度だけパーサと集約規則を定義すれば取得可能(多くの場合 30 分未満の工数)。 ## 提案手法 - **アーキテクチャ**(Figure 3): System Performance Tools(PMU・RAPL 等)と Application からの OS/アプリメトリクスを API-Telemetry(§5)が集約し、Context Manager(§4.1)がクロスラン Memory(§4.3)と組み合わせて Tuning prompt を構築する。Tuner(§4.2)がノブ更新を提案し、Parameter Validator(§4.4)が型・カテゴリ・依存関係を検証したうえで OS Knobs(スケジューラ・NAPI・電力)に適用する。1 回のチューニング区間はこの 6 ステップ(①タイプ付きチューニング要求 → ②テレメトリ取得 → ③メモリ結合 → ④コンテキスト構築とプロンプト送信 → ⑤検証済みノブ提案 → ⑥適用)から成る。 ![[_attachments/arxiv-2605.15026/fig03-system-overview.png]] (Figure 3. TuxBot のシステム概観。System Performance Tools と Application からのテレメトリを API-Telemetry が収集し、Context Manager が Memory と統合してチューニングプロンプトを構築、Tuner が提案したノブ更新を Parameter Validator が検証してから OS Knobs に適用する 6 ステップの制御ループ。Source: Figure 3.) - **コンテキスト構築(§4.1、Figure 4)**: プロンプトはセッション仕様(役割・タスク・制約・アクティブなノブ集合とメタデータ・探索戦略・クロスラン記憶から合成したウォームスタート事前分布)と、毎回更新される per-iteration update(現在の設定・直近の計測値・直近の行動-応答トレース)から構成される。コールドスタート時はクロスラン記憶なしで最初のリクエストを送る。 - **Dual-loop 制御(§4.2、Figure 5)**: 高速な Instant ループ(1〜5 秒ごと)は局所的な探索と即時修正を担い、低速な Reasoning ループ(数十秒ごと)はより長い履歴を見て探索戦略全体を見直す。両ループは共有コンテキストを読むが、履歴の保持方法が異なる。Reasoning の結果(reasoning context entry)は次の Reasoning が消費するまで永続するのに対し、Instant の結果(instant context entry)は次の Reasoning 結果がコミットされた時点で消費・除去される。この置換ポリシーにより、Instant コンテキストの無制限な増大が O(|Reasoning|) に抑えられ(O(|Instant|) にならない)、コンテキスト膨張による遅延・品質劣化が防がれる。オプションとして、セッション冒頭の少数イテレーションだけ LLM 推論を使って探索空間を刈り込み、その後は縮小された空間を MLOS 等の下流オプティマイザに委ねる TuxBot-Trim(ST-Trim)モードも用意する。 - **メモリ(§4.3)**: セッション内ではチューニング区間ごとに選択した行動・結果設定・観測されたシステム/アプリケーションメトリクス・制約状態をコンパクトなトレースとして保持し、直近の行動-応答履歴として後続プロンプトに供給する。セッション横断では、各セッションの per-iteration トレースを ChromaDB ベクトルストアに保存し、新規セッション開始時に最初の 1 ウィンドウから構築したブートストラップクエリで埋め込みベースの近傍検索を行い、上位 k=3 件の類似する過去実行を取得する。Reasoning モデルが取得した実行群を圧縮し、再利用可能なパラメータ関係・有望/危険な領域・初期探索の助言を含む短いテキスト要約(クロスラン記憶事前分布)を生成し、以降の全イテレーションのセッション仕様に注入する。この事前分布は制約ではなくソフトなヒントであり、実測値と新規の行動-応答履歴が古い記憶を上書きする。 - **型付き検証とアクチュエーション(§4.4)**: モデル出力は提案にすぎない。Context Manager はアクティブなノブスキーマ・現在のノブ状態・パラメータ記述・カテゴリ的定義域・依存関係のヒントを構造化プロンプトに含め、応答スキーマを現在のチューナブル集合から設定する。Parameter Validator は現在のチューナブル集合内のノブのみを受理し、カテゴリ的定義域を検査し、必要に応じてアクティブなコアマスクに沿って per-core 更新を展開し、アクティブなセッションポリシー外の提案を拒否する。検証を通過した提案は debugfs・sysfs・CPU 周波数パス・sysctl 等のインタフェースを通じてホスト側ロックの下で書き込まれ、書き込みが成功した場合のみ新しい運用点として記録される(失敗時は直前の設定を維持)。各提案は正当化・タイミング・適用結果とともに記録され監査可能。 - **実装上の工夫**: Python 制御プレーンとして実装され、コア(dual-loop チューナー・テレメトリ/アクチュエーションパス・セッションロジック)が 6,374 SLOC、ベースラインチューナーが 3,775 SLOC。OpenAI API・OpenRouter・Gemini 互換のバックエンドをすべてサポートし、LLM 応答は自由形式のシェルアクションではなく構造化された型付きチューナー応答(ノブ更新・短い説明・収束フラグ・オプションのコマンド・トークン使用量メタデータ)として返される。クロスラン記憶のベクトル化には Gemini Embedding、ベクトルストアには ChromaDB を使用。TuxBot は終了時に default 設定を復元する。 ## 新規性 既存のオンライン OS チューニング(MLOS などのベイズ最適化・Q-Learning/DQN 等の強化学習)は、各 OS ノブを独立な数値変数として扱い、スカラー報酬を最適化する。しかし著者らは、カーネルがこれらの設定を独立に適用せず、スケジューラ・CPU 電力・メモリ・I/O の設定を組み合わせて 1 つの実行時ポリシーとして解釈する点を示し、この見方が 3 種類の失敗を招くと論じる。 1. **数値的妥当性は良いポリシーを意味しない**: Memcached の高負荷実験(Table 1)で、MLOS は極端なビジーポーリング・浅い C-state・数十 ms のスケジューラウィンドウを組み合わせる、数値的には妥当だが当該ワークロードには意味を成さない設定(20〜25 秒で p99 が 64〜68 ms に悪化)や、minperfpct>maxperfpct のような意味論的に矛盾する設定(225 秒・250 秒)を繰り返し訪問する。 2. **報酬の欠落と誤解を招くプロキシ**: アプリケーションメトリクスが得られない実運用では、IPC やキャッシュミスのような単一の低レベルプロキシに置き換えると性能が大きく悪化する(PostgreSQL/Wikipedia で p99 が最大 2 倍悪化、Figure 2 左)。 3. **ノブが増えるほど意味論的リスクが増大する**: PostgreSQL/TPC-C でチューニング対象を 1 から 32 ノブに増やすと p99 が 50% 悪化する(Figure 2 右)。Linux は既に 1,200 超のチューナブルノブを公開しており、この傾向は制御サーフェスの拡大とともに悪化する。 TuxBot はこれらの失敗の根本原因(意味論的構造の欠如)に対処するため、LLM を「ノブ名・サブシステム構造・ドキュメント・現在のテレメトリ・直近履歴」から候補設定を文脈内で解釈できる意味論的推論器として位置づける。これにより、(a) 矛盾する/ワークロードに無意味なノブ組み合わせを事前に棄却し安全な修復を提案できる、(b) 単一の脆いプロキシではなく joint telemetry signature(CPU 飽和度・ランキュー増加・メモリ圧迫・電力状態の振る舞い・I/O 待ち)からアプリケーション進捗を推論できる、(c) 制御サーフェスが大きい場合にサブシステムと現在の症状を関連づけて探索を絞り込める、という 3 つの能力を得る。 先行する LLM ベースのシステムチューナー(DB-BERT・GPTuner・λ-Tune・SchedCP・ADRS 等)は主にオフラインまたは統制された設定で探索を構造化・刈り込み・誘導するのに対し、TuxBot は同じ意味論的推論をライブのオンライン制御ループに持ち込む点で異なる。単一ループのプロンプト駆動チューナーである Expert in Residence [59](同じ著者グループによる先行研究、狭い Linux CFS 設定のみを対象)とも異なり、TuxBot は明示的なコンテキスト構築とメモリを備えた dual-loop 制御で、スケジューラ・電力・メモリ・I/O・ネットワーキングにまたがる最大 41 ノブの OS 全体サーフェスを co-tune する。 ## 実験設定 - **実験環境**: CloudLab のベアメタルホスト(Intel Xeon Silver 4114 デュアルソケット、40 ハードウェアスレッド、192 GiB DRAM、Ubuntu 22.04.2 LTS、Linux 5.15.0-160-generic)。ホストごとに 1 ベンチマークを実行し、レイテンシ指向の実行は CPU 0-9 にピン留め(性能カウンタの採取対象と一致)。 - **対象ノブ空間**: 既定は CFS(min_granularity_ns・latency_ns・wakeup_granularity_ns・migration_cost_ns)・DVFS(min_perf_pct・max_perf_pct)・C-state 選択(cstate_max)・NAPI ポーリング(napi_busy_poll)の 8 ノブ。より高次元の実験では energy-performance preference・turbo・PM QoS・VM dirty/writeback 設定・NUMA トグル・ソケットバックログ/バッファサイズ・TCP 挙動などを加えて最大 41 ノブに拡張。 - **データセット/ワークロード**: 5 ベンチマークスイート・13 ワークロード(Memcached/Mutilate、BenchBase 上の PostgreSQL 14 の TPC-C・Wikipedia・YCSB・Twitter・SIbench・Masstree・Silo・Xapian・Sysbench OLTP-RW、Tailbench、Sysbench CPU、DCPerf の Sphinx・Sparkbench)。レイテンシ指向グループは p99 最小化、スループット指向グループ(Sphinx・Sysbench CPU・Sparkbench)は最大化を目的とする。 - **比較対象**: Default Parameters(Ubuntu 22.04 既定設定)、MLOS(SMAC3 + Expected Improvement によるベイズ最適化。全ベースライン中最強かつ大規模混合型ノブ空間に自然にスケールする唯一の手法として主要な非 LLM ベースラインに採用)、単純なベイズ最適化ベースライン、表形式 Q-Learning、DQN。LLM 変種として Single-Reasoning(Reasoning ループのみ)・Single-Instant(Instant ループのみ)・TuxBot-Trim(ST-Trim、10 ウィンドウで刈り込み後 MLOS に引き渡す)。 - **評価指標**: Default Parameters に対する相対改善率(乗法的改善係数の幾何平均、5 回リランの平均、標準偏差を誤差棒表示)。30 チューニングウィンドウ + 20 安定ウィンドウを 1 反復単位とし、TuxBot は最終受理アクション後にノブ変更を止める(安定フェーズ)のに対し、MLOS 等の連続探索ベースラインは 31〜50 ウィンドウ目も探索を継続する。追加のロバスト性指標として P50/P10 bad-window rate(Default Parameters より悪い区間の割合の中央値/10 パーセンタイル)と variability(リラン間の標準偏差を Default Parameters の平均で正規化した値)を用いる。 ## 実験結果 - **ベースライン比較(§6.2、Figure 6)**: TuxBot はチューニング中に Default Parameters 比 +59.36%、安定フェーズで +72.5% 改善する唯一の手法で、MLOS(-33.79%/-31.91%)・TuxBot-Trim(-30.62%/-26.14%)・Bayesian(-45.77%/-37.46%)・DQN(-40.41%/-44.49%)・Q-Learning(-51.66%/-58.49%)は全て負を記録する(数値は Xapian・Memcached の破局的劣化を含む全ベンチマーク平均)。破局的劣化を除いた 11 ベンチマーク部分集合では、TuxBot は +72.49% から +87.22% に上昇するのみだが、古典ベースラインは大きく上昇し(MLOS +50.52%、Bayesian +37.37%、DQN +33.68%)、この差は Xapian と Memcached での queue-dominated metastable failure に起因する。 - **間接シグナル下の性能(§6.3、Figure 7)**: アプリケーションメトリクスをシステムメトリクスに置き換えても TuxBot の劣化は小さい(直接メトリクス +72.5% → システムメトリクス +31.9% → IPC 単独 +16.2%、いずれも安定フェーズ)。MLOS はアプリケーションメトリクスを与えられていても TuxBot(システムメトリクスのみ)に対し安定フェーズで 104.4 ポイント劣る。 - **Dual-loop vs. 単一ループとコスト(§6.4、Figure 8)**: 非破局的部分集合で TuxBot は安定フェーズ +87.2%(セッションあたり $0.20)、Single-Reasoning は +89.7%($0.42)とほぼ同等ながら約半分のコストで達成する。Single-Instant は $0.12 だが +25.4% と大きく劣る。TuxBot-Trim は +63.9%($0.15)で TuxBot に及ばない。 - **探索フェーズのロバスト性(§6.5、Figure 9)**: 破局的ケースを除き、TuxBot の集計 P50 bad-window rate は 16.9%(MLOS 28.8%、TuxBot-Trim 29.7%)、P10 は 12.0%(MLOS 26.3%、TuxBot-Trim 29.6%)、variability は 11.1%(MLOS 25.1%、TuxBot-Trim 24.7%)。TuxBot は 13 ワークロード中 12 で MLOS より低い variability を示し、Xapian(10.9% vs 39120.2%)・Memcached(40.3% vs 1388.2%)で特に差が大きい。 - **パラメータ次元数へのスケーラビリティ(§6.6、Figure 10、Table 2)**: TPC-C・Sysbench OLTP-RW・Silo の 3 ワークロードで、TuxBot は 8〜41 ノブにわたり安定フェーズで +105%〜+216.7% を維持するのに対し、MLOS は 4 ノブで +119.3% だったものが 16・32・41 ノブで +19.6%/+28.3%/+13.0% に急落し、チューニングフェーズは既にマイナス(-7.4%/-6.3%/-11.1%)になる。決定latencyもMLOSは1ノブの0.49秒から41ノブで5.73秒へ10倍に増加するのに対し、TuxBotのReasoningループは8.08〜15.80秒でスケールと強く連動せずクリティカルパス外にあり、Instantループは1.01〜2.55秒を維持する。 - **クロスラン記憶によるウォームスタート(§6.7、Figure 11)**: 未見ワークロード(TPC-C・Silo・Sysbench OLTP-RW を評価対象から除いた記憶を用いる transfer 設定)で、Top-3 記憶はアプリメトリクスで +155.6%/+202.9%(チューニング/安定)まで改善し、No Memory(+86.3%/+144.7%)や Top-1(むしろ最も弱い、記憶が単一の弱い一致に引きずられるため脆い)を上回る。Top-3 はランごとのばらつきも縮小させる(誤差棒 54.6/106.0 → 14.1/15.3)。 - **モデルバックエンドの比較(Appendix A.2、Figure 12)**: 同じ dual-loop アーキテクチャで Gemini 2.5 Flash($0.20/セッション、+153.7%/+216.7%)・Gemini 3 Flash($0.28、+138.4%/+152.7%)・Kimi K2($0.048、+77.1%/+143.8%)を比較すると、Gemini 2.5 Flash が品質・コストの両面で最良、Kimi K2 は最安だが安定フェーズ後のばらつき(±85.0)が大きい。 ## 考察 - 失敗の根本原因は数値探索の弱さではなく、ノブの意味論的構造(依存関係・矛盾・ワークロードとの整合性)を無視していることにある。LLM はこの意味論を「人間の専門家が経験・知識・直感から避けるであろう領域」を回避する形で埋め合わせる。 - Dual-loop アーキテクチャは、単一の強力な Reasoning モデルだけを置く場合の「遅い意思決定による収束の遅延・コスト増」と、Instant モデルだけを置く場合の「局所最適への停滞」の双方を回避する設計上の折衷であり、コンテキスト増大を O(|Reasoning|) に抑える置換ポリシーが鍵となる。 - TuxBot-Trim(オンライン刈り込み → MLOS に引き渡す)は MLOS 単体より改善するが、TuxBot 本体には及ばない。これは「良い探索範囲を与えるだけ」では不十分で、探索の後半段階でも意味論的理解が必要であることを示す(Instant ループを LLM ベースにする設計判断の妥当性を裏付ける)。 - クロスラン記憶は「制約」ではなく「ソフトなウォームスタートのヒント」として設計されている。Top-1 が Top-3 より劣るという結果は、単一の過去実行に偏った記憶が探索を弱い領域に誘導しうることを示し、複数実行の要約が偏りを緩和する。 - TuxBot は非専門家の開発者/運用者や、細粒度のアプリケーションメトリクスを公開できないレガシー/不透明なサービス向けに設計されている。定常状態のオンラインチューニングを対象とするため、短命ジョブや急変するバースト性ワークロード、サブ秒の反応を要する過負荷エピソードには不向き(この境界はチューニング目標の性質によるものであり、LLM のオーバーヘッドだけによるものではない)。 - 運用ドリフトへの対応は現状「小さいドリフトは現在/直近の安定設定から再開、大きいドリフトはゼロからセッションを再開する」という単純な方針であり、著者らは永続的なワークロード/プラットフォームシフトの検知・対応を今後の課題としている。複数アプリケーションの co-located なチューニング(干渉・多目的報酬・cgroups 等でのパーティション化された制御領域)も本論文のスコープ外。 ## 強み / 弱点・課題 **強み** - MLOS を含む全ベースラインに対し、チューニング・安定フェーズの両方で一貫して優位(§6.2)。かつ 13 ワークロード中 9 で改善、劣化はゼロ(安定フェーズ)という「広く効く」性質(Table 3 の観察)。 - アプリケーションメトリクスが得られない環境でも実用的な性能を維持できる(§6.3)ため、レガシー/不透明サービスへの適用可能性が高い。 - 30 ウィンドウあたり約 $0.20 という低い運用コストで、dual-loop により単一 Reasoning ループとほぼ同等の品質を約半分のコストで達成する(§6.4)。 - ノブ数が増えるほど MLOS との差が拡大し(§6.6)、Linux の巨大な実際の制御サーフェス(1,200 超のノブ)への適用に対してスケーラブルな性質を示す。 **弱点・課題(著者らが明記または本文から読み取れる懸念)** - 破局的劣化を除外した部分集合では TuxBot の相対的な優位が縮小する(+72.49%→+87.22%)。これは Xapian・Memcached という 2 ワークロードでの他手法の壊滅的失敗が全体平均を支配的に押し下げているためであり、TuxBot の優位性の一部は「破局を避ける」効果に由来する。 - クロスラン記憶は k=1 で脆く、単一の類似実行に強く依存すると探索を弱い領域へ誘導しうる(§6.7)。 - モデルバックエンドへの依存があり、Gemini 2.5 Flash 以外(Gemini 3 Flash・Kimi K2)では品質・コスト・安定性のいずれかが劣化する(Appendix A.2)。 - 単一アプリケーション・単一ホストのセッションを前提とした設計であり、co-located な複数アプリケーションのチューニングや、ドリフト検知の高度化は today's TuxBot の範囲外として今後の課題に位置づけられている(§4.5)。 - ワークロードごとのアプリケーションメトリクス取得には(軽量とはいえ)ワークロード固有のパーサ・集約規則の実装が必要で、Tailbench のように区間レベル計測のための改造を要した例もある(§5)。