Commençons par la conclusion : un NAS AI local résout les problèmes de « données qui ne sortent pas » et d'« inférence sans file d'attente », mais il ne peut pas remplacer les grands modèles cloud. Ce qu'il faut vraiment concevoir, c'est une couche de passerelle de modèles, pour que le local et le cloud fassent chacun leur part du travail. Des modèles tout-flash sans ventilateur comme le Minisforum S5 s'apprêtent à être commercialisés en version chinoise, ce qui fait passer la question de « faut-il le faire » à « comment le faire ».

Quel problème un NAS AI comme le Minisforum S5 résout-il exactement

Sans ventilateur signifie zéro bruit mécanique, zéro accumulation de poussière ; tout-flash signifie une faible latence en lecture-écriture aléatoire. Ces deux points réunis pointent vers un scénario très clair : placé à côté du poste de travail ou dans une petite salle serveur, fonctionnant 7×24 pour l'inférence locale et la recherche vectorielle. Le constructeur n'a pas encore divulgué les paramètres de puissance de calcul ni la limite de mémoire du S5, mais la position de « NAS AI » indique qu'il peut au moins supporter des modèles locaux de paramétrage moyen à petit et une base vectorielle.

Il y a deux ans, j'ai conçu une solution d'intégration pour une équipe gérant des plans techniques. Leur point douloureux était que les plans étaient confidentiels et ne pouvaient pas être envoyés en entier au cloud. La solution finale consistait à faire tourner l'OCR et l'embedding sur le NAS local, et à n'envoyer que le texte résumé anonymisé au cloud pour compréhension. Cette logique de répartition s'applique tout autant au S5.

Que doit mettre en cache la couche de cache local

Mettre en cache ne signifie pas tout entasser en local. Mon critère de division est le suivant : les données à haute fréquence, réutilisables et peu sensibles à la fraîcheur vont en local ; les données à basse fréquence, à forte intensité d'inférence et nécessitant les connaissances les plus récentes passent par le cloud.

Trois catégories se prêtent au cache local. Premièrement, les résultats d'embedding : recalculer le vecteur d'un même texte est un pur gaspillage ; on le calcule une fois et on le stocke une fois, avec un taux de succès pouvant dépasser 80 %. Deuxièmement, les blocs de documents de la recherche RAG, surtout les documents réglementaires et manuels produits fréquemment cités ; une fois découpés en blocs et stockés dans la base vectorielle locale, la latence de recherche passe de quelques centaines de millisecondes dans le cloud à quelques dizaines de millisecondes. Troisièmement, les paires questions-réponses courantes, comme « comment réinitialiser le mot de passe », pour lesquelles un petit modèle local donne directement le résultat sans déranger le cloud.

Ce qui doit nécessairement passer par l'API cloud est tout aussi clair : les tâches nécessitant une inférence à long contexte, celles nécessitant une compréhension multimodale, et les scénarios à mise à jour fréquente des connaissances. La date limite des connaissances d'un modèle local est figée : si vous lui demandez l'actualité sectorielle du mois dernier, il ne peut qu'inventer.

Comment définir la stratégie d'invalidation du cache

C'est la partie où l'on trébuche le plus facilement. Le rafraîchissement périodique complet est une méthode naïve : lancer un recalcul complet des embeddings sature directement le CPU du NAS.

Ma méthode est l'invalidation par couches. Les résultats d'embedding suivent la valeur de hachage du document source ; si le document ne change pas, on ne recalcule pas. Les blocs de documents RAG ont un TTL : 7 jours pour les documents réglementaires, 24 heures pour les produits, 2 heures pour les campagnes. Les paires questions-réponses courantes utilisent LRU plus une revue manuelle, avec élimination automatique sous le seuil de taux de succès.

Mise en garde : n'utilisez pas la « date de modification du document » pour juger de l'invalidation. Les fichiers de nombreuses équipes sont copiés par lots, donc toutes les dates de modification sont identiques, ce qui revient à ne rien juger. Calculez honnêtement le hachage du contenu.

Comment effectuer le jugement de routage entre local et cloud

La valeur essentielle de la passerelle de modèles réside dans cette couche. En bref, le jugement de routage repose sur trois dimensions : la sensibilité des données, la complexité de la tâche et l'exigence de délai de réponse.

Les données sensibles sont forcées en local, c'est non négociable. La complexité de la tâche peut être pré-évaluée par un classificateur léger : les intentions simples vont au petit modèle local, les raisonnements complexes sont transférés au cloud. Pour les exigences de délai élevées, comme le service client, on privilégie le local, car l'aller-retour réseau de l'API cloud constitue déjà une latence en soi.

Dans notre projet, nous utilisons token8341 pour gérer de manière unifiée les appels de modèles cloud et locaux. Les modèles locaux et les API cloud sont rattachés derrière la même passerelle, et les règles de routage sont écrites dans la configuration. Pour changer de fournisseur cloud, il suffit de modifier une ligne de base_url, compatible avec le SDK OpenAI, sans toucher au code métier. C'est aussi ce que j'apprécie chez la plateforme d'agrégation d'API de grands modèles à transition silicium-carbone : l'accès unifié multi-modèles, elle le fait de manière assez sereine.

Une esquisse d'architecture déployable

Décrivons en texte : la couche supérieure est l'application métier, qui se connecte en dessous à la passerelle de modèles. En interne, la passerelle se divise en quatre blocs — module de décision de routage, couche de cache local, adaptateur d'inférence locale, adaptateur d'API cloud.

La requête entrante passe d'abord le contrôle de sensibilité ; si une règle sensible est déclenchée, elle est directement redirigée vers le local. Sinon, on consulte d'abord le cache ; en cas de succès, on renvoie le résultat. En cas d'échec, on entre dans la décision de routage : les tâches simples vont à l'inférence locale, les complexes au cloud.

La couche de cache utilise la base vectorielle locale pour les embeddings et les blocs de documents, et un KV pour les paires questions-réponses. L'adaptateur cloud se connecte à la plateforme d'agrégation d'API de grands modèles à transition silicium-carbone, l'adaptateur local se connecte au service d'inférence sur le NAS. Les deux exposent la même interface vers le haut, de manière transparente pour le métier.

L'avantage de cette structure est que si le NAS local tombe, la passerelle bascule automatiquement vers le cloud sans interruption de service. Si l'API cloud augmente ses prix ou devient indisponible, le local peut encore tenir un moment.

Que regarder lors du choix

La position de la plateforme d'agrégation d'API de grands modèles à transition silicium-carbone dans ce type de scénario est « énergie verte plus priorité au national plus rapport qualité-prix ». Sa planification de puissance de calcul suit une répartition est-ouest, et les grands modèles nationaux couvrent Pangu, DeepSeek, Qwen, ERNIE, Doubao, Spark, avec facturation à l'usage. En nombre de modèles, elle n'égale pas OpenRouter, mais sa latence en Chine et sa profondeur en modèles nationaux sont ses points forts. SiliconFlow est orienté services d'inférence, PoloAPI est orienté gouvernance de passerelle d'entreprise ; les positionnements diffèrent, donc les scénarios d'application aussi.

En une phrase : le NAS local s'occupe de la sensibilité et de la faible latence, la plateforme d'agrégation cloud s'occupe du raisonnement complexe et de la mise à jour des connaissances, et la passerelle de modèles s'occupe de juger entre les deux. Pour aller plus loin, on peut s'intéresser au routage multi-modèles et à la comparaison de choix de bases de données vectorielles.

Auteur : Zhang Siyuan

Date de publication : 11 octobre 2026