Tencent open source AngelSpec, remettant en cause le speculative decoding universel

Tencent Hunyuan a open sourcé AngelSpec après avoir rapporté une inférence de Hy3-A21B jusqu’à 2,40 fois plus rapide que le décodage autorégressif standard. Le framework combine prise en charge de l’entraînement, de l’évaluation et du déploiement pour deux voies distinctes de speculative decoding. Son affirmation centrale remet en cause une hypothèse courante : une seule méthode de drafting ne peut pas gérer efficacement toutes les charges de travail des modèles de langage.

AngelSpec inclut la prédiction de plusieurs tokens, ou MTP, qui propose plusieurs tokens futurs via un drafter autorégressif léger. Il introduit également DFly, un système de block-diffusion qui prépare en parallèle un groupe plus long de tokens. Tencent affirme que DFly a offert un débit supérieur de 10,5 % à 11,8 % à celui de DFlash dans les conditions de serving testées.

Cette comparaison est importante, car DFlash avait déjà éloigné le speculative decoding du drafting strictement séquentiel. AngelSpec ne propose pas simplement un autre drafter plus rapide. Il organise deux approches contrastées autour de la charge de travail que chacune traite le mieux, puis ajuste la vérification en fonction des conditions d’exécution.

Le résultat est un framework ouvert offrant une vision plus opérationnelle de l’accélération de l’inférence. Les développeurs peuvent examiner le parcours d’entraînement, tester les modèles de draft Hy3 publiés et analyser l’évolution des performances en fonction du trafic. Toutefois, les gains rapportés par Tencent proviennent de ses propres modèles, configurations et méthodologie d’évaluation. Des résultats de production indépendants restent l’élément de preuve décisif manquant.

AngelSpec transforme un choix de recherche en choix de déploiement

AngelSpec traite le speculative decoding comme un problème de sélection selon la charge de travail, et non comme une compétition visant une architecture de drafting universelle.

Les chercheurs de Tencent ont soumis la première version de l’article AngelSpec le 28 juillet 2026. Une version révisée a suivi le 29 juillet. L’entreprise a ensuite annoncé la sortie open source avec le code d’entraînement et les poids du modèle de draft Hy3-A21B.

Le speculative decoding utilise un drafter plus petit ou moins coûteux pour proposer plusieurs tokens futurs. Le modèle cible complet vérifie ensemble ces propositions et accepte le préfixe correspondant. Lorsque les propositions sont exactes, le système produit plusieurs tokens valides tout en évitant un nombre équivalent de passes coûteuses du modèle cible.

La méthode préserve la distribution de sortie du modèle cible lorsqu’elle est mise en œuvre avec le processus requis de vérification et de rejet. Elle modifie donc l’efficacité de la génération des tokens, plutôt que de substituer les réponses du drafter à celles du modèle cible.

La qualité du draft détermine toujours si cet avantage théorique se traduit par une accélération pratique. Un drafter faible produit des tokens rejetés, ajoutant du travail sans faire progresser la génération. Un drafter important peut prédire avec précision, mais consommer trop de temps et de mémoire. La vérification peut également devenir coûteuse lorsque les systèmes testent plus de candidats qu’une requête ne le justifie.

AngelSpec intègre ces variables dans un même framework d’entraînement et d’évaluation. Il prend en charge MTP et le speculative decoding block-parallel, y compris la génération d’états cachés, l’entraînement à long contexte, les workflows de rollout et l’évaluation de l’acceptation en ligne. La sortie vise à couvrir une plus grande partie du chemin entre un checkpoint de recherche et un service d’inférence opérationnel.

Les deux voies de drafting du framework divisent le problème selon le comportement de sortie. Tencent entraîne son drafter MTP sur des données conversationnelles variées, où le langage est ouvert et les prochains tokens restent relativement incertains. Il entraîne la voie block-diffusion sur le code et les mathématiques, où les continuations plus longues suivent souvent des structures plus prévisibles.

Cette spécialisation constitue le changement le plus important de l’événement. De nombreuses comparaisons de speculative decoding demandent quelle méthode l’emporte en moyenne. AngelSpec demande plutôt quelle structure de drafting correspond à une distribution donnée, puis expose les deux structures via un parcours de développement commun.

Les poids associés rendent également cette sortie plus testable qu’un article décrivant un système indisponible. Tencent affirme avoir publié des drafters MTP et DFly pour Hy3-A21B via ses canaux de modèles. Les développeurs ont toujours besoin du modèle cible correspondant et d’un matériel de serving adapté, mais ils n’ont pas à recréer chaque étape d’entraînement avant de commencer l’évaluation.

Hy3 fournit à cette sortie une cible exigeante. Le dépôt officiel du modèle Hy3 décrit un modèle mixture-of-experts comptant 295 milliards de paramètres au total et 21 milliards de paramètres actifs. Il répertorie également une couche MTP de 3,8 milliards de paramètres et une fenêtre de contexte de 256 000 tokens.

Ces spécifications rendent l’efficacité de l’inférence importante sur le plan économique. Seule une fraction du modèle complet est activée pour chaque token, mais le serving exige toujours une mémoire, des communications et des calculs du modèle cible considérables. Un drafter qui augmente la sortie acceptée par étape de vérification peut améliorer la latence ou le débit sans réentraîner le modèle principal.

AngelSpec arrive donc comme plus qu’un simple accessoire de Hy3. Il offre un framework explicite pour choisir, entraîner et évaluer des systèmes de draft à mesure que les conditions de serving évoluent. Cette portée plus large exerce une pression sur le speculative decoding universel.

Les gains rapportés mettent sous pression les stratégies de drafting statiques

L’affirmation la plus forte de Tencent ne réside pas seulement dans l’accélération maximale, mais dans l’avance de DFly à chaque niveau de concurrence testé, de 4 à 64.

Selon l’article, DFly a offert une accélération de bout en bout de 1,98 à 2,40 fois par rapport au décodage autorégressif sur Hy3-A21B. Tencent rapporte également un débit supérieur de 10,5 % à 11,8 % à celui de DFlash et une sortie acceptée moyenne environ 30 % plus longue.

La concurrence mesure le nombre de requêtes que le système de serving traite simultanément. Elle modifie l’équilibre entre calcul, efficacité du batching, pression mémoire et surcharge de vérification. Une méthode qui semble rapide pour une requête peut perdre son avantage lorsque de nombreuses requêtes se disputent les mêmes accélérateurs.

Tencent affirme que DFly a atteint le débit moyen le plus élevé à chaque niveau de concurrence testé, de 4 à 64. Cette plage est importante, car elle couvre un trafic relativement léger comme un service davantage batché. Le résultat suggère que le scheduler et la stratégie de vérification de DFly ont contribué au-delà du taux brut d’acceptation du modèle de draft.

Les chiffres exigent néanmoins une interprétation prudente. Une accélération de 2,40 fois ne signifie pas que chaque utilisateur voit les réponses arriver 2,40 fois plus vite. L’accélération de bout en bout dépend de la charge de travail de benchmark, de la longueur de sortie, du mélange de requêtes, de la politique de batching, du profil matériel et de la configuration de référence.

Le débit et la latence répondent également à des questions différentes. Le débit mesure la quantité de travail accomplie par un système au fil du temps. Les utilisateurs interactifs se préoccupent souvent davantage du délai avant le premier token et du délai entre les tokens suivants. Un service peut augmenter son débit total tout en apportant des améliorations plus modestes ou inégales à une requête individuelle.

Cette distinction met sous pression les équipes d’inférence utilisant des politiques de drafting fixes. Une politique statique peut choisir une longueur de draft, une profondeur de vérification ou un drafter pour l’ensemble du trafic. AngelSpec soutient que ces choix devraient répondre au domaine, aux caractéristiques des requêtes, à la charge en ligne et au matériel de déploiement.

La cible de cette pression n’est donc pas une entreprise en particulier. C’est l’approche qui traite le speculative decoding comme un ajout fixe au modèle. Si les conclusions de Tencent se confirment ailleurs, les opérateurs auront besoin d’une logique de routage et de scheduling capable de déterminer quand le travail de drafting reste utile.

DFlash fournit la comparaison la plus directe. Sa conception block-diffusion utilise les états cachés du modèle cible pour prédire plusieurs tokens de draft en parallèle. Cette approche évite de générer chaque proposition via une étape distincte de drafter séquentiel.

Les auteurs de DFlash ont rapporté une accélération supérieure à six fois dans certaines expériences sélectionnées ainsi que des gains par rapport à EAGLE-3. Ces résultats reposaient sur des cibles et des conditions de test différentes ; ils ne doivent donc pas être comparés directement au maximum de 2,40 fois d’AngelSpec. L’affirmation pertinente de Tencent est la comparaison contrôlée avec DFly rapportée dans sa propre évaluation de Hy3.

Les systèmes de type EAGLE demeurent une autre référence importante. Ils utilisent les caractéristiques du modèle cible pour guider un drafter autorégressif plus petit, en organisant souvent les propositions pour une vérification efficace. Ces systèmes peuvent fournir des résultats stables sur des textes variés, mais les dépendances séquentielles au sein du drafting peuvent limiter la vitesse à laquelle de longues séquences candidates sont proposées.

MTP occupe une version plus légère de cette voie autorégressive. Il est plus facile à intégrer lorsque la cible expose déjà des couches de prédiction compatibles. La sortie Hy3 de Tencent inclut elle-même une couche MTP, faisant du modèle un banc d’essai naturel pour comparer le drafting léger à un système block-parallel spécialisé.

La pression exercée par AngelSpec sur les déploiements existants est pratique. Les équipes doivent déterminer si le modèle supplémentaire, la logique de scheduler, le profiling et l’utilisation mémoire génèrent suffisamment de tokens acceptés pour justifier leur complexité. Le framework leur fournit du code et des poids pour explorer cette question, mais il ne rend pas la réponse universelle.

Comment AngelSpec rend DFly plus sélectif

DFly associe drafting parallèle et informations autorégressives, puis consacre le travail de vérification là où le rendement attendu est le plus élevé.

Un drafter block-diffusion prédit plusieurs positions ensemble au lieu de les compléter une à une. La prédiction parallèle réduit la latence de drafting, en particulier lorsque le bloc candidat est long. Cependant, les tokens d’une phrase ou d’une séquence de code dépendent fortement des tokens antérieurs au sein de ce même bloc.

Cette dépendance crée une faiblesse. Si chaque position est prédite à partir de voisins masqués ou incomplets, les propositions ultérieures peuvent manquer d’informations qu’un drafter autorégressif reçoit naturellement. Une erreur précoce peut raccourcir le préfixe accepté par le modèle cible, gaspillant une grande partie du bloc proposé.

DFly traite cette tension avec deux composants connectés. Son backbone s’appuie sur des caractéristiques du modèle cible tout en conservant une génération block-parallel. Une tête autorégressive conditionnée par les prédécesseurs fournit également aux prédictions des informations sur les tokens antérieurs, améliorant les dépendances au sein du bloc proposé.

L’architecture ne transforme pas l’ensemble du draft en un processus séquentiel conventionnel. La conception de Tencent cherche à préserver le travail parallèle dans le backbone tout en ajoutant suffisamment d’informations sur les prédécesseurs pour améliorer la cohérence des candidats. Cet équilibre est essentiel à l’augmentation revendiquée de la longueur moyenne acceptée.

La longueur acceptée correspond au nombre de tokens proposés que le modèle cible approuve avant de rencontrer une divergence. Des préfixes acceptés plus longs répartissent chaque étape coûteuse de vérification sur davantage de sortie utile. Toutefois, maximiser la longueur acceptée seule peut être trompeur si la production et la vérification de ces candidats consomment trop de temps.

AngelSpec ajoute donc une méthode de vérification adaptative appelée D-Cut. La profondeur de vérification désigne la part de chaque continuation proposée que le modèle cible contrôle. Une profondeur fixe peut surinvestir dans des candidats incertains ou s’arrêter trop tôt sur des candidats hautement prévisibles.

D-Cut traite la capacité de vérification comme une ressource partagée au niveau du batch. Il estime la valeur attendue de la conservation de positions candidates supplémentaires et la compare à un coût d’exécution profilé. Le scheduler peut alors orienter davantage de travail de vérification vers les préfixes à forte confiance à travers plusieurs requêtes.

Il s’agit d’une décision de serving, et pas seulement d’un choix de modèle. Deux requêtes exécutées sur le même modèle peuvent justifier des niveaux de vérification différents. Une complétion de code structurée peut maintenir un long préfixe avec un haut niveau de confiance, tandis qu’une réponse de chat ouverte peut diverger après seulement quelques tokens.

Le matériel modifie également le calcul. Un lot de vérification plus important peut être efficace sur une configuration d’accélérateurs et coûteux sur une autre. Les coûts de communication, la bande passante mémoire, les kernels et le parallélisme du modèle cible influencent tous la question de savoir si une position candidate supplémentaire fait gagner du temps.

C’est pourquoi AngelSpec profile le coût d’exécution au lieu de s’appuyer uniquement sur des estimations de probabilité. Une candidate peut sembler susceptible d’être acceptée tout en offrant une faible utilité si sa vérification étend un lot vers une forme inefficace. Le planificateur a besoin à la fois de confiance et de coûts système mesurés.

La documentation de Nvidia sur le décodage spéculatif illustre la manière dont les frameworks de déploiement exposent déjà une configuration propre à chaque méthode. Sa prise en charge de DFlash requiert un modèle draft, une longueur draft, un token de masque et des couches cibles sélectionnées. AngelSpec pousse le problème plus loin, vers une allocation adaptative entre des requêtes actives.

La séparation par domaines complète cette adaptation à l’exécution. MTP reste la voie légère pour les sorties conversationnelles à plus forte incertitude. DFly cible le code et les mathématiques, où des blocs parallèles peuvent capturer des séquences prévisibles plus longues. Aucune de ces méthodes ne reçoit automatiquement la priorité pour chaque requête.

Prenons un service de codage par IA qui génère une suite de tests répétitive. Les imports, signatures de fonctions et motifs d’assertions peuvent rendre le bloc suivant relativement prévisible. DFly peut proposer une continuation plus longue, et D-Cut peut préserver une vérification plus approfondie tant que la confiance reste élevée.

Considérons maintenant le même service répondant à une question d’architecture ambiguë. Plusieurs explications valides peuvent commencer à partir du même prompt. Le préfixe accepté peut être plus court, car le drafteur et la cible choisissent des formulations différentes. Une proposition MTP plus petite peut éviter de dépenser des ressources sur un long bloc candidat ayant peu de chances d’être conservé.

Ce mécanisme rend cette publication plus importante qu’une simple amélioration sur un benchmark. Il redéfinit le décodage spéculatif comme une politique couvrant les données d’entraînement, l’architecture du drafteur, la classification des requêtes et le coût de serving. L’accélération provient de la coordination de ces couches plutôt que de la maximisation d’un score isolé.

Ce que les chiffres d’AngelSpec ne démontrent pas

AngelSpec apporte des éléments crédibles de première main, mais ne démontre pas encore que DFly l’emporte sur l’ensemble des modèles, du matériel ou du trafic de production.

Les résultats de l’article proviennent de l’équipe qui a conçu le framework et entraîné les modèles draft. Les comparaisons rapportées n’avaient pas été reproduites indépendamment au moment de la publication. Les lecteurs doivent considérer ces accélérations comme des affirmations mesurées par l’entreprise, et non comme des garanties de performances universelles.

La dépendance au modèle constitue la première limite. DFly utilise des caractéristiques internes de la cible ; un drafteur est donc étroitement lié à l’architecture et aux caractéristiques d’entraînement de sa cible. Un drafteur Hy3-A21B ne peut pas simplement devenir un accélérateur prêt à l’emploi pour une famille de modèles sans rapport.

Cette relation augmente les coûts d’entraînement et de maintenance. Chaque cible prise en charge peut nécessiter son propre processus d’extraction d’états cachés, son mélange de données d’entraînement, son checkpoint et son cycle de validation. Les mises à jour du modèle cible peuvent également nécessiter de nouveaux tests de compatibilité ou un nouvel entraînement du drafteur.

La dépendance au matériel crée une autre incertitude. Tencent indique que D-Cut utilise un coût d’exécution profilé, reconnaissant que la meilleure politique de vérification varie selon les systèmes. Une politique réglée pour un cluster peut nécessiter de nouveaux profils avant d’être performante sur d’autres accélérateurs ou topologies réseau.

Les chiffres phares publics condensent également plusieurs charges de travail en plages de résultats. Le code, les mathématiques et la conversation présentent une prédictibilité différente. Le débit moyen peut masquer des catégories faibles, des longueurs de prompts défavorables ou des schémas de trafic où le surcoût du drafting se rapproche du calcul cible économisé.

Le comportement en contexte long mérite une attention particulière. AngelSpec prend en charge l’entraînement en contexte long, et Hy3 annonce une fenêtre de contexte de 256 000 tokens. Toutefois, de grands caches clé-valeur accroissent la pression mémoire et peuvent modifier le coût relatif du drafting et de la vérification. Les résultats obtenus sur des contextes plus courts ne peuvent pas trancher les performances à proximité de la fenêtre maximale du modèle.

La préservation de la qualité exige également une discipline d’implémentation. Le décodage spéculatif peut préserver la distribution cible grâce à un algorithme d’acceptation et de rejet approprié. Des raccourcis de déploiement, une vérification approximative, un échantillonnage modifié ou une quantification incompatible peuvent modifier les sorties. Les opérateurs doivent valider à la fois la vitesse et l’équivalence comportementale.

La mémoire représente un autre coût réel. Le modèle cible, le modèle draft, les interfaces d’états cachés et les buffers d’exécution supplémentaires doivent coexister. Même un drafteur léger peut réduire l’espace disponible pour le cache clé-valeur ou pour des lots plus importants. Le compromis de capacité qui en résulte peut effacer un gain de débit dans des déploiements contraints par la mémoire.

La complexité opérationnelle compte également. Un service de production doit surveiller la longueur d’acceptation, le temps de drafting, le temps de vérification, le comportement des files d’attente et les performances de repli. Le routage entre MTP et DFly ajoute une couche de décision supplémentaire dont les erreurs peuvent envoyer les mauvaises charges de travail vers le mauvais drafteur.

La publication open source rend ces questions testables, ce qui est précieux. Elle n’y répond pas automatiquement. Les équipes devraient reproduire une base autorégressive sur leur propre matériel avant de comparer l’une ou l’autre des voies AngelSpec.

Elles devraient ensuite séparer les mesures par charge de travail et niveau de trafic. Les catégories utiles incluent le chat interactif, la complétion de code, le raisonnement mathématique, les traces d’utilisation d’outils et la génération longue. Chaque catégorie devrait inclure les percentiles de latence, le débit, la consommation mémoire, la longueur d’acceptation et des vérifications d’équivalence des sorties.

Une comparaison équitable avec DFlash exige également des conditions identiques. Le même modèle cible, la même précision, le même framework de serving, la même distribution de prompts, la même longueur de sortie et le même niveau de concurrence doivent être utilisés. Sinon, les affirmations architecturales peuvent se retrouver mêlées à la qualité des kernels ou à des différences de configuration.

Les retours de la communauté offrent des signaux précoces, mais ne remplacent pas une reproduction contrôlée. Les rapports de déploiement local utilisent souvent des modèles quantifiés, du matériel grand public ou des moteurs de serving modifiés. Ces résultats peuvent révéler des problèmes de compatibilité, mais correspondent rarement assez étroitement à la configuration de l’article pour valider sa plage de résultats phare.

L’écart de benchmark ne rend pas AngelSpec sans importance. Il définit la prochaine étape de l’histoire. Tencent a fourni une architecture, un chemin de code et des poids de modèles que des équipes externes peuvent mettre à l’épreuve dans des conditions que les auteurs d’origine ne contrôlaient pas.

Trois signaux détermineront si AngelSpec dépasse Hy3

L’importance d’AngelSpec dépendra d’une réplication indépendante, d’une prise en charge plus large des modèles et de preuves que le routage adaptatif résiste au trafic réel de production.

Le premier signal sera un benchmark Hy3-A21B reproductible par une équipe d’inférence indépendante. Le test le plus probant utiliserait les poids MTP et DFly publiés tout en indiquant le matériel, la précision, les versions de framework, le mélange de prompts et les longueurs de sortie. Il devrait comparer le décodage autorégressif, MTP, DFlash et DFly dans des conditions identiques.

Une réplication proche de la plage de 1,98 à 2,40 fois annoncée par Tencent renforcerait l’affirmation centrale. Des gains constants par rapport à DFlash suggéreraient également que le conditionnement par prédécesseur et D-Cut apportent une valeur au-delà du drafting général par diffusion de blocs. Des gains plus faibles ou instables réduiraient l’intérêt pratique d’AngelSpec.

Le rapport indépendant le plus utile publierait davantage que le débit moyen. Il devrait inclure le délai jusqu’au premier token, la latence inter-token, la latence en queue, l’utilisation mémoire, la longueur acceptée et les performances selon les niveaux de concurrence. Ces mesures montreraient si l’efficacité globale améliore l’expérience utilisateur.

Le deuxième signal sera la prise en charge d’une autre grande famille de modèles cibles. AngelSpec dispose actuellement de ses preuves les plus nettes et de poids draft publiés autour de Hy3. Un portage réussi vers Qwen, Llama ou un autre modèle ouvert largement déployé permettrait de vérifier si son framework se généralise au-delà de l’architecture de Tencent.

Le portage révélerait également le coût réel de l’adoption. Les chercheurs devraient générer les états cachés de la cible, entraîner des drafteurs spécialisés, intégrer la vérification et profiler le comportement d’exécution. Un portage documenté avec un effort d’ingénierie raisonnable renforcerait l’affirmation d’une utilisabilité de bout en bout du framework.

L’absence de portages suggérerait qu’AngelSpec constitue principalement un package d’optimisation pour Hy3. Ce résultat pourrait toujours bénéficier aux utilisateurs des modèles Tencent, mais il affaiblirait l’argument plus large en faveur d’un framework unifié de décodage spéculatif.

Le troisième signal sera constitué de preuves de production sur des charges de travail mixtes. L’argument de Tencent repose sur l’hétérogénéité ; un benchmark statique ne peut donc pas le valider entièrement. Le test décisif consiste à savoir si un service en direct peut choisir entre MTP et DFly alors que le trafic, les domaines et l’utilisation du matériel évoluent.

Les opérateurs devraient observer à quelle fréquence les décisions de routage améliorent la sortie acceptée par unité de coût de vérification. Ils devraient également mesurer les taux de repli et les erreurs de routage. Un système adaptatif complexe doit surpasser une base plus simple après prise en compte de ses coûts de surveillance et de planification.

Ce test est particulièrement pertinent pour les services combinant chat, codage, travail mathématique et actions d’agents. Ces produits génèrent des sorties dont l’entropie et la longueur diffèrent fortement. Ils offrent les conditions dans lesquelles un drafting spécialisé devrait surpasser une politique universelle.

Si des déploiements à charges mixtes montrent des gains stables, les concurrents subiront une pression pour exposer des contrôles de routage similaires. Les frameworks de serving pourraient évoluer d’une sélection d’un algorithme spéculatif unique au lancement vers l’attribution, par requête, d’algorithmes et de budgets de vérification.

Si les gains s’effondrent hors de charges de travail sélectionnées, des méthodes plus simples resteront attrayantes. MTP peut être plus facile à exploiter, en particulier lorsqu’un modèle est déjà livré avec des couches compatibles. Les stratégies draft statiques réduisent également le nombre de modèles et de politiques que les équipes doivent maintenir.

Les développeurs qui évaluent cette publication devraient conserver leurs résultats de test et leurs décisions de configuration dans une base de connaissances d’ingénierie consultable. Les expériences de décodage spéculatif impliquent suffisamment de variables en interaction pour que des exécutions non documentées deviennent rapidement impossibles à comparer.

AngelSpec a déjà changé la question à laquelle font face les ingénieurs d’inférence. Le choix ne consiste plus seulement à activer ou non le décodage spéculatif. Il s’agit de savoir si le drafteur, la distribution d’entraînement, la politique de vérification et le profil matériel correspondent suffisamment à chaque requête pour économiser du travail réel.

Les un à trois prochains mois devraient révéler si des équipes externes reproduisent les chiffres de Tencent, portent DFly au-delà de Hy3 et valident le routage adaptatif sous une demande réelle. D’ici là, AngelSpec est une expérience open source sérieuse avec des résultats de première main prometteurs, et non un vainqueur établi.

Pour les équipes qui servent Hy3 aujourd’hui, la prochaine étape utile consiste en un benchmark contrôlé face à leurs configurations autorégressives et MTP existantes. Pour tous les autres, la question clé est plus étroite : le drafting tenant compte de la charge de travail apporte-t-il une efficacité suffisamment durable pour justifier un modèle et une couche de planification supplémentaires ? La réponse déterminera si AngelSpec devient un framework d’inférence largement adopté ou reste un avantage bien conçu, principalement lié à la propre famille de modèles de Tencent.