github llama.cpp · il y a 1 h · inference

llama.cpp b10080 corrige le plantage du serveur et l'erreur de validation de l'interface utilisateur

Traduit de English → Français

La version llama.cpp b10080 traite deux bugs spécifiques dans les composants du serveur et de l'interface utilisateur. Le serveur renvoie désormais correctement un code d'état 400 au lieu de planter avec une erreur 500 lorsque la validation échoue pour les requêtes contenant l'en-tête X-Conversation-Id. De plus, l'interface utilisateur n'envoie plus le placeholder backend_sampling, qui provoquait précédemment l'échec de la validation des complétions par défaut.

Serveur : Corrige un plantage std::bad_function_call en gérant next_orig vide dans on_complete() lorsque set_next() est ignoré lors d'erreurs de validation.
Serveur : Évince les sessions installées par set_req() pour les requêtes échouées afin de prévenir les fuites de ressources et les problèmes de découverte.
Interface utilisateur : Protège le champ backend_sampling avec hasValue() pour filtrer les placeholders de chaînes vides tout en préservant les valeurs false explicites.

Ces modifications améliorent la stabilité en empêchant les plantages du serveur sur des entrées invalides et en garantissant que les paramètres par défaut sont correctement transmis depuis le client.

Importance 1/3 Confiance 1/3 llama.cpp Inference efficiency

Lire l'original

Articles similaires

github llama.cpp · à l'instant En direct

llama.cpp b10081 résout le dépôt de brouillon vers son sidecar demandé

La version llama.cpp b10081 corrige un bug où le drapeau `--hfd` pointait vers un dépôt contenant des sidecars spéculatifs, mais le plan de brouillon était incorrectement résolu vers le modèle principal au lieu du sidecar. Cela s'est produit car `find_best_model()` excluait les fichiers sidecar et le plan de brouillon explicite supprimait la découverte des sidecars.

arxiv arXiv cs.LG · il y a 5 h

SkewAdam utilise un état d'optimiseur en couches pour réduire la mémoire de formation MoE de 97 %

Les chercheurs présentent SkewAdam, un optimiseur conçu pour les modèles à mélange d'experts (MoE) qui alloue différents types d'état à des populations de paramètres distinctes afin de réduire drastiquement l'utilisation de la mémoire. En attribuant le momentum float32 et les moments seconds factorisés au noyau, les moments seconds factorisés aux experts, et les moments seconds exacts au routeur, SkewAdam réduit l'état de l'optimiseur de 50,6 Go à 1,29 Go pour un modèle de 6,78 milliards de paramètres.

github llama.cpp · il y a 7 h

llama.cpp b10078 refactorise la gestion des files d'attente Vulkan pour contourner le mutex côté hôte

Le projet llama.cpp a publié la compilation b10078, qui comprend une refactorisation significative du backend Vulkan pour améliorer l'efficacité de la synchronisation. La mise à jour intègre le support de VK_KHR_internally_synchronized_queues, permettant à la bibliothèque d'abstraire la soumission des files d'attente dans une interface polymorphique qui contourne complètement le verrouillage du mutex côté hôte lorsque le pilote le prend en charge.

github llama.cpp · il y a 14 h

llama.cpp b10076 vectorise get_rows avec copie int4 pour une accélération de 27 %

Le projet llama.cpp a publié la compilation b10076, qui introduit une optimisation de performance dans le backend CUDA en vectorisant l'opération `get_rows` à l'aide de copies int4. Ce changement extrait le travail invariant par ligne de la boucle élément par élément et ajoute un chemin vectorisé qui copie 16 octets par thread pour des données contiguës du même type.

media Hugging Face Forums · il y a 2 j · 1 vue

La production d'agents vocaux avec des LLM locaux fait face à une latence persistante et à des limites de contexte

Une équipe déployant deux agents vocaux en production en Espagne, utilisant Retell AI, Ollama et des modèles locaux sur un RTX 4000 Ada, rapporte que si la qualité des conversations s'est améliorée, le problème fondamental de latence reste non résolu. La contrainte principale est un délai d'attente (timeout) d'environ 3 secondes imposé par Retell AI ; si le LLM ne parvient pas à produire un premier jeton dans cette fenêtre, la connexion est interrompue, entraînant la fin de l'appel après deux tentatives de reconnexion.