Validate paired LightX2V H3 renders on Windows/NVIDIA CUDA
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript
- Domain
- ai, machine-learning, testing
Research direction
Read docs/MINIMAX_H3_LIGHTX2V.md and inspect scripts/generate_minimax_h3_cuda.py plus the existing CUDA selector/history integration. This work is blocked until a suitable Windows/NVIDIA CUDA host, accepted model terms, and pinned weights are available. Run the protocol’s same-machine stock/profile pairs for text and image requests, record the specified runtime and resource evidence, and inspect output quality; close after the paired results are documented.
Written by the indexing model from the issue text.
Description
Split from #13637 at the user's request; original CUDA-first implementation and provenance are in #13612, and the protocol is docs/MINIMAX_H3_LIGHTX2V.md. This successor owns only paired full-model evidence for the shipped Windows/NVIDIA CUDA contract. MLX integration is a separate successor and not a prerequisite.
Current evidence: the Windows/CUDA-first implementation provides the original LightX2V v1.3 split adapter, pinned four-update schedule and dual shifts, explicit terms-gated download, cache/digest admission, quantization-preserving residual applicator and selector/history integration. No full-model timing or quality comparison was performed because the available environment cannot load the full H3 checkpoint.
Chosen next step: an operator with Windows/NVIDIA CUDA, 96 GB host RAM and a supported H3 NVIDIA offload profile runs the existing protocol with already accepted terms and explicitly provisioned pinned weights. Do not download weights or spend money unattended. Do not extrapolate an MLX result or upstream measurement.
Affected areas: docs/MINIMAX_H3_LIGHTX2V.md, scripts/generate_minimax_h3_cuda.py, server/lib/minimaxH3Lightx2v.json and existing CUDA selector/history integration, only if a reproduced defect requires repair. Do not mutate the shipped v1.3 contract to implement MLX.
Acceptance criteria:
- Run same-machine stock/profile pairs for text and image requests, holding full prompt, seed, canvas, frame count and user LoRAs identical.
- Record exact PortOS revision, runtime fingerprint, cold load, inference timing, peak memory and actual outputs; genuinely inspect motion/detail, prompt adherence, soundtrack and character/style fidelity.
- Keep outputs private and record redacted reproducible parameters/evidence, without private paths, credentials or personal assets.
- Keep performance claims absent until supported by measured PortOS results. Fix or file reproduced failures without weakening admission, cache, adapter or terms gates.
Hardware blocker / help wanted: an operator must supply a suitable Windows/NVIDIA CUDA H3 host, model-term acceptance and existing pinned weights. Keep blocked until these prerequisites exist. Close only after the paired evidence is inspected and documented.
Dispatch rationale: model:medium for running a specified existing protocol and documenting evidence; effort:high for controlled timing/memory and visual/audio fidelity inspection.
- Dominant language
- JavaScript
- Stars
- 38
- Forks
- 32
- Avg merge
- 44m
- Merged PRs (30d)
- 990
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from atomantic/PortOS
-
apple-silicon area:media blocked effort:high enhancement help wanted macos model:heavy plan
Difficulty 5/5 Over a week Newbie friendliness 20/100
atomantic/PortOS#13682 · 1 comment ·
Maintainers usually reply within 1 day
-
area:media blocked cuda effort:medium help wanted model:medium plan windows
Difficulty 3/5 1-2 days Newbie friendliness 35/100
atomantic/PortOS#13681 · 1 comment ·
Maintainers usually reply within 1 day
-
apple-silicon area:media blocked effort:medium help wanted macos model:medium plan
Difficulty 4/5 3-5 days Newbie friendliness 28/100
atomantic/PortOS#13680 · 1 comment ·
Maintainers usually reply within 1 day
-
area:media blocked effort:high model:medium plan planner:gpt-6-1-sol
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
area:media blocked effort:xhigh model:heavy plan planner:gpt-6-1-sol
Difficulty 5/5 Over a week Newbie friendliness 25/100
Maintainers usually reply within 1 day
All issues in atomantic/PortOS
Similar issues
-
area: apple-music area: build-release bug effort: small priority: high
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
ChristianTabor/Argon#32 ·
Maintainers usually reply within 1 day
-
0️⃣ phase/new
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Link Checker ReportOpenautomated issue report
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
good first issue tests
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day