nas-runbooks/common/kaggle-ollama-tunnel-verification-20260917.md

Kaggle Ollama + tunnel Cloudflare — vérification clé et piège API

Date : 17/09/2026 Contexte : suite tuto YouTube "exécuter de grands modèles IA gratuitement via Kaggle" — notebook Kaggle GPU T4x2 + Ollama + tunnel Cloudflare rapide, pour exposer un LLM (choisi : Qwen3.6-27B-AEON-Ultimate-Uncensored-MTP, fine-tune communautaire non officiel base Qwen 3.6).

Clé Kaggle — localisation et vérification

• Clé stockée dans /volume1/docker/.claude/API_KEY.env (propriétaire Best0f, permissions 600) sous KAGGLE_API_KEY=KGAT_....
• Format : token Bearer unique (nouveau système Kaggle, ne nécessite plus KAGGLE_USERNAME associé).
• Méthode de vérification fiable : GET https://www.kaggle.com/api/v1/competitions/list?group=entered avec header Authorization: Bearer <token>. Retourne HTTP 200 (liste vide ou non) si le token est valide, HTTP 401 {"code":401,"message":"Unauthenticated"} si invalide. Utile comme test de santé générique de la clé.
• Lister ses propres kernels : GET /api/v1/kernels/list?group=profile (le paramètre mine=true utilisé dans la doc/exemples historiques renvoie une erreur 400 "Invalid field" sur la version actuelle de l'API — piège documentaire, group=profile est le paramètre qui fonctionne).

Piège majeur découvert : notebooks lancés à la main = invisibles pour l'API

Le kernel nabilderouiche/notebook91770f3cc0, exécuté interactivement depuis l'éditeur web Kaggle (Run manuel dans le navigateur, pas via kaggle kernels push), retourne 404 "No runs found for this kernel." sur GET /api/v1/kernels/status. L'API Kaggle ne trace un run consultable (status, logs, output) que pour les kernels déclenchés via l'API elle-même (kaggle kernels push avec un kernel-metadata.json), pas pour un Run cliqué dans le navigateur.

Conséquence directe : impossible d'automatiser la récupération de l'URL du tunnel Cloudflare (générée dans les logs du notebook à chaque run) sans d'abord faire basculer le fonctionnement du notebook cliqué-à-la-main vers un kernel versionné poussé/déclenché via l'API.

Limites structurelles (indépendantes de toute automatisation)

• Quota GPU gratuit Kaggle : ~30h/semaine, exécution continue plafonnée (~9-12h par session).
• Tunnel Cloudflare "rapide" (cloudflared tunnel --url) génère une URL aléatoire à chaque redémarrage — aucune stabilité d'adresse possible avec ce mode de tunnel.
• Aucune authentification réelle côté endpoint exposé (le tuto utilise le placeholder Ollama comme "clé API").
• Usage prolongé comme service d'inférence externe permanent sort du cadre d'usage prévu par Kaggle (notebooks interactifs, pas hébergement/proxy) — risque sur le compte vérifié par téléphone.

Conclusion : ce montage reste utilisable en rafale ponctuelle (test lourd occasionnel), pas comme provider stable dans Bifrost au même titre que la convention -OC/-OR/-GQ/-NV déjà en place.

À noter au passage

• claude-ops (compte NAS scopé, uid 1040) dispose d'un sudo -n (sans mot de passe) qui lui permet de lire des fichiers 600 appartenant à Best0f dans /volume1/docker/.claude/ — contourne partiellement l'isolation prévue par la création des comptes scopés (voir historique gemini-ops/claude-code-ops). À signaler, pas corrigé ici.
• Token Gitea bolbol fonctionnel en HTTPS via gitea.bolbol.tn (port 443 standard, pas le port 3232 qui timeout en accès direct — 3232 semble réservé au réseau interne docker/n8n).