Repository navigation
os: the onebit manifest reads the keyed catalogue, so it lists the entries - #586
Conversation
…tries
The manifest producer matched nothing and wrote `mode=live` with zero entries, which made the models row
PASS VACUOUSLY ("0 onebit HRX entries and 0 NPU entries listed") - worse than a failure, because it hides
a real gap. Candidate 6's build log said it plainly: "onebit-models: 0 hrx + 0 npu", and candidate 7's
gate R then showed the row skipping on "0 HRX + 0 NPU entries are registered".
Cause: the vendored server_models.json is a dict KEYED BY MODEL ID
({"Qwen2.5-0.5B-Instruct-CPU": {...}, ...}), not a list of dicts carrying an "id" field. The walk only
looked for an "id" field, found none at the top level, and descended into the values without ever
associating a record with its key.
Now: a dict value that looks like a record ("recipe" or "onebit_backend" present) is taken with its KEY
as the id when it has none; lists and nested dicts are still walked. Verified against the real catalogue
on the candidate 6/7 build:
before: 0 hrx + 0 npu
after : 26 hrx + 0 npu (GLM-4.7-Flash-1bit, LFM2-1.2B-1bit, MiniCPM-V-4.6-1bit, MiniCPM5-1B-1bit,
Qwen2.5-Coder-1.5B-Instruct-1bit, ...)
The npu count stays 0 because the four "onebit_backend" hits in this catalogue are not "npu" - that is
the catalogue's content, not a parsing gap.
bash -n clean.
PR Reviewer Guide 🔍(Review updated until commit 7ba6204)Here are some key observations to aid the review process:
|
… labelled hrx Follow-up to the walk fix on this branch: onebit_backend does exist in the vendored catalogue, but it is nested inside each record's recipe_options, not at the record's top level: /Qwen3-0.6B-NPU-1bit/recipe_options -> "npu" /Qwen3-1.7B-NPU-1bit/recipe_options -> "npu" /Qwen3-4B-NPU-1bit/recipe_options -> "npu" /Qwen3.6-35B-A3B-NPU-1bit/recipe_options -> "npu" Reading it from the top level alone classified all four NPU models as "hrx", which would have made the models row expect them in Lemonade's HRX list and fail there for the wrong reason. Both places are now consulted, so either shape works. Verified against the real catalogue (candidate 6/7 build tree, 286 entries): before both fixes: 0 hrx + 0 npu (vacuous pass) walk fix only : 26 hrx + 0 npu (NPU entries mislabelled) now : 22 hrx + 4 npu = 26, matching the catalogue's 26 recipe==onebit entries exactly npu Qwen3-0.6B-NPU-1bit, Qwen3-1.7B-NPU-1bit, Qwen3-4B-NPU-1bit, Qwen3.6-35B-A3B-NPU-1bit. bash -n clean.
|
Persistent review updated to latest commit 9e97a69 |
|
Persistent review updated to latest commit 7ba6204 |
Follow-up to #579, which added the manifest producer. It matched nothing and wrote
mode=livewith zero entries, so themodelsrow would have passed vacuously — "0 onebit HRX entries and 0 NPU entries listed". A vacuous pass is worse than a failure: it hides the gap.The evidence was in plain sight and I read past it twice:
onebit-models: 0 hrx + 0 npuSKIP models : … (0 HRX + 0 NPU entries are registered …)Cause. The vendored
server_models.jsonis a dict keyed by model id:My walk looked for an
"id"field, found none at the top level, and descended into the values without ever associating a record with its key. So every onebit record was invisible.Fix. A dict value that looks like a record (
recipeoronebit_backendpresent) is taken with its key as the id when it has none. Lists and nested dicts are still walked, so the list-of-dicts shape keeps working.Verified against the real catalogue on the candidate 6/7 build tree:
e.g.
GLM-4.7-Flash-1bit,LFM2-1.2B-1bit,MiniCPM-V-4.6-1bit,MiniCPM5-1B-1bit,Qwen2.5-Coder-1.5B-Instruct-1bit.npustays 0 because the fouronebit_backendhits in this catalogue are not"npu"— that is the catalogue's content, not a parsing gap.bash -nclean.Worth pairing with #585 in the next candidate: with this fix the
modelsrow becomes a real check on hardware (26 entries expected, each looked up in Lemonade's list), and with #585 thehrx-devicerow stops failing in the GPU-less VM. Together they turn two vacuous/false rows into the two that would actually have caught c5.