运维测试
- 作者仓库星标 0
- 作者更新于 实时读取
- 作者仓库 skills-registry
- 领域
- AI 智能
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @tomevault-io · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需手动接入
- 是否需要外部 API Key
- 需要 · Vendor-specific
- 兼容的系统
- 未声明(默认跨平台)
- 底层运行要求
- Python
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 读取环境变量
- 网络行为
- 允许外网请求
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: vllm-configuration
description: |- Use when this capability is needed. Target audience: operators deploying vLLM in production —…
category: AI 智能
runtime: Python
---
# vllm-configuration 输出预览
## PART A: 任务判断
- 适用问题:提示词、Agent 工作流、模型评估或自动化推理。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“Why this matters / Precedence, in one sentence / The YAML config file”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于提示词、Agent 工作流、模型评估或自动化推理,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“Why this matters / Precedence, in one sentence / The YAML config file”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、执行终端命令、读取环境变量、会按任务需要访问外部网络、需要准备 Vendor-specific API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令、读取环境变量;会按任务需要访问外部网络;需要准备 Vendor-specific API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文出现了 `/models`、`/mnt`、`/local`、`/metrics` 这类斜杠命令;如果你的 Agent 支持命令触发,优先用命令开场,再补充目标和边界。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件、执行终端命令、读取环境变量。
先用一个小任务确认它会围绕“Why this matters / Precedence, in one sentence / The YAML config file”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: vllm-configuration
description: |- Use when this capability is needed. Target audience: operators deploying vLLM in production —…
category: AI 智能
source: tomevault-io/skills-registry
---
# vllm-configuration
## 什么时候使用
- 把 AI / Agent方向的常用动作沉淀成 Agent 可调用的技能 适合处理AI Agent、提示词、模型评估与自动化推理,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查…
- 面向提示词、Agent 工作流、模型评估或自动化推理,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「Why this matters / Precedence, in one sentence / The YAML config file」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令、读取环境变量;会按任务需要访问外部网络;需要准备 Vendor-specific API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "vllm-configuration" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> Why this matters / Precedence, in one sentence / The YAML config file
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> Python | 读取文件、写入/修改文件、执行终端命令、读取环境变量 | 会按任务需要访问外部网络
安全层 -> 需要准备 Vendor-specific API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} vLLM configuration
Target audience: operators deploying vLLM in production — datacenter GPUs, containerized, often inside networks that can't reach huggingface.co directly and need to use internal mirrors or fully offline caches.
Why this matters
vLLM's config surface is deceptively layered: CLI flags, a YAML --config file, VLLM_* env vars, and the HuggingFace / Transformers env vars it inherits transparently. The same setting can exist in three places, and the precedence ordering is not intuitive. Getting this wrong produces three classic failure modes:
- First-boot network errors — operator pre-downloaded weights to a local path, but vLLM still hits
huggingface.cofor a revision check, a missing tokenizer file, or usage stats. The "local path" illusion is incomplete. - Env-var namespace collisions — a Kubernetes Service named
vllminjectsVLLM_SERVICE_HOST/VLLM_SERVICE_PORTinto every pod, which silently overridesVLLM_HOST_IP/VLLM_PORT. vLLM's internal distributed init then uses the k8s cluster IP and breaks. VLLM_HOST_IPas an API host — operators alias--host $VLLM_HOST_IPassuming symmetry with the API server.VLLM_HOST_IPis the internal inter-worker bind address, not the OpenAI-compat server host. Using it as the API host breaks TP/PP distributed init.
The fix in every case is understanding the layering. This skill teaches that layering, then gives the operator-facing knobs, then the air-gapped recipe.
Precedence, in one sentence
CLI arg > --config FILE.yaml > VLLM_* env var > library default.
So vllm serve /models/llama --config prod.yaml uses /models/llama even if prod.yaml sets model: meta-llama/Llama-3.1-8B. And VLLM_LOGGING_LEVEL=DEBUG is overridden by --log-level=INFO.
One non-obvious case: env vars that vLLM reads directly (like HF_HUB_OFFLINE) are consumed by the library layer, not the arg parser, so they aren't subject to this precedence — they gate behaviour unconditionally.
The YAML config file
Every CLI flag has a YAML equivalent. Keys use the same name, hyphens allowed or underscored. Booleans must be explicit (true/false, not YAML's loose yes/on).
# prod.yaml
model: /mnt/models/Llama-3.1-70B-Instruct
tensor-parallel-size: 4
gpu-memory-utilization: 0.9
max-model-len: 32768
dtype: bfloat16
enable-prefix-caching: true
served-model-name: llama-70b
# Nested composite configs — YAML dict becomes a JSON string on the CLI
speculative-config:
model: nvidia/Llama-3.1-70B-Instruct-Eagle3
num_speculative_tokens: 3
compilation-config:
pass_config:
fuse_allreduce_rms: true
vllm serve --config prod.yaml
Gotchas:
listargs become YAML sequences (allowed-origins: ["http://a", "http://b"]).- Dict args (
--kv-transfer-config,--speculative-config,--compilation-config) can be written as YAML dicts; the parser serializes to JSON before handing to the CLI layer. - Older versions had a key-order bug (issue #8947) where
served-model-nameplaced last could break parsing. Fixed on current main, but still seen on v0.10–v0.11 images. trust_remote_codein YAML:trust-remote-code: true(explicit boolean).
For the full per-section catalog (ModelConfig, CacheConfig, ParallelConfig, SchedulerConfig, LoadConfig, LoRAConfig, SpeculativeConfig, ObservabilityConfig, FrontendArgs), see references/config-file.md.
Environment variables — the operator-facing subset
Full catalog in references/env-vars.md. The ones that matter most in production:
Storage / cache (persist these):
VLLM_CACHE_ROOT(default~/.cache/vllm) — Torch compile, Triton, XLA, assets. Mount on PVC; otherwise the compile tax is paid every pod restart.HF_HOME(default~/.cache/huggingface) — HuggingFace hub cache. Preferred over the deprecatedTRANSFORMERS_CACHE.HF_HUB_CACHE— subdir underHF_HOME, rarely set directly.
Air-gap control:
HF_HUB_OFFLINE=1— required in air-gapped mode. Without it, vLLM hits HF on every startup to check for newer revisions, even with a warm cache. (vLLM CI itself adoptedHF_HUB_OFFLINE=1to avoid this — issue #23451, closed 2025-11-26.)TRANSFORMERS_OFFLINE=1— set both; some transformers-layer code paths honour only this one.HF_ENDPOINT=https://hf-mirror.com— redirect all HF traffic to a mirror. No trailing slash or it breaks.VLLM_USE_MODELSCOPE=true— route base-model downloads to ModelScope. Known gap: LoRA adapters still try HuggingFace. PR #13220 attempted the fix but was closed unmerged (2025-06-20); no upstream fix has landed. Workaround: download LoRA adapters manually, pass--lora-modules name=/local/path.HF_TOKEN— still required offline for gated repos (meta-llama/, google/gemma). vLLM validates access through the hub config layer before weight loading even when weights are local (issue #9255).
Telemetry (disable in air-gap):
VLLM_NO_USAGE_STATS=1orVLLM_DO_NOT_TRACK=1orDO_NOT_TRACK=1or touch$HOME/.config/vllm/do_not_track. Default endpoint ishttps://stats.vllm.ai. In air-gap, connection errors in logs result otherwise.
Networking (internal — read the warning below):
VLLM_HOST_IP— internal inter-worker bind IP for distributed (TP/PP/DP) init. NOT the API server host. Use--hoston the CLI for the API server.VLLM_PORT— internal base port for distributed; auto-increments for each worker. NOT the API server port. Use--port.
Server auth:
VLLM_API_KEY— Bearer token for the OpenAI-compat server. Equivalent to--api-keyon the CLI.
Long-context / safety overrides:
VLLM_ALLOW_LONG_MAX_MODEL_LEN=1— bypasses the model'smax_position_embeddingssanity check. Footgun — usually means the rope scaling config doesn't match the served weights.VLLM_ALLOW_INSECURE_SERIALIZATION=1— permits unsafe serialization formats over the wire. Never enable on multi-tenant.
Logging:
VLLM_LOGGING_LEVEL=DEBUG|INFO|WARN|ERROR,VLLM_LOGGING_PREFIX="rank0: ",VLLM_CONFIGURE_LOGGING=0(let the host app own config).
Air-gapped operation — the short recipe
Full recipe in references/air-gapped.md. The essentials:
Pre-stage on a connected host:
# new hf CLI HF_HOME=/export/hf hf download meta-llama/Llama-3.1-70B-Instruct # or python python -c "from huggingface_hub import snapshot_download; \ snapshot_download('meta-llama/Llama-3.1-70B-Instruct', local_dir='/export/models/llama-70b')"Transfer the directory into the enclave (rsync, physical media, MinIO, whatever the security posture allows).
Pick one of three patterns:
A. Fully offline with local path (simplest, recommended):
export HF_HOME=/mnt/hf-cache export HF_HUB_OFFLINE=1 export TRANSFORMERS_OFFLINE=1 export VLLM_NO_USAGE_STATS=1 vllm serve /mnt/models/llama-70b --tensor-parallel-size 8B. Internal HF mirror (reverse proxy):
export HF_ENDPOINT=https://hf.internal.example.com # NO trailing slash export HF_TOKEN=<internal-bot-token> # mirror may still gate vllm serve meta-llama/Llama-3.1-70B-Instruct --tensor-parallel-size 8C. ModelScope (Chinese / restricted networks):
export VLLM_USE_MODELSCOPE=true vllm serve qwen/Qwen2-72B-Instruct --trust-remote-code --tensor-parallel-size 8Caveat: LoRA adapters historically still fetched from HF even with this flag.
For gated models,
HF_TOKENmust be in the pod environment even when weights are local — it gates the config-validation path.
Critical pitfalls
Kubernetes Service named
vllmpoisons env vars. Kubernetes injects<SERVICE>_SERVICE_HOST/<SERVICE>_SERVICE_PORTinto every pod in the namespace. A Service namedvllmcollides with vLLM'sVLLM_namespace and in some versions interferes. The vLLM docs explicitly warn against naming the servicevllm. Name itvllm-apiorinferenceinstead.VLLM_HOST_IPis not the API host. It's the internal distributed bind address. Aliasing--host $VLLM_HOST_IPon the CLI breaks inter-worker init. API server host goes on--host; internal goes on the env var.HF_HUB_OFFLINE=1needs the cache fully populated or first-request fails. Includeconfig.json,tokenizer*,special_tokens_map.json,generation_config.json, and anymodeling_*.pyreferenced byauto_map— not just weights.Gated models offline still need
HF_TOKEN. The token is consulted during hub-config validation before weight load. Putting it only on the staging host isn't enough; bake it into the runtime env.trust_remote_codeexecutes arbitrary Python from the model repo. Any model not in vLLM's hard-coded architecture registry falls through toAutoConfig+auto_map, which only runs with the flag. In air-gap this runs pre-staged code — treat model directory provenance as equivalent to running arbitrary binaries. Verify checksums.TRANSFORMERS_CACHEis deprecated. Rename legacy scripts to useHF_HOME(and letHF_HUB_CACHEdefault). Setting the old var still works but emitsFutureWarning.YAML CLI positional beats config
model:.vllm serve /local/path --config prod.yamluses/local/pathregardless of whatprod.yamlsays. Intentional but surprising.Revision pinning:
--revisionapplies to model weights;--tokenizer-revisionis separate. Pinning the model to a commit but leaving the tokenizer floating lets it drift, and token counts change subtly. Pin both.load-format dummyfor profiling. Skips weight download entirely, materializes random weights. Useful for measuring startup / attention kernel perf in air-gap before weights arrive. Don't ship with this. Sibling flag--load-format fastsafetensorsaccelerates safetensors load via batched pread + NUMA-aware buffers (requiresfastsafetensors>=0.2.2+libnuma-dev; no env-var toggle exists in vLLM source).Torch compile cache misses cost minutes per startup. Persist
VLLM_CACHE_ROOTacross pod restarts (PVC, hostPath, or a shared NFS mount). First warmup of a new model config rebuilds CUDA graphs and torch.compile artifacts; subsequent starts hit cache.
For more failure modes and the fuller troubleshooting flow (first-boot hang, revision-check failure detection, tokenizer mismatch diagnosis), see references/troubleshooting.md.
Verifying a configuration
Before shipping, sanity-check the effective config:
# Grep the startup log — vLLM prints the resolved EngineConfig in the first 200 lines
kubectl logs <pod> --tail=400 | grep -A 40 'EngineConfig\|EngineArgs'
# Hit /metrics to confirm prefix caching, block size, KV dtype are live
curl -s http://localhost:8000/metrics | grep -E 'prefix_cache|gpu_cache|kv_cache'
# Confirm the model path that was actually loaded
curl -s http://localhost:8000/v1/models | jq '.data[].id'
${CLAUDE_SKILL_DIR}/scripts/check-config.sh bundles these checks — run it against a staged server to verify the config landed as intended.
External references
- Env vars (authoritative): https://docs.vllm.ai/en/stable/configuration/env_vars/
- Engine args: https://docs.vllm.ai/en/latest/configuration/engine_args/
- Serve args + YAML config: https://docs.vllm.ai/en/latest/configuration/serve_args/
- CLI: https://docs.vllm.ai/en/stable/cli/
- HF integration design: https://github.com/vllm-project/vllm/blob/main/docs/design/huggingface_integration.md
- Air-gapped thread: https://discuss.vllm.ai/t/setting-up-vllm-in-an-airgapped-environment/916
- Offline discussion: https://github.com/vllm-project/vllm/discussions/1405
- Blog — Anatomy of vLLM: https://vllm.ai/blog/anatomy-of-vllm
- Sibling skills:
vllm-caching(KV tiering + offload config),vllm-benchmarking(bench methodology + output JSON)
Source: air-gapped/skills — distributed by TomeVault.
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核