# Correct configuration to train Mask2Former on Amazon Sagemaker multi GPU ml.p4d.24xlarge instance

**URL:** <https://discuss.huggingface.co/t/correct-configuration-to-train-mask2former-on-amazon-sagemaker-multi-gpu-ml-p4d-24xlarge-instance/146327>\
**Category:** Intermediate\
**Created:** [March 18, 2025, 5:32pm UTC](https://discuss.huggingface.co/t/correct-configuration-to-train-mask2former-on-amazon-sagemaker-multi-gpu-ml-p4d-24xlarge-instance/146327 "2025-03-18T17:32:45Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Thibaut](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/thibaut/32/40904_2.png) [@Thibaut](https://discuss.huggingface.co/u/Thibaut)\
**Post date:** [March 18, 2025, 5:32pm UTC](https://discuss.huggingface.co/t/correct-configuration-to-train-mask2former-on-amazon-sagemaker-multi-gpu-ml-p4d-24xlarge-instance/146327/1 "2025-03-18T17:32:45Z")

</div>

Hi,

I use the Trainer class for my model on Sagemaker, it works well on single GPU instances. However, switching to multi GPU it encounter NCCL timeout .

Is it because of the Trainer class or because of my configuration?

```auto
transformers_version = "4.46"
pytorch_version = '2.3'
python_version = "py311"
git_transformers_version = "v4.46.0"

hyperparameters = {
    'model_name_or_path': 'facebook/mask2former-swin-base-IN21k-cityscapes-instance', 
    'output_dir':'/opt/ml/model',
    'dataset_name': 'xxx/xxx',
    'token': hf_token,
    'image_height':1080,
    'image_width':1920,
    'do_train':True,
    'fp16': True,
    'num_train_epochs': 20, 
    'learning_rate': 1e-5,
    'lr_scheduler_type': 'constant',
    'per_device_train_batch_size': 1, 
    'gradient_accumulation_steps': 4,
    'dataloader_num_workers': 8,
    'dataloader_persistent_workers': True,
    #'dataloader_prefetch_factor': 4, # Does not seems to be supported
    'do_eval': True,
    'evaluation_strategy': 'epoch',
    'logging_strategy':'epoch',
    'save_strategy':'epoch',
    'save_total_limit': 2,
    'push_to_hub': True,
    'hub_model_id': 'xxx/xxx',
    # Multi-GPU training specific parameters
    'ddp_find_unused_parameters': False,
    'ddp_bucket_cap_mb': 25,
    # Early stopping not available for our model?
    # 'early_stopping_patience': 3,
    # 'metric_for_best_model': 'eval_segm-AP',
    # 'load_best_model_at_end': True,
}

git_config = {
    'repo': 'https://github.com/huggingface/transformers.git',
    'branch': git_transformers_version,
    'username': uf_username, # Your HF username
    'password': hf_token # Your HF token here
}

huggingface_estimator = HuggingFace(
	entry_point='train_v4.46.0.py', # local copy of run_instance_segmentation.py
	source_dir='/home/sagemaker-user/code/',
	instance_type='ml.p4d.24xlarge',
	instance_count=1,
	role=role,
	git_config=git_config,
	transformers_version=transformers_version,
	pytorch_version=pytorch_version,
	py_version=python_version,
	hyperparameters = hyperparameters,
       distribution={'pytorchddp': {'enabled': True}},  
)

```

The error is :

````auto
[1,mpirank:0,algo-1]<stderr>:[rank0]:[E ProcessGroupNCCL.cpp:1316] [PG 0 Rank 0] Heartbeat monitor timed out! Process will be terminated after dumping debug info. workMetaList_.size()=17
[1,mpirank:0,algo-1]<stderr>:[rank0]:[E ProcessGroupNCCL.cpp:1153] [PG 0 Rank 0] ProcessGroupNCCL preparing to dump debug info.
[1,mpirank:0,algo-1]<stderr>:[rank0]:[F ProcessGroupNCCL.cpp:1169] [PG 0 Rank 0] [PG 0 Rank 0] ProcessGroupNCCL's watchdog got stuck for 600 seconds without making progress in monitoring enqueued collectives. This typically indicates a NCCL/CUDA API hang blocking the watchdog, and could be triggered by another thread holding the GIL inside a CUDA api, or other deadlock-prone behaviors.If you suspect the watchdog is not actually stuck and a longer timeout would help, you can either increase the timeout (TORCH_NCCL_HEARTBEAT_TIMEOUT_SEC) to a larger value or disable the heartbeat monitor (TORCH_NCCL_ENABLE_MONITORING=0).If either of aforementioned helps, feel free to file an issue to PyTorch about the short timeout or false positive abort; otherwise, please attempt to debug the hang. workMetaList_.size() = 17
[1,mpirank:4,algo-1]<stderr>:/opt/conda/bin/runwithenvvars: line 66: 101 Aborted (core dumped) $@
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.```
````

---

<div class="post-metadata">

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\
**Post date:** [March 19, 2025, 10:31am UTC](https://discuss.huggingface.co/t/correct-configuration-to-train-mask2former-on-amazon-sagemaker-multi-gpu-ml-p4d-24xlarge-instance/146327/2 "2025-03-19T10:31:02Z")

</div>

Hmmm… Difficult issue.

> <https://github.com/huggingface/open-r1/issues/389>
>
> sft with 2GPUs，get the error information as follows, how to solve it?
> 
> 
> \[rank1\]:…\[E221 17:54:38.780558231 ProcessGroupNCCL.cpp:1484\] \[PG ID 0 PG GUID 0(default\_pg) Rank 1\] ProcessGroupNCCL's watchdog got stuck for 1200 seconds without making progress in monitoring enqueued collectives. This typically indicates a NCCL/CUDA API (e.g., CudaEventDestroy) hang blocking the watchdog, and could be triggered by another thread holding the GIL inside a CUDA api (for example, CudaEventDestroy), or other deadlock-prone behaviors.If you suspect the watchdog is not actually stuck and a longer timeout would help, you can either increase the timeout (TORCH\_NCCL\_HEARTBEAT\_TIMEOUT\_SEC) to a larger value or disable the heartbeat monitor (TORCH\_NCCL\_ENABLE\_MONITORING=0).If either of aforementioned helps, feel free to file an issue to PyTorch about the short timeout or false positive abort; otherwise, please attempt to debug the hang.

> <https://github.com/huggingface/open-r1/issues/343>
>
> I tried to follow the exact README setup for SFT experiments. However, I find th…at if setting packing = false . Then the process will get stuck at the beginning of the training.
> 
> 
> \<img width="1209" alt="Image" src="https://github.com/user-attachments/assets/f1a0dd0b-0ab0-4d2f-b53b-575d9a1615d2" /\>
> 
> This is ok in a single GPU setting. SO I assume it must be correlated with NCCL communication
> 
> Any ideas why this happens?

> <https://github.com/vllm-project/vllm/issues/5484>
>
> \### Your current environment
> 
> \`\`\`text
> Collecting environment information...
> …PyTorch version: 2.3.0+cu121
> Is debug build: False
> CUDA used to build PyTorch: 12.1
> ROCM used to build PyTorch: N/A
> 
> OS: Ubuntu 22.04.3 LTS (x86\_64)
> GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
> Clang version: 14.0.0-1ubuntu1.1
> CMake version: version 3.24.4
> Libc version: glibc-2.35
> 
> Python version: 3.10.12 (main, Nov 20 2023, 15:14:05) \[GCC 11.4.0\] (64-bit runtime)
> Python platform: Linux-5.10.112-005.ali5000.alios7.x86\_64-x86\_64-with-glibc2.35
> Is CUDA available: True
> CUDA runtime version: 12.3.107
> CUDA\_MODULE\_LOADING set to: LAZY
> GPU models and configuration:
> GPU 0: NVIDIA A100-SXM4-80GB
> GPU 1: NVIDIA A100-SXM4-80GB
> GPU 2: NVIDIA A100-SXM4-80GB
> GPU 3: NVIDIA A100-SXM4-80GB
> GPU 4: NVIDIA A100-SXM4-80GB
> GPU 5: NVIDIA A100-SXM4-80GB
> GPU 6: NVIDIA A100-SXM4-80GB
> GPU 7: NVIDIA A100-SXM4-80GB
> 
> Nvidia driver version: 515.105.01
> cuDNN version: Probably one of the following:
> /usr/lib/x86\_64-linux-gnu/libcudnn.so.8.9.4
> /usr/lib/x86\_64-linux-gnu/libcudnn\_adv\_infer.so.8.9.4
> /usr/lib/x86\_64-linux-gnu/libcudnn\_adv\_train.so.8.9.4
> /usr/lib/x86\_64-linux-gnu/libcudnn\_cnn\_infer.so.8.9.4
> /usr/lib/x86\_64-linux-gnu/libcudnn\_cnn\_train.so.8.9.4
> /usr/lib/x86\_64-linux-gnu/libcudnn\_ops\_infer.so.8.9.4
> /usr/lib/x86\_64-linux-gnu/libcudnn\_ops\_train.so.8.9.4
> HIP runtime version: N/A
> MIOpen runtime version: N/A
> Is XNNPACK available: True
> 
> CPU:
> Architecture: x86\_64
> CPU op-mode(s): 32-bit, 64-bit
> Address sizes: 46 bits physical, 57 bits virtual
> Byte Order: Little Endian
> CPU(s): 128
> On-line CPU(s) list: 0-127
> Vendor ID: GenuineIntel
> BIOS Vendor ID: Intel(R) Corporation
> Model name: Intel(R) Xeon(R) Platinum 8369B CPU @ 2.90GHz
> BIOS Model name: Intel(R) Xeon(R) Platinum 8369B CPU @ 2.90GHz
> CPU family: 6
> Model: 106
> Thread(s) per core: 2
> Core(s) per socket: 32
> Socket(s): 2
> Stepping: 6
> CPU max MHz: 3500.0000
> CPU min MHz: 800.0000
> BogoMIPS: 5800.00
> Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant\_tsc art arch\_perfmon pebs bts rep\_good nopl xtopology nonstop\_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds\_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4\_1 sse4\_2 x2apic movbe popcnt tsc\_deadline\_timer aes xsave avx f16c rdrand lahf\_lm abm 3dnowprefetch cpuid\_fault epb cat\_l3 invpcid\_single intel\_ppin ssbd mba ibrs ibpb stibp ibrs\_enhanced tpr\_shadow vnmi flexpriority ept vpid ept\_ad fsgsbase tsc\_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdt\_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel\_pt avx512cd sha\_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm\_llc cqm\_occup\_llc cqm\_mbm\_total cqm\_mbm\_local split\_lock\_detect wbnoinvd dtherm ida arat pln pts hwp hwp\_act\_window hwp\_epp hwp\_pkg\_req avx512vbmi umip pku ospke avx512\_vbmi2 gfni vaes vpclmulqdq avx512\_vnni avx512\_bitalg tme avx512\_vpopcntdq rdpid fsrm md\_clear pconfig flush\_l1d arch\_capabilities
> Virtualization: VT-x
> L1d cache: 3 MiB (64 instances)
> L1i cache: 2 MiB (64 instances)
> L2 cache: 80 MiB (64 instances)
> L3 cache: 96 MiB (2 instances)
> NUMA node(s): 1
> NUMA node0 CPU(s): 0-127
> Vulnerability Itlb multihit: Not affected
> Vulnerability L1tf: Not affected
> Vulnerability Mds: Not affected
> Vulnerability Meltdown: Not affected
> Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
> Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and \_\_user pointer sanitization
> Vulnerability Spectre v2: Vulnerable: eIBRS with unprivileged eBPF
> Vulnerability Srbds: Not affected
> Vulnerability Tsx async abort: Not affected
> 
> Versions of relevant libraries:
> \[pip3\] mypy==1.9.0
> \[pip3\] mypy-extensions==1.0.0
> \[pip3\] numpy==1.26.2
> \[pip3\] nvidia-nccl-cu12==2.20.5
> \[pip3\] onnx==1.16.0
> \[pip3\] onnx-graphsurgeon==0.3.27
> \[pip3\] onnxruntime==1.16.3
> \[pip3\] torch==2.3.0
> \[pip3\] triton==2.3.0
> \[pip3\] tritonclient==2.44.0
> \[conda\] Could not collectROCM Version: Could not collect
> Neuron SDK Version: N/A
> vLLM Version: 0.4.2
> vLLM Build Flags:
> CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
> GPU Topology:
> GPU0	GPU1	GPU2	GPU3	GPU4	GPU5	GPU6	GPU7	NIC0	NIC1	NIC2	NIC3	CPU Affinity	NUMA Affinity
> GPU0 X NV12	NV12	NV12	NV12	NV12	NV12	NV12	PXB	SYS	SYS	SYS	0-127 N/A
> GPU1	NV12 X NV12	NV12	NV12	NV12	NV12	NV12	PXB	SYS	SYS	SYS	0-127 N/A
> GPU2	NV12	NV12 X NV12	NV12	NV12	NV12	NV12	SYS	PXB	SYS	SYS	0-127 N/A
> GPU3	NV12	NV12	NV12 X NV12	NV12	NV12	NV12	SYS	PXB	SYS	SYS	0-127 N/A
> GPU4	NV12	NV12	NV12	NV12 X NV12	NV12	NV12	SYS	SYS	PXB	SYS	0-127 N/A
> GPU5	NV12	NV12	NV12	NV12	NV12 X NV12	NV12	SYS	SYS	PXB	SYS	0-127 N/A
> GPU6	NV12	NV12	NV12	NV12	NV12	NV12 X NV12	SYS	SYS	SYS	PXB	0-127 N/A
> GPU7	NV12	NV12	NV12	NV12	NV12	NV12	NV12 X SYS	SYS	SYS	PXB	0-127 N/A
> NIC0	PXB	PXB	SYS	SYS	SYS	SYS	SYS	SYS X SYS	SYS	SYS
> NIC1	SYS	SYS	PXB	PXB	SYS	SYS	SYS	SYS	SYS X SYS	SYS
> NIC2	SYS	SYS	SYS	SYS	PXB	PXB	SYS	SYS	SYS	SYS X SYS
> NIC3	SYS	SYS	SYS	SYS	SYS	SYS	PXB	PXB	SYS	SYS	SYS X
> 
> Legend:
> 
> X = Self
> SYS = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
> NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
> PHB = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
> PXB = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
> PIX = Connection traversing at most a single PCIe bridge
> NV# = Connection traversing a bonded set of # NVLinks
> 
> NIC Legend:
> 
> NIC0: mlx5\_bond\_0
> NIC1: mlx5\_bond\_1
> NIC2: mlx5\_bond\_2
> NIC3: mlx5\_bond\_3
> \`\`\`
> 
> 
> \### 🐛 Describe the bug
> 
> \`\`\`python
> from vllm import LLM
> import psutil
> import random
> 
> llm = LLM($MODEL\_PATH, trust\_remote\_code=True, tensor\_parallel\_size=4)
> 
> prompt\_token\_ids\_list = \[\[random.randint(1, 40000) for \_ in range(random.randint(1, 1000))\] for \_ in range(1000)\]
> 
> for i in range(0, 10000):
> batch\_size = random.randint(1, 64)
> print(f"\>\>\> Iteration: {i}, Batch Size: {batch\_size}")
> output = llm.generate(prompt\_token\_ids=prompt\_token\_ids\_list\[:batch\_size\], use\_tqdm=False)
> if i % 1000 == 0:
> cpu\_percent = psutil.cpu\_percent()
> memory\_percent = psutil.virtual\_memory().percent
> print(f"CPU utilization: {cpu\_percent}%")
> print(f"Memory utilization: {memory\_percent}%")
> print("=========================================")
> 
> print("Done!")
> \`\`\`
> 
> This is an occasional BUG, ​​which will cause the nccl timeout problem shown below
> !\[image\](https://github.com/vllm-project/vllm/assets/19977378/3c7fb932-37b3-45ae-8d38-2ffab2338f57)
> 
> cudagraph and custom all recude are enabled
> 
> related issue：https://github.com/vllm-project/vllm/issues/1726 https://github.com/vllm-project/vllm/issues/5360 https://github.com/vllm-project/vllm/issues/4653 https://github.com/vllm-project/vllm/issues/4430

> <https://github.com/pytorch/pytorch/issues/137268>
>
> \### 🐛 Describe the bug
> 
> The process is working correctly with DDP world size 1 b…ut then with world size \> 1 is going to hang with GPU 0 at 0% and GPU 1 fixed to max occupancy. I've replicated this both with A100 and H100, with and without torch.compile.
> 
> I got this message on nightly:
> \`\`\`python
> PG ID 0 PG GUID 0(default\_pg) Rank 1\] ProcessGroupNCCL's watchdog got stuck for 480 seconds without making progress in monitoring enqueued collectives. This typically indicates a NCCL/CUDA API (e.g., CudaEventDestroy) hang blocking the watchdog, and could be triggered by another thread holding the GIL inside a CUDA api (for example, CudaEventDestroy), or other deadlock-prone behaviors.If you suspect the watchdog is not actually stuck and a longer timeout would help, you can either increase the timeout (TORCH\_NCCL\_HEARTBEAT\_TIMEOUT\_SEC) to a larger value or disable the heartbeat monitor (TORCH\_NCCL\_ENABLE\_MONITORING=0).If either of aforementioned helps, feel free to file an issue to PyTorch about the short timeout or false positive abort; otherwise, please attempt to debug the hang.
> \`\`\`
> 
> \### Versions
> 
> PyTorch version: 2.6.0.dev20241001+cu124
> Is debug build: False
> CUDA used to build PyTorch: 12.4
> ROCM used to build PyTorch: N/A
> 
> OS: Ubuntu 22.04.5 LTS (x86\_64)
> GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
> Clang version: Could not collect
> CMake version: version 3.30.4
> Libc version: glibc-2.35
> 
> Python version: 3.11.10 | packaged by conda-forge | (main, Sep 30 2024, 18:08:57) \[GCC 13.3.0\] (64-bit runtime)
> Python platform: Linux-6.1.100+-x86\_64-with-glibc2.35
> Is CUDA available: True
> CUDA runtime version: Could not collect
> CUDA\_MODULE\_LOADING set to: LAZY
> GPU models and configuration: GPU 0: NVIDIA A100-SXM4-40GB
> Nvidia driver version: 550.90.07
> cuDNN version: Could not collect
> HIP runtime version: N/A
> MIOpen runtime version: N/A
> Is XNNPACK available: True
> 
> CPU:
> Architecture: x86\_64
> CPU op-mode(s): 32-bit, 64-bit
> Address sizes: 46 bits physical, 48 bits virtual
> Byte Order: Little Endian
> CPU(s): 12
> On-line CPU(s) list: 0-11
> Vendor ID: GenuineIntel
> Model name: Intel(R) Xeon(R) CPU @ 2.20GHz
> CPU family: 6
> Model: 85
> Thread(s) per core: 2
> Core(s) per socket: 6
> Socket(s): 1
> Stepping: 7
> BogoMIPS: 4400.41
> Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant\_tsc rep\_good nopl xtopology nonstop\_tsc cpuid tsc\_known\_freq pni pclmulqdq ssse3 fma cx16 pcid sse4\_1 sse4\_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf\_lm abm 3dnowprefetch invpcid\_single ssbd ibrs ibpb stibp ibrs\_enhanced fsgsbase tsc\_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat avx512\_vnni md\_clear arch\_capabilities
> Hypervisor vendor: KVM
> Virtualization type: full
> L1d cache: 192 KiB (6 instances)
> L1i cache: 192 KiB (6 instances)
> L2 cache: 6 MiB (6 instances)
> L3 cache: 38.5 MiB (1 instance)
> NUMA node(s): 1
> NUMA node0 CPU(s): 0-11
> Vulnerability Gather data sampling: Not affected
> Vulnerability Itlb multihit: Not affected
> Vulnerability L1tf: Not affected
> Vulnerability Mds: Not affected
> Vulnerability Meltdown: Not affected
> Vulnerability Mmio stale data: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
> Vulnerability Reg file data sampling: Not affected
> Vulnerability Retbleed: Mitigation; Enhanced IBRS
> Vulnerability Spec rstack overflow: Not affected
> Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
> Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and \_\_user pointer sanitization
> Vulnerability Spectre v2: Mitigation; Enhanced / Automatic IBRS; IBPB conditional; RSB filling; PBRSB-eIBRS SW sequence; BHI SW loop, KVM SW loop
> Vulnerability Srbds: Not affected
> Vulnerability Tsx async abort: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
> 
> Versions of relevant libraries:
> \[pip3\] mypy-extensions==1.0.0
> \[pip3\] numpy==1.26.4
> \[pip3\] optree==0.12.1
> \[pip3\] pytorch-triton==3.1.0+cf34004b8a
> \[pip3\] torch==2.6.0.dev20241001+cu124
> \[pip3\] torchaudio==2.5.0.dev20241001+cu124
> \[pip3\] torchelastic==0.2.2
> \[pip3\] torchvision==0.20.0.dev20241001+cu124
> \[conda\] numpy 1.26.4 pypi\_0 pypi
> \[conda\] optree 0.12.1 pypi\_0 pypi
> \[conda\] pytorch-triton 3.1.0+cf34004b8a pypi\_0 pypi
> \[conda\] torch 2.6.0.dev20241001+cu124 pypi\_0 pypi
> \[conda\] torchaudio 2.5.0.dev20241001+cu124 pypi\_0 pypi
> \[conda\] torchelastic 0.2.2 pypi\_0 pypi
> \[conda\] torchvision 0.20.0.dev20241001+cu124 pypi\_0 pypi
> 
> cc @XilunWu @H-Huang @awgu @kwen2501 @wanchaol @fegin @fduwjj @wz337 @wconstab @d4l3k @c-p-i-o

---

<div class="post-metadata">

**Author:** ![Thibaut](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/thibaut/32/40904_2.png) [@Thibaut](https://discuss.huggingface.co/u/Thibaut)\
**Post date:** [March 24, 2025, 8:58am UTC](https://discuss.huggingface.co/t/correct-configuration-to-train-mask2former-on-amazon-sagemaker-multi-gpu-ml-p4d-24xlarge-instance/146327/3 "2025-03-24T08:58:24Z")

</div>

Thanks, the 10mn timeout may just be too short. Anyway, I decided to stay on Mono GPU training for the time being. I tried multi-GPU with Accelerate. It works well, but the resulting model cannot be integrated into CVAT as a pre-annotation model with the standard CVAT’s Hugging Face integration.
