메뉴
Merge a base HF model dir with an extra HF model dir by index diff — take tensors only present in extra, append them to a new output dir in HF-standard shard layout. Base wins on overlap.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/InternLM/xtuner --skill model-patch명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
Add or audit an XTuner chat-template implementation and its loss mask from an official Hugging Face model repository or local model directory. Use when supporting a new model under xtuner/v1/data_proto/messages, checking an existing implementation against tokenizer or processor apply_chat_template, deciding which assistant output and stop/EOS tokens receive loss, adding regression tests, or validating that exported training behavior matches vLLM and SGLang inference.
Implement a missing XTuner Hugging Face config export from the official HF model when possible, then validate it against the installed Transformers round-trip and versioned inference-engine field contracts. Use when adding a model, when hf_config is missing or returns None, when changing from_hf/hf_config/save_hf, when reviewing config.json differences, or when debugging vLLM/SGLang checkpoint-load or inference failures. Also use for requests named check_hf_config_save.
Use when the user wants to instrument, inspect, or debug XTuner traces to reconstruct a sample/request execution path, follow cross-process call chains, or identify latency hotspots, bottleneck stages, and abnormal paths from span data.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | model_patch |
| description | Merge a base HF model dir with an extra HF model dir by index diff — take tensors only present in extra, append them to a new output dir in HF-standard shard layout. Base wins on overlap. |
Produce out = base ∪ (extra \ base) at the tensor level, by diffing the
two model.safetensors.index.json files. Useful when extra is a sibling
checkpoint (different training run, fine-tune, or fp8 conversion) that holds a
few tensors the base is missing — e.g. an updated head, a newly-added MTP
block, or auxiliary projections — and you want a self-contained merged dir
without re-running the whole conversion pipeline.
Overlap rule: base wins. Any tensor present in both indexes is taken from
base; the corresponding entry in extra is ignored.
.claude/skills/model_patch/
├── SKILL.md # this file
└── model_patch.py # CLI + library
python model_patch.py \
--base /path/to/base-model \
--extra /path/to/extra-model \
--out /path/to/merged-model
model-{i:05d}-of-{N:05d}.safetensors shards (total N = base shards +
newly-packed shards holding the extra-only tensors)model.safetensors.index.jsonbase — config.json, tokenizer files,
modeling/configuration .py, generation_config.json, README, etc. —
copied verbatim so out is loadable on its own. Subdirectories are
copied recursively. Existing entries in out are overwritten.extra's aux files are deliberately not copied. The skill's overlap
rule is "base wins" at the tensor level, and that extends to configs: extra
often carries engine-specific edits or modality keys that don't match the
tensor topology we keep. If you need fields from extra's config.json
(e.g. a new modality), merge them into out/config.json as a separate,
explicit step.
-of-N total. By default the
bytes are fully copied so out is independent of base. Pass
--hardlink to use os.link instead (fast, but the two trees share
inodes — editing one mutates the other; deleting one keeps the other
intact since hardlinks are symmetric).--shard-size-gb GiB (default 4), appended after the base shards.So a base with 12 shards plus 5 GB of extra-only tensors yields:
model-00001-of-00014.safetensors … model-00012-of-00014.safetensors
(copies of the base shards) and
model-00013-of-00014.safetensors / model-00014-of-00014.safetensors
(freshly written, containing only the extra tensors).
| Situation | Use this? |
|---|---|
extra contains a few tensors base is missing; everything else is identical. | Yes |
| You need to merge two checkpoints whose overlapping tensors differ in value. | No — this skill silently keeps base; you probably want a manual decision per key. |
extra is a full quantization of base and you want the quantized weights. | No — use model_normalize with --reference extra instead. |
You want a single model.safetensors instead of standard shards. | No — repack downstream. |
Before invoking model_patch.py:
--base, --extra, --out) with the user
via AskUserQuestion. Never infer them from earlier conversation.model.safetensors.index.json files and reporting:
After a successful run, do not ask the user where the output should go —
--out is already the final destination the user named. Just report what
landed there (shard count, index path, total size, and that base's aux files
were mirrored over). Unlike model_normalize, model_patch has no
staging-area concept: there is no temp dir, and the caller already made the
placement decision when they passed --out.
If the user wanted any of extra's aux files (e.g. a config.json that
documents a new modality), call that out — those are not copied by the
skill and must be merged in by hand.