You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/guides/monitoring_and_debugging/features_and_diagnostics.md
-18Lines changed: 0 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,24 +16,6 @@
16
16
17
17
# Features and diagnostics
18
18
19
-
## Collect stack traces
20
-
21
-
When running a Single Program, Multiple Data (SPMD) job on accelerators, the overall process can hang if there is any error or any VM hangs/crashes for some reason. In this scenario, capturing stack traces will help to identify and troubleshoot the issues for the jobs running on TPU VMs.
22
-
23
-
The following configurations will help to debug a fault or when a program is stuck or hung somewhere by collecting stack traces. Change the parameter values accordingly in `src/maxtext/configs/base.yml`:
24
-
25
-
1. Set `collect_stack_trace: True` to enable collection of stack traces on faults or when the program is hung. This setting will periodically dump the traces for the program to help in debugging. To disable this, set `collect_stack_trace: False`.
26
-
2. Set `stack_trace_to_cloud: False` to display stack traces on console. `stack_trace_to_cloud: True` will create a temporary file in `/tmp/debugging` in the TPUs to store the stack traces. There is an agent running on TPU VMs that will periodically upload the traces from the temporary directory to cloud logging in the gcp project. You can view the traces in Logs Explorer on Cloud Logging using the following query:
3.`stack_trace_interval_seconds` signifies the duration in seconds between each stack trace collection event. Setting `stack_trace_interval_seconds: 600` will collect the stack traces every 600 seconds (10 minutes).
34
-
35
-
Here is the related PyPI package: https://pypi.org/project/cloud-tpu-diagnostics.
Copy file name to clipboardExpand all lines: docs/reference/architecture/architecture_overview.md
-1Lines changed: 0 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -179,6 +179,5 @@ The critical technology enabling this strategy is the suite of checkpoint conver
179
179
180
180
Debugging performance issues in a distributed system with thousands of accelerators is a notoriously difficult challenge. MaxText incorporates several built-in diagnostic features designed to provide visibility into the system's behavior at scale.
181
181
182
-
- Stack trace collection: To diagnose program hangs or faults, users can set `collect_stack_trace: True` in the configuration. This feature will periodically dump the Python stack traces from all worker processes. The traces can be directed to the console for immediate inspection or, more scalably, uploaded to Cloud Logging, where they can be aggregated and queried to identify misbehaving nodes.
183
182
- HLO dumping: For deep, low-level performance analysis, MaxText allows users to dump the XLA High-Level Optimizer (HLO) graph. By setting the `dump_hlo` flag, the compiled graph for a specific training step can be saved to a local directory or uploaded to Cloud Storage. This HLO representation is invaluable for compiler engineers and advanced users who need to understand exactly how XLA is interpreting and optimizing the model, making it possible to debug subtle performance regressions or compiler-related issues.
184
183
- Goodput monitoring: The framework integrates with the ml-goodput-measurement library, which provides a more holistic view of job efficiency than simple TFLOPs calculations. This allows for the tracking of metrics that capture overall "goodput," accounting for factors like data loading time, compilation overhead, and idle time, giving a truer picture of end-to-end performance.
Copy file name to clipboardExpand all lines: docs/reference/models/supported_models_and_architectures.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ MaxText is an open-source, high-performance LLM framework written in Python/JAX.
13
13
-**Supported Precisions**: FP32, BF16, INT8, and FP8.
14
14
-**Ahead-of-Time Compilation (AOT)**: For faster model development/prototyping and earlier OOM detection.
15
15
-**Quantization**: Via **Qwix** (recommended) and AQT. See the [Quantization guide](quantization-doc).
16
-
-**Diagnostics**: Structured error context via **`cloud_tpu_diagnostics`** (filters stack traces to user code), simple logging via `max_logging`, profiling in **XProf**, and visualization in **TensorBoard**.
16
+
-**Diagnostics**: Simple logging via `max_logging`, profiling in **XProf**, and visualization in **TensorBoard**.
17
17
-**Multi-Token Prediction (MTP)**: Enables token efficient training with multi-token prediction.
18
18
-**Elastic Training**: Fault-tolerant and dynamic scale-up/scale-down on Cloud TPUs with Pathways.
19
19
-**Flexible Remat Policy**: Provides fine-grained control over memory-compute trade-offs. Users can select pre-defined policies (like 'full' or 'minimal') or set the policy to **'custom'**.
@@ -78,7 +73,7 @@ Behavior when `DECOUPLE_GCLOUD=TRUE`:
78
73
79
74
## Guidelines:
80
75
81
-
- Prefer calling `jetstream()`/ `cloud_diagnostics()`once at module import and branching on `is_decoupled()` for functionality that truly requires the dependency.
76
+
- Prefer calling `jetstream()` once at module import and branching on `is_decoupled()` for functionality that truly requires the dependency.
82
77
- Use `is_decoupled()` to avoid direct `os.environ["DECOUPLE_GCLOUD"]` checking.
83
78
- Use `get_test_config_path()` instead of hard-coded `base.yml`.
84
79
- Prefer conditional local fallbacks for cloud buckets and avoid introducing direct `gs://...` paths.
-**Workload Failures**: Review the logs for specific error messages and
216
218
ensure all environment variables are properly set.
219
+
-**Parallelism ValueError (At most one can be -1)**: If you see `ValueError: At most one of rollout_tensor_parallelism, ... can be -1 (auto-derived)`, it means you have not explicitly defined the rollout parallelism parameters.
220
+
-**Solution**: Explicitly pass at least one of them in your training command (e.g., `rollout_tensor_parallelism=8` as shown in the example commands above).
217
221
-**Workload retry / resume**:
218
222
-**Retry (fresh run)**: Use a unique run name to avoid overwriting
219
223
outputs: `export RUN_NAME=${RUN_NAME?}-retry1 export MAXTEXT_CKPT_PATH=${BASE_OUTPUT_DIRECTORY?}/${RUN_NAME?}/0/items`. Then
0 commit comments