Use this skill when adding support for a new model to VeOmni. Covers the full lifecycle: analyzing the HuggingFace model, creating model patches, defining parallel plans, writing configs, integrating with the trainer, and testing. Trigger: 'add model', 'support new model', 'integrate a model', 'new model support'.
77
96%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Use TodoWrite to track all phases:
Phase 1: Analyze HF model -> in_progress
Phase 2: Create model patch -> pending
Phase 3: Define parallel plan -> pending
Phase 4: Write training config -> pending
Phase 5: Integrate with trainer -> pending
Phase 6: Test -> pendingIdentify the model on HuggingFace. Read its config.json, modeling_*.py, and any processor configs.
Determine model category:
veomni/models/transformers/<model_name>/veomni/models/transformers/<model_name>/ + veomni/data/multimodal/veomni/distributed/moe/ integrationveomni/models/diffusers/<model_name>/veomni/models/seed_omni/Check existing similar models: Find the closest existing model in veomni/models/transformers/ and use it as a reference. E.g., if adding a new Qwen variant, reference qwen3/ or qwen3_vl/.
Identify required patches: VeOmni uses a patchgen system (veomni/patchgen/) to auto-generate model patches from HuggingFace models. Check if a patch spec already exists or if one needs to be created.
Create the model directory: veomni/models/transformers/<model_name>/
Required files:
__init__.py — model registration (MODELING_REGISTRY / MODEL_CONFIG_REGISTRY / MODEL_PROCESSOR_REGISTRY)<model_name>_gpu_patch_gen_config.py — declarative patchgen config (replace_class / override_method / replace_function / modify_init / add_post_import_block / drop_import_names) defining all VeOmni patches against the upstream HF modeling<model_name>_npu_patch_gen_config.py — NPU patchgen config (often just imports the GPU config and applies NPU-specific overrides via name_map)parallel_plan.py — FSDP / TP / EP sharding plangenerated/patched_modeling_<model_name>_{gpu,npu}.py — patchgen output (do NOT edit manually)Patch patterns — follow existing models:
OpSlot for attention/loss and override forward via patchgengate_up_proj [E, 2*I, H] / down_proj [E, H, I]) and add a veomni_moe_experts_forward OpSlotveomni_causal_lm_loss OpSlot and return CausalLMOutputWithLogProbs__init__.py (no entry in veomni/models/auto.py is needed for transformers models — registration happens via the per-model MODELING_REGISTRY decorators)Run patchgen: make patchgen regenerates every generated/patched_modeling_*.py from the matching *_patch_gen_config.py.
Create parallel_plan.py in the model directory.
Define FSDP/FSDP2 sharding strategy:
If the model is MoE, define expert parallelism plan in addition to FSDP.
Reference existing parallel plans for guidance (e.g., veomni/models/transformers/qwen3_moe/parallel_plan.py).
Model config: Create configs/model_configs/<model_family>/<ModelName>.json matching HuggingFace format.
Training config: Create YAML in the appropriate directory:
configs/text/<model_name>.yamlconfigs/multimodal/<model_name>/<model_name>.yamlconfigs/dit/<model_name>.yamlConfig must include: model path, data config, optimizer settings, parallelism config, checkpoint settings.
Verify against existing configs — match the structure of similar model configs.
Verify the model works with the appropriate trainer:
TextTrainer (veomni/trainer/text_trainer.py)VLMTrainer (veomni/trainer/vlm_trainer.py)DitTrainer (veomni/trainer/dit_trainer.py)If the model needs custom data preprocessing:
veomni/data/data_transform.py or veomni/data/multimodal/If the model needs custom collator logic:
veomni/data/data_collator.pyVLM only — multimodal metadata precompute: to keep the ViT forward free
of host-device CUDA syncs, derive ViT cu_seqlens / max_seqlen in the
collator rather than the forward. Follow the checklist in
.agents/knowledge/multimodal_metadata.md ("Adding the hook to a new model"):
a collate_multimodal_metadata patchgen helper + a get_metadata_collate_func
override, the per-modality vit_metadata sub-dict threaded through
Model.forward → ViT.forward (with a runtime fallback), and the model added to
_MM_METADATA_WIRED_CASES in the sync gate test.
Create toy config: Add tests/toy_config/<model_name>_toy/config.json with minimal parameters for fast testing.
Unit tests: Add tests in tests/models/ to verify:
veomni.models.autoE2e tests (if feasible): Test a short training run using the toy config.
Run make quality and pytest tests/models/.
Update documentation:
docs/ (training command, config reference)..agents/knowledge/architecture.md if the model adds a new module or trainer path.README.md if applicable.__init__.py. If the model's AutoConfig type is not registered, build_foundation_model() will fail.generated/ directories — they are overwritten by patchgen. Edit the matching <model>_{gpu,npu}_patch_gen_config.py and re-run make patchgen instead.veomni/data/chat_template.py.transformers==5.9.0 (pinned by the transformers-stable default dependency group). Models register through the patchgen-generated path under generated/; do not introduce legacy modeling_<m>.py files or apply_veomni_<m>_patch() helpers.9ff4858
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.