runbook: automatisation complete kaggle-qwen (push API + tunnel nomme + 3 pieges corriges)
This commit is contained in:
@@ -0,0 +1,31 @@
|
||||
# Kaggle Qwen — automatisation complète via l'API (push de kernel) et tunnel Cloudflare nommé
|
||||
|
||||
**Date** : 17/09/2026
|
||||
**Contexte** : suite du runbook `kaggle-ollama-tunnel-verification-20260917.md`. Objectif : rendre le montage Kaggle GPU + Ollama + tunnel entièrement automatisé (pas de clic dans le notebook), avec une adresse publique stable, et complètement séparé de Bifrost (Qwen coûte plus cher que Mimo dans le forfait OpenCode Go de Nabil).
|
||||
|
||||
## Tunnel Cloudflare nommé (remplace le tunnel rapide à URL aléatoire)
|
||||
Créé via l'API Cloudflare (Global API Key + email du compte, zone yesminedor.tn — bolbol.tn n'est pas dans ce compte Cloudflare) :
|
||||
- Tunnel nommé `kaggle-qwen-tunnel` (id `bb09176f-a0cf-4e3f-ac07-81cb2e7e46c5`), `config_src: cloudflare` (configuration à distance, pas de fichier config.yml côté Kaggle)
|
||||
- Hostname fixe : `kaggle-qwen.yesminedor.tn`, CNAME proxied vers `<tunnel_id>.cfargotunnel.com`
|
||||
- Token de connexion stocké dans `/volume1/docker/.claude/API_KEY.env` (`CF_TUNNEL_TOKEN`)
|
||||
- Ingress : `{hostname: kaggle-qwen.yesminedor.tn, service: http://localhost:11434, originRequest: {httpHostHeader: "localhost:11434"}}`
|
||||
|
||||
## Automatisation Kaggle : push de kernel via l'API (pas de notebook manuel)
|
||||
`POST /api/v1/kernels/push` (auth `Authorization: Bearer <KAGGLE_API_KEY>`) avec un script Python (`kernelType: script`, `enableGpu: true`, `enableInternet: true`, `isPrivate: true`) qui installe et lance tout, puis boucle ~11h pour garder la session active (marge sous le plafond ~12h GPU de Kaggle). Kernel : `nabilderouiche/kaggle-qwen-runner-auto`.
|
||||
|
||||
**Avantage clé découvert** : un kernel poussé via l'API est enfin traçable (`/kernels/status`, `/kernels/output`), contrairement au notebook cliqué à la main du runbook précédent — mais **`/kernels/output` ne renvoie les logs qu'une fois le run terminé, pas en direct pendant qu'il tourne**. Pour déboguer un run encore actif, interroger directement l'endpoint public exposé (le tunnel) plutôt que d'attendre les logs.
|
||||
|
||||
## Trois pièges réels rencontrés et corrigés (dans l'ordre)
|
||||
|
||||
**1. `ollama install.sh` échoue sur l'image Kaggle : `zstd` manquant.** L'image de base Kaggle n'a ni `zstd` ni `pciutils` (ce dernier utile pour l'auto-détection GPU par le script d'install). Fix : `apt-get install -y zstd pciutils` avant l'install Ollama.
|
||||
|
||||
**2. `ollama pull hf.co/<repo>` échoue : `realm host "huggingface.co" does not match original host "hf.co"`.** Bug de redirection dans le pont Ollama↔HuggingFace sur cette version/cet environnement — le modèle `orcarouter/Qwen3.8-27B-Uncensored-GGUF` initialement visé n'a jamais pu être tiré par ce chemin. Fix : utiliser un modèle publié nativement sur le registre Ollama (pas via le pont hf.co), qui pull sans ce problème. Modèle finalement retenu : `huihui_ai/qwen3.5-abliterated:27b` (huihui-ai = référence établie et fiable pour l'abliteration, "27b" disponible directement dans son namespace Ollama officiel).
|
||||
|
||||
**3. Le tunnel se connecte (confirmé "healthy" côté API Cloudflare) mais toute requête renvoie 403 vide.** Cause : Ollama rejette par défaut les requêtes dont le header `Host` n'est pas `localhost`/`127.0.0.1` (protection anti-DNS-rebinding), ce qui est exactement le cas derrière un tunnel avec un vrai nom de domaine public. **`OLLAMA_ORIGINS=*` ne corrige PAS ce problème** (ça ne gouverne que le CORS `Origin`, pas le `Host`) malgré ce que suggèrent beaucoup de guides communautaires. Le vrai fix, sans toucher au script Kaggle ni à Ollama : réécrire le header `Host` au niveau du tunnel lui-même, via `originRequest.httpHostHeader: "localhost:11434"` dans la config d'ingress Cloudflare (`PUT /accounts/{id}/cfd_tunnel/{tunnel_id}/configurations`).
|
||||
|
||||
## État final vérifié
|
||||
`https://kaggle-qwen.yesminedor.tn/v1/models` et `/v1/chat/completions` répondent correctement (testé en direct, réponse française correcte). Débit observé : environ 2,5 tokens/s pour un modèle 27B en Q4 — probablement lié à l'allocation d'un seul GPU T4 (16 Go) via l'API de push, plutôt que le T4x2 (32 Go cumulés) sélectionnable manuellement dans l'éditeur web Kaggle. Utilisable mais pas rapide.
|
||||
|
||||
## Non résolu / limites connues
|
||||
- Le kernel doit être repoussé manuellement (ou via cron à construire) toutes les ~11h pour rester dans le plafond de session Kaggle ; pas d'automatisation de relance périodique en place à ce stade.
|
||||
- Pas de bascule automatique si le tunnel tombe en dehors des heures d'exécution du kernel (aucun repli configuré, assumé volontairement puisque ce montage est hors Bifrost).
|
||||
Reference in New Issue
Block a user