2bitのDS4はGPUサーバーを自律構築できるのか

Kenetsu Hanabusa

— 4 min read
Share

新旧DS4 Q4/Q2でH100×2のクリーン構築を比較した

今回検証したのは、チャットの受け答えや単発のコード生成ではありません。クリーンなUbuntu 24.04に、NVIDIAドライバー、NVIDIA HPC SDK、GPU対応Quantum ESPRESSO、MUNGE、Slurmを順に導入し、最後にSlurmからGPU計算を完走させる、実運用に近い長時間タスクです。

構成を正確に書くと、次のとおりです。

A100×4上で動作するDS4が、クリーンなUbuntu 24.04を搭載したH100×2サーバーをSSH経由で構築・検証した。

DS4そのものをH100×2で動かしたわけではありません。推論側は全モデルともA100 80GBを4枚、構築対象だけがH100 PCIeを2枚搭載したサーバーです。

比較した4モデル

  • 2026-07-31以前のDS4 Q4
  • 2026-07-31以前のDS4 Q2
  • 2026-07-31版DS4 Q4
  • 2026-07-31版DS4 Q2

各GGUFはファイル名、サイズ、SHA-256を保存しました。モデルごとにH100×2を同じclean OSへ戻し、同じプロンプト、同じ安全制限、同じSSH経路、同じ最大時間、同じ再試行条件で実行しています。他モデルが導入したパッケージや設定は流用していません。

1MコンテキストをDS4とCodexの両方へ通知

長い自律作業では、モデルサーバーだけを1Mコンテキストにしても不十分です。操作役のCodex CLIが小さいコンテキストだと認識すれば、Codex側で先に履歴圧縮が起こる可能性があるからです。

そこで全モデルに次を固定しました。

  • DS4サーバー: 1,048,576 tokens
  • Codex CLI: 1,048,576 tokens
  • Codexカスタムモデルカタログ: 1,048,576 tokens、実効100%
  • 自動圧縮しきい値: 1,000,000 total tokens
  • DS4出力上限: 65,536 tokens
  • reasoning effort: xhigh

さらに各実行後、Codexのrollout、DS4のモデル情報API、リクエストトレースを照合しました。4モデルすべてで実効コンテキストは1,048,576、自動圧縮は0回でした。OpenAI公式リファレンスにもmodel_context_windowとmodel_auto_compact_token_limitが定義されています。OpenAI Configuration Reference

結果

項目 旧Q4 旧Q2 新Q4 新Q2
ドライバー/H100×2 成功 成功 成功 成功
HPC SDK/OpenACC 成功 成功 成功 成功
QE GPU SCF 成功 成功 成功 成功
MUNGE/Slurm 成功 成功 成功 成功
Slurm GPU隔離 成功 部分成功 成功 成功
Slurm経由QE 成功 部分成功 成功 成功
最終判定 成功 部分成功 成功 成功
実測時間 57分25秒 1時間20分22秒 1時間56分37秒 1時間16分04秒

予想以上に印象的だったのは新Q2です。NVIDIAドライバーをロードし、HPC SDK 26.5のCUDA 13.2環境でOpenACCを動かし、QE 7.6をSM90向けにビルドしました。直接実行したシリコンSCFだけでなく、Slurmの1GPUジョブ内でCUDA_VISIBLE_DEVICES=0とCUDA runtimeの可視デバイス数1を確認し、Slurm経由のQEでもJOB DONEまで到達しています。

NVIDIAの公式リリースノートでは、HPC SDK 26.5がCUDA 13.2U1を含むこと、CUDA 13.xのminor-version compatibilityにはR580以上のドライバーが必要であることを確認できます。HPC SDK 26.5 Release Notes、CUDA 13.0 Release Notes

旧Q2は何に失敗したのか

旧Q2も、QEのGPU計算自体には成功しています。H100を使ったSCFは収束し、JOB DONEも出ました。部分成功にした理由は別です。

第一に、QEの取得記録が評価で指定したQEF GitLabまたはquantum-espresso.orgではなくGitHubでした。第二に、保存されたビルドログが376 bytes、10行しかなく、完全なビルド記録とは言えません。第三に、Slurmジョブ内でCUDA_VISIBLE_DEVICESが空でした。H100を使って計算はできても、要求した1GPUへ隔離された証拠がありません。

Slurm公式ドキュメントは、GPUジョブステップにCUDA_VISIBLE_DEVICESを設定する動作を説明しています。今回、新Q2はここまで確認でき、旧Q2は確認できませんでした。Slurm GRES Scheduling

新Q4は遅いが、証拠が厚い

新Q4は1時間56分37秒で、旧Q4の57分25秒より約2.03倍長くかかりました。ただし、新Q4は2つの1GPUジョブの同時実行や2GPU割当、Slurm accountingまで踏み込み、最も広い証拠を残しました。

速さだけなら旧Q4、証拠の広さなら新Q4という違いがあります。GPUマキシマイザーの評価では、最終成功だけでなく、どこまで検証したかも分けて見る必要があります。

結論

この1回のテストで言えるのは、新DS4の2bit版が「小さく動くだけ」のモデルではなかったということです。旧Q2で未解決だったSlurmのGPU隔離まで自力で修正し、Q4と同じ最終到達点に達しました。

一方で、各モデル1回だけなので、成功率や一般的な知能差までは断定できません。次は実行順をランダム化して3～5回ずつ反復し、成功率、中央値時間、回復率を測る必要があります。

今回の結果は「4bitが勝ち、2bitが負け」ではありません。

  • 旧Q4: 最速で全項目成功
  • 旧Q2: QE GPU計算には成功したが、証拠とSlurm隔離が不足
  • 新Q4: 最も時間を使い、最も広くSlurmを検証
  • 新Q2: 旧Q2の未解決点を解消して全項目成功

長時間の実機構築では、答えの文章よりも、失敗後の修正と検証ログがモデル差をはっきり示しました。

YouTube動画版はこちら: https://youtu.be/nLyHazKafyQ

Read more