- Expédié
- 25 septembre 2026 à 10:25 UTC
- Auteur
- Kamo
- Commit
- 5edb887
Le moteur ONNX de TEI 1.5 démarre un fil d'inférence par noyau d'hôte physique (24 sur k1m1) et ne lit aucun réglage de fil, donc sous le quota 1-CPU de la nacelle, les gaz CFS ont gelé la piscine mi-lot: un lot de 8 est passé de 0,3 s à 5-11 s, /santé (qui attend le lot dans vol) a dépassé le 1-s timeout de kubelet, et la vivacité a tué le modèle deux fois dans un réindex. RAGService prend un événement dont l'intégration a échoué, de sorte que ces mises à jour KB et note ont été perdues, et 106 Les articles du Centre d'aide n'ont jamais reçu de vecteurs. - image cpu-1.5 -> cpu-1.9.4: à partir de 1.6, le pool ONNX est dimensionné à partir de la limite CPU de cgroup. Les mêmes fichiers modèles; les vecteurs sont identiques à ceux de 1.5, de sorte que les points de Qdrant restent valides. Le reclasseur de SP01 a la même étiquette. - --tokenization-workers 1, et OMP/MKL/RAYON NUM THREADS=1 (l'image définit RAYON à 8), donc Chaque piscine correspond à la limite même si TEI revient à son moteur de bougie. - durée de vie et de préparation à l'arrêtSecond 1 -> 10. - Oui. (python3 -m unittest discover -s embedding-model/tests) pins le manifeste, et avec TEI ROOTFS/TEI MODEL DIR exécute l'image du manifeste, args et env sous son quota CPU avec cinq clients en forme de RAGService : cpu-1.5 a lancé 35 fils, 2,7 morceaux/s et a échoué 102 des 121 sondes; cpu-1.9.4 fait tourner 6 fils, 8,1 morceaux/s et ne fait aucun échec. Examen final de KamoAI SP00 I-1.