Repository navigation
NEXUS AI Studio (French)
Version 25
English · Français · 日本語 · 한국어
Ouvrir la version navigateur · Télécharger l’application complète · README
Un espace IA local pour dialoguer avec les modèles pris en charge via le moteur personnalisé WebGPU ou Nexus.cpp.
Ouvrez l’application, choisissez le profil GPU et la capacité mémoire dans Models & settings, puis sélectionnez un modèle GGUF local et chargez-le pour dialoguer. Aucun modèle n’est inclus. Le moteur WebGPU vérifie l’architecture, le graphe des tenseurs, la quantification et le tokenizer. Un adaptateur WebGPU fonctionnel et une mémoire suffisante sont nécessaires. Un profil GPU ne prouve pas la compatibilité et ne mesure pas la VRAM libre. Les profils RX 7900 XT et XTX indiquent des capacités nominales de 20 Go et 24 Go.
Le fichier HTML unique intègre l’interface, le code d’inférence et la bibliothèque de tokenisation et de modèles de conversation pour permettre une évaluation en ligne sans Python, installation ni compilation. L’importation et le chargement du modèle prennent du temps supplémentaire. La version navigateur ne téléverse pas les données du modèle, n’utilise pas de serveur local et ne propose aucun repli vers le CPU. Nexus.cpp natif, services en ligne, voix, caméra et fonctions d’enseignant ne sont pas inclus.
L’application complète associe vérification des modèles, contrôle de la conversation et diagnostics consultables dans ses moteurs navigateur et natif distincts. Le protocole natif 3 propose Stop, New Chat, cache de préfixe et réglages d’échantillonnage ; les exécutables natifs doivent être recompilés pour ces fonctions. Le lot natif reste limité à un token par étape ; Flash Attention natif et cache KV à précision réduite ne sont pas implémentés.
Téléchargez le paquet complet en conservant les fichiers de données numérotés, le manifeste, l’installateur et l’arborescence fournie. Exécutez Install_Nexus_AI.py avec CPython 3.10+ ; les contrôles Linux enregistrés utilisent 3.12.14. Nexus AI n’utilise pas de backend PyTorch. L’application complète exige son service local ; Nexus.cpp exige un exécutable compatible et une configuration compilateur/HIP/pilote adaptée à l’accélération Radeon. La fenêtre de bureau facultative utilise pywebview>=5,<7.
La version navigateur a passé des contrôles scriptés de démarrage sans réseau. Ils ne qualifient pas la qualité ni les performances GPU d’un modèle complet. Un contrôle de logits finis et non constants n’est qu’un test élémentaire de disponibilité. Aucune performance Windows/Radeon ni compatibilité universelle n’est revendiquée. Révision navigateur : v25-browser-r1. Le paquet natif version 25, les chemins Candidate25 et les empreintes restent inchangés ; Candidate24 reste disponible pour revenir en arrière.
L’usage personnel et les tests et évaluations commerciaux internes sont autorisés pour les éléments appartenant à Nexus, y compris cette version navigateur. La distribution, la modification, le déploiement en production et les autres usages commerciaux nécessitent un consentement écrit exprès. Les licences tierces et les droits déjà accordés restent inchangés.
Rich Dunbar / Nexus Emerging Technology. License · Evaluation permission (English).
Le texte original ci-dessous est l’historique du projet, pas un guide actuel d’installation, d’exécution ou de licence. Utilisez la section actuelle de la version 25 ci-dessus et sa documentation liée.
Développé par Rich Dunbar avec l’aide de l’IA pour le codage.
NEXUS AI s’est construit au fil de centaines d’itérations : développer, tester, recueillir des captures d’écran et des diagnostics, tirer des enseignements des échecs et améliorer l’application grâce aux retours des utilisateurs.
Inférence dans le navigateur · Modules vocaux et d’analyse des expressions en option · Apprentissage des préférences soumis à validation · Évaluation de la perplexité
Je voulais un assistant personnalisable, capable de fonctionner sur mon propre matériel et de s’adapter à ma manière de travailler.
Mon développement a commencé avec LM Studio, puis s’est orienté vers ma propre interface graphique et, finalement, vers un moteur d’inférence personnalisé dans le navigateur. Je souhaitais également réduire la dépendance à des applications d’IA installées séparément et aux contraintes de déploiement que j’avais rencontrées.
LM Studio mérite d’être reconnu pour son rôle dans ce point de départ. Il fournit des outils et des API pour les modèles locaux ; le moteur d’exécution local actuel de NEXUS est une implémentation distincte. Documentation de développement de LM Studio
Les règles de déploiement dépendent de l’organisation, du produit et de sa version. Il ne faut pas confondre trois éléments différents :
- LM Studio : une application de bureau avec ses propres conditions d’utilisation.
- llama.cpp : un logiciel d’inférence distribué sous licence MIT.
- Meta Llama : des familles de modèles dont les poids sont soumis à des conditions distinctes, propres à chaque modèle.
LM Studio a supprimé en juillet 2025 son obligation de prise de contact spécifique pour une utilisation commerciale. Mon récit du développement ne doit pas être interprété comme une affirmation selon laquelle cette ancienne exigence s’appliquerait encore, ou selon laquelle toutes les organisations interdiraient ces outils. Annonce de LM Studio · Licence de llama.cpp · Exemple de licence : Llama 3.3
Dans mon processus de travail, la distribution d’un exécutable de bureau soulevait des difficultés liées à la signature et aux avertissements de sécurité. Le passage à HTML m’a permis de modifier plus facilement l’interface et a réduit le besoin de distribuer un exécutable Windows séparé.
Windows SmartScreen tient compte de la réputation de l’application et de son éditeur ; une signature ne garantit pas qu’une nouvelle version évitera les avertissements. Un conditionnement pour navigateur ne vaut pas non plus automatiquement approbation par l’organisation et ne dispense pas de respecter les politiques de sécurité. Documentation de Microsoft SmartScreen
J’ai commencé par une implémentation répartie sur plusieurs fichiers qui, selon mon récit du développement, a fini par en compter des centaines. J’ai trouvé qu’une structure applicative monolithique permettait de travailler plus vite et de coordonner plus facilement les modifications assistées par l’IA.
Il s’agit d’un choix de développement propre à ce projet, et non d’une affirmation selon laquelle les logiciels à fichier unique seraient toujours plus rapides ou meilleurs.
flowchart LR
A["Développer une modification ciblée"] --> B["Tester et mesurer"]
B --> C["Examiner les captures d’écran et les diagnostics"]
C --> D["Apprendre des résultats et des retours"]
D --> A
B --> E["Vérifications de non-régression"]
E --> F["MVP opérationnel"]
F --> D
style A fill:#123456,stroke:#38bdf8,color:#ffffff
style B fill:#164e63,stroke:#22d3ee,color:#ffffff
style D fill:#312e81,stroke:#a5b4fc,color:#ffffff
style F fill:#14532d,stroke:#4ade80,color:#ffffff
L’IA m’a aidé à implémenter et à déboguer. J’ai défini l’orientation, mis les processus à l’épreuve et utilisé les résultats pour guider la révision suivante.
Un produit minimum viable opérationnel, ou MVP, offre quelque chose de concret à tester. Il est suivi d’autres améliorations : commandes plus claires, meilleurs diagnostics, sauvegarde fiable, vérifications de compatibilité et modifications guidées par les retours.
L’interface principale et la logique applicative sont livrées ensemble dans un fichier HTML qui utilise HTML, CSS et JavaScript.
Le paquet hors ligne complet contient néanmoins des poids de modèles, des ressources d’exécution et des ressources de workers séparés. Un point d’entrée HTML unique ne signifie pas que tous les modèles neuronaux sont intégrés dans ce fichier.
Les compromis comprennent des fichiers plus volumineux, une navigation plus difficile et la nécessité de tests rigoureux. Les limites de contexte de l’IA continuent de s’appliquer.
Le moteur d’exécution local du modèle de langage qui a été examiné utilise du code personnalisé en JavaScript, WebGPU et WGSL. Il ne nécessite ni LM Studio ni llama.cpp dans son mode normal d’inférence locale.
Les moteurs accessibles en ligne par API sont optionnels et distincts. Un serveur local de fichiers statiques peut être nécessaire pour respecter les exigences d’origine du navigateur ; cela ne revient pas à exiger un serveur de modèle de langage.
flowchart TD
U["Interface utilisateur"] --> L["Moteur local de modèle de langage WebGPU"]
U --> R["Mémoire et recherche d’informations"]
U --> V["Module optionnel d’analyse des expressions"]
U --> S["Modules vocaux distincts"]
L --> A["Adaptateur optionnel de la tête de sortie"]
A --> E["Évaluation sur données réservées et critères d’activation"]
V --> C["Indication prudente et optionnelle pour le ton"]
C --> L
style L fill:#123456,stroke:#38bdf8,color:#ffffff
style V fill:#312e81,stroke:#a5b4fc,color:#ffffff
style S fill:#164e63,stroke:#22d3ee,color:#ffffff
style E fill:#14532d,stroke:#4ade80,color:#ffffff
La mémoire, la recherche d’informations et la personnalisation des consignes peuvent modifier les réponses sans changer les poids du modèle. L’entraînement effectif d’un adaptateur suit un processus distinct.
Une prise en charge implémentée ne signifie pas une validation matérielle complète. L’admissibilité dépend de l’architecture exacte, de l’organisation des tenseurs, du tokeniseur, du gabarit de conversation et de la mémoire disponible.
| Famille ou profil | Périmètre implémenté | Limites des éléments de validation |
|---|---|---|
| SmolLM / SmolLM2 | Modes d’exécution GGUF denses sous contraintes, dont les profils de base et Instruct | Les vérifications numériques antérieures sur des modèles réels couvrent des fichiers SmolLM2-135M F16 et Q8 précis ; les autres tailles ne sont pas entièrement validées |
| Mistral-7B-v0.3 | Profil de complétion textuelle de base examiné | Vérifications du tokeniseur et vérifications numériques à échelle réduite |
| Mistral-Small-3.2-24B-Instruct-2506 | Profil textuel examiné | Vérifications de l’en-tête, du tokeniseur et d’un graphe réduit ; aucune exécution complète du modèle 24B |
| Ministral-3-14B-Reasoning-2512 | Profil textuel de raisonnement examiné | Vérifications numériques à échelle réduite, du gabarit et des encodages positionnels rotatifs |
| Qwen2 / Qwen2.5 / Qwen3 | Modes d’exécution textuels denses sous contraintes | N’établit pas la compatibilité avec toutes les variantes ou tailles |
| Gemma 3 | Graphe textuel distinct | Inspection d’un en-tête et d’un tokeniseur réels, et vérifications numériques synthétiques ; aucune validation complète des sorties du modèle 27B |
| GPT-oss-20B | Graphe personnalisé à mélange d’experts | Tests synthétiques ; aucune exécution matérielle complète du modèle 20B |
| GPT-oss-120B | Accès explicitement conditionné à un futur matériel | Non validé pour la configuration déclarée de 20 Gio de mémoire GPU et de 32 Gio de RAM |
| Qwen2.5-VL-7B | Profil précis de texte et d’images fixes avec le composant visuel local correspondant | Tests synthétiques à échelle réduite ; aucune validation complète du modèle 7B avec conditionnement par image |
| LittleBit personnalisé | Format pris en charge à facteurs compactés | Métadonnées et encodage exacts requis |
GGUF est un conteneur, pas une garantie de compatibilité universelle. Les architectures arbitraires, les fichiers GGUF fractionnés, les organisations de quantification non prises en charge et le chargement général de fichiers PyTorch/Safetensors sortent du périmètre du chargeur examiné.
Les capacités des modèles en amont ne deviennent pas non plus automatiquement celles de l’application. Par exemple, la limite habituelle du contexte alloué dans cette version est de 4 096 tokens.
Recherches et crédits des modèles : SmolLM2 · Gemma 3 · Qwen2.5-VL · Fiche du modèle GPT-oss
Le module caméra actuel effectue une détection des visages et une classification des expressions faciales, sans reconnaissance de l’identité.
Il utilise :
- YuNet pour détecter les visages et leurs points de repère.
- ProgressiveTeacherFER avec une architecture de base MobileFaceNet pour classer les expressions.
- ONNX Runtime Web, exécuté dans un worker WASM distinct, sur CPU et avec un seul fil d’exécution.
Ce module est distinct du moteur WebGPU du modèle de langage.
Le classificateur comporte sept catégories : colère, dégoût, peur, joie, neutralité, tristesse et surprise. L’interface présente des libellés prudents tels que « évoquant la tristesse » ou « évoquant la surprise ». Il n’existe pas de classe « enthousiaste » issue de la caméra.
Des contrôles de qualité, des seuils de score de confiance, des estimations répétées et une expiration au bout de cinq secondes aident l’application à s’abstenir lorsque les observations ne conviennent pas. Ces heuristiques ne constituent pas des garanties étalonnées concernant les sentiments d’une personne.
Avec un consentement explicite et un réglage facultatif de la conversation locale, désactivé par défaut, une estimation récente de l’expression peut ajouter une indication prudente aux consignes système.
Cette indication demande à l’assistant de :
- Traiter l’estimation comme incertaine.
- Donner la priorité aux propos réels de l’utilisateur.
- Ajuster légèrement le ton si cela est utile.
- Poser une question plutôt que supposer.
- Éviter de déduire une identité, des intentions, un diagnostic ou un risque.
Une humeur déclarée par l’utilisateur et sélectionnée séparément est prioritaire et dispose de règles de ton explicites.
Je décris cela comme une adaptation programmée des réponses tenant compte des indices affectifs. Ce n’est pas une preuve que le système comprend les sentiments intérieurs ou possède une intelligence émotionnelle au sens psychologique validé.
L’informatique affective apporte un contexte de recherche pertinent, tandis que les travaux sur les expressions faciales mettent en garde contre l’idée que les mouvements du visage permettraient de lire les émotions de manière fiable et univoque. Picard : les défis de l’informatique affective · Barrett et al. : réexaminer les expressions émotionnelles
Les contextes issus de la caméra sont exclus de la collecte automatique destinée à l’entraînement des adaptateurs. La fonction d’analyse des expressions ne conserve intentionnellement ni galeries de visages ni historiques d’expressions. Les services en ligne activés séparément disposent de leurs propres flux de données.
Le paquet complet comprend les ressources Kokoro-82M ONNX Q8, les voix Bella et Fenrir, un phonémiseur et un dictionnaire anglais, ainsi qu’un worker ONNX Runtime.
Après l’importation du paquet fourni dans le stockage du navigateur, ce mode synthétise la parole localement. Le paquet intégré est exclusivement anglophone ; traduire ce wiki n’ajoute pas la prise en charge d’autres langues pour la voix. Fiche du modèle Kokoro
Aucun modèle de reconnaissance vocale n’est fourni.
La reconnaissance en mode strictement hors ligne exige une reconnaissance locale compatible dans le navigateur et un module linguistique déjà installé. Si ces conditions ne sont pas réunies, elle échoue au lieu de basculer silencieusement vers une reconnaissance dans le cloud.
Lorsque le mode strictement hors ligne est désactivé, la reconnaissance du navigateur ou une API configurée séparément peut utiliser un service en ligne.
Une synthèse vocale hors ligne ne rend pas automatiquement la reconnaissance vocale hors ligne.
L’application actuelle contient une véritable adaptation de type LoRA de la tête de sortie.
Le modèle GGUF de base, les blocs du transformeur et les plongements d’entrée restent figés. Des matrices de faible rang entraînables modifient les logits de sortie. Le calcul de propagation avant du modèle figé utilise WebGPU ; les gradients de l’adaptateur et l’optimiseur s’exécutent en JavaScript sur le CPU.
Les modes d’apprentissage comprennent :
- Une optimisation hors ligne des préférences de type DPO à partir de paires approuvées de réponses préférées et rejetées.
- Un entraînement par entropie croisée à partir de réponses positives approuvées.
- Un processus distinct, soumis à examen, pour les corpus générés par un modèle enseignant.
LoRA décrit le mécanisme d’adaptation. DPO décrit un objectif d’apprentissage des préférences. Ni l’un ni l’autre ne justifie de qualifier chaque interaction de mise à jour par apprentissage par renforcement. Cette version ne démontre pas l’existence d’une boucle de RLHF en ligne fondée sur PPO. LoRA · Optimisation directe des préférences
L’interface Learning propose des commandes d’entraînement, d’évaluation et d’activation. L’action End Session peut également tenter un entraînement facultatif lorsque des données admissibles approuvées et un modèle pris en charge et vérifié sont prêts.
L’activation d’une nouvelle version exige des vérifications sur des données réservées à l’évaluation et des tests de non-régression. Les utilisateurs peuvent terminer sans entraîner, et les échecs préservent l’adaptateur précédent.
Les points de contrôle sont liés à l’identité du modèle et du moteur d’exécution. Les contextes influencés par la caméra et ceux contenant une question explicite sur une image sont exclus de la collecte automatique.
« Le modèle grandit au fil de mes interactions » doit surtout se comprendre comme l’accumulation, au fil du temps, d’exemples approuvés et de mises à jour facultatives de l’adaptateur. Le modèle de base ne gagne pas de paramètres, et aucune amélioration n’est garantie.
La mémoire fondée sur la recherche d’informations est un mécanisme entièrement différent. Elle fournit du contexte sans réentraîner les poids. Génération augmentée par la recherche d’informations
L’application évalue la prédiction du token suivant en fournissant les tokens précédents de référence et calcule :
Perplexité = exp(log-vraisemblance négative totale ÷ nombre de tokens évalués).
Elle conserve les caractéristiques permettant d’identifier l’évaluation : texte, tokenisation, modèle, moteur d’exécution, adaptateur et paramètres de contexte. Des comparaisons pertinentes avant et après modification exigent un protocole d’évaluation identique.
Cela peut aider à évaluer l’effet d’un adaptateur compatible. Ce n’est pas une mesure directe de l’exactitude factuelle, du raisonnement, de la compréhension émotionnelle ou de l’intelligence globale.
Un score plus faible sur les données d’entraînement peut refléter une mémorisation. Il faut également utiliser des données réellement réservées à l’évaluation et des tests sur des tâches.
Je rapporte avoir testé des versions de développement de NEXUS sur ma configuration AMD Radeon RX 7900 XT, Windows 11 et Microsoft Edge.
Il s’agit de mon expérience de développement. Elle ne doit pas être présentée comme un test de performance matériel reproduit indépendamment pour chaque moteur pris en charge ou pour la toute dernière version précise.
La version examinée contient des calculs opérationnels d’apprentissage des préférences, des mises à jour par l’optimiseur, des vérifications d’identité du modèle et un évaluateur de perplexité. Des tests synthétiques ciblés ont vérifié les gradients, les partitions de données figées et la couverture des fenêtres d’évaluation.
Les vérifications antérieures sur de véritables modèles SmolLM2 portaient sur un nombre limité de positions de préfixe, avec une exécution logicielle sur CPU/Vulkan. Les traces de test du module d’expressions couvrent l’exécution du modèle et l’abstention en l’absence de visage ; celles de la voix couvrent la synthèse. Elles n’établissent ni la précision sur de vrais visages, ni une fiabilité complète sur les navigateurs et appareils, ni les performances physiques d’une carte Radeon.
Les articles scientifiques expliquent les méthodes. Ils ne certifient pas l’implémentation de NEXUS AI et ne reproduisent pas ses tests de performance.
Cette page décrit l’application empaquetée le 9 octobre 2026, examinée le 10 octobre 2026.
SHA-256 de l’application :
1a1d6eb77958a8b276607843eb446a391d887c65612c5acfabb301ac7daca465
Les fonctionnalités des applications autonomes Nexus Adapter Studio, Foundry et Recovery ne doivent pas être attribuées à cette version, sauf si leur intégration a été vérifiée séparément.
Ma contribution comprend l’application NEXUS, l’intégration personnalisée, l’interface, les travaux sur le moteur d’exécution et le processus de développement itératif. Le mérite du travail des créateurs de modèles et des contributeurs en amont leur revient.
Les dépendances pertinentes comprennent :
- Kokoro : hexgrad, avec une conversion ONNX par ONNX Community/Xenova.
- YuNet : Shiqi Yu et les contributeurs.
- ProgressiveTeacherFER : Jing Jiang ; crédit de l’implémentation ONNX de Chengrui Wang préservé.
- ONNX Runtime : Microsoft et les contributeurs.
- Modules linguistiques HeadTTS : Mika Suominen.
- Dictionnaire de prononciation CMU : Carnegie Mellon University.
Le paquet applicatif examiné déclare UNLICENSED. Les dépendances open source n’attribuent pas automatiquement une licence open source à l’ensemble de l’application. Consultez la licence effective du dépôt avant d’affirmer l’existence de droits de redistribution ou d’utilisation commerciale.
Le paquet d’analyse des expressions préserve les déclarations en amont, mais les questions concernant la licence exacte du point de contrôle et la provenance des données d’entraînement restent non résolues. Elles doivent être clarifiées avant toute affirmation d’utilisation sans restriction.
Construire. Mesurer. Apprendre. Vérifier. Affiner.
Rich Dunbar · NEXUS Emerging Technology