ksterx/srunx

ksterx/srunx

от ksterx
srunx управляет SLURM-очередью: отправляет и отменяет задания, мониторит GPU и логи, запускает YAML-workflow. Работает с локальным и удалённым кластером по 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
$ srunx sbatch --job-name training --gpus-per-node 2 --conda ml_env --wrap "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обязательный
5.0.0основная
4.3.0
4.2.1
4.2.0
4.1.1
4.1.0
4.0.1
4.0.0
3.0.3
3.0.2
3.0.1
3.0.0
2.2.1
2.2.0
2.1.3
2.1.2
2.1.1
2.1.0
2.0.0
1.2.1
1.2.0
1.1.1
1.1.0
1.0.1
1.0.0
0.17.1
0.17.0
0.15.0
0.13.0
0.12.1
0.8.0
0.6.1
0.6.0
0.5.1
0.5.0
0.4.1
0.3.0
0.2.8
0.2.6
0.2.4
0.2.3
0.2.1
0.2.0
0.1.1
0.1.0

Выберите клиент, чтобы установить ksterx/srunx:

Любой клиент

Конфиг добавления MCP сервера стандартный, обычно он не меняется вообще, поэтому подходит практически к любому ИИ клиенту, поддерживающему MCP.

{
  "mcpServers": {
    "ksterx-srunx-1fprzpowpu": {
      "command": "uvx",
      "args": [
        "--from",
        "srunx[mcp]",
        "srunx-mcp"
      ]
    }
  }
}
CursorCursor

Перейдите по ссылке и сервер автоматически будет добавлен в Cursor. Либо откройте/создайте файл ~/.cursor/mcp.json(%USERPROFILE%\.cursor\mcp.json на Windows) и добавьте конфиг сервера:

{
  "mcpServers": {
    "ksterx-srunx-1fprzpowpu": {
      "command": "uvx",
      "args": [
        "--from",
        "srunx[mcp]",
        "srunx-mcp"
      ]
    }
  }
}
VS Code

Создайте .vscode/mcp.json в проекте (ключ верхнего уровня — servers):

{
  "servers": {
    "ksterx-srunx-1fprzpowpu": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "--from",
        "srunx[mcp]",
        "srunx-mcp"
      ]
    }
  }
}

Либо добавьте сервер через терминал:

code --add-mcp "{\"name\":\"ksterx-srunx-1fprzpowpu\",\"type\":\"stdio\",\"command\":\"uvx\",\"args\":[\"--from\",\"srunx[mcp]\",\"srunx-mcp\"]}"
ClaudeClaude Desktop

Откройте Settings → Developer → Edit Config — это откроет файл claude_desktop_config.json:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
  • Windows: %APPDATA%\Claude\claude_desktop_config.json

Впишите сервер и полностью перезапустите Claude Desktop:

{
  "mcpServers": {
    "ksterx-srunx-1fprzpowpu": {
      "command": "uvx",
      "args": [
        "--from",
        "srunx[mcp]",
        "srunx-mcp"
      ]
    }
  }
}
Claude CodeClaude Code

Добавьте сервер одной командой в терминале:

claude mcp add ksterx-srunx-1fprzpowpu -- uvx --from srunx[mcp] srunx-mcp

Либо через JSON-конфиг:

claude mcp add-json ksterx-srunx-1fprzpowpu "{\"command\":\"uvx\",\"args\":[\"--from\",\"srunx[mcp]\",\"srunx-mcp\"]}"
CodexCodex

Добавьте сервер командой в терминале:

codex mcp add ksterx-srunx-1fprzpowpu -- uvx --from srunx[mcp] srunx-mcp

Либо вручную в ~/.codex/config.toml(%USERPROFILE%\.codex\config.toml на Windows):

[mcp_servers.ksterx-srunx-1fprzpowpu]
command = "uvx"
args = ["--from", "srunx[mcp]", "srunx-mcp"]
PerplexityPerplexity

MCP доступен подписчикам Perplexity Pro / Max / Enterprise. Локальные серверы — только в приложении для macOS.

  1. Откройте Настройки аккаунта → Connectors.
  2. Установите вспомогательное приложение PerplexityXPC (один раз).
  3. Нажмите Add Connector → вкладка Simple.
  4. В поле Server Name укажите ksterx/srunx, а в поле команды запуска — строку ниже:
uvx --from srunx[mcp] srunx-mcp

Нажмите Save и дождитесь статуса Running.

WindsurfWindsurf

Откройте Windsurf Settings → Cascade → MCP Servers или отредактируйте файл ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "ksterx-srunx-1fprzpowpu": {
      "command": "uvx",
      "args": [
        "--from",
        "srunx[mcp]",
        "srunx-mcp"
      ]
    }
  }
}
ClineCline

В панели Cline нажмите иконку MCP Servers → Configure → Configure MCP Servers (или отредактируйте ~/.cline/mcp.json) и добавьте сервер:

{
  "mcpServers": {
    "ksterx-srunx-1fprzpowpu": {
      "command": "uvx",
      "args": [
        "--from",
        "srunx[mcp]",
        "srunx-mcp"
      ],
      "disabled": false,
      "autoApprove": []
    }
  }
}
Continue

Создайте файл в .continue/mcpServers/ (например ksterx-srunx-1fprzpowpu.yaml) или добавьте блок в config.yaml. MCP работает только в режиме agent:

mcpServers:
  - name: ksterx-srunx-1fprzpowpu
    command: uvx
    args:
      - "--from"
      - "srunx[mcp]"
      - "srunx-mcp"
Zed

Выполните agent: add context server или откройте настройки (zed: open settings file) и добавьте сервер в объект context_servers:

{
  "context_servers": {
    "ksterx-srunx-1fprzpowpu": {
      "command": "uvx",
      "args": [
        "--from",
        "srunx[mcp]",
        "srunx-mcp"
      ]
    }
  }
}

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

gotohuman/gotohuman-mcp-server

gotohuman/gotohuman-mcp-server

от gotohuman

MCP сервер gotoHuman добавляет человеческий контроль в AI-агенты. Запрашивайте одобрение задач, управляйте workflow с customizable UI. Интегрируется в Cursor, Claude, Windsurf для безопасных автоматизаций.

TypeScript⭐ 52
cameroncooke/xcodebuildmcp

cameroncooke/xcodebuildmcp

от cameroncooke

Собирает, тестирует и отлаживает iOS и macOS проекты через Xcode. Запускает сборки, прогоняет тесты, вытаскивает логи. Официальное решение от Sentry.

TypeScript⭐ 6489
kehvinbehvin/json-mcp-filter

kehvinbehvin/json-mcp-filter

от kehvinbehvin

MCP-сервер для JSON-схем и фильтрации данных. Работает с локальными файлами и удаленными HTTP-эндпоинтами. Извлекает нужные поля из больших JSON (до 50 MB) для контекста LLM. Генерирует TypeScript-...

JavaScript⭐ 26
gpartin/WaveGuardClient

gpartin/WaveGuardClient

от gpartin

WaveGuard — MCP сервер для обнаружения аномалий на основе волновой физики. Отправляйте любые данные (метрики, транзакции, логи) — получайте оценку аномальности и объяснения. Не требует обучения, ра...

Python⭐ 4
jordandalton/restcsv-mcp-server

jordandalton/restcsv-mcp-server

от jordandalton

Сервер для работы с CSV-данными через REST API: с ним AI-агенты (Claude, Cursor) могут читать, записывать и управлять таблицами как удалёнными ресурсами. Полезен для автоматизации аналитики и интеграции данных без загрузки файлов.

TypeScript⭐ 12
flowzap-xyz/flowzap-mcp

flowzap-xyz/flowzap-mcp

от flowzap-xyz

MCP-сервер для создания визуальных диаграмм workflow, sequence и architecture через ИИ-ассистенты (Claude, Cursor и др.). Использует собственный язык FlowZap Code. Полезен разработчикам для быстрой...

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

Лука Никитин