Composants Go réutilisables d'Ollama pour LLM local

Composants autonomes dans le code source d'Ollama

Un développeur a récemment analysé le code source d'Ollama pour identifier les éléments qui pourraient être utilisés indépendamment dans d'autres projets Go. L'enquête a révélé plusieurs composants qui n'ont pas d'équivalents sous forme de bibliothèques Go autonomes disponibles ailleurs.

Implémentation de l'échantillonnage de tokens

Le package sample/ d'Ollama contient une implémentation en Go pur de l'échantillonnage par température, top-k, top-p, min-p et glouton. Le développeur n'a trouvé aucune alternative Go autonome - les solutions existantes encapsulent soit llama.cpp via CGo, soit envoient des paramètres à des API distantes. L'ordre du pipeline (topK d'abord, puis température, puis softmax, puis topP, puis minP) est crucial ; le modifier produit des résultats différents.

Gestion des fichiers GGUF

Bien qu'il existe un lecteur GGUF indépendant (gpustack/gguf-parser-go) qui offre des fonctionnalités comme l'analyse à distance et l'estimation de la VRAM, il est en lecture seule. Le package fs/ggml d'Ollama inclut une fonction WriteGGUF() sans équivalent ailleurs en Go. Le lecteur de bas niveau (fs/gguf) est particulièrement propre avec zéro importation du reste du code source d'Ollama - copier 5 fichiers permet de le compiler indépendamment. Cependant, le code d'analyse GGUF présente des préoccupations de sécurité : il y a eu 13+ CVE liés à des attaques DoS provenant de fichiers GGUF malformés, et le code source contient des lacunes de validation des entrées qui pourraient entraîner des allocations de mémoire illimitées à partir de champs de taille contrôlés par un attaquant.

Capacités de conversion de modèles

Le package convert/ gère la conversion de SafeTensors et PyTorch vers GGUF pour plus de 25 architectures de modèles. Le seul équivalent est le script Python convert_hf_to_gguf.py. Extraire ce composant est plus complexe en raison des dépendances sur des packages internes, mais les parties lecteur et tokeniseur sont étonnamment indépendantes.

Système de modèles de conversation

Ollama inclut plus de 20 modèles de conversation intégrés et utilise une approche de correspondance approximative avec la distance de Levenshtein pour faire correspondre les chaînes de modèles Jinja2 des fichiers GGUF à des équivalents Go. Aucune bibliothèque Go existante ne fournit de rendu de modèles de conversation spécifiques aux modèles, bien que chaque nouveau format de modèle nécessite des modèles portés manuellement.

Couche de compatibilité OpenAI

Environ 600 lignes de fonctions de transformation pures convertissent le format OpenAI au format Ollama sans logique HTTP. Malgré cette implémentation propre, des projets comme LocalAI et one-api ont construit leurs propres versions à partir de zéro plutôt que d'extraire ce composant.

Considérations de sécurité

L'analyse a noté des aspects de sécurité préoccupants : 22+ CVE depuis 2024, plus de 175 000 instances exposées trouvées par SentinelOne, et aucune authentification API intégrée. Les vulnérabilités d'analyse GGUF affecteraient toute extraction de ce code, bien que l'échantillonneur et les transformations OpenAI soient propres.

Lacune dans l'écosystème Go

Le développeur a observé que bien que l'écosystème Go dispose de bons outils en haut (clients API, serveurs HTTP) et en bas (liaisons CGo vers GGML et CUDA), il manque une couche intermédiaire pour l'échantillonnage, les modèles, la conversion de format et l'écriture GGUF qui n'existe actuellement que dans Ollama.

📖 Read the full source: r/LocalLLaMA