| # Contributing to UMoX |
|
|
| Thank you for considering this early research project. UMoX will improve fastest |
| if contributors are welcoming to people and demanding of measurements. |
|
|
| Useful contributions include: |
|
|
| - reproducing the utility-concurrency result on another device; |
| - proposing a safer or more accurate routing rule; |
| - adding paired capability evaluations; |
| - improving queueing, cache, or speculative-decoding experiments; |
| - adding power and thermal telemetry; |
| - testing another GPU/NPU model pair; |
| - documenting a failed approach clearly enough that others need not repeat it. |
|
|
| ## Evidence expectations |
|
|
| Before running an experiment, record: |
|
|
| 1. hypothesis and expected mechanism; |
| 2. exact hardware, power state, runtime, model, quantization, context, and |
| sampling identities; |
| 3. matched control; |
| 4. quality and safety gates; |
| 5. promotion and stop thresholds. |
|
|
| Report every measured pair, errors, warm-up behavior, and negative result. Do |
| not mix kernel ceilings with end-to-end throughput or inherit an upstream model |
| score as a UMoX score. |
|
|
| Please start a Hugging Face Discussion before a large change. For the current |
| performance roadmap, review the questions at the end of |
| [PERFORMANCE_PLAN.md](PERFORMANCE_PLAN.md). |
|
|
| ## Community tone |
|
|
| UMoX is a prototype, and polishing is still needed. Questions, replications, |
| corrections, and alternative designs are welcome. Assume good faith, explain |
| tradeoffs, and help new contributors reproduce the setup. Challenge claims with |
| evidence, not people. |
|
|
|
|
