Downloads · 30 days
305
54% of all-time downloads
snapdragon-test-npu
gat45/snapdragon-test-npu
snapdragon-test-npu is a machine learning model from gat45. Use it for the machine learning task on the model card, and read the license before you ship it in a product.
Ce dossier = le runtime gelé qui a produit toutes les campagnes du 02/09, les commandes exactes, les résultats bruts et les modèles — pour reproduction autonome et contrôle par un tiers.
All-time downloads
561
Public
Repo size
6.7 GB
Likes
0
Public
Repo makeup
Click a slice to open those files.
.gguf6.7 GB · 100%
At a glance
- Access
- Public
- Created
- Sep 2, 2026
- Updated
- Oct 5, 2026
- SHA
- 9b06e54f
Model card
From the Hugging Face model README
Archive RUNTIME HTP GELÉ — OnePlus 15 / SM8850 / HTP v81 (2026-09-02)
Ce dossier = le runtime gelé qui a produit toutes les campagnes du 02/09, les commandes exactes, les résultats bruts et les modèles — pour reproduction autonome et contrôle par un tiers.
| Device | OnePlus 15 · Snapdragon 8 Elite Gen 5 (SM8850) · Android 16 · Magisk 30.7 |
| Accélérateurs | Hexagon HTP v81 (cDSP) · Adreno GPU (OpenCL) · CPU |
| Runtime | fork JZ exp-pr28202-0983d01 · HEAD 9ef4543d · ggml-hexagon 0.99.7.7 |
| Skel critique | htp/libggml-htp-v81.so = 734 920 o (rebuilt — le seul qui ouvre HTP0 en user shell) |
| Modèles archivés | Qwen3.5-9B-D2-A-MTP-attnQ4 (5,08 GiB, config « 16 t/s ») · Marco-Nano-Instruct Q4_0 (4,26 GiB, contrôle MoE) |
| Statut | VALIDÉ : config dense reproduite et dépassée (100/300 tokens) + contrôle MoE indépendant (2e architecture) |
1. Pourquoi cette archive existe
L'investigation « 16 t/s » a commencé sur un chiffre historique non reproductible. La campagne du 02/09 a établi — avec un protocole gardé (kill-all → port libre → PID → health → meta → clean) — ce qui est réellement mesurable sur ce SoC, sur deux architectures de modèle, et ce qui doit rester dans les « artefacts de formule ». Tout le monde peut re-mesurer les mêmes chiffres avec ce dossier ; rien n'est reconstruit de mémoire.
2. Résultats consolidés (les faits, pas les réclames)
2.1 Qwen dense (config « 16 t/s » : attnQ4 + MTP n_max=1 + HTP0 + --fit off)
| Mesure | Valeur | Condition |
|---|---|---|
| wall 16 tokens (ref) | 10,32 t/s · accept 0,75 · mean_len 1,75 | froid, propre |
| wall 3×300 tokens | 11,01 ± 0,16 t/s · accept 0,87-0,90 | consolidé (régime tenu) |
| wall 100 tokens | 11,26-11,31 t/s | propre |
| « 16,6 / 16,4-18,9 effectifs » | = wall × mean_len | ⚠ ARTEFACT DE FORMULE — ne jamais publier comme débit |
| Placement | HTP0 pur 11,26 > HTP→GPU 8,35 > GPU→HTP 4,2-6,1 > GPU seul 4,9 | HTP0 imbattable sur dense |
| MTP vs non-MTP | +72 % (5,78 → 9,4-10,4) | MTP = SEUL levier spéculatif valable sur HTP |
| ngram (mod, propre) | 2,55-3,36 t/s | ❌ réfuté (le « 10,27 » historique = contaminé) |
| RAM MTP | RSS ≈ 0 Δ vs non-MTP (+1,4 Go VA réservée seulement) | pas de doublement réel |
| Q8→Q4 attention | MUL_MAT −17 % · DSP −14 % · wall ≈ inchangé | Q4 = condition de SÛRETÉ (5,08 Go < swap), pas levier de vitesse |
2.2 Contrôle Marco-Nano MoE (même runtime, 2e architecture : 17,3B / 0,6B actifs, 256 experts top-8)
| Mesure | Valeur |
|---|---|
| HTP0 pur | 26,7 → 30,6 t/s (screening 30,64 · A/B 29,93) |
| GPU→HTP 80/20 | 39,1 → 42,1 t/s (+40 % vs HTP pur, A/B/A/B confirmé) |
| HTP→GPU (ordre inversé) | 22,5 t/s — pire que HTP pur |
| ARGSORT → CPU (A/B/A/B, n=200) | 28,75 → 33,35 t/s (+16 %) |
| ARGSORT HTP | 215 µs/op fixe · 35,7 % du DSP · tri complet 256 pour 8 utilisés (96,9 % jeté) |
Le classement de placement s'INVERSE selon l'architecture : dense compute-bound → HTP0 ; MoE sparse orchestration-bound → GPU (mégablocs OpenCL 1416 nœuds vs micro-splits HTP 58 nœuds). Le levier n'est pas « quel silicium » mais « comment découper le graph ».
2.3 APK (test conditions réelles — boutons sur le téléphone)
HTP0 : 28,2-29,8 t/s · GPU : 21,1-21,5 t/s (100 tokens, sortie affichée).
→ APK : C:\Users\videl\Desktop\geniex_harness\android\marco_moe_htp_test\app\build\outputs\apk\debug\app-debug.apk
3. Arborescence
D:\archive_16tps_20260902\
├── README.md ← ce fichier (entrée)
├── DOSSIER_REPRODUCTION_RUNTIME_20260902.md ← référence : inventaire, configs, résultats
├── TUTO_REPRODUCTION_PAS_A_PAS_20260902.md ← procédure 8 étapes + dépannage
├── RAPPORT_ARCHIVE_RUNTIME_16TPS_20260902.md ← rapport maître 12 sections
├── sha256_runtime.txt ← SHA-256 des binaires (vérif intégrité)
├── git_state_jz_fork.txt ← HEAD 9ef4543d, branche, log -12
├── runtime_device 16ts\ ← RUNTIME GELÉ (binaires + .so + skel + cfg)
│ ├── llama-server · ggml-hexagon.cfg
│ ├── libggml-{base,cpu,hexagon,opencl}.so · libggml.so
│ ├── libllama.so · libllama-common.so · libllama-server-impl.so
│ ├── libOpenCL.so · libcdsprpc.so · libmtmd.so · libomp.so
│ ├── vendor.qti.hardware.dsp*.so
│ └── htp\libggml-htp-v81.so (734 920 o) + v68/69/73/75/79 + lib_june_20260602 (réf. KO)
├── scripts\ ← protocole + campagnes
│ ├── run_guarded_bench.sh ← protocole GARDÉ (référence)
│ ├── campaign_3x300.sh ← 3×300 tokens config gelée
│ ├── campaign_ratios_npu_gpu.sh ← 8 configs placement Qwen
│ ├── campaign_ratios_npu_gpu_moe.sh ← 8 configs placement Marco
│ ├── bench_argsort_ab.sh ← A/B ARGSORT HTP vs CPU
│ ├── bench_moe_placement_ab.sh ← A/B HTP pur vs GPU→HTP
│ └── device\ (320+ scripts device bruts) · devices\
├── results\ ← RÉSULTATS BRUTS (meta.txt par run)
│ ├── bench_out_16tps\ (16tps_r1..r3, q4m1_ref16, q4m1_100t)
│ ├── camp_ratios_qwen\synthese.txt
│ ├── camp_ratios_moe\synthese.txt
│ └── argsort_ab\synthese.txt
├── reports\ ← 9 rapports détaillés (liens §4)
└── models\
├── Qwen3.5-9B-D2-A-MTP-attnQ4.gguf (5 450 272 384 o)
└── Marco-Nano-Instruct.Q4_0.gguf (4 569 976 352 o)
Liens externes : D:\profil_40tokens\ (logs de profiling n_predict=40) ·
D:\jz_work snapdragon\ggml-hexagon-fork\ (SOURCE, 7,8 Go) ·
C:\Users\videl\Desktop\geniex_harness\bench_results\ (83 rapports) ·
D:\models_marco\ (Marco Q8_0 source + Q4_0).
4. Où trouver quoi (rapports)
| Sujet | Fichier |
|---|---|
| Protocole gardé (pourquoi les anciens chiffres étaient contaminés) | reports/RAPPORT_PROTOCOLE_GARDE_VALIDE_20260902.md |
| Config gelée × croisement complet | reports/RAPPORT_CONFIG_16TPS_GELÉE_CROISEMENT_20260902.md |
| Test soutenu 100/300 tokens (le « 16 » vs le réel) | reports/RAPPORT_16TPS_SOUTENU_100_300_TOKENS_20260902.md |
| Placement Qwen (8 configs) | reports/RAPPORT_CAMPAGNE_RATIOS_NPU_GPU_20260902.md |
| Contrôle MoE Marco (26,7 t/s HTP0) | reports/RAPPORT_CONTROLE_MOE_MARCO_HTP_20260902.md |
| Renversement MoE×placement (GPU +40 %) | reports/RAPPORT_MOE_PLACEMENT_REVERSEMENT_20260902.md |
| Coût fixe par-op HTP (215 µs, profil mixte) | reports/RAPPORT_PROFIL_MIXTE_MOE_GPU_HTP_20260902.md |
| ARGSORT top-k : +16 % CPU, sortie ≠ entre backends | reports/RAPPORT_ARGSORT_TOPK_REPRODUCTIBLE_20260902.md |
| Impasse MoE ≤ 8B avec tête MTP | reports/RAPPORT_MOE_NATIF_MTP_INTROUVABLE_20260902.md |
Le même contenu vit dans bench_results/ du repo (avec les scripts dans tools/
et le projet APK dans android/marco_moe_htp_test/).
5. Reproduction rapide (résumé — détail : TUTO_PAS_A_PAS)
# 0. Device froid (< 45 °C), aucun llama-server résiduel
ADB="C:/Users/videl/Desktop/geniex_harness/tools/platform-tools/adb.exe"
# 1. Déployer le runtime gelé (une fois) : contenu de "runtime_device 16ts\" → /data/local/tmp/npu/
# (binaires + .so + ggml-hexagon.cfg + htp/libggml-htp-v81.so = 734 920 o EXACTEMENT)
# 2. Pousser le modèle (config « 16 t/s ») :
"$ADB" push "D:\archive_16tps_20260902\models\Qwen3.5-9B-D2-A-MTP-attnQ4.gguf" \
/data/local/tmp/Qwen3.5-9B-D2-A-MTP-attnQ4.gguf
# 3. Run gardé (env requis : user shell, PAS su ; --fit off obligatoire) :
"$ADB" shell "sh /data/local/tmp/run_guarded_bench.sh ref16 8541 16 \
'The capital of France is' --spec-type draft-mtp --spec-draft-n-max 1"
# → attendu : tps≈10,3 wall · accept 0,75 · mean_len 1,75 (PAS 16 — voir §2.1)
# 4. Long : sh /data/local/tmp/campaign_3x300.sh → 11,0 ± 0,3 t/s attendus
# 5. Contrôle MoE : MODEL=/data/local/tmp/Marco-Nano-Instruct.Q4_0.gguf
# → HTP0 ~27-31 t/s · -dev GPUOpenCL,HTP0 (ts 0.8,0.2) → ~39-42 t/s
Pièges connus (détail dans le tuto) : lancer via su = crash HTP0
(0x80000406 / mémoire CDSP non rapportée) — sauf l'APK qui passe par
su + setsid (validé). Après reboot : attendre 30+ min avant tout benchmark
(post-boot = 1,5-1,9 t/s contaminants). Cooldown T ≤ 45 °C entre runs.
APK : autoriser l'UID 10375 dans Magisk (UPDATE policies SET policy=2 WHERE uid=10375 + kill $(pidof magiskd)) sinon « runtime absent » en boucle.
6. Ce qui est prouvé / pas prouvé (garde-fous)
[MEASURED, reproductible] — wall 11,0 ± 0,3 t/s (Qwen dense, config gelée, 3×300) · 26-31 t/s (Marco HTP0) · 39-42 t/s (Marco GPU→HTP 80/20) · +16 % (ARGSORT CPU) · fixe par-op HTP 215 µs · sortie ≠ entre backends HTP/CPU (déterministe par backend).
[ÉTABLI] — MTP est le seul levier spéculatif utile sur HTP (+72 %) ; ngram réfuté ; hybrides HTP/GPU réfutés sur dense (−24/-29 %) ; le classement de placement dépend de l'architecture du modèle.
[ARTEFACT, ne pas citer comme débit] — « 16,6 effective t/s » = wall × mean_len. Débit wall réel soutenu = 10,3-11,3 t/s (Qwen) / 26-30 t/s (Marco HTP0).
[NON PROUVÉ / limites] — contrôle thermique à ±0,5 °C (comparer moyennes ± σ sur ≥ 3 runs, jamais le meilleur run) · profil absolus µs sur run profilé (overhead 2,4× — ratios % fiables, µs à confirmer) · le GPU côté OpenCL n'est pas profilé (GGML_OPENCL_PROFILING non compilé dans le binaire) · prompt court (5 tokens) — un prefill long peut changer le ratio.
7. Contexte projet
Ce dossier documente la partie exécution HTP du projet geniex_harness
(harnais Reason-Act-Observe local : README.md du repo, AGENTS.md pour les
axes expérimentaux AXE-6→10, governor/ pour le moteur de décision adaptatif).
La chronologie des faits expérimentaux est dans docs/TRAVAUX_ET_FONCTIONNEMENT.md
et les rapports horodatés dans bench_results/.
Dernière mise à jour : 2026-09-02 · généré depuis les résultats bruts de
results/ (aucun chiffre reconstruit de mémoire).
- Created
- Sep 2, 2026
- Updated
- Oct 5, 2026