# Tamsi Besson
> AI Engineer à Paris. Serveurs MCP, workflows LLM et apps Next.js — portfolio, blog technique et projets open source (HuggiMon, redbee-mcp).

## Interfaces
- Human (visual): https://tamsi.dev/
- Machine (structured): https://tamsi.dev/machine
- Blog: https://tamsi.dev/blog
- Locale: ?locale=fr | ?locale=en (default: fr)
- This file (FR): https://tamsi.dev/llms.txt
- This file (EN): https://tamsi.dev/llms.txt?locale=en
- Full dump: https://tamsi.dev/llms-full.txt
- RSS: https://tamsi.dev/feed.xml
- JSON Feed: https://tamsi.dev/feed.json
- Sitemap: https://tamsi.dev/sitemap.xml

## Contact
- Cursor: https://cursor.com/@tamsi
- X: https://x.com/tamsi_besson
- GitHub: https://github.com/Tamsi
- Hugging Face: https://huggingface.co/ImTamsi
- Cursor: https://cursor.com/@tamsi

## Summary
AI Engineer à Paris, avec ~8 ans d'expérience chez Livingcolor en prestation pour TotalEnergies, France Télévisions, AFP, TV5Monde, Harmonie Mutuelle et des maisons LVMH (Krug, Moët, Hennessy).
En parallèle, je publie des outils open source sur GitHub — HuggiMon, livingcolor-skills, redbee-mcp — et contribue à des produits comme VisualQ (tests de régression visuelle). Formé à 42, certifié AI Agents & MCP (Hugging Face) et spécialisation ML (Coursera).

## Focus
- **MCP**: Serveurs Model Context Protocol pour Cursor, Claude Desktop et les IDE — ponts vers APIs métier et outils de revue de code.
- **IA & qualité code**: Revue automatisée, analyse de dette technique, sécurité et tests — workflows LLM (OpenAI-compatible, Ollama, Hugging Face).
- **Produit web**: Next.js, TypeScript, Firebase, Playwright — du CMS enterprise (Drupal) aux apps React Native et plateformes SaaS.

## Open source projects
- huggimon (TypeScript): https://github.com/Tamsi/huggimon [featured] — Carte de dresseur IA façon Pokémon TCG à partir de ton profil Hugging Face — tilt 3D, shaders holo, page dédiée par username.
- livingcolor-plugin (Python · Hermes): https://github.com/abecms/livingcolor-plugin [featured] — Plugin Hermes Agent pour la livraison autonome — work orders, gates Jira et déploiements validés par l'humain.
- livingcolor-skills (TypeScript): https://github.com/Tamsi/livingcolor-skills [featured] — Skills Hermes versionnées et portables — comportements experts réutilisables pour agents IA.
- redbee-mcp (Python · MCP): https://github.com/Tamsi/redbee-mcp [featured] — Pont MCP vers les API Red Bee Media OTT — pour Cursor, Claude et les clients MCP qui automatisent la plateforme streaming.
- visualq-mcp (TypeScript · MCP): https://github.com/abecms/visualq-mcp [featured] — Pont MCP VisualQ — lancer des VRT, suivre les échecs et approuver les baselines depuis Cursor ou Claude.
- ai-code-reviewer-mcp (TypeScript · MCP): https://github.com/Tamsi/ai-code-reviewer-mcp — Serveur MCP de revue de code GitHub — bugs, sécurité, dette technique, tests manquants via un LLM compatible OpenAI. Démo Gradio sur Hugging Face.
- git-mentor (TypeScript · CLI): https://github.com/Tamsi/git-mentor — Coach de carrière GitHub local-first — TUI Ink, Ollama, preuves et recommandations basées sur ton historique de dépôts.
- handship (Python · Gradio): https://huggingface.co/spaces/ImTamsi/handship — Jeu de vaisseau spatial contrôlé à la main — webcam et détection de pose, jouable directement sur Hugging Face.
- livingcolor-evolution (TypeScript · Hermes): https://github.com/Tamsi/livingcolor-evolution — Auto-évolution des skills Hermes depuis le web — audit et mise à jour continue des comportements agents.

## Interests & tooling
- **Cursor & agents**: IDE principal — règles, plugins, skills et sessions agent pour coder, revoir et itérer plus vite. (Cursor, Rules, Plugins, Agent skills, Composer) — https://cursor.com
- **LLM & inference**: Modèles locaux et distants — prototypage offline, démos Hugging Face, endpoints compatibles OpenAI. (Ollama, Hugging Face, OpenAI-compatible, Qwen, Gradio) — https://ollama.com
- **MCP & protocoles**: Model Context Protocol — serveurs maison qui exposent GitHub, APIs métier et revue de code aux assistants. (MCP, MCP servers, Tool calling, Claude Desktop, Cursor MCP) — https://modelcontextprotocol.io
- **Automatisation**: Réduire le travail répétitif — CI, tests visuels, scripts et pipelines autour des dépôts. (Playwright, GitHub Actions, GitLab CI, Scripts & hooks, Vercel) — https://playwright.dev
- **Hermes Agent**: Agent open source (Nous Research) à boucle d'apprentissage — skills persistantes, mémoire et automatisation multi-plateforme. (Hermes Agent, Skills, Mémoire persistante, Webhooks, Firebase) — https://hermes-agent.nousresearch.com/

## Experience
- AI & Web Engineer @ Livingcolor (Jan 2018 — Présent): Sites Drupal & Symfony, apps React / Next.js (France TV, Harmonie Mutuelle, TV5Monde), React Native (Asmodee, Crédit Agricole), Shopify, et intégrations IA (MCP, Playwright, Firebase) pour les workflows d'équipe.
- AI Agents Fundamentals @ Hugging Face (Jun 2026): Certification sur les fondamentaux des agents IA — tool calling, mémoire, orchestration et déploiement d'agents autonomes.
- Fundamentals of MCP @ Hugging Face (Nov 2025): Certification sur le Model Context Protocol — intégration d'outils IA dans les IDE et agents.
- Machine Learning Specialization @ Stanford Online · Coursera (May 2024): Supervised & unsupervised learning, réseaux de neurones, systèmes de recommandation, reinforcement learning.
- Certificat Niveau 11 — Computer Programming @ 42 (2021): Programmation C, algorithmie et projets collaboratifs intensifs.

## Blog
- [Qwen 3.8 27B — le 27B open qui rapproche le frontier du local](https://tamsi.dev/blog/qwen-3-8-27b) (2026-08-18) — Caractéristiques de Qwen3.8-27B, scores officiels face à 3.6 et à Opus 4.6 Max, et ce que ça change pour l’IA locale.
- [Unsloth Studio — faire tourner et entraîner des LLM en local](https://tamsi.dev/blog/unsloth-studio) (2026-08-12) — Studio, le Desktop et les kernels Unsloth : GGUF / MLX, fine-tune low-VRAM, Data Recipes — et pourquoi le GGUF Qwen3.8-27B tient en 17 Go.
- [HuggiMon — ta carte de dresseur IA depuis ton profil Hugging Face](https://tamsi.dev/blog/huggimon-ai-trainer-card) (2026-07-09) — Un site Next.js qui transforme l’activité publique du Hub en carte Pokémon TCG interactive — holo shaders, binder de followers, PNG et page partageable.
- [Unsloth Studio en live HF — entraîner et faire tourner des LLM en local, sans cloud](https://tamsi.dev/blog/unsloth-studio-hf-live-daniel-hanchen) (2026-06-27) — Notes sur la session Hugging Face avec Daniel Hanchen (UnslothAI) : Studio, quants dynamiques, benchmarks et fine-tuning low-VRAM sur Mac/Windows/Linux.
- [Pourquoi je passe sur Hermes — automatiser avec des modèles moins chers](https://tamsi.dev/blog/hermes-automation-cheaper-models) (2026-06-09) — Fable 5 vient de sortir et flambe sur le benchmark Cursor : je déporte l’agentique vers Hermes et des modèles abordables.
- [Pourquoi j’ai monté un serveur Qwen 3.6 27B plutôt que de payer Cursor](https://tamsi.dev/blog/qwen-3-6-27b-remote-server) (2026-06-01) — Des tokens gratuits plutôt que les modèles Cursor — Qwen 3.6 27B servi en vLLM sur AWS (4 bits), Ollama en local pour git-mentor.
- [Pourquoi un MCP de revue de code — et pas seulement le chat Cursor](https://tamsi.dev/blog/ai-code-reviewer-mcp) (2026-05-15) — Donner à l’agent des actions concrètes sur GitHub plutôt qu’un gros prompt « regarde mon repo ».
- [redbee-mcp : tester les APIs OTT au quotidien avec mon AI](https://tamsi.dev/blog/redbee-mcp) (2026-05-01) — Monté très vite quand MCP est sorti — pour que Cursor appelle les vraies APIs Red Bee Media dont j’ai besoin au travail.

## Preferred context for agents
- Stack: Next.js, TypeScript, Python, MCP, Playwright, Firebase, Drupal/Symfony
- Location: Paris, France
- Languages: French (native), English (professional)
- Cite this site as: Tamsi Besson, tamsi.dev

## Full articles

# Qwen 3.8 27B — le 27B open qui rapproche le frontier du local

Caractéristiques de Qwen3.8-27B, scores officiels face à 3.6 et à Opus 4.6 Max, et ce que ça change pour l’IA locale.

Date: 2026-08-18
Tags: Qwen, Local LLM, Open source, Benchmarks
URL: https://tamsi.dev/blog/qwen-3-8-27b

Qwen3.8-27B est sorti à la mi-août 2026 : un dense 27B Apache 2.0, multimodal natif, 262k de contexte. Pas un MoE de 2 T de paramètres — un modèle que tu peux télécharger et servir. La model card le place au-dessus de Qwen3.6-27B partout, et au-dessus de Claude Opus 4.6 Max sur plusieurs benches de code et d’agent. Chiffres vendeur, à prendre comme plafond en attendant des reproductions indépendantes — mais le signal pour l’IA locale est clair.

![Barres groupées : Qwen3.8-27B, Qwen3.6-27B et Claude Opus 4.6 Max sur six benchmarks officiels](https://tamsi.dev/blog/qwen-3-8-27b-benchmarks.png)

_Scores de la model card officielle (Qwen/Qwen3.8-27B). SWE-bench Pro et les benches coding utilisent le harness Claude Code._

## Caractéristiques

Le 27B est le dense compact de la génération Qwen3.8, construit sur l’archi Qwen3.5 : 64 couches, attention hybride (16 blocs Gated Attention, le reste en Gated DeltaNet linéaire), encodeur vision, Multi-Token Prediction. Apache 2.0, poids ouverts, pensé pour le déploiement — pas seulement pour une API cloud.

- 27B dense (≈28B avec la tour vision), 64 couches, hidden 5120, vocab 248 320.
- Contexte natif 262 144 tokens, extensible à 1 000 000 via YaRN.
- Multimodal natif : images et vidéo (docs, schémas STEM, vidéos longues).
- Thinking on by default, réglable via `reasoning_effort` (xhigh / medium / low) et `preserve_thinking`.
- Servi par vLLM 0.17+, SGLang, Transformers ≥ 5.8 ; quants communautaires MLX / GGUF / NVFP4 / FP8 dès le jour 0.

## Ce que disent les benches

Sur la carte officielle, le saut vs 3.6 est surtout agentique et coding. DeepSWE 1.1 passe de 13,3 à 42,2. QwenSWEBench de 49,3 à 79,0. SWE-bench Pro 61,7 vs 53,5 (et 53,4 pour Opus 4.6 Max, harness différent pour Opus). LiveCodeBench v6 90,3 vs 83,9. Côté vision / computer use : OSWorld-Verified 84,3 vs 63,9.

- Terminal-Bench 2.1 : 73,0 (3.6 : 63,4 — Opus : 78,2).
- SWE-bench Pro : 61,7 (3.6 : 53,5 — Opus : 53,4).
- LiveCodeBench v6 : 90,3 (3.6 : 83,9 — Opus : 88,8).
- CoWorkBench : 70,7 (3.6 : 61,0 — Opus : 68,2).
- IFBench : 79,5 (3.6 : 69,1 — Opus : 62,5).
- OSWorld-Verified : 84,3 (3.6 : 63,9 — Opus : 72,7).

Opus reste devant sur Terminal-Bench, GPQA Diamond (91,3 vs 89,2) et Humanity’s Last Exam. Le 27B n’est pas « mieux qu’Opus partout ». Il est assez proche, sur assez de tâches d’ingénierie, pour qu’un poids open de 27B change le calcul local vs API.

## Impact sur l’IA locale

Jusqu’ici, le local tenait surtout le volume : petits modèles, quants agressifs, tâches courtes. Le frontier agentique (gros diffs, computer use, boucles d’outils) restait facturé au token. Un 27B Apache qui affiche des scores de coding / SWE au niveau d’un Opus cloud, et qui tourne en FP8 sur une 48 Go ou en 4-bit sur laptop, déplace la frontière.

- Plus de licence à négocier, plus de quota qui coupe une session agent au milieu d’un refactor.
- 262k de contexte natif : un repo, pas un fichier, tient dans une fenêtre locale.
- Vision + computer use (OSWorld, WebArena, AndroidWorld) : le local n’est plus « texte only ».
- Quants jour 0 (Unsloth, MLX, GGUF, NVFP4) : le même poids va du Mac au serveur vLLM.
- Thinking contrôlable : tu paies le raisonnement seulement quand la tâche le justifie.

Ça ne tue pas les APIs. Ça rend défendable de garder le travail quotidien — revue, proto, MCP, Hermes — sur une machine que tu contrôles. Le 3.6 m’avait déjà poussé vers vLLM self-hosted ; le 3.8 rend ce choix moins « compromis qualité ».

## Un essai local

Je l’ai fait tourner en MLX 4-bit dans Unsloth Studio sur un MacBook M1 32 Go. Pas un bench : un Tetris HTML, ~11 tok/s, assez fluide pour itérer. Détail ici : x.com/tamsi_besson/status/2089656034449080484

## Bilan

Qwen 3.8 27B n’est pas un miracle de taille. C’est un dense open, multimodal, long-contexte, dont les scores officiels de coding et d’agent se rapprochent des flagships cloud. Pour l’IA locale, c’est le palier où « self-host un 27B » cesse d’être un hobby et devient une option d’ingénierie. Les reproductions indépendantes diront si les barres tiennent ; les poids, eux, sont déjà là.

- Model card : huggingface.co/Qwen/Qwen3.8-27B
- Essai local : x.com/tamsi_besson/status/2089656034449080484
- Studio : /blog/unsloth-studio
- Serveur 3.6 : /blog/qwen-3-6-27b-remote-server

---

# Unsloth Studio — faire tourner et entraîner des LLM en local

Studio, le Desktop et les kernels Unsloth : GGUF / MLX, fine-tune low-VRAM, Data Recipes — et pourquoi le GGUF Qwen3.8-27B tient en 17 Go.

Date: 2026-08-12
Tags: Unsloth, Local LLM, GGUF, Qwen, Fine-tuning
URL: https://tamsi.dev/blog/unsloth-studio

Mi-août, Unsloth a poussé un GGUF de Qwen3.8-27B. En moins de 24 heures : 1 000 likes, 3e modèle trending sur Hugging Face, 1 M de downloads. Leur phrase utile n’est pas le compteur — c’est « Run on 17GB RAM/VRAM setups via Unsloth ». Un 27B frontier-adjacent qui tient sur une machine que tu possèdes, c’est exactement le job de Studio.

![Annonce Unsloth : Qwen3.8-27B GGUF, 1000 likes en 24 h, exécutable en 17 Go via Unsloth](https://tamsi.dev/blog/unsloth-qwen38-gguf.jpg)

_UnslothAI — Qwen3.8-27B GGUF : 1 000 likes en 24 h, #3 trending, 1 M de downloads, 17 Go RAM/VRAM._

## Ce qu’est Unsloth

Unsloth (github.com/unslothai/unsloth) est d’abord une lib de training : kernels custom, ~2× plus vite, ~70 % de VRAM en moins vs le stack Transformers + PEFT, sans perte de qualité annoncée. Studio est l’UI locale par-dessus : une app Desktop (Mac, Windows, Linux) ou un `unsloth studio` dans le navigateur. Même moteur, plus de notebook.

- Inférence locale : GGUF, safetensors, MLX sur Mac, diffusion image/vidéo.
- Training no-code : 500+ modèles texte, vision, TTS, embeddings — QLoRA, LoRA, FP8, full.
- Data Recipes : PDF, CSV, JSON, DOCX, TXT → dataset (NVIDIA NeMo Data Designer).
- Export : GGUF, safetensors 16-bit, adaptateur LoRA — vers llama.cpp, Ollama, vLLM, LM Studio.
- Agents : endpoint OpenAI-compatible + `unsloth start` (Claude Code, Codex, Hermes, OpenCode).

## Pourquoi 17 Go changent le calcul

Le GGUF Unsloth de Qwen3.8-27B (huggingface.co/unsloth/Qwen3.8-27B-GGUF) est le cas d’école. Le même modèle en BF16 pèse ~55 Go. En quant Unsloth, il rentre dans 17 Go — RTX 4070, Mac 32 Go en MLX, petite instance cloud. Tu ne loues plus une H100 pour « juste essayer ». Tu charges, tu chats, tu compares, tu exportes.

- Pas besoin de fine-tuner pour s’en servir : Studio charge un GGUF et c’est tout.
- Tool calling self-healing, web search privé, exécution Bash/Python sandboxée.
- Arena : deux modèles / quants côte à côte dans la même UI.
- Offline : pas de télémétrie d’usage ; hardware minimal pour la compat.

## Le parcours Studio

La doc (unsloth.ai/docs/new/studio) décrit une boucle unique. Tu n’enchaînes plus Transformers, un quantizer, Ollama et un YAML.

- Lancer Desktop ou `unsloth studio` — chercher un modèle Hub ou un GGUF local.
- Optionnel : Data Recipes pour fabriquer le set à partir de tes fichiers.
- Fine-tune QLoRA (défaut low-VRAM) / LoRA / full, métriques et VRAM en temps réel.
- Comparer le checkpoint au baseline dans le chat.
- Exporter vers le runtime que tu as déjà.

## Installer

Desktop : unsloth.ai/download/mac (aussi Windows et Linux). CLI :

```bash
# macOS / Linux / WSL
curl -fsSL https://unsloth.ai/install.sh | sh

unsloth studio -H 0.0.0.0 -p 8888
# → http://127.0.0.1:8888

# Tunnel HTTPS Cloudflare (optionnel)
unsloth studio --secure
```

NVIDIA : training + inférence GPU. Mac : training, MLX et GGUF. CPU : chat et Data Recipes. Le training lourd reste côté GPU NVIDIA. Une fois un modèle chargé :

```bash
unsloth start hermes
# aussi : claude, codex, opencode, openclaw
```

## Dans mon stack

vLLM sur AWS garde l’agent quotidien. Studio est là où j’essaie un GGUF du jour — Qwen3.8-27B en 4-bit sur le M1, par exemple — et où je fine-tunerais un corpus qui ne doit pas sortir de la machine. Détail sur le 27B : /blog/qwen-3-8-27b

## Bilan

Unsloth n’est plus seulement une lib de LoRA rapide. Studio en fait l’endroit où tu cours, compares et exportes les modèles open du moment — y compris un 27B qui rentre en 17 Go. Le tweet Qwen3.8 n’est pas du marketing vide : c’est la preuve que le local a rattrapé le rythme des sorties.

- Doc Studio : unsloth.ai/docs/new/studio
- Repo : github.com/unslothai/unsloth
- GGUF Qwen3.8-27B : huggingface.co/unsloth/Qwen3.8-27B-GGUF
- Annonce : x.com/UnslothAI/status/2088627177655050362
- Qwen 3.8 27B : /blog/qwen-3-8-27b

---

# HuggiMon — ta carte de dresseur IA depuis ton profil Hugging Face

Un site Next.js qui transforme l’activité publique du Hub en carte Pokémon TCG interactive — holo shaders, binder de followers, PNG et page partageable.

Date: 2026-07-09
Tags: Hugging Face, Next.js, Open source, Side project
URL: https://tamsi.dev/blog/huggimon-ai-trainer-card

Sur Hugging Face, ton profil public raconte déjà une histoire : les modèles que tu publies, les Spaces que tu maintiens, les datasets que tu partages, les likes et les téléchargements qui s’accumulent. **HuggiMon** ([huggimon.co](https://huggimon.co)) prend ces signaux — uniquement des données publiques — et les convertit en **carte de dresseur IA** façon Pokémon TCG : tilt 3D, shaders holo, binder de followers, page dédiée par username.

## Pourquoi ce projet

Le Hub est excellent pour héberger du ML, moins pour « montrer qui tu es » en un coup d’œil. Les README listent des repos ; les stats sont dispersées entre models, datasets et spaces. J’avais envie d’un résumé ludique — pas un leaderboard sérieux, mais une carte que tu peux ouvrir sur `huggimon.co/ton-username`, partager sur X, ou coller dans ton README Hub.

- Zéro auth : un username suffit, tout est lu via l’API publique Hugging Face.
- Carte interactive avec 14 paliers holo selon ton niveau HF.
- Binder 3×3 : tes followers deviennent des mini-cartes à feuilleter.
- PNG téléchargeable + snippet Markdown pour ton README.

## Comment ça marche

Le flux est linéaire : fetch → score → render. Tu ouvres `/{username}` ; HuggiMon récupère l’overview utilisateur et les repos publics (modèles, datasets, spaces). Un module de scoring calcule six stats (0–100), déduit un type, une rareté, un niveau, des attaques et une énergie (basée sur les likes). Le rendu côté client repose sur les shaders holo de [pokemon-cards-css](https://github.com/simeydotme/pokemon-cards-css) ; le serveur compose le visage de la carte en PNG 660×921.

```text
/{username} → hf-fetcher → scoring → PokemonCard (holo + tilt)
                      ↳ /api/card/{username}/face → PNG partageable
```

### Les six stats

- **MODEL** — modèles publiés, likes et downloads.
- **DATA** — datasets et leur traction.
- **SPACE** — Spaces publiés et likes associés.
- **IMPACT** — likes + downloads agrégés sur tout le travail public.
- **COMMUNITY** — followers et discussions.
- **DOCS** — part des repos avec une description.

### Holo, énergie et binder

Ton niveau HF détermine un **palier holo** parmi 14 (reverse holo → Secret Gold). Les likes sur ton travail deviennent des **énergies** sur la carte. Tes **followers** remplissent un binder paginé 3×3 avec animation de feuilletage — clique sur une mini-carte pour l’inspecter en grand.

## Partager et intégrer

Chaque profil a une URL publique et un snippet README prêt à coller :

```markdown
[![HuggiMon](https://huggimon.co/api/card/ImTamsi/face)](https://huggimon.co/ImTamsi)
```

- `GET /{username}` — page profil (carte + binder + partage).
- `GET /api/card/{username}` — métadonnées JSON (stats, type, rareté, énergie).
- `GET /api/card/{username}/face` — PNG composé 660×921.
- `GET /api/binder/{username}` — page binder des followers (`?page=` optionnel).

## Stack technique

- **Next.js** — app dans `web/`, déployée sur Vercel ([huggimon.co](https://huggimon.co)).
- **pokemon-cards-css** — effets holo 3D (tilt, glare, shaders par rareté), port React via `@react-spring/web`.
- **gitfut** — inspiration pour le pattern `/{username}` et l’embed README (appliqué au Hub HF plutôt qu’à GitHub).
- **MIT** — code ouvert sur [github.com/Tamsi/huggimon](https://github.com/Tamsi/huggimon).

## Essayer

Va sur [huggimon.co](https://huggimon.co), entre un @username HF, ou ouvre directement [huggimon.co/ImTamsi](https://huggimon.co/ImTamsi). C’est un side project du Build Small Hackathon : fun d’abord, mais le scoring est transparent — le repo est sur GitHub si tu veux challenger la formule ou contribuer.

- Site : huggimon.co
- Repo : github.com/Tamsi/huggimon

---

# Unsloth Studio en live HF — entraîner et faire tourner des LLM en local, sans cloud

Notes sur la session Hugging Face avec Daniel Hanchen (UnslothAI) : Studio, quants dynamiques, benchmarks et fine-tuning low-VRAM sur Mac/Windows/Linux.

Date: 2026-06-27
Tags: Unsloth, Hugging Face, Fine-tuning, GGUF, Local LLM
URL: https://tamsi.dev/blog/unsloth-studio-hf-live-daniel-hanchen

J’ai suivi la session live Hugging Face avec Daniel Hanchen (UnslothAI) autour d’Unsloth Studio. Le pitch est simple : une interface web open-source pour entraîner, exécuter et exporter des modèles open (Gemma, Qwen, DeepSeek, etc.) entièrement en local — Mac, Windows ou Linux — sans passer par un cloud GPU à la minute.

![Capture de la démo Unsloth Studio pendant le live Hugging Face avec Daniel Hanchen](https://tamsi.dev/blog/unsloth-studio-hf-live.png)

_Unsloth Studio — démo live Hugging Face (Daniel Hanchen, UnslothAI)._

## Pourquoi ça m’intéresse

Mon stack tourne déjà autour du local et du self-hosted : Qwen en vLLM sur AWS pour l’agent lourd, Ollama pour le léger, GGUF partout où je peux. Ce qui manquait souvent, c’est la couche « atelier » : préparer un dataset, lancer un fine-tune, comparer des quants, exporter vers Ollama ou llama.cpp — sans enchaîner cinq outils et dix fichiers YAML. Studio vise exactement ce workflow unifié, dans le navigateur, sur la machine.

## Ce qu’est Unsloth Studio

Unsloth Studio (beta) est l’UI web du projet Unsloth : no-code pour l’essentiel, mais branchée sur les kernels Unsloth qui promettent ~2× plus vite et ~70 % de VRAM en moins sur le fine-tuning, avec des benchmarks officiels (dont vérification Hugging Face) qui montrent des gains réels en vitesse et mémoire par rapport au stack Hugging Face + PEFT classique.

- Chat et inférence locale : GGUF et safetensors, llama.cpp + Hugging Face, multi-GPU et offload automatique.
- Fine-tuning : 500+ modèles texte, vision, audio/TTS, embeddings — LoRA, FP8, full fine-tune selon le cas.
- Data Recipes : PDF, CSV, DOCX, JSON → datasets synthétiques sans tout coder à la main.
- Export : safetensors 16-bit, GGUF (2-bit et au-delà) pour Ollama, LM Studio, vLLM, etc.
- Comparaison côte à côte de modèles / quants dans la même UI.

## Quants dynamiques et benchmarks

Une partie centrale du live : la quantification dynamique — pas seulement du 4-bit « par défaut », mais des quants agressifs (2-bit, GGUF) avec des courbes de qualité / vitesse / VRAM présentées sur des benchmarks officiels. L’idée n’est pas « compresse à tout prix », mais choisir le bon compromis pour ton hardware : un 27B qui ne tient pas en FP16 peut devenir utilisable en inférence locale ou en fine-tune LoRA sur une seule carte consommateur.

Daniel insiste sur la reproductibilité : les chiffres ne viennent pas d’un tweet, ils sont documentés et comparés au baseline HF. Pour quelqu’un qui hésite entre AWQ, GPTQ, GGUF Q4_K_M ou plus bas, la démo de comparaison dans Studio évite des heures de tests manuels.

## Démo live : chargement, inférence, fine-tuning

La session enchaîne des exemples concrets : recherche et téléchargement d’un modèle, lancement du chat avec réglages d’inférence auto (température, top-p, templates), exécution de code en sandbox (Bash + Python) et tool calling « self-healing ». On voit aussi le parcours training — upload de docs, graphe de Data Recipe, lancement d’un fine-tune optimisé VRAM — puis export GGUF pour repartir en offline pur.

```bash
# Lancer Studio en local (doc officielle)
unsloth studio -p 8888
# → http://127.0.0.1:8888
```

### Plateformes

- NVIDIA (RTX 30/40/50, Blackwell…) : training + inférence GPU.
- macOS : training, MLX et inférence GGUF — aligné avec ma config laptop.
- CPU seul : chat + Data Recipes ; le training lourd reste côté GPU NVIDIA pour l’instant.
- AMD : chat OK ; training Studio annoncé prochainement (Unsloth Core déjà utilisable).

## Discussion avec l’hôte HF

La fin du live repasse en visio avec l’hôte Hugging Face : partenariat HF × NVIDIA, feuille de route multi-GPU et MLX sur Apple Silicon, et surtout la philosophie produit — rendre l’open-source AI aussi simple qu’une app SaaS, mais sans envoyer tes poids et tes données ailleurs. C’est le même fil que mes articles sur Qwen self-hosted : contrôle, coût maîtrisé, offline quand tu en as besoin.

## Bilan

Unsloth Studio ne remplace pas Cursor ni mon endpoint vLLM pour l’agent quotidien. En revanche, pour tout ce qui est « je veux adapter un Qwen/Gemma à mon cas, le quantifier proprement et le servir en local », c’est aujourd’hui l’une des interfaces les plus complètes — surtout si tu veux éviter le cloud training à la carte. Je garde la vidéo sous la main comme référence ; la doc et le repo Unsloth pour l’installation.

- Article atelier : /blog/unsloth-studio
- Doc Studio : unsloth.ai/docs/new/studio
- Repo : github.com/unslothai/unsloth
- Annonce HF : post Daniel Hanchen sur le Hub

---

# Pourquoi je passe sur Hermes — automatiser avec des modèles moins chers

Fable 5 vient de sortir et flambe sur le benchmark Cursor : je déporte l’agentique vers Hermes et des modèles abordables.

Date: 2026-06-09
Tags: Hermes, Cursor, Coût, Automation
URL: https://tamsi.dev/blog/hermes-automation-cheaper-models

J’aime Cursor comme IDE. En revanche, la facture agentique devient difficile à défendre : chaque session longue, chaque refactor, chaque boucle MCP coûte cher — surtout quand Anthropic sort Fable 5 et que Cursor le met en avant comme modèle par défaut haut de gamme.

## Fable 5 : très bon, très cher

Le graphique CursorBench 3.1 est parlant : Fable 5 high (default) est en haut à gauche — meilleur score (~71 %), mais autour de 12 $ par tâche. Composer 2.5 ou GPT-5.5 medium font ~60 % pour 1 à 3 $. Sur une journée de dev, la différence n’est pas théorique.

![CursorBench 3.1 : score vs coût par tâche — Fable 5 high en haut à gauche, modèles moins chers à droite](https://tamsi.dev/blog/cursorbench-fable5-cost.png)

_CursorBench 3.1 — performance vs coût moyen par tâche (axe X inversé : moins cher à droite)._

## Pourquoi Hermes entre dans la boucle

Hermes Agent (Nous Research) n’est pas un remplacement de Cursor — c’est la couche qui automatise en dehors de l’IDE : skills persistantes, mémoire, webhooks, tâches récurrentes. Je l’utilise pour ce qui doit tourner sans cliquer « Continue » toutes les deux minutes, branché sur des modèles que je contrôle (Qwen en vLLM sur AWS, Ollama en local) plutôt que sur Fable 5 à chaque prompt.

- Tâches répétitives (veille repo, checks API, scripts de validation) → Hermes + petit modèle.
- Sessions agent lourdes dans Cursor → mon endpoint Qwen, pas le modèle premium intégré.
- MCP pour le métier (redbee, code review) → même stack OpenAI-compatible, coût GPU fixe.
- Hermes pour enchaîner plusieurs outils sans payer la taxe « modèle flagship » à chaque étape.

## En pratique

Cursor reste mon éditeur. Hermes prend les workflows qui doivent vivre plus longtemps qu’un chat : pipelines, rappels, intégrations Firebase/Slack, skills apprises une fois et réutilisées. Le déclencheur aujourd’hui, c’est Fable 5 : excellent benchmark, prix qui pousse à sortir l’intelligence agentique des modèles les plus chers du marketplace Cursor.

## Bilan

Ce n’est pas « anti-Cursor » ni « anti-Anthropic ». C’est : utiliser le bon modèle au bon endroit. Flagship dans Cursor pour un coup ponctuel si besoin ; Hermes + modèles cheap pour l’automatisation du quotidien. Mon portefeuille tokens remercie, et je garde la main sur la stack.

---

# Pourquoi j’ai monté un serveur Qwen 3.6 27B plutôt que de payer Cursor

Des tokens gratuits plutôt que les modèles Cursor — Qwen 3.6 27B servi en vLLM sur AWS (4 bits), Ollama en local pour git-mentor.

Date: 2026-06-01
Tags: LLM, Qwen, AWS, vLLM, Cursor
URL: https://tamsi.dev/blog/qwen-3-6-27b-remote-server

Cursor est un excellent IDE agentique. En revanche, les modèles qu’il propose en natif m’ont vite frustré : quotas, facturation au token, sessions agent qui s’arrêtent au pire moment, et une qualité/prix difficile à justifier quand on enchaîne les revues de code, les refactors et les essais MCP toute la journée.

## Le vrai problème

Ce n’était pas « je veux héberger un LLM pour le plaisir ». C’était : je veux utiliser l’agent sans regarder la jauge de tokens toutes les dix minutes. Mes projets (MCP, prototypes Gradio, gros diffs GitHub) consomment beaucoup de contexte. Payer Cursor pour chaque itération, c’est acceptable une fois de temps en temps — pas en boucle sur du travail perso et open source.

## Ce que le serveur distant m’apporte

- Tokens gratuits côté inférence : je paie le GPU à l’heure, pas chaque prompt. Je peux relancer l’agent dix fois sur le même bug sans culpabiliser.
- Un Qwen 3.6 27B branché en API OpenAI-compatible — Cursor, mes serveurs MCP et mes scripts parlent au même endpoint.
- Même workflow qu’avant dans l’IDE ; seul le modèle change. Pas besoin de quitter Cursor.
- Indépendance : si demain les tarifs ou les limites bougent encore, mon stack reste le mien.

## Comment c’est monté (en bref)

Instance GPU sur AWS (48 Go VRAM), vLLM pour servir Qwen 3.6 27B, reverse proxy en TLS + token Bearer devant. vLLM expose l’API OpenAI-compatible (`/v1/chat/completions`) — Cursor, ai-code-reviewer-mcp et redbee-mcp pointent tous vers ce endpoint avec les mêmes `OPENAI_API_BASE` / `OPENAI_API_KEY`.

### Pourquoi vLLM sur AWS (et pas Ollama ici)

Pour un 27B en prod agent — gros contexte, requêtes parallèles, uptime — vLLM est plus adapté : throughput, batching, API stable. Ollama brille ailleurs (voir git-mentor ci-dessous). Sur AWS je lance le modèle quantifié une fois ; je paie l’instance GPU, pas les tokens Cursor.

### Pourquoi du 4 bits (AWQ / GPTQ)

Un 27B en FP16 demande ~54 Go de VRAM — hors budget sur une seule carte « classique ». En quantification 4 bits (AWQ ou GPTQ, le format que vLLM charge nativement), le poids tombe autour de 16 Go : le modèle tient sur le GPU avec de la marge pour le contexte long et plusieurs requêtes agent. On perd un peu de finesse vs le full precision, mais pour du code review, du refactor et des appels MCP, la différence est rarement bloquante — surtout comparée au coût d’un gros modèle cloud facturé au token.

- FP16 : meilleure qualité, VRAM ×3 — utile si tu as 80 Go+ ou plusieurs GPUs.
- AWQ / GPTQ 4 bits : bon compromis qualité / prix / latence pour vLLM au quotidien.
- Q8 : milieu si tu veux gratter un peu de qualité sans doubler la facture EC2.

```bash
# Sur l'instance AWS (exemple vLLM + poids AWQ)
vllm serve Qwen/Qwen3-27B-Instruct-AWQ \
  --quantization awq \
  --host 127.0.0.1 --port 8000

# Côté Cursor / MCP (via le proxy TLS)
OPENAI_API_BASE=https://llm.example.com/v1
OPENAI_API_KEY=<token-proxy>
OPENAI_MODEL=Qwen/Qwen3-27B-Instruct-AWQ
```

### Ollama en local pour git-mentor

git-mentor, c’est un autre cas d’usage : analyse de profil GitHub avec un PAT qui ne doit pas transiter par un serveur distant si je peux l’éviter, sessions courtes, modèle plus petit suffisant. Là j’utilise Ollama sur ma machine — zéro coût cloud, offline possible, `localhost:11434/v1`. Le gros Qwen AWS reste pour Cursor et les MCP ; git-mentor reste local-first par design.

```bash
# Mac / laptop — git-mentor en local
ollama run llama3.2

export OPENAI_API_BASE=http://localhost:11434/v1
export OPENAI_API_KEY=ollama
git-mentor analyze --user Tamsi
```

## Le bilan

Deux stacks complémentaires : vLLM sur AWS pour l’agent « à fond » (tokens gratuits côté inférence), Ollama en local pour git-mentor. Le setup AWS m’a pris une après-midi ; le gain, c’est surtout mental et économique. Cursor reste mon interface ; le cerveau lourd tourne chez moi sur GPU, le cerveau léger sur le laptop. Suite : Qwen 3.8 27B — /blog/qwen-3-8-27b.

---

# Pourquoi un MCP de revue de code — et pas seulement le chat Cursor

Donner à l’agent des actions concrètes sur GitHub plutôt qu’un gros prompt « regarde mon repo ».

Date: 2026-05-15
Tags: MCP, Code review, GitHub
URL: https://tamsi.dev/blog/ai-code-reviewer-mcp

Demander à Cursor « fais une code review » sur un gros diff, c’est pratique une fois. En répétition — PRs open source, projets clients, mes propres repos — tu veux quelque chose de reproductible : mêmes axes (bugs, sécurité, tests manquants), mêmes sorties, sans re-expliquer le contexte à chaque session.

## L’intérêt du MCP ici

ai-code-reviewer-mcp n’est pas une « meilleure prompt engineering ». C’est exposer des outils : lire le diff, cibler un fichier, formuler un commentaire PR. L’agent choisit les étapes ; moi je contrôle ce qu’il a le droit de toucher. Ça évite les reviews vague-du-vendredi et ça s’accroche au modèle distant (tokens gratuits) dont je parle dans l’autre article.

## Pourquoi c’est utile pour moi

- Open source : feedback structuré avant de merge, sans ouvrir cinq onglets.
- Même logique branchée sur mon Qwen distant (vLLM sur AWS) — pas de surcoût Cursor par review.
- Démo Gradio sur Hugging Face pour montrer le concept sans installer MCP.
- Template pour d’autres intégrations « l’AI agit sur un vrai système ».

## Comment c’est monté (en bref)

Serveur MCP TypeScript (stdio) + Octokit pour GitHub + client OpenAI-compatible branché sur le Qwen servi en vLLM sur AWS. Les outils découpent la review : lister les fichiers du diff, récupérer un hunk, analyser avec un prompt ciblé (bug / sécurité / dette / tests).

- `list_changed_files` / `get_file_diff` — contexte minimal, pas le repo entier.
- `analyze_snippet` — un focus à la fois, sortie JSON structurée.
- Même stack LLM que Cursor (base URL custom) → tokens gratuits, pas de double facturation.
- Space Gradio sur Hugging Face : même moteur d’analyse, sans couche MCP, pour démo publique.

```typescript
// Un outil = une responsabilité
server.tool('analyze_snippet', { path, diffHunk, focus }, async (input) => {
  const findings = await llmReview(input) // → vLLM AWS
  return { content: [{ type: 'text', text: JSON.stringify(findings) }] }
})
```

## En bref

Je n’ai pas construit ça pour remplacer un humain en review finale. Je l’ai construit pour automatiser la première passe — celle que personne n’a envie de refaire à la main — et pour prouver que MCP + LLM self-hosted, c’est un combo crédible en dehors des demos Twitter.

---

# redbee-mcp : tester les APIs OTT au quotidien avec mon AI

Monté très vite quand MCP est sorti — pour que Cursor appelle les vraies APIs Red Bee Media dont j’ai besoin au travail.

Date: 2026-05-01
Tags: MCP, Red Bee, API, Travail
URL: https://tamsi.dev/blog/redbee-mcp

Quand le Model Context Protocol est arrivé, l’intérêt m’a paru évident : enfin un moyen standard de brancher l’IDE sur des outils réels, pas seulement sur le code du repo. Je travaille avec les APIs Red Bee Media (OTT, streaming). Doc, Postman, copier-coller de tokens — ça fonctionne, mais ça casse le flow quand tu veux juste vérifier un endpoint pendant une feature.

## Pourquoi je l’ai fait si vite

Pas pour publier un projet GitHub stylé. Parce que le jour où MCP est devenu utilisable dans Cursor, j’ai vu le cas d’usage immédiat : « demain matin, je veux demander à l’agent de lister les assets, lancer un playback test, ou debug une réponse 403 » sans quitter la conversation. redbee-mcp, c’est ce pont — Python, quelques outils MCP, les endpoints que j’utilise déjà en prod chez des clients.

## Ce que ça change au quotidien

- L’AI ne devine plus la forme des APIs : elle les appelle, voit la vraie réponse JSON, adapte le code ensuite.
- Moins de aller-retour doc ↔ IDE ↔ Postman ; surtout sur des plateformes avec beaucoup de surfaces (catalogue, DRM, analytics…).
- Tests exploratoires en langage naturel : « essaie cette série avec tel customer token » — utile en debug, pas seulement en démo.
- Base réutilisable : même pattern pour d’autres APIs métier derrière MCP.

## Comment c’est monté (en bref)

Serveur MCP Python en stdio — le pattern le plus simple pour Cursor. Chaque outil correspond à un appel HTTP que je faisais déjà à la main : catalogue, métadonnées asset, session playback, etc. Les credentials restent en variables d’environnement côté serveur ; l’agent ne voit que les réponses JSON.

- SDK MCP Python + `httpx` pour les requêtes Red Bee.
- Un outil = un endpoint documenté (params typés, erreurs remontées telles quelles).
- Config dans `.cursor/mcp.json` : commande `uv run` ou `python -m redbee_mcp`.
- Première version en quelques heures : copier les headers auth existants, pas réinventer l’API.

```json
{
  "mcpServers": {
    "redbee": {
      "command": "uv",
      "args": ["run", "redbee-mcp"],
      "env": {
        "REDBEE_BASE_URL": "https://…",
        "REDBEE_API_KEY": "…"
      }
    }
  }
}
```

## L’idée à retenir

MCP n’est pas qu’un buzzword open source. Pour moi c’était le premier protocole où ça valait le coup de coder un serveur en urgence parce que le ROI était visible le lundi suivant. redbee-mcp est modeste en taille ; l’intérêt, c’est le temps gagné à chaque sprint quand l’agent parle enfin la langue de la plateforme sur laquelle je facture.