docs: separate technique guidance into docs, skills, and knowledge

Clarify which training guidance is stable documentation versus operational enablement so technique knowledge can be maintained without duplicated docs.

Signed-off-by: yaoyu-33 <yaoyu.094@gmail.com>
Made-with: Cursor

Author: yaoyu-33

docs/training/README.md

@@ -41,6 +41,7 @@ This directory contains comprehensive documentation for training and customizing
 | **[Optimizer & Scheduler](optimizer-scheduler.md)** | Optimizer and learning rate scheduler configuration | Setting up optimization |
 | **[Mixed Precision](mixed-precision.md)** | Mixed precision training for memory efficiency | Reducing memory usage |
 | **[Communication Overlap](communication-overlap.md)** | Overlapping communication with computation | Optimizing distributed training |
+| **[Hybrid Context Parallel](hybrid-context-parallel.md)** | Hierarchical `a2a+p2p` context parallel guidance | Advanced long-sequence scaling |
 | **[Attention Optimizations](attention-optimizations.md)** | Optimizing attention mechanisms | Improving training speed |
 | **[Activation Recomputation](activation-recomputation.md)** | Gradient checkpointing strategies | Reducing memory footprint |
 | **[CPU Offloading](cpu-offloading.md)** | Offloading to CPU for memory management | Working with limited GPU memory |
@@ -59,6 +60,7 @@ This directory contains comprehensive documentation for training and customizing
 |----------|---------|--------------|
 | **[PEFT](peft.md)** | Parameter-Efficient Fine-Tuning (LoRA, etc.) | Fine-tuning with limited resources |
 | **[Packed Sequences](packed-sequences.md)** | Sequence packing for efficiency | Optimizing data loading |
+| **[Megatron FSDP](megatron-fsdp.md)** | Stable overview of Megatron FSDP | Choosing an FSDP path |
 | **[Distillation](distillation.md)** | Knowledge distillation techniques | Transferring knowledge between models |
 | **[Checkpointing](checkpointing.md)** | Checkpoint saving, loading, and resuming | Managing training state |
 | **[Callbacks](callbacks.md)** | Inject custom logic into training loop | Custom logging, metrics, third-party integrations |

docs/training/communication-overlap.md

@@ -0,0 +1,64 @@
+# Hybrid / Hierarchical Context Parallel
+
+This page covers the stable Bridge-facing meaning of hierarchical context
+parallelism, especially the `a2a+p2p` transport path and
+`hierarchical_context_parallel_sizes`.
+
+For operational setup, code anchors, and verification commands, see
+`skills/perf-techniques/hybrid-context-parallel.md`.
+
+## What It Is
+
+In upstream Megatron-Core, `cp_comm_type="a2a+p2p"` plus
+`hierarchical_context_parallel_sizes` enables a hierarchical context-parallel
+transport path. This is the Bridge-relevant form of hierarchical context
+parallelism.
+
+It is important to separate that from the upstream boolean
+`hybrid_context_parallel`, which is a different feature for balancing packed or
+variable-length workloads. The two concepts should not be treated as
+interchangeable.
+
+## When to Use It
+
+Hierarchical context parallelism is relevant when:
+
+- plain context parallelism is already required
+- larger CP sizes make flat `p2p` less attractive
+- you specifically want the hierarchical `a2a+p2p` transport path
+
+It should be treated as an advanced feature rather than a default recommendation.
+
+## Stable Bridge Limitation
+
+The most important Bridge-specific limitation is that hierarchical context
+parallelism is currently supported only on the MPU initialization path.
+
+In practice, that means:
+
+- `dist.use_decentralized_pg=False` is the supported Bridge path
+- the decentralized process-group path should not be assumed to materialize HCP
+  groups
+
+## Stable Constraints
+
+The durable constraints are:
+
+- `hierarchical_context_parallel_sizes` must match
+  `context_parallel_size` multiplicatively
+- the usual CP sequence-length divisibility rules still apply
+- Transformer Engine version support matters for `a2a+p2p`
+
+## Recommendation Level
+
+Use hierarchical context parallelism in Bridge only when you intentionally want
+that transport path and are prepared to validate execution-path details. It is
+not yet the kind of feature that should be presented as universally safe across
+all Bridge initialization modes.
+
+## Related Docs
+
+- `docs/performance-guide.md`
+- `docs/training/communication-overlap.md`
+- `skills/perf-techniques/hybrid-context-parallel.md`
+- `knowledge/techniques/hybrid_context_parallel.yaml`