# DS4 DGX Spark Q2 評価プロンプト（公開用sanitized版）

> この文書は、評価時に1回だけ与えた統合プロンプトを公開用にsanitizedしたものです。SSH設定、hostname、内部path、Rescue OS partition識別子をplaceholderへ置換しています。命令内容は変更していません。
>
> 原文：290行、1,393語、15,969 bytes  
> 原文SHA-256：`a64dbb47a9386f94ee020b047d5d15b731c63f94885b89c3279b1a44ea350453`  
> 公開版は置換とこの注記の追加により、原文とは異なるSHA-256です。

---

# DS4 GPU Maximizer end-to-end bare-metal evaluation

You are controlling a clean Ubuntu 24.04 installation on a real two-GPU NVIDIA H100 PCIe server from DGX Spark. Work autonomously through failures. Do not merely propose commands: execute, diagnose, repair, and verify them. Read `RUN_METADATA.json` in your current workspace first and use its exact model identity in your report.

Your inference server and Codex CLI are both configured for a 1048576-token context window. Codex automatic compaction is set to begin at 1000000 tokens, and the server output ceiling is 65536 tokens. Do not manually compact the context. If any automatic compaction occurs, record it in the final report.

## Connection and safety boundary

- Connect only with `ssh -F <EVALUATION_SSH_CONFIG> <H100_EVALUATION_HOST>`.
- The target hostname must be `<H100_EVALUATION_HOSTNAME>` and `/` must be Btrfs subvolume `<EVALUATION_BTRFS_SUBVOLUME>`. Verify both before changing anything.
- Do not access, mount, modify, format, or inspect `<RESCUE_OS_PARTITIONS>`, or any Rescue OS/partition.
- Do not modify Tailscale, EFI boot entries, GRUB, or non-evaluation Btrfs subvolumes.
- Do not reboot. A reboot would intentionally return to PROD; load the newly installed NVIDIA modules live instead.
- `/data` is the large persistent work disk. Use only `<EVALUATION_RUN_DIR>` for downloads, source, builds, installs, and evidence.
- Do not read other run directories. They belong to other independently evaluated models.
- On DGX Spark, use only your current `<INFERENCE_WORKSPACE>` workspace and the read-only control files required for SSH. Do not inspect `<OTHER_USER_HOME>`, other users, or unrelated local files.
- You have passwordless sudo on the clean evaluation OS.

## Objective

1. Capture a baseline proving NVIDIA driver/toolkit, HPC SDK, Quantum ESPRESSO, MUNGE, and Slurm were initially absent.
2. Discover and install a production-appropriate NVIDIA open GPU driver for both H100 PCIe GPUs from official NVIDIA/Ubuntu sources. Do not reboot; unload conflicting modules if necessary and load the new modules live. Record package versions, kernel modules, `nvidia-smi`, GPU UUIDs, and driver/CUDA compatibility reasoning.
3. Obtain and install the current NVIDIA HPC SDK 26.5 for Ubuntu 24.04/x86_64 from an official NVIDIA source. Use the CUDA 13.2 bundle compatible with the chosen driver. Install large files under the run directory and expose a conventional `/opt/nvidia/hpc_sdk` path without copying another model's files.
4. Compile and run a small OpenACC or CUDA Fortran/C program on an H100. Record compiler commands and raw output.
5. Obtain official Quantum ESPRESSO 7.6 source from the QEF GitLab `qe-7.6` release/tag or quantum-espresso.org. Record URL, tag/commit, download date, and SHA-256.
6. Configure and build a GPU-enabled `pw.x` with NVIDIA HPC SDK. Install it at `/opt/qe/7.6/bin/pw.x` (the underlying data may live in your run directory). Preserve the complete build transcript.
7. Run a small scientifically valid silicon SCF calculation with a legitimate, clearly sourced pseudopotential. Preserve its input, pseudopotential provenance, launch environment, GPU evidence, and complete output containing `JOB DONE`.
8. Install and configure a single-node Slurm scheduler with MUNGE, systemd services, cgroup task tracking, and two NVIDIA H100 GRES devices. Both GPUs must be schedulable and CUDA_VISIBLE_DEVICES must be constrained correctly.
9. Submit a one-GPU Slurm job whose saved output contains `NVIDIA H100`.
10. Submit the successful QE silicon calculation through Slurm and preserve output containing `JOB DONE`.
11. Write the final report and evidence files described below. Include exact commands, failures, fixes, elapsed times, versions, caveats, and a concise reproducibility section.

## Required durable outputs

Use `RUN=<EVALUATION_RUN_DIR>` and create:

- `$RUN/final_report.md`
- `$RUN/evidence/baseline.txt`
- `$RUN/evidence/driver.txt`
- `$RUN/evidence/openacc-smoke.log`
- `$RUN/evidence/qe-source.txt`
- `$RUN/evidence/qe-build.log`
- `$RUN/evidence/qe-scf.in`
- `$RUN/evidence/qe-scf.out` containing `JOB DONE`
- `$RUN/evidence/slurm-gpu-job.out` containing `NVIDIA H100`
- `$RUN/evidence/slurm-qe-job.out` containing `JOB DONE`
- `$RUN/evidence/timeline.tsv`

## Evaluation rules

- You are judged on actual machine state and raw evidence, not confidence or prose.
- Use current official documentation when uncertainty matters.
- Do not fabricate success. If blocked, preserve logs and explain the precise blocker after exhausting safe alternatives.
- Do not ask the evaluator to run commands for you.


## Frozen comparison protocol

- The wall-clock limit is 6 hours per model, measured from the start of the Codex agent process to its exit or forced timeout.
- For each major objective (driver, HPC SDK, GPU smoke test, Quantum ESPRESSO build/SCF, MUNGE/Slurm, Slurm jobs), make at most 3 corrective attempts after the first failure.
- Do not repeat an unchanged failed command more than twice. Preserve every failure, then change to a reasoned safe alternative or mark the objective blocked.
- Do not ask for or accept solution hints from a human. Infrastructure-only intervention (for example, restoring the clean OS or repairing the evaluator's SSH control plane) is performed outside your run and must not be counted as your solution.
- Work serially. Do not delegate to subagents or use another model.
- Relative to the A100x4 baseline, the model file and checksum, DS4 runtime source commit, 1048576-token context setting, 1000000-token Codex auto-compaction threshold, 65536-token server output ceiling, xhigh reasoning setting, Codex CLI version, tool harness, target-side SSH method, LAN path, wall-clock limit, and retry limits are frozen. The deliberate experimental variable is the inference platform: one DGX Spark GB10 with 128 GB unified memory and an ARM64-native binary replaces four A100 80GB GPUs and an x86_64 binary.
- Treat any Codex context-compaction event as an evaluation event. Do not hide it. The evaluator will independently inspect the JSONL transcript and server logs for compaction and actual request limits.
- The text under the media-evidence addendum below was supplied by the evaluator and minimally adapted only to name DGX Spark as the inference platform. It does not relax any earlier safety boundary.


## Evaluator-supplied media evidence addendum (DGX Spark adaptation)

現在進めているDS4新旧モデル・4bit/2bit量子化モデルの評価について、最終的にServerGearのブログ記事とYouTube動画にまとめたいと考えています。

既存の安全境界、評価ハーネス、クリーンOSへの復元手順、操作対象の制限を最優先し、評価の公平性を崩さない範囲で、以下を意識して作業と証拠保存を進めてください。

目的は、単なる回答品質の比較ではありません。

「DS4の新旧モデルおよび4bit/2bit量子化モデルが、クリーンなUbuntu 24.04のH100×2 GPUサーバーに、実運用で必要となるソフトウェアをどこまで自律的に導入し、失敗を診断・修正し、実動作まで確認できるか」

を比較することです。

【重要な環境表記】

DS4の推論をDGX Spark側で実行し、SSH経由でH100×2サーバーを操作している場合は、結果に必ずその構成を明記してください。

「DS4をH100×2上で動かした」と誤解されないように、次のように表現してください。

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

モデルの推論環境と、構築対象のGPUサーバーを明確に分けて記録してください。

【公平な比較条件】

各モデルについて、可能な限り次の条件を統一してください。

- 同じクリーンOSの初期状態
- 同じ評価プロンプト
- 同じ安全制限
- 同じネットワーク条件
- 同じ利用可能時間
- 同じ最大再試行回数
- 同じ推論パラメーター
- 同じツールとSSH接続方法
- 他モデルが作成したファイルやインストール結果を流用しない
- モデル名、リリース、量子化方式、モデルファイル、チェックサムを記録する
- 推論ランタイム、コンテキスト長、主要設定を記録する

モデルの呼び方を「新」「旧」だけにせず、記事で特定できる正式なモデルID、リリース名または日付、4bit/2bitの方式を残してください。

【評価する作業】

少なくとも以下について、モデルごとに成功・部分成功・失敗を判定してください。

1. 初期状態の確認
   - NVIDIAドライバーが未導入であること
   - CUDA Toolkitが未導入であること
   - NVIDIA HPC SDKが未導入であること
   - Quantum ESPRESSOが未導入であること
   - MUNGEとSlurmが未導入であること
   - H100が2枚搭載されていること

2. NVIDIAドライバー
   - H100に適したドライバーを選択できたか
   - 公式または信頼できる配布元を選べたか
   - インストールできたか
   - 再起動禁止条件の中でモジュールをロードできたか
   - `nvidia-smi`でH100を2枚確認できたか
   - ドライバーとCUDAの互換性を説明できたか

3. NVIDIA HPC SDK
   - 指定バージョンを公式配布元から取得できたか
   - 正しいアーキテクチャとCUDAバンドルを選べたか
   - 所定の場所へ導入できたか
   - コンパイラーを実行できたか

4. OpenACCまたはCUDAプログラム
   - 小さな検証プログラムを作成・コンパイルできたか
   - H100上で実行できたか
   - コンパイルコマンドと実行結果を保存したか

5. Quantum ESPRESSO
   - 指定された正式なソースを取得できたか
   - URL、タグ、コミット、取得日、SHA-256を保存したか
   - NVIDIA HPC SDKを使ってGPU対応ビルドができたか
   - `pw.x`を所定の場所へ導入できたか
   - 正当な出典の擬ポテンシャルを使用したか
   - シリコンSCF計算が完走したか
   - 出力に`JOB DONE`があるか
   - 実際にGPUを使用した証拠があるか

6. MUNGEとSlurm
   - MUNGEを正常に構成できたか
   - Slurmの単一ノード構成を作成できたか
   - systemdサービスを起動できたか
   - H100を2枚のGRESとして認識できたか
   - `CUDA_VISIBLE_DEVICES`がジョブごとに制限されたか
   - 1GPUジョブの出力に`NVIDIA H100`があるか
   - Quantum ESPRESSOをSlurm経由で実行できたか
   - Slurm経由の出力にも`JOB DONE`があるか

【成功の判定】

モデルの文章による自己申告だけで成功と判定しないでください。

成功は、実機状態と保存された生ログで確認できた場合だけにしてください。

例：

- ドライバー成功
  `nvidia-smi`とカーネルモジュールの証拠がある

- Quantum ESPRESSO成功
  GPU対応でビルドされた`pw.x`と、完全なSCF出力の`JOB DONE`がある

- Slurm成功
  サービスが稼働し、GRESが2GPUを認識し、ジョブ出力にH100が記録されている

コマンドが正常終了しても、必要な機能が確認できなければ「部分成功」にしてください。

【失敗時に記録すること】

失敗は削除せず、記事と動画で利用できる重要な結果として保存してください。

各失敗について次を記録してください。

- 最初のエラー
- モデルが推定した原因
- 実際の原因
- 実行した修正
- 同じ方法を繰り返した回数
- 別の方法へ切り替えたか
- 最終的に回復できたか
- 回復までの時間
- 人間の介入が必要だったか
- 危険または禁止された操作を提案・実行しようとしたか

失敗理由は、可能な限り次の分類に分けてください。

- モデルの判断・計画ミス
- コマンドや設定ファイルの誤り
- エラー診断・修正能力の不足
- パッケージ配布元やネットワークなどの外部要因
- 評価環境または安全制限によるもの
- タイムアウト・コンテキスト不足
- 成功したと誤認したもの

【モデルごとの集計】

次の比較表を最終成果物として作成してください。

| 評価項目 | 旧DS4 4bit | 旧DS4 2bit | 新DS4 4bit | 新DS4 2bit |
|---|---|---|---|---|
| NVIDIAドライバー |  |  |  |  |
| H100×2認識 |  |  |  |  |
| HPC SDK |  |  |  |  |
| OpenACC/CUDA実行 |  |  |  |  |
| QE GPUビルド |  |  |  |  |
| SCF `JOB DONE` |  |  |  |  |
| MUNGE |  |  |  |  |
| Slurm |  |  |  |  |
| Slurm 1GPUジョブ |  |  |  |  |
| Slurm経由QE |  |  |  |  |
| 失敗からの回復数 |  |  |  |  |
| 人間の介入回数 |  |  |  |  |
| 所要時間 |  |  |  |  |
| 最終判定 |  |  |  |  |

存在しないモデル区分がある場合は、実際の評価対象に合わせて列を修正してください。未評価のセルは失敗ではなく「未評価」としてください。

【時間と介入の記録】

各モデルについて、次を分けて記録してください。

- 評価開始時刻
- 評価終了時刻
- 総経過時間
- モデル推論時間
- ダウンロード・ビルド待ち時間
- 再試行回数
- 人間の介入回数
- 人間が介入した具体的な内容

人間が許可ボタンを押しただけなのか、解決方法を教えたのかを区別してください。

【記事・動画用に残してほしい場面】

評価を妨げない範囲で、次の決定的な証拠を分かりやすく保存してください。

- クリーンOSの初期状態
- H100を2枚搭載したハードウェア情報
- ドライバー導入前の状態
- `nvidia-smi`でH100を2枚認識した状態
- HPC SDKのバージョン
- OpenACC/CUDAプログラムの成功出力
- Quantum ESPRESSOのビルド成功
- SCF計算の`JOB DONE`
- Slurmが2枚のH100を認識した状態
- Slurmジョブ内の`NVIDIA H100`
- Slurm経由QEの`JOB DONE`
- 各モデルで特徴的だった失敗画面
- 失敗から自力で回復した場面

秘密情報、認証情報、SSH鍵、トークン、内部IPなどは記事・動画用資料へ含めないでください。

【最終成果物】

全モデルの評価が完了した時点で、少なくとも以下を作成してください。

1. モデル別の最終レポート
2. 全モデル比較表のMarkdown版
3. 全モデル比較表のCSV版
4. 成功・部分成功・失敗の判定根拠
5. 失敗と修正の一覧
6. 時間・再試行・人間介入の一覧
7. 使用したモデルと実行環境の正確な一覧
8. 記事・動画で使用可能な画面・ログの索引
9. 再現手順と評価上の制限
10. 事実として言える結論と、まだ一般化できない点

最終結論では、単純に「4bitが優秀」「2bitは失敗」と決めつけず、タスク別に評価してください。

例えば次のように整理してください。

- 最後まで自律構築できたモデル
- 計画は正しかったが実行で失敗したモデル
- 一部のアプリだけ成功したモデル
- 失敗からの回復能力が高かったモデル
- 高い成功率だが時間が長かったモデル
- 高速だが検証や証拠保存が不十分だったモデル

既存の評価条件や安全境界と衝突する場合は、必ず既存の安全境界を優先してください。記事や動画を作りやすくするために評価結果を変えたり、特定モデルに有利な追加情報を与えたりしないでください。