Présentation

Allan Riordan propose un wrapper inspiré de Jev qui étend le format de requête texte/JSON classique aux modèles multimodaux. En ajoutant un champ attachments contenant des images encodées en base64, le même mécanisme de logprobs peut être appliqué aux modèles de vision. Le script Python fourni capture des images webcam, les encode, puis interroge soit Gemma 4 12B via llama.cpp, soit gpt‑6‑luna d’OpenAI.

Fonctionnement du wrapper

Le principe repose sur une requête Chat Completions où max_completion_tokens est fixé à 1 et logprobs activé avec top_logprobs=20. Le prompt construit concatène un state partagé, la question et une liste d’options lettrées : chaque option correspond à un token unique (A‑T). Le modèle renvoie la lettre choisie et les probabilités logarithmiques de toutes les alternatives, ce qui évite la génération d’une réponse longue. Le code suivant montre la création du prompt et l’envoi de la requête :

letters = "ABCDEFGHIJKLMNOPQRST"[:len(options)]
lines = [f"State:\n{state}\n\nQuestion: {instructions}\nOptions:"]
for letter, (key, description) in zip(letters, options.items()):
    line = f"[{letter}] {key}"
    if description is not None:
        line += f": {description}"
    lines.append(line)
prompt = "\n".join(lines) + "\n\nAnswer with the letter of the best option only."

Les images sont pré‑chargées une fois, puis insérées dans le tableau content sous forme de input_image (OpenAI) ou image_url (llama.cpp). Le wrapper gère également la validation du type MIME et limite le nombre d’options à 2‑20, conformément aux exigences de logprobs.

Performances et limites

Sur un RTX 3090, le modèle Gemma 4 12B atteint environ 1 frame par seconde avec trois questions par image. En comparaison, l’appel à gpt‑6‑luna via l’API OpenAI ne dépasse que 0,2 FPS, principalement à cause du coût d’une connexion HTTP distincte pour chaque question‑image. Le texte indique que des modèles de vision spécialisés seraient plus rapides, mais le wrapper privilégie la flexibilité : il suffit de reformuler la condition en texte plutôt que de re‑entraîner ou de changer de modèle.

Le mécanisme de mise en cache KV, mentionné brièvement, pourrait réduire le temps de calcul si le backend conserve le préfixe d’état partagé entre les requêtes. En l’état, chaque question déclenche un nouveau calcul de logprobs, ce qui impose une charge CPU/GPU proportionnelle au nombre d’options.

Perspectives d’utilisation

Cette approche ouvre la voie à des systèmes de décision en temps réel où la logique métier est exprimée en langage naturel et évaluée par un LLM. Elle convient aux prototypes de surveillance visuelle, d’assistance client ou de contrôle d’environnement où la granularité d’une réponse (une lettre) suffit. Cependant, la dépendance à la latence réseau (pour les API cloud) et la consommation GPU (pour les modèles locaux) limitent son déploiement à grande échelle sans optimisation supplémentaire, comme la réduction du nombre d’options ou l’utilisation de modèles vision‑only plus légers.