Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Dedicated LocalBackend vLLM server can become unreachable during LoRA adapter reload

Đang mở
  • Có gì không ổn?
#678 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 3 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
50/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
python
Lĩnh vực
ai, backend, infrastructure

Hướng nghiên cứu

Bắt đầu trong art/unsloth/service.py tại _reload_adapter(...) và theo dõi lời gọi của nó từ _train_dedicated; kiểm tra vòng đời của dedicated server và đường dẫn _training_stage trong art/pipeline_trainer/trainer.py. Tái hiện lỗi reload adapter với thiết lập LocalBackend và PipelineTrainer được liệt kê, sau đó xác minh rằng vLLM server tạm thời không khả dụng sẽ khôi phục hoặc tạo ra chẩn đoán chứa trạng thái health và các log gần đây của nó.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

In LocalBackend dedicated mode with PipelineTrainer, some runs fail or become unhealthy immediately after an early training step when ART tries to reload the newly saved LoRA adapter into the dedicated vLLM server.

The observed failure is an httpx.ConnectError: All connection attempts failed from UnslothService._reload_adapter(...). After this starts happening, rollout workers also repeatedly fail with generic Connection error while calling /chat/completions.

This was seen after upgrading ART to main commit 48b2e5f6c384a62b44f34e1472e5fb1eeaa3474a.

Setup

  • ART commit: 48b2e5f6c384a62b44f34e1472e5fb1eeaa3474a
  • Backend: LocalBackend
  • Trainer: PipelineTrainer
  • Mode: dedicated trainer/inference GPUs
  • Hardware: 1 node, 2x H200; one GPU for trainer and one GPU for inference
  • Base model class: Llama 3.1 8B Instruct
  • Training: GRPO/CISPO via Unsloth
  • vLLM from the ART lock at this commit (vllm 0.17.0+art1 in the generated lock)
  • Checkpoint saving enabled
  • eval_at_start enabled

No private data is needed to reproduce the failure mode; this appears to be an infrastructure / adapter reload stability issue.

Symptoms

One run failed after the first training step with this stack:

Pipeline stage failed: All connection attempts failed
ExceptionGroup: unhandled errors in a TaskGroup
  File ".../art/pipeline_trainer/trainer.py", line 467, in _training_stage
    result = await self.backend.train(...)
  File ".../art/unsloth/service.py", line 628, in _train_dedicated
    await self._reload_adapter(checkpoint_dir, new_step)
  File ".../art/unsloth/service.py", line 455, in _reload_adapter
    response = await client.post(...)
  File ".../httpx/_client.py", line 1859, in post
    return await self.request(...)
httpx.ConnectError: All connection attempts failed

Other concurrent runs on the same setup remained marked as running, but stopped making useful training progress and emitted repeated rollout failures like:

Worker N: rollout failed: Connection error.
Retrying request to /chat/completions ...

Expected behavior

If the dedicated vLLM server is temporarily unavailable during adapter reload, ART should either:

  1. Wait for the server to become healthy again before resuming rollouts/training, or
  2. Restart/recover the dedicated inference server, or
  3. Fail with a clearer diagnostic that includes vLLM process health and recent server logs.

A transient adapter reload/server restart should not leave the pipeline in a state where rollout workers keep generating connection errors indefinitely.

Actual behavior

At least one run hard-failed during _reload_adapter(...) after saving a checkpoint. Other runs kept running at the Sky/job level but repeatedly failed rollout calls to the local vLLM endpoint and did not advance training meaningfully.

Possibly related

This was found while investigating forked LocalBackend/PipelineTrainer runs. There is already an open fork-specific issue here:

  • #651

The adapter reload/connectivity failure described in this issue is separate from whether the run started from the intended fork checkpoint. Even after ignoring the fork correctness problem, the dedicated vLLM server becoming unreachable during or after adapter reload appears to be a separate stability issue.

Suggested debugging additions

It would help if _reload_adapter(...) logged or surfaced:

  • Target URL/endpoint being called
  • Whether the vLLM subprocess is still alive
  • Last lines of the dedicated vLLM log file
  • Health check result before and after adapter reload
  • The checkpoint path and step being reloaded
Ngôn ngữ chính
Python
Star
10.8k
Fork
989
Merge trung bình
11 giờ 38 phút
Pull request đã merge (30 ngày)
104

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của OpenPipe/ART

Tất cả issue của OpenPipe/ART

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.