[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CSNG5R3BY7BQ55T6FASFPT":3,"skill-same:01M7CSNG5R3BY7BQ55T6FASFPT":72},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":6,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M7CSNG5R3BY7BQ55T6FASFPT","nemo-mbridge-perf-moe-vlm-training",null,"Practical guidance for training MoE VLMs in Megatron Bridge. Compares FSDP and 3D-parallel approaches, using rounded lessons from Qwen3-VL, Qwen3-Next, and other multimodal experiments.","YYC-Cube\u002FYYC3-Knowledge-Base","YYC-Cube","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235006543?v=4","01M79J2PH4SWD2X0825X6PN748","yyc3","01M79J2PHVK3F6ZBYT8K2SCZCW",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-vlm-training\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: nemo-mbridge-perf-moe-vlm-training\ndescription: Practical guidance for training MoE VLMs in Megatron Bridge. Compares FSDP and 3D-parallel approaches, using rounded lessons from Qwen3-VL, Qwen3-Next, and other multimodal experiments.\nlicense: Apache-2.0\nwhen_to_use: Training MoE VLMs, or investigating a commit that caused MoE VLM training failure or OOM; 'MoE VLM', 'multimodal MoE', 'Qwen3-VL training', 'FSDP vs 3D-parallel for VLM', 'MoE vision language model'.\n---\n\n# MoE VLM Training\n\nStable docs: @docs\u002Ftraining\u002Fmoe-optimization.md\nCard: @skills\u002Fnemo-mbridge-perf-moe-vlm-training\u002Fcard.yaml\n\n## FSDP vs 3D Parallel\n\n| Approach | Strength | Best fit |\n|---|---|---|\n| FSDP | Simplest path to a working multimodal run | first bring-up, memory-first tuning, awkward PP boundaries |\n| 3D parallel | Higher ceiling after tuning | stable models with a clean PP layout and time for deeper sweeps |\n\nFor MoE VLMs, the practical workflow is usually:\n\n1. get the first reliable run with FSDP\n2. stabilize real-data input, recompute, and memory behavior\n3. move to 3D parallel only if the throughput headroom is worth the extra work\n\n## Rounded Findings From Recent VLM Runs\n\n### Qwen3-VL class models\n\nThe main patterns were consistent across the tracker:\n\n- FSDP on GB200-class systems can already reach healthy high-teens utilization\n  with a comparatively simple setup\n- B200 FSDP runs are viable, but more sensitive to recompute choice and frozen\n  vision settings\n- 3D parallel can recover to a similar or better operating point, but only after\n  tuning MBS, recompute, and the real vision path together\n\n### Real data vs mock data\n\nMock-data VLM runs are not trustworthy performance proxies. In the experiments,\nimage-free mock runs looked closer to \"roughly twice as fast\" than \"slightly\noptimistic\" when compared with real multimodal input.\n\nUse real or realistic image payloads before drawing any conclusion about VLM\nthroughput.\n\n### Smaller multimodal MoE runs\n\nThe smaller Qwen3.5-style multimodal experiments reinforce the same lessons:\n\n- HybridEP is a solid default on GB200\n- TE-scoped CUDA graphs help once the training loop is stable\n- larger MBS can pay off, but only if the vision encoder does not become the\n  next bottleneck\n\n## Decision Guide\n\n### Choose FSDP when\n\n- you are bringing up a new VLM for the first time\n- the model has awkward stage boundaries across embedding, vision, and decoder\n- memory fit matters more than absolute throughput\n- you may freeze the vision stack during decoder-focused tuning\n\n### Choose 3D parallel when\n\n- the model is already stable under FSDP\n- the PP layout is clear and repeatable\n- you can sweep MBS, recompute, and CUDA-graph scope together\n- the goal is best steady-state throughput, not easiest bring-up\n\n## Key Tuning Knobs\n\n1. **Freeze the vision stack when appropriate**: if the work is decoder-focused,\n   freezing the vision side often gives a small but real throughput gain and\n   reduces memory pressure.\n\n2. **Sweep MBS aggressively**: VLMs are more MBS-sensitive than text-only MoE\n   runs because the vision path changes the compute-to-overhead balance.\n\n3. **Prefer selective recompute once the model fits**: full recompute is a\n   useful bring-up tool, but selective recompute is usually the better steady\n   state.\n\n4. **Match CUDA-graph scope to the workload**: `attn moe_router moe_preprocess`\n   is the safer MoE default, while narrower scopes can still be useful for\n   controlled experiments.\n\n5. **Use ETP only when EP alone is insufficient**: it can unlock a layout, but\n   it also introduces more communication and more tuning surface.\n\n## Representative Config Families\n\n### FSDP-first GB200 path\n\n```text\nTP=1  CP=1  PP=1\nEP sized to the expert topology, often large\nDispatcher: HybridEP on GB200-class systems\nRecompute: start with full, then relax toward selective recompute\n```\n\n### 3D-parallel GB200 path\n\n```text\nTP=1  CP=1  PP=1 or modest PP\nEP and ETP sized to the expert topology\nDispatcher: HybridEP\nCUDA Graph: start narrow, then widen only after the real-data path is stable\n```\n\n## Compatibility\n\n| Feature | FSDP | 3D parallel |\n|---|---|---|\n| HybridEP on GB200 | strong default | strong default once topology is stable |\n| CUDA graphs | useful after bring-up | useful, but more scope-sensitive |\n| Freeze vision | natural fit | possible, but less often used as the headline perf path |\n| Selective recompute | recommended | recommended |\n\n## Pitfalls\n\n1. **Mock multimodal data is misleading**: it can make the decoder look much\n   healthier than the real end-to-end VLM path.\n\n2. **The vision encoder can dominate unexpectedly**: profile encoder, projector,\n   and decoder separately before attributing everything to the dispatcher.\n\n3. **Do not compare FSDP and 3D-parallel runs with different effective work**:\n   normalize by useful tokens and workload shape, not only by step time.\n\n4. **ETP is not free**: use it as a fit or topology tool, not as the default.\n\n5. **Recompute and CUDA-graph choices are coupled**: the setting that gets the\n   model to fit is often not the setting that gives the best steady-state speed.\n","# MoE VLM Training\n\nStable docs: @docs\u002Ftraining\u002Fmoe-optimization.md\nCard: @skills\u002Fnemo-mbridge-perf-moe-vlm-training\u002Fcard.yaml\n\n## FSDP vs 3D Parallel\n\n| Approach | Strength | Best fit |\n|---|---|---|\n| FSDP | Simplest path to a working multimodal run | first bring-up, memory-first tuning, awkward PP boundaries |\n| 3D parallel | Higher ceiling after tuning | stable models with a clean PP layout and time for deeper sweeps |\n\nFor MoE VLMs, the practical workflow is usually:\n\n1. get the first reliable run with FSDP\n2. stabilize real-data input, recompute, and memory behavior\n3. move to 3D parallel only if the throughput headroom is worth the extra work\n\n## Rounded Findings From Recent VLM Runs\n\n### Qwen3-VL class models\n\nThe main patterns were consistent across the tracker:\n\n- FSDP on GB200-class systems can already reach healthy high-teens utilization\n  with a comparatively simple setup\n- B200 FSDP runs are viable, but more sensitive to recompute choice and frozen\n  vision settings\n- 3D parallel can recover to a similar or better operating point, but only after\n  tuning MBS, recompute, and the real vision path together\n\n### Real data vs mock data\n\nMock-data VLM runs are not trustworthy performance proxies. In the experiments,\nimage-free mock runs looked closer to \"roughly twice as fast\" than \"slightly\noptimistic\" when compared with real multimodal input.\n\nUse real or realistic image payloads before drawing any conclusion about VLM\nthroughput.\n\n### Smaller multimodal MoE runs\n\nThe smaller Qwen3.5-style multimodal experiments reinforce the same lessons:\n\n- HybridEP is a solid default on GB200\n- TE-scoped CUDA graphs help once the training loop is stable\n- larger MBS can pay off, but only if the vision encoder does not become the\n  next bottleneck\n\n## Decision Guide\n\n### Choose FSDP when\n\n- you are bringing up a new VLM for the first time\n- the model has awkward stage boundaries across embedding, vision, and decoder\n- memory fit matters more than absolute throughput\n- you may freeze the vision stack during decoder-focused tuning\n\n### Choose 3D parallel when\n\n- the model is already stable under FSDP\n- the PP layout is clear and repeatable\n- you can sweep MBS, recompute, and CUDA-graph scope together\n- the goal is best steady-state throughput, not easiest bring-up\n\n## Key Tuning Knobs\n\n1. **Freeze the vision stack when appropriate**: if the work is decoder-focused,\n   freezing the vision side often gives a small but real throughput gain and\n   reduces memory pressure.\n\n2. **Sweep MBS aggressively**: VLMs are more MBS-sensitive than text-only MoE\n   runs because the vision path changes the compute-to-overhead balance.\n\n3. **Prefer selective recompute once the model fits**: full recompute is a\n   useful bring-up tool, but selective recompute is usually the better steady\n   state.\n\n4. **Match CUDA-graph scope to the workload**: `attn moe_router moe_preprocess`\n   is the safer MoE default, while narrower scopes can still be useful for\n   controlled experiments.\n\n5. **Use ETP only when EP alone is insufficient**: it can unlock a layout, but\n   it also introduces more communication and more tuning surface.\n\n## Representative Config Families\n\n### FSDP-first GB200 path\n\n```text\nTP=1  CP=1  PP=1\nEP sized to the expert topology, often large\nDispatcher: HybridEP on GB200-class systems\nRecompute: start with full, then relax toward selective recompute\n```\n\n### 3D-parallel GB200 path\n\n```text\nTP=1  CP=1  PP=1 or modest PP\nEP and ETP sized to the expert topology\nDispatcher: HybridEP\nCUDA Graph: start narrow, then widen only after the real-data path is stable\n```\n\n## Compatibility\n\n| Feature | FSDP | 3D parallel |\n|---|---|---|\n| HybridEP on GB200 | strong default | strong default once topology is stable |\n| CUDA graphs | useful after bring-up | useful, but more scope-sensitive |\n| Freeze vision | natural fit | possible, but less often used as the headline perf path |\n| Selective recompute | recommended | recommended |\n\n## Pitfalls\n\n1. **Mock multimodal data is misleading**: it can make the decoder look much\n   healthier than the real end-to-end VLM path.\n\n2. **The vision encoder can dominate unexpectedly**: profile encoder, projector,\n   and decoder separately before attributing everything to the dispatcher.\n\n3. **Do not compare FSDP and 3D-parallel runs with different effective work**:\n   normalize by useful tokens and workload shape, not only by step time.\n\n4. **ETP is not free**: use it as a fit or topology tool, not as the default.\n\n5. **Recompute and CUDA-graph choices are coupled**: the setting that gets the\n   model to fit is often not the setting that gives the best steady-state speed.\n",{"name":5,"license":15,"description":7,"when_to_use":24},"Training MoE VLMs, or investigating a commit that caused MoE VLM training failure or OOM; 'MoE VLM', 'multimodal MoE', 'Qwen3-VL training', 'FSDP vs 3D-parallel for VLM', 'MoE vision language model'.","main","87afe6ce96220accf50a345dea46784c8c9f210e","YYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-vlm-training",0,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base","https:\u002F\u002Fkb.yyc3.top\u002F","https:\u002F\u002Fgithub.com\u002FYYC-Cube","万象归元于云枢 | 深栈智启新纪元","2026-11-10 10:37:32",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add YYC-Cube\u002FYYC3-Knowledge-Base --skill nemo-mbridge-perf-moe-vlm-training",{"tool":40,"command":41},"bunx","bunx skills add YYC-Cube\u002FYYC3-Knowledge-Base --skill nemo-mbridge-perf-moe-vlm-training",{"tool":43,"command":44},"pnpm","pnpm dlx skills add YYC-Cube\u002FYYC3-Knowledge-Base --skill nemo-mbridge-perf-moe-vlm-training","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-vlm-training\u002FSKILL.md",true,[48,54,58,62,66],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"BENCHMARK.md","REFERENCE","参考文档",4355,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-vlm-training\u002FBENCHMARK.md",{"path":55,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":56,"sourceHtmlUrl":57},"card.yaml",2993,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-vlm-training\u002Fcard.yaml",{"path":59,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":60,"sourceHtmlUrl":61},"evals\u002Fevals.json",1770,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-vlm-training\u002Fevals\u002Fevals.json",{"path":63,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":64,"sourceHtmlUrl":65},"skill-card.md",3931,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-vlm-training\u002Fskill-card.md",{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"skill.oms.sig","OTHER","其他",4829,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-vlm-training\u002Fskill.oms.sig",[73,81,88,95,102,109],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M7CTDWHERCXPQCP0K03A86AS","vercel-sandbox","Run agent-browser + Chrome inside Vercel Sandbox microVMs for browser automation from any Vercel-deployed app. Use when the user needs browser automation in a Vercel app (Next.js, SvelteKit, Nuxt, Remix, Astro, etc.), wants to run headless Chrome without binary size limits, needs persistent browser sessions across commands, or wants ephemeral isolated browser environments. Triggers include \"Vercel Sandbox browser\", \"microVM Chrome\", \"agent-browser in sandbox\", \"browser automation on Vercel\", or any task requiring Chrome in a Vercel Sandbox.","MIT","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Fvercel-sandbox\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M7CTD8D2BNJY54S65M47HEJA","slack","Interact with Slack workspaces using browser automation. Use when the user needs to check unread channels, navigate Slack, send messages, extract data, find information, search conversations, or automate any Slack task. Triggers include \"check my Slack\", \"what channels have unreads\", \"send a message to\", \"search Slack for\", \"extract from Slack\", \"find who said\", or any task requiring programmatic Slack interaction.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Fslack\u002FSKILL.md",[],[],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":19},"01M7CTCSSB8ZP3Q58C3YZDZK1W","electron","Automate Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify, etc.) using agent-browser via Chrome DevTools Protocol. Use when the user needs to interact with an Electron app, automate a desktop app, connect to a running app, control a native app, or test an Electron application. Triggers include \"automate Slack app\", \"control VS Code\", \"interact with Discord app\", \"test this Electron app\", \"connect to desktop app\", or any task requiring automation of a native Electron application.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Felectron\u002FSKILL.md",[],[],{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":19},"01M7CTCBJY76688V4DCZGWFHGQ","dogfood","Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to \"dogfood\", \"QA\", \"exploratory test\", \"find issues\", \"bug hunt\", \"test this app\u002Fsite\u002Fplatform\", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Fdogfood\u002FSKILL.md",[],[],{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":19},"01M7CTC4H0FFGVEAQR9PA4GA1A","agent-browser","Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to \"open a website\", \"fill out a form\", \"click a button\", \"take a screenshot\", \"scrape data from a page\", \"test this web app\", \"login to a site\", \"automate browser actions\", or any task requiring programmatic web interaction.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Fagent-browser\u002FSKILL.md",[],[],{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":19},"01M7CTBKVFYBG78FDSABSDJTTQ","shadcn","Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI, including chat interfaces. Provides project context, component docs, and usage examples. Applies when working with shadcn\u002Fui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for \"shadcn init\", \"create an app with --preset\", \"switch to --preset\", and for building a design system or applying a DESIGN.md or brand spec to shadcn\u002Fui.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-UI-界面组件\u002FYYC3-UI-界面组件-ui\u002Fskills\u002Fshadcn\u002FSKILL.md",[],[]]