ksterx/srunx

ksterx/srunx

от ksterx
MCP сервер srunx открывает AI-агентам прямой доступ к SLURM через CLI, веб-дашборд или Python API — отправка задач, мониторинг очереди, запуск workflows и GPU-статус. Работает локально и через SSH, поддерживает контейнеры.
srunx logo

srunx

A unified CLI, web dashboard, and Python API for SLURM job management.

Stop juggling sbatch scripts, squeue loops, and SSH sessions.

PyPI Downloads Python 3.12+ License CI Docs Ask DeepWiki

srunx web dashboard
  • Submit & manage SLURM jobs from CLI, browser, or Python
  • Orchestrate multi-step workflows with YAML and dependency graphs
  • Monitor GPU availability and job states with Slack notifications
  • Local or remote, one CLI — target a local SLURM or any SSH'd cluster with --profile <name>; no shell-in, no separate "remote" commands — the same verbs you already know
  • Container-native — Pyxis, Apptainer, and Singularity support built in

Installation

Requires Python 3.12+ and access to a SLURM cluster (local or via SSH).

uv add srunx             # with uv (recommended)
pip install srunx        # or with pip

The web dashboard and Slack notifications are included in the base install — no extras required.

For AI agent integration (MCP server), add the mcp extra:

uv add "srunx[mcp]"

Quick Start

Submit a job, wait for it, and view the logs — end to end:

# 1. Submit (use -- to separate srunx flags from the command)
$ srunx sbatch --name training --gpus-per-node 2 --conda ml_env -- python train.py
✅ Submitted job training (id=847291)

# 2. Follow until completion
$ srunx watch jobs 847291
847291 training  PENDING  →  RUNNING  →  COMPLETED (4m 12s)

# 3. Inspect output
$ srunx tail 847291 -n 20
Инструменты были проиндексированы:
cancel_job

Отменяет выполняющееся или ожидающее задание SLURM. Аргументы: job_id: Идентификатор задания SLURM для отмены transport: Селектор кластера - опустите или укажите "local" для локального SLURM, или имя SSH-профиля для отмены на удалённом кластере.

Параметры
  • job_idstringобязательный
  • transportstring | null
create_workflow

Создаёт YAML-файл рабочего процесса SLURM. Генерирует определение рабочего процесса в YAML, которое можно выполнить с помощью run_workflow. Каждая задача в рабочем процессе может зависеть от других задач, образуя DAG. Аргументы: name: Имя рабочего процесса для идентификации jobs: Список определений задач. Каждый словарь задачи должен содержать: - name (обязательно): Идентификатор задачи - command (обязательно для обычных задач): Команда в виде строки или списка строк - script_path (обязательно для shell-задач): Путь к shell-скрипту - depends_on: Список имён задач, от которых зависит эта задача (например, ["preprocess"]) Поддерживаются типы зависимостей: "afterok:job_a", "after:job_a", "afterany:job_a" - retry: Количество повторных попыток при сбое (по умолчанию 0) - retry_delay: Секунд между повторными попытками (по умолчанию 60) - resources: Словарь с полями nodes, gpus_per_node, ntasks_per_node, cpus_per_task, memory_per_node, time_limit, partition, nodelist - environment: Словарь с полями conda, venv, env_vars, container - log_dir: Путь к каталогу логов - work_dir: Путь к рабочему каталогу output_path: Путь к файлу для записи YAML-описания рабочего процесса (например, "workflow.yaml") args: Необязательные переменные шаблона для Jinja2-шаблонизации в определениях задач default_project: Имя SSH-проекта/точки монтирования по умолчанию для синхронизации файлов

Параметры
  • argsobject | null
  • default_projectstring | null
  • jobsobject[]обязательный
  • namestringобязательный
  • output_pathstringобязательный
get_config

Получает текущую конфигурацию srunx, включая настройки ресурсов по умолчанию и параметры окружения.

Параметры

Без параметров.

get_job_logs

Получает логи stdout/stderr для задачи SLURM. Аргументы: job_id: ID задачи SLURM job_name: Необязательное имя задачи для поиска файлов логов transport: Селектор кластера: опустить / "local" для локального SLURM или имя SSH-профиля для получения логов с этого удалённого кластера.

Параметры
  • job_idstringобязательный
  • job_namestring | null
  • transportstring | null
get_job_status

Получает статус конкретной задачи SLURM. Аргументы: job_id: Идентификатор задачи SLURM для проверки. transport: Селектор кластера — опустите / "local" для локального SLURM, или имя SSH-профиля для запроса удалённого кластера.

Параметры
  • job_idstringобязательный
  • transportstring | null
get_resources

Получает текущую доступность GPU и узлов в кластере SLURM. Аргументы: partition: Конкретная партиция для проверки (None для всех партиций) transport: Селектор кластера — опустите / укажите "local" для локального SLURM или имя SSH-профиля для запроса к удалённому классеру.

Параметры
  • partitionstring | null
  • transportstring | null
get_workflow

Читает и разбирает YAML-файл workflow, возвращая его полную структуру. Аргументы: yaml_path: Путь к YAML-файлу workflow.

Параметры
  • yaml_pathstringобязательный
inspect_mount

Сообщает, что изменит синхронизация точки монтирования, не внося никаких изменений. Только чтение: эта операция никогда не передает, не удаляет и не создает ничего в кластере. Вызывайте её свободно, в том числе перед синхронизацией, в которой вы не уверены. Её основная задача — ответить на вопрос, на который не может ответить sync_files: что находится в кластере, чего больше нет локально? Синхронизация аддитивна, поэтому эти файлы остаются — включая код, удалённый при локальном рефакторинге, который задача в кластере всё ещё может импортировать и выполнять. Они перечислены здесь как mirror_delete_candidate_paths. Эти кандидаты смешивают два типа объектов: * созданные задачами — контрольные точки, логи, выходные данные. НЕЛЬЗЯ удалять. * оставшиеся локально — устаревшие модули, переименованные файлы. Обычно следует удалять. stale_upload_paths — это вторая группа сама по себе: пути, которые srunx записал как загруженные, но которых больше нет локально. Вывод задач никогда не загружался, поэтому он там не появляется — это верно, даже если список исключений точки монтирования пропустил выходную директорию, что в противном случае похоронило бы несколько устаревших скриптов среди десятков артефактов. Одно исключение: выходные данные, вытянутые в локальное дерево с помощью srunx ssh sync --pull, становятся файлом, которым управляет следующая отправка, поэтому они записываются как любые другие и могут быть отмечены как устаревшие, как только их локальная копия будет удалена. Исключение выходных директорий из точки монтирования позволяет этого избежать, и это в любом случае стоит сделать. Сначала проверьте `stale_uploads_known`. Если оно ложно, запись не смогла ответить (ещё ничего не загружено с отслеживанием, запись нечитаема или изменён фильтр исключений), и stale_uploads: 0 означает "не удалось определить", а не "ничего не устарело" — stale_uploads_unknown_reason говорит, что именно. В этом случае вернитесь к самостоятельному чтению полного списка кандидатов. Args: transport: Имя SSH-профиля для проверки. Обязателен: локальной проверки нет, и (в отличие от CLI) нет неявного возврата к текущему профилю. Вызовите list_ssh_profiles, чтобы получить доступные профили и точки монтирования, которые определяет каждый из них. mount: Имя точки монтирования…

Параметры
  • max_pathsinteger
  • mountstringобязательный
  • transportstringобязательный
list_jobs

Выводит список заданий SLURM в очереди (все пользователи, как squeue). Args: transport: Cluster selector - опустите / "local" для локального SLURM или имя SSH-профиля для запроса к удаленному кластеру.

Параметры
  • transportstring | null
list_ssh_profiles

Перечисляет все настроенные профили SSH-подключений для удаленных кластеров SLURM. Показывает имена профилей, имена хостов и настроенные точки монтирования.

Параметры

Без параметров.

list_workflows

Перечисляет файлы YAML workflow в директории. Сканирует директорию на предмет файлов YAML, содержащих корректную структуру srunx workflow (должен содержать ключи 'name' и 'jobs'). Аргументы: directory: Директория для поиска файлов workflow (по умолчанию: теущая дикректория)

Параметры
  • directorystring
run_workflow

Выполняет SLURM workflow из YAML-файла. Задачи выполняются в порядке зависимостей — независимые задачи запускаются параллельно, зависимые ожидают завершения своих предпосылок. Аргументы: yaml_path: Путь к YAML-файлу workflow from_job: Начать выполнение с этой задачи (пропустить предыдущие задачи) to_job: Остановить выполнение на этой задаче (пропустить последующие задачи) single_job: Выполнить только эту конкретную задачу, игнорируя зависимости dry_run: Если true, показать, что будет выполнено, без фактического запуска args: Необязательное отображение, объединяемое поверх секции YAML args перед обработкой Jinja. Значения с префиксом python: отклоняются. sweep: Необязательная спецификация sweep: {"matrix": {...}, "fail_fast": bool, "max_parallel": int}. При наличии запрос проходит через :class:SweepOrchestrator, и ответ содержит sweep_run_id. transport: Селектор кластера — опустить / "local" для локального SLURM, или имя SSH-профиля для запуска на удалённом кластере. Ортогонален mount: transport выбирает какой кластер, mount выбирает корень преобразования путей внутри этого кластера. mount: Необязательное имя точки монтирования в SSH-профиле, включающее преобразование путей с учётом точки монтирования для work_dir / log_dir. Требует SSH transport; передача mount с локальным transport является ошибкой.

Параметры
  • argsobject | null
  • dry_runboolean
  • from_jobstring | null
  • mountstring | null
  • single_jobstring | null
  • sweepobject | null
  • to_jobstring | null
  • transportstring | null
  • yaml_pathstringобязательный
submit_job

Отправляет задачу SLURM. Аргументы: command: Команда оболочки для выполнения (например, "python train.py --epochs 100") name: Имя задачи для идентификации в очереди SLURM nodes: Количество вычислительных узлов для выделения gpus_per_node: Количество GPU на узел (0 для только CPU) ntasks_per_node: Количество задач на узел cpus_per_task: Количество CPU на задачу memory_per_node: Память на узел (например, "32GB", "64G") time_limit: Лимит времени выполнения (например, "4:00:00", "1-00:00:00") partition: Имя раздела SLURM (например, "gpu", "cpu") nodelist: Конкретные узлы для использования (например, "node001,node002") conda: Имя окружения Conda для активации перед запуском venv: Путь к виртуальному окружению Python для активации env_vars: Дополнительные переменные окружения как пары ключ-значение log_dir: Директория для лог-файлов stdout/stderr work_dir: Рабочая директория для задачи (по умолчанию текущая директория) transport: Выбор кластера — опустите или укажите "local" для локального SLURM, либо имя SSH-профиля для отправки на удалённый кластер.

Параметры
  • commandstringобязательный
  • condastring | null
  • cpus_per_taskinteger
  • env_varsobject | null
  • gpus_per_nodeinteger
  • log_dirstring
  • memory_per_nodestring | null
  • namestring
  • nodeliststring | null
  • nodesinteger
  • ntasks_per_nodeinteger
  • partitionstring | null
  • time_limitstring | null
  • transportstring | null
  • venvstring | null
  • work_dirstring | null
sync_files

Синхронизирует настроенное монтирование с этой машины на удалённый кластер SLURM. Копирует только новые и изменённые файлы. Файлы, которые есть на кластере, но не локально, остаются нетронутыми, если не задан параметр delete=True. То есть файл, удалённый локально, остаётся на кластере, и задание может его подхватить. Этот инструмент не сообщает о них — вызовите inspect_mount, чтобы их увидеть. Он доступен только для чтения, поэтому его можно безопасно вызывать до или после синхронизации; используйте его вместо установки delete=True, чтобы узнать, что устарело. Args: transport: Имя SSH-профиля для синхронизации. Обязательный параметр, должен указывать на SSH-профиль — синхронизация локально-локально не поддерживается, и (в отличие от CLI) неявного возврата к текущему профилю нет. "local" отклоняется. Вызовите list_ssh_profiles, чтобы увидеть профили и монтирования, определённые для каждого. mount: Имя монтирования из этого SSH-профиля. Синхронизировать можно только предварительно зарегистрированные монтирования; произвольные пути не принимаются. dry_run: Только предварительный просмотр. Сообщает, что именно будет передано и удалено, не трогая кластер. Используйте этот параметр сначала, если не уверены, и всегда перед запуском с delete=True. delete: Зеркалирует монтирование — также УДАЛЯЕТ файлы на кластере, которых больше нет локально. Это уничтожает данные, существующие только на удалённой стороне, такие как чекпоинты обучения, журналы заданий и результаты, записываемые заданиями на кластере, которых по определению нет локально. Не включайте, если только пользователь явно не запросил зеркалирование, и сначала выполните предпросмотр с dry_run=True. max_delete: Отказывается от зеркалирования, ничего не меняя, если будет удалено больше указанного количества элементов. Элементы — это файлы и каталоги, соответствует единице --max-delete в rsync: удаление каталога с двумя файлами считается как три элемента (оба файла плюс каталог), поэтому задавайте значение больше, чем количество файлов, которое вы имеете в виду. Защищает от зеркалирования из неверного или неполного источника.

Параметры
  • deleteboolean
  • dry_runboolean
  • max_deleteinteger
  • mountstringобязательный
  • transportstringобязательный
validate_workflow

Проверяет файл YAML рабочего процесса на корректность. Проверяет правильность синтаксиса YAML, структуру заданий, разрешение зависимостей и обнаружение циклических зависимостей. Args: yaml_path: Путь к файлу YAML рабочего процесса для проверки.

Параметры
  • yaml_pathstringобязательный

Похожие MCP-сервера

Grafana MCP

Grafana MCP

официальный

MCP сервер для интеграции с Grafana: управляйте дашбордами, выполняйте запросы к Prometheus, Loki, CloudWatch и другим источникам через MCP. Упрощает мониторинг, анализ метрик и логов — полезен для инженеров и DevOps.

Go3446
iris-eval/mcp-server

iris-eval/mcp-server

Iris - open-source MCP сервер для оценки безопасности и качества AI-агентов. Проверяет вывод на PII, инъекции, галлюцинации, контролирует стоимость. Логирует трассировки, имеет веб-дашборд. Работает с любым MCP-клиентом без SDK.

TypeScript9
smigolsmigol/llmkit

smigolsmigol/llmkit

MCP-сервер для мониторинга затрат на AI-запросы в Claude Code, Cline, Cursor. 11 инструментов: прокси-аналитика, локальные расходы, прогноз бюджета. Помогает разработчикам AI-агентов контролировать...

TypeScript16
shibley/apistatuscheck-mcp-server

shibley/apistatuscheck-mcp-server

MCP-сервер для проверки доступности 114+ облачных сервисов (AWS, GitHub, Stripe, OpenAI и других) в реальном времени. Полезен разработчикам и DevOps для быстрого мониторинга статуса API прямо из ас...

TypeScript1
xzq.xu/jvm-mcp-server

xzq.xu/jvm-mcp-server

MCP-сервер для мониторинга JVM на JDK-утилитах (jps, jstack, jmap). Не требует Arthas. Предоставляет диагностику потоков, памяти, классов, декомпиляцию. Работает локально и через SSH. Идеален для р...

Python90
edgedelta/edgedelta-mcp-server

edgedelta/edgedelta-mcp-server

MCP сервер для интеграции с Edge Delta API: автоматизирует сбор и анализ observability данных, а также создание AI-инструментов на платформе. Полезен разработчикам для взаимодействия с данными мониторинга.

Go9
© Каталог MCP, 2026. Все права защищены.
Проект не аффилирован с Anthropic и любыми упомянутыми продуктами.
Все названия и торговые марки принадлежат их владельцам.
Контакты для связи: hi@mcp-katalog.ru

Лука Никитин