AutoDock‑GPU: HTS‑скрининг на облачных GPU

Задача страницы. Дать инженерный рецепт массового докинга (High‑Throughput Screening, HTS) на GPU: организация батчей по библиотекам лигандов, раскладка по GPU/нодам, NVMe‑кэш, устойчивость к прерываниям (Interruptible), метрики ligands_per_min и экономика Cost_per_1K_ligands. Страница — входная точка ветки AutoDock‑GPU.

TL;DR

Сценарии: когда это нужно

  • HTS‑кампании по 10^4–10^7 лигандам. Массовая проверка «быстро‑дёшево», затем пере‑докинг топ‑N.
  • Фармакофорные/целевые поднаборы. Десятки тысяч лиганов с приоритизацией по скрининговому скорингу.
  • Пере‑докинг/рафинирование. С меньшим параллелизмом, с повышенной точностью/экзостивностью.
  • Гибридные пайплайны. HTS → отбор → молекулярная динамика (GROMACS/NAMD/AMBER). См. https://cloudcompute.ru/solutions/hpc/gromacs/ и https://cloudcompute.ru/solutions/hpc/namd/

Архитектуры/пайплайны A) Масштабируемый HTS: шардирование по лигандам

[Library (ligands.pdbqt/*)] -> [Validator/Indexer] -> [Sharder] -> [Job Queue]
 |
 +------------------------------+------------------------------+
 | |
 [GPU Worker #1] (1 proc = 1 GPU) [GPU Worker #N]
 | |
 [Maps/Grid/Conf -> NVMe] [Batch (≤120 s) -> Poses/Scores] ... [Batch -> Poses/Scores]
 ___________________________ ______________________________/
 [Reducer/Merge -> CSV/Parquet + Top-N Poses -> Cold]

Ключи: NVMe «горячий» кэш, батчи фиксированного размера по времени, идемпотентные задачи (повторяемые без дубликатов), сбор результатов и сортировка по score.

B) Многоузловой пул воркеров (RDMA не обязателен)

[Scheduler/API] -> [Node Pool: GPUxM per node]
 | | |
 W1 W2 Wk (каждый = 1 процесс на 1 GPU)

Ключи: обменов между задачами нет, сеть нужна в основном для I/O; RDMA критичен только если шарите общий FS с высокой конкуренцией — предпочтительнее локальный NVMe.

C) Пере‑докинг top‑N

[Top-N ligands] -> [Re-docking Queue (higher exhaustiveness)] -> [GPU Workers] -> [Refined Scores/Poses]

Профили GPU/VRAM/ориентиры

**Профиль** **VRAM** **Типовые батчи** **Режим** **Отн. throughput (≈)** **Примечания**
**24 ГБ (Compact)** 24 ГБ Мелкие/средние лиги, базовые сетки Interruptible / On‑Demand 1.0 Отличная плотность с **MIG**‑шардингом
**48 ГБ (Balanced)** 48 ГБ Стандарт HTS, устойчивый ligands\_per\_min Оба 1.5–1.8 База для кампаний 10^5–10^6
**80 ГБ (HQ)** 80 ГБ Крупные лиги/гриды, высокий параллелизм Оба 2.2–2.6 Имеет смысл для пере‑докинга/рафинирования

Относительные индексы; итог зависит от размера лигандов/гридов и параметров докинга.

Конфиги и скелеты

1) YAML‑спека HTS‑задания

job:
 name: "autodock_gpu_hts_batch01"
 mode: "interruptible" # on-demand | interruptible
 gpu_profile: "48GB-Balanced" # 24GB-Compact | 48GB-Balanced | 80GB-HQ
 chunk_seconds: 120
 retries: 3
 input:
 ligands_glob: "s3://warm/ligands/*.pdbqt"
 receptor_maps: "s3://warm/receptor/maps/" # предвычисленные карты/сетка
 config: "s3://warm/receptor/docking.conf" # параметры докинга (exhaustiveness/poses и т.д.)
 batching:
 ligands_per_task: 200 # подберите под цель ≤120 с
 max_parallel_tasks_per_gpu: 1 # 1 процесс = 1 GPU
 output:
 dir: "s3://cold/hts/results/batch01/"
 write_poses: true
 topn: 1000
 hooks:
 on_start: ["python /scripts/prefetch_nvme.py"]
 on_task_done: ["python /scripts/register_result.py"]
 on_failure: ["python /scripts/requeue.py --backoff"]

2) Воркер (Python‑скелет): батчевый запуск докера/CLI

import glob, os, subprocess, json, time, pathlib, random
NVME = "/nvme"
LIGS = sorted(glob.glob(f"{NVME}/ligands/*.pdbqt"))
MAPS = f"{NVME}/maps"
CONF = f"{NVME}/docking.conf"
OUT = f"{NVME}/out"; pathlib.Path(OUT).mkdir(parents=True, exist_ok=True)
BATCH = int(os.environ.get("LIGANDS_PER_TASK","200"))
def run_batch(batch):
 started = time.time()
 out_csv = os.path.join(OUT, f"scores_{batch[0].split('/')[-1]}_{len(batch)}.csv")
 cmd = [
 "autodock_gpu", # замените на фактический бинарь/обёртку контейнера
 "--maps", MAPS,
 "--config", CONF,
 "--out", OUT,
 "--scores", out_csv,
 "--ligands"
 ] + batch
 subprocess.run(cmd, check=True)
 return time.time() - started, out_csv
i = 0
while i < len(LIGS):
 batch = LIGS[i:i+BATCH]
 t, path = run_batch(batch)
 print(json.dumps({"batch_start": batch[0], "count": len(batch), "seconds": t, "scores": path}))
 i += BATCH

Если используется контейнер, оборачивайте autodock_gpu внутри docker run --gpus all -v /nvme:/nvme image .... Параметры (--maps/--config/--ligands) подставьте под ваш фактический CLI.

3) Docker/Compose — пул GPU‑воркеров

services:
 hts-broker:
 image: registry.local/hts-broker:latest
 environment:
 - POLICY_TASK_SECONDS=120
 - POLICY_RETRIES=3
 networks: [hts-net]
 hts-worker-01:
 image: registry.local/autodock-gpu:latest
 deploy:
 resources:
 reservations:
 devices: [{ capabilities: ["gpu"] }]
 environment:
 - LIGANDS_PER_TASK=200
 volumes:
 - /nvme:/nvme
 command: ["bash","-lc","python3 /opt/worker.py"]
 networks: [hts-net]
 hts-worker-02:
 image: registry.local/autodock-gpu:latest
 deploy:
 resources:
 reservations:
 devices: [{ capabilities: ["gpu"] }]
 volumes:
 - /nvme:/nvme
 command: ["bash","-lc","python3 /opt/worker.py"]
 networks: [hts-net]
networks:
 hts-net: {}

4) SSE‑прогресс для панели

from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import json, time, random
app = FastAPI()
def stream():
 done = 0
 while True:
 done += random.randint(50,150)
 payload = {"ligands_done": done, "ligands_per_min": 600, "gpu_utilization": 0.8}
 yield f"data: {json.dumps(payload)}nn"
 time.sleep(1)
@app.get("/events")
def events(): return StreamingResponse(stream(), media_type="text/event-stream")

5) Slurm — «горизонтальное» масштабирование по GPU

#!/bin/bash
#SBATCH -J autodock_hts
#SBATCH -N 2
#SBATCH --gpus-per-node=4
#SBATCH -t 08:00:00
#SBATCH -p gpu
#SBATCH --exclusive
module load cuda # при необходимости
srun --mpi=pmix_v3 bash -lc 'python3 /opt/worker.py'
``` **Наблюдаемость/метрики/алерты**

Опорные хабы:[ https://cloudcompute.ru/solutions/monitoring-logging/](https://cloudcompute.ru/solutions/monitoring-logging/?utm_source=chatgpt.com) •[ https://cloudcompute.ru/solutions/llm-inference/observability/](https://cloudcompute.ru/solutions/llm-inference/observability/?utm_source=chatgpt.com)

**Метрики HTS:**

- Производительность: ligands\_per\_min, ligand\_seconds (histogram), p50/p95 task\_time\_seconds.
- Качество: success\_rate (валидные позы/всего), top\_score, median\_score, failed\_total.
- GPU: gpu\_utilization, gpu\_memory\_used\_bytes, sm\_occupancy, gpu\_power\_watts.
- I/O: io\_read\_mb\_s, io\_write\_mb\_s, nvme\_usage\_bytes, cache\_hit\_ratio{tier="nvme"}.
- Очередь: job\_queue\_depth, tasks\_inflight, retry\_total, time\_to\_topN\_ready.

**Алерты:**

- Падение ligands\_per\_min &gt; X% к эталону N мин.
- success\_rate ниже порога → проблемы с входными PDBQT/гридами.
- gpu\_utilization &lt; 60% при глубокой очереди → I/O или слишком мелкие батчи.
- nvme\_usage\_bytes &gt; 85% → авто‑drain/cleanup поз/логов.
- Взрыв retry\_total → нестабильные файлы/конфиг.

## **Экономика и формулы**

См.[ https://cloudcompute.ru/solutions/cost-planner/](https://cloudcompute.ru/solutions/cost-planner/?utm_source=chatgpt.com) и <https://cloudcompute.ru/solutions/throughput-vs-latency/>

**Базовые:**

Throughput = ligands\_per\_min

t\_1K = 1000 / Throughput \* 60 # сек

Cost\_per\_1K\_ligands = (c\_gpu \* t\_1K / 3600) / U \* r # r — retry-factor для Interruptible

**Кампания из L лиганов:**

Total\_cost = (c\_gpu \* t\_total / 3600) / U \* r

t\_total ≈ (L / Throughput) \* 60 / (N\_gpu\_eff) # N\_gpu\_eff — число эффективно занятых GPU

**Сравнение профилей GPU:**

ΔCost = Cost\_24GB - Cost\_48GB

Выбираем профиль, где Cost\_per\_1K минимален при стабильном SLA p95 task\_time\_seconds.

**Безопасность/политики**

См.[ https://cloudcompute.ru/solutions/security/](https://cloudcompute.ru/solutions/security/?utm_source=chatgpt.com)

- **Приватные библиотеки лиганов/таргетов.** Доступ по временным токенам, запрет листинга бакетов, проекты и ACL.
- **Секреты/лицензии.** Токены баз, репозиториев, ключи — через секрет‑хранилище; не логировать.
- **Изоляция.** Отдельные сети/учётки под проекты; egress — по allow‑list.
- **Ретеншн.** Сырые логи/временные позы — автоочистка; итоговые CSV/Parquet и top‑N позы — в «холодное».
- **Аудит.** Кто запускал, какие наборы использовал, какие результаты публиковал.

**Траблшутинг (симптом → причина → решение)**

<table><tbody><tr><td>**Симптом**

</td><td>**Возможная причина**

</td><td>**Решение**

</td></tr><tr><td>Низкий ligands\_per\_min при глубокой очереди

</td><td>Узкое место I/O/холодный кэш

</td><td>NVMe‑prefetch, увеличить размер батча до цели ≤ 120 с, параллельные воркеры

</td></tr><tr><td>Много failed\_total

</td><td>Битые PDBQT/несовместимые форматы

</td><td>Валидатор входов, фильтр по размеру/заряду, отчёт об ошибках в reducer

</td></tr><tr><td>«Пилит» p95 task\_time\_seconds

</td><td>Конкуренция на диске/сети

</td><td>Разнести воркеров по NVMe, лимитировать запись поз, collate результаты батчами

</td></tr><tr><td>OOM VRAM

</td><td>Слишком большие лиги/параметры

</td><td>Снизить параллелизм, уменьшить размер батча, перейти на 48–80 ГБ

</td></tr><tr><td>Разные результаты на нодах

</td><td>Разные версии контейнеров/параметров

</td><td>Зафиксировать версии, единый контейнер, smoke‑батч

</td></tr><tr><td>Всплески retry\_total

</td><td>Прерывания/нестабильные файлы

</td><td>Сократить чанк, включить rolling‑сейвы, использовать идемпотентные ключи задач

</td></tr><tr><td>Низкий gpu\_utilization

</td><td>Слишком мелкие батчи/высокие накладные

</td><td>Увеличить ligands\_per\_task, «1 процесс = 1 GPU», убрать CPU‑бутылочные места

</td></tr></tbody></table>

## **Как запустить в cloudcompute.ru**

1. **Шаблон:**[ https://cloudcompute.ru/solutions/templates/](https://cloudcompute.ru/solutions/templates/?utm_source=chatgpt.com)
 - «AutoDock‑GPU HTS (batch workers)» — пул воркеров и брокер очередей.
 - «HPC MPI (Slurm/K8S)» — если хочется горизонтально масштабировать запуск воркеров через планировщик.
2. **Профиль GPU:** 24/48/80 ГБ по таблице; для сверхплотности — 24 ГБ + **MIG**; для пере‑докинга/крупных лигандов — 48–80 ГБ.
3. **Режим:** **Interruptible** (чанк ≤ 120 с, ретраи) для массовых батчей; критичные пере‑докинги — **On‑Demand**. См. <https://cloudcompute.ru/solutions/interruptible-patterns/>
4. **Хранилище/кэш:** предвычисленные карты/конфиги — «тёплое»; лиги/позы/логи — NVMe; итоговые CSV/Parquet — «холодное». См.[ https://cloudcompute.ru/solutions/storage-data/](https://cloudcompute.ru/solutions/storage-data/?utm_source=chatgpt.com)
5. **Оркестрация/CI:** единый контейнер, YAML‑спеки, smoke‑батч (например, 10 000 лиганов) до масштабирования. См. <https://cloudcompute.ru/solutions/containers-ci-cd/>
6. **Наблюдаемость/алерты:** дашборды ligands\_per\_min, p95 task\_time\_seconds, gpu\_utilization, io\_\*, алерты по падению throughput. См.[ https://cloudcompute.ru/solutions/monitoring-logging/](https://cloudcompute.ru/solutions/monitoring-logging/?utm_source=chatgpt.com)

**Чек‑лист перед продом**

- Определён таргет и подготовлены **карты/сетки**; валидатор входов ловит битые PDBQT.
- Батчи калиброваны под **≤ 120 с**; ретраи/backoff включены; задачи идемпотентны.
- «1 процесс = 1 GPU», пул воркеров масштабируется; для плотности — MIG.
- NVMe‑scratch подключён; префетч активен; cache\_hit\_ratio{tier="nvme"} высокий.
- Дашборды и алерты: ligands\_per\_min, p50/p95, gpu\_utilization, io\_\*, retry\_total.
- Экономика посчитана: Cost\_per\_1K\_ligands, Total\_cost по профилям 24/48/80 ГБ.
- Политики безопасности/ретенции применены; секреты в секрет‑хранилище; аудит включён.
- Smoke‑батч прошёл, результаты детерминируемы в пределах выбранных параметров.

**Навигация**

- Хаб HPC: <https://cloudcompute.ru/solutions/hpc/>
- Родственные приложения:
 
 - GROMACS: <https://cloudcompute.ru/solutions/hpc/gromacs/>
 - NAMD/AMBER: <https://cloudcompute.ru/solutions/hpc/namd/>
 - LAMMPS: <https://cloudcompute.ru/solutions/hpc/lammps/>
 - CFD (OpenFOAM‑CUDA): <https://cloudcompute.ru/solutions/hpc/openfoam-gpu/>
 - Clara Parabricks (геномика): <https://cloudcompute.ru/solutions/hpc/parabricks/>
 - Монте‑Карло: <https://cloudcompute.ru/solutions/hpc/monte-carlo/>
 - Граф‑аналитика (cuGraph): <https://cloudcompute.ru/solutions/hpc/graph-analytics/>
 - Линал: <https://cloudcompute.ru/solutions/hpc/linear-algebra/>
- Сквозные и вспомогательные:
 
 - Multi‑GPU/топологии:[ https://cloudcompute.ru/solutions/multi-gpu/](https://cloudcompute.ru/solutions/multi-gpu/?utm_source=chatgpt.com) • MIG: <https://cloudcompute.ru/solutions/mig/>
 - Данные/хранилище:[ https://cloudcompute.ru/solutions/storage-data/](https://cloudcompute.ru/solutions/storage-data/?utm_source=chatgpt.com)
 - Контейнеры/CI/CD: <https://cloudcompute.ru/solutions/containers-ci-cd/>
 - Мониторинг/логи:[ https://cloudcompute.ru/solutions/monitoring-logging/](https://cloudcompute.ru/solutions/monitoring-logging/?utm_source=chatgpt.com)
 - Наблюдаемость:[ https://cloudcompute.ru/solutions/llm-inference/observability/](https://cloudcompute.ru/solutions/llm-inference/observability/?utm_source=chatgpt.com)
 - Оптимизация вычислений:[ https://cloudcompute.ru/solutions/performance-tuning/](https://cloudcompute.ru/solutions/performance-tuning/?utm_source=chatgpt.com) • <https://cloudcompute.ru/solutions/throughput-vs-latency/>
 - Interruptible‑паттерны: <https://cloudcompute.ru/solutions/interruptible-patterns/>

Готовы запустить?

Запустить GPU-сервер