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

oracle vllm: gateable = yes sits on pin a7c23ac96d, which no build-and-run has ever measured

Đang mở
  • Có gì không ổn?
#3,346 0 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 1 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
55/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
cpp
Lĩnh vực
build-system, testing-qa

Hướng nghiên cứu

Start with AGENTS.md §"Pin vLLM", then inspect .agents/oracles/vllm.md and the 2026-09-22 sync report. Build the pinned vLLM commit a7c23ac96d and run a model through it, using scripts/check-oracle-pins.py to verify the record. Done means the oracle's gateable value and evidence reflect a build-and-run at that pin, while prior-pin measurements remain historical.

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

Mô tả

gateable = yes in .agents/oracles/vllm.md currently sits on a pin it was never measured at.

The pin. a7c23ac96d7806e7c7e7d862eadbce5a33529b94, 0.3.0.dev267, pinned_on = 2026-09-22. It replaced e126687a9a (0.28.1rc1.dev132, pinned 2026-09-03). 1187 commits separate the two, 232 of them touching ported subtrees.

Why the record is wrong. AGENTS.md §"Pin vLLM" is explicit: "An oracle is only gateable once it demonstrably builds and runs the model. Constructing a config proves nothing." The gateable = yes was earned at e126687a9a, where the oracle was built and run on two boards. The pin then moved, and the structured field did not.

What the September 22 sync report actually records. .agents/sync/2026-09-22-a7c23ac96d.md records two gates, and both are this project's own C++:

  • test_scheduler 48/48
  • the vllm library build

Neither is the oracle. The one PORT-NOW commit in the range (c64b15cde5, the scheduler) was ported from source reading, not from a capture. The advance was made to unblock MODEL-JEV, which needs the DiffusionGemma architecture from vllm-project/vllm#57250.

The checker does not catch this, and that is worth stating. scripts/check-oracle-pins.py:314-327 accepts gateable = yes when the evidence path exists in the tree. It checks that a document is present, not that the document records a build-and-run of the oracle. So for as long as evidence pointed at a sync report, the gate read yes on an unmeasured pin. Every other oracle in .agents/oracles/ that is not demonstrably run is already gateable = no and names its owing issue; vllm is the one that drifted.

What this issue owes. Build the pinned vLLM at a7c23ac96d and run a model through it, then set gateable back to yes with evidence that says so. The prior pin's measurements stay as historical evidence in the prose sections of the oracle file; they are measurements of e126687a9a and are labelled as such.

Related, and still owed separately. #2818 is the standing post-hoc issue for the previous pin advance, e126687a9a. This is the same class of debt for the advance that superseded it, so #2818's scope does not cover it.

Until this is discharged, gateable = no is the truthful disposition.

Ngôn ngữ chính
C++
Star
423
Fork
53
Merge trung bình
1 ngày 4 giờ
Pull request đã merge (30 ngày)
366

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 mudler/vllm.cpp

Tất cả issue của mudler/vllm.cpp

Issue tương tự

Thêm issue về C++

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.