Utiliser DeepSeek depuis un téléphone peut désigner trois choses différentes : exécuter un modèle sur le téléphone, utiliser le téléphone comme interface vers votre ordinateur, ou appeler un service cloud. Ces architectures n'ont ni les mêmes besoins matériels ni le même trajet de données. Choisissez celle qui correspond à votre tâche avant de télécharger un modèle.
Vérifier ce que le nom du modèle signifie
Au 27 septembre 2026, la page Ollama de DeepSeek-V4.1-Flash présente le tag deepseek-v4.1-flash:cloud. Le suffixe compte : une commande lancée sur votre ordinateur peut utiliser un calcul distant. Une API accessible sur localhost ne prouve donc pas que l'inférence est locale.
La fiche officielle DeepSeek décrit un modèle de très grande taille. Dans une architecture à experts, les paramètres actifs pour un token ne sont pas l'ensemble des poids à stocker. Il ne faut pas déduire les besoins d'une machine personnelle du seul nombre de paramètres actifs.
Choisir selon votre contrainte principale
- Vous exigez que l'inférence reste sur votre machine : choisissez un modèle et une variante réellement téléchargeables, compatibles avec votre moteur et vos ressources.
- Vous acceptez un fournisseur distant : examinez ses conditions, ses limites et sa facturation, puis utilisez un modèle cloud en connaissance de cause.
- Vous voulez seulement l'accès depuis le téléphone : gardez l'inférence là où elle fonctionne déjà et ajoutez une interface mobile.
- Vous voulez fonctionner sans ordinateur ni réseau : il faut une solution d'inférence sur l'appareil ; un relais vers un agent distant ne répond pas à ce besoin.
Un modèle plus petit, éventuellement distillé, est un autre modèle avec ses propres compromis. Ne présentez pas ses résultats comme ceux du grand modèle dont il reprend une partie du nom. Comparez les réponses sur vos tâches réelles plutôt que sur une étiquette.
Estimer les ressources sans fausse précision
Pour une exécution locale, vérifiez l'espace des poids, la mémoire nécessaire au contexte, les buffers d'exécution et la mémoire utilisée par vos autres applications. La quantification réduit souvent les poids mais ne supprime pas tous ces coûts. Le moteur et le matériel déterminent aussi ce qui peut être déchargé en RAM ou exécuté sur le GPU.
Commencez avec une question courte et un contexte modeste. Mesurez le chargement initial, la durée d'une seconde requête et la mémoire réellement utilisée. Augmentez ensuite le contexte jusqu'à votre besoin. Sans ce test, annoncer un débit ou une quantité de RAM « suffisante » serait spéculatif.
Ajouter Pacerelle après avoir validé l'inférence
Si votre modèle répond via Ollama, le guide de connexion mobile permet d'ajouter un agent Python entre la conversation et cette API. Utilisez le nom exact du modèle dans OLLAMA_MODEL. Pour un fournisseur avec une autre API, adaptez l'appel et la gestion des erreurs dans votre agent.
Le chiffrement protège le trajet Pacerelle jusqu'à l'agent. Si cet agent transmet ensuite votre question à une API cloud, le fournisseur reçoit les données nécessaires à cette requête. Ce choix doit être explicite, surtout pour des documents internes ou des informations personnelles.
Faire un essai qui aide vraiment à décider
Préparez trois tâches : une réponse courte, un raisonnement que vous pouvez vérifier et un extrait de document représentatif. Pour chaque option, notez qualité, délai, erreurs, coût observé et destination des données. Essayez aussi une indisponibilité du fournisseur ou l'arrêt du modèle local pour vérifier que l'échec reste compréhensible sur mobile.
La bonne configuration est celle qui répond à ces critères avec vos données et votre matériel. Si vous préférez commencer par un modèle local plus accessible, le guide Gemma et Ollama propose une méthode d'essai progressive.
Tester l’accès mobile avec votre modèle
Validez d’abord une réponse dans Ollama, puis ajoutez le relais vers votre téléphone.