oracle vllm: gateable = yes sits on pin a7c23ac96d, which no build-and-run has ever measured
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 55/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- cpp
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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_scheduler48/48- the
vllmlibrary 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.
- 主要语言
- C++
- 星标
- 440
- 派生
- 55
- 平均合并
- 1 天 4 小时
- 30 天内合并 PR
- 366
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
mudler/vllm.cpp 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 88/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 75/100
mpfaffenberger/privateer_reimagined#658 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 85/100
microsoft/onnxruntime#33018 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
AXERA-TECH/ax-llm#81 ·
-
enhancement
难度 2/5 半天 新手友好度 78/100
ros-industrial/ros2_canopen#448 ·
-
难度 1/5 1 小时以内 新手友好度 78/100
维护者通常 1 天内回复