SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsaccel-init

accel-init

Coding & development

View repository

Updated 10-15 20:08

About this skill

accel-init: compute platform initialization orchestration

Linear six stages; each stage produces a definite output before proceeding to the next; if the reality of any step does not match expectations, stop and align instead of forcing through.

Stage 0: Determine the platform and current state

Probe first; even when the user has already stated the platform directly, spot-check to verify:

# 厂商 smi 工具（命中任一即强信号）
nvidia-smi -L 2>/dev/null; mthreads-gmi 2>/dev/null; npu-smi info 2>/dev/null; rocm-smi --showproductname 2>/dev/null
lspci | grep -iE 'nvidia|display|3d|accelerator|processor.*musa|huawei|amd/ati'   # vendor ID 交叉确认
ls /dev/nvidia* /dev/davinci* /dev/musa* 2>/dev/null
# 驱动/SDK/运行时现状
lsmod | grep -E 'nvidia|mthreads|davinci|amdgpu'; ls /usr/local/ | grep -iE 'cuda|musa|ascend|rocm|CANN'

Compare against the platforms.md registry: platform, detection commands, official entry points, known ecosystem conclusions. If the probe is unclear or multiple accelerators coexist → ask the user, do not guess.

Environment boundary three checks(which likewise affect all subsequent stages):

uname -m                      # aarch64（昇腾等）wheel 生态窄，部分包无预编译只能源编
ls /.dockerenv 2>/dev/null; grep -qE 'docker|kubepods' /proc/1/cgroup 2>/dev/null && echo 容器内
# 容器内 lspci 不可靠，以 /dev 结点 + smi 为准；官方容器路线（nvidia-container/厂商镜像）作为选项提给用户
curl -sm3 -o /dev/null -w '%{http_code}\n' https://pypi.tuna.tsinghua.edu.cn/simple/ https://hf-mirror.com/ 2>/dev/null

Network probe unreachable (normal for research servers) → change all source configuration to reachable paths: during the interview ask about intranet mirrors/offline packages/proxies; do not copy Tsinghua mirrors and hf-mirror verbatim.

Current-state grading(determines the scope of later stages): driver+SDK both present / driver only / bare metal. Shared clusters are usually the first case.

Stage 1: Interview (ask only what affects behavior)

  • root/sudo present or not → determines whether the driver layer gets installed (no root and no driver → stop, hand back to the user to find an administrator).
  • Which layer to install: minimal torch stack, or +transformers/vllm/distributed.
  • Whether the project has any Python version requirements (determines which ABI column of the wheel matrix to choose).
  • Exclusive or shared machine → naming conventions, cache location, test card slots (do not test cards occupied by others).
  • Whether the SDK/version is specified (if not, research and give a recommended row for the user to decide).
  • When the external network is unreachable: intranet mirror addresses, where offline packages are, how to use the proxy (at least one of the three).

Stage 2: Python dual-stack foundation (platform-independent, set up first)

Conventions:Both miniconda and uv are installed; the user can use whichever they prefer; set all three default sources to Tsinghua:

  • Install miniconda to {{用户认可的目录}}(on shared machines put it on a large-capacity disk; the installer goes through the Tsinghua mirror https://mirrors.tuna.tsinghua.edu.cn/anaconda/miniconda/）。
  • uv: install via the official install script or pip, whichever is available (when there is no external network, pip install uv can also be obtained from intranet/mirror sources).
  • Put caches on a large disk: point the pip/uv/HF cache directories to a large-capacity disk (symlink or configuration); do not stuff the small /home disk full.
  • Configure sources in three places: pip (pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple）、conda（~/.condarc Tsinghua channels), uv (UV_DEFAULT_INDEX=https://pypi.tuna.tsinghua.edu.cn/simple, written into ~/.config/uv/uv.toml or shell configuration).
  • apt sourcesonly remind, do not change: inform the user of the Tsinghua/USTC mirror addresses and how to switch manually; whether to switch is up to the user (distribution formats vary widely, and changing it wrong will break apt).
  • All foundation facts are recorded in the host layer (persisted in Stage 5).

If conda/uv/pip configuration already exists, check the actual state item by item and only fill in gaps; do not overwrite existing configuration (especially when private/intranet sources already exist, keep the machine's local values).

Data foundation(mandatory for compute servers, platform-independent): implement per the model-datasets skill——/data large-disk preparation (decide based on current state: use directly/symlink/initialize LVM+fstab),/data/models|datasets|hub directory, uv tool install hf/modelscope CLI, mirror environment variables (HF_ENDPOINT=hf-mirror, HF_HOME, HF_HUB_DISABLE_XET=1),dl script and verification checklist (clean up after the next tiny model is tested successfully). /data initialization includes partitioning/formatting; before doing anything, first confirm with the user that the disk is empty.

Phase 3: Platform research

The first entry point is the vendor's official documentation/download center, not public mirror sources. Platform-specific wheels (torch backend packages, platform-version triton, vendor communication libraries) do not exist on PyPI/Tsinghua mirror or have the wrong versions—not finding them on public sources only proves "not on public sources," it does not prove the platform is unsupported; install it exactly as the vendor documentation says. Use web search tools available on the host (project convention: tavily/firecrawl, not the built-in weak search).

Search path (in order):

  1. Vendor official website → Documentation center/Download center → Installation guide: find pip index-url, offline SDK packages, driver firmware downloads, version compatibility matrix.
  2. Vendor GitHub org (e.g. MooreThreads, Ascend, ROCm) → torch backend repo README: version match lines, ecosystem support statements (which libraries are upstream-native, which are vendor forks).
  3. Search query reference:{{厂商}} {{SDK名}} 安装指南 pip 源、{{厂商}} pytorch wheel index-url、site:{{官方域}}。
  4. After finding the index-url, you must verify the loop with actual checks:python -m pip index versions torch --index-url <厂商源>——documentation may lag; actual checks take precedence and record the date.

Item-by-item verification checklist (against the platforms.md registry, including each platform's official entry point):

  1. Compatibility set: OS ↔ driver ↔ SDK ↔ toolchain version constraints (official matrix).
  2. wheel matrix: on the vendor pip index, torch / torch 后端包 / torchvision / torchaudio / triton(平台版) / tilelang 类 available version lines × Python ABI;python -m pip index versions <pkg> --index-url <厂商源> actual check.
  3. Ecosystem compatibility: whether transformers/accelerate/vllm etc. are upstream-native supported, vendor forks (branch + version), or unsupported—record evidence links library by library.
  4. Cross-contamination prevention points: which public CUDA wheel packages will override the platform torch (torch/torchvision/triton/flash-attn/bitsandbytes/nvidia-*).
  5. Current-state check: installed SDK version, user-space directories, LD_LIBRARY_PATH conventions.

Output: candidate solutions (usually 1–2 version lines) + step checklist + risk points, for the user to decide.

Phase 4: Execution and verification ladder

  • User space first; root operations (drivers, kernel modules, system packages) listed one by one and explicitly confirmed before acting.
  • Pre-flight disk check before starting：df -h target disk (torch stack + SDK + cache easily tens of GB); if insufficient, clean up or switch disks first, then start installation.
  • Background long downloads/long compiles: put large wheels, SDK offline packages, and source builds into nohup/background + poll logs; do not block on a single command.
  • Walk the verification ladder step by step; each level must pass before moving up: L1 toolchain/version query → L2 ldd no missing libraries → L3 single device visible + small matmul + autocast + synchronize → L4 single-process communication library → L5 two-process torchrun all-reduce → L6 short real workload.
  • If any level fails: return to Phase 3 and recheck the compatibility set; do not repeatedly force-install.
  • Record throughout: exact versions, commands, paths, output summaries (strip PIDs/job names)—needed for writing to disk in Phase 5.

Phase 5: Write to disk and hand off

According to accel-skill-template solidify the verified knowledge: The three platform layers arefixed generic namesThree-piece set (accel-platform-install / accel-pytorch-python / accel-pytorch-code-porting, already installed on this machine with the set) —Rewrite the main text in placefor the current platform (each piece has a "how to specialize" guide at its head), without creating a new platform-named skill; host machine facts go into the host layer (named for this machine, never entered into the installation list). The rewritten three-piece set is then the execution basis for this machine on that platform; when the content is universally applicable to other machines, run platform-environment-skill-audit desensitize and then flow back to the repository to update the distribution version (old instances go into git history; machines already installed do not chase the new version).

Boundaries

  • This skill does not write code or port projects — that is <platform>-pytorch-code-porting 's job.
  • CPU-only workstation with a Python base: stage 2 applies on its own, skip the other stages.
  • Each machine's platform stack facts exist only in the host layer, platform-generic knowledge exists only in the platform's three layers, and the two layers do not mix.