trtllm-moe-develop

Review TensorRT-LLM MoE code changes against canonical architecture and ownership boundaries.

Updated May 23, 2026
One-click install
npx skills add https://github.com/yo-steven/skills-exploration-20260522 --skill trtllm-moe-develop
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: trtllm-moe-develop
Source: https://github.com/yo-steven/skills-exploration-20260522/tree/main/skills/TensorRT-LLM/trtllm-moe-develop
Command: npx skills add https://github.com/yo-steven/skills-exploration-20260522 --skill trtllm-moe-develop

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It prevents MoE changes from drifting away from TensorRT-LLM’s current architecture by enforcing clean ownership boundaries across ConfigurableMoE, MoEScheduler, backends, quantization/weights, EPLB, communication, and routing-factory logic.

Core Features & Use Cases

  • Architecture-aligned design and refactoring: Guides reviews and edits that touch MoE modules (fused_moe modules, ConfigurableMoE, MoEScheduler, communication strategies, EPLB, quantization/weight handling, routing/factories, and MoE tests).
  • Owner-boundary enforcement: Ensures behavior is implemented in the correct layer (assembler vs scheduler vs backend compute vs quantization-weight methods vs communication strategies).
  • Testability and safety gates: Requires citing canonical code patterns and planning targeted unit coverage for the specific boundary being changed (including multi-GPU and EPLB/migration-related behavior).

Quick Start

Use the trtllm-moe-develop skill to review or plan a refactor you intend to make in TensorRT-LLM’s MoE codebase, ensuring the change preserves architecture boundaries and includes the right MoE tests.

Frequently Asked Questions about trtllm-moe-develop

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review TensorRT-LLM MoE code without breaking architecture boundaries?

Review TensorRT-LLM MoE code by enforcing clean ownership boundaries across ConfigurableMoE, MoEScheduler, backends, EPLB, communication, and routing. This ensures behavior stays in the correct layer and requires citing canonical patterns with file and line evidence.

What is the correct ownership boundary for MoEScheduler forward policy changes in TensorRT-LLM?

MoEScheduler forward policy changes belong to the scheduler layer, distinct from backend compute or communication strategies. Correct ownership boundaries prevent behavior from leaking across assembler, scheduler, and quantization-weight methods.

How do I refactor fused MoE modules in TensorRT-LLM safely?

Refactor fused MoE modules by following canonical reference patterns and planning targeted unit tests for the specific boundary being changed. This includes coverage for multi-GPU and EPLB-related behavior to ensure safety.

Does TensorRT-LLM MoE development require specific tests for EPLB and load balancing changes?

Yes, EPLB and load balancing changes require targeted unit coverage for the specific boundary being modified. Planning boundary-specific test plans ensures multi-GPU and migration-related behavior remains correct.

How do I handle quantization and weight changes in TensorRT-LLM MoE architectures?

Handle quantization and weight changes within their designated quantization-weight methods layer. Enforcing architecture alignment ensures these changes do not drift from canonical TensorRT-LLM MoE patterns.

When should I check communication and dispatch strategy boundaries in TensorRT-LLM MoE?

Check communication and dispatch strategy boundaries whenever touching fused MoE modules or multi-GPU configurations. Ensuring behavior is implemented in the correct communication layer prevents architectural drift.