- Configurar la API Key de DeepSeek y elegir modelo.
- Comparar V4-Flash y V4-Pro por tarea, coste y latencia.
- Añadir otros proveedores solo cuando aporten una ventaja clara.
DeepSeek primero
Empieza con el proveedor oficial de DeepSeek porque es el camino que el tutorial evalúa. En Settings -> Models pega la API Key de platform.deepseek.com y selecciona el modelo adecuado para la misión.
Usa V4-Flash para la mayoría de tareas de exploración, documentación y cambios controlados. Reserva V4-Pro para misiones donde el fallo de razonamiento cueste más que la diferencia de precio o latencia.
- V4-Flash: equilibrio entre velocidad, coste y contexto.
- V4-Pro: más capacidad para tareas difíciles, revisiones profundas o planes complejos.
- Thinking/reasoning: súbelo solo cuando la tarea lo justifique; medir importa más que activar todo al máximo.
Cómo guarda DSH las credenciales
La página de modelos trata las claves como write-only: después de guardar, la interfaz recibe un descriptor redactado, no el secreto literal.
La guía oficial indica que la clave se guarda en `$DSH_HOME/.credentials.yaml` y que la configuración conserva solo una referencia a esa credencial. Esto cambia la auditoría: revisas referencias y permisos de archivo, no capturas de pantalla con claves.
Comprobación segura: - no pegues la API key en prompts - no la subas al repo - revisa permisos de $DSH_HOME - rota la clave si la mostraste en una captura
Proveedores adicionales
El diseño de DSH permite cambiar de proveedor sin cambiar el harness. Eso no significa que debas conectar todos: cada proveedor añade una política de datos, una factura y una superficie de fallo.
Añade OpenAI, Anthropic, Google, Kimi u otro proveedor solo si necesitas comparar una tarea concreta o cubrir una limitación clara del modelo principal.
Criterio para añadir proveedor: - tarea que DeepSeek no resuelve bien - política de datos revisada - coste por resultado estimado - prueba con el mismo prompt y workspace - decisión registrada en el Trajectory
Proveedor de catálogo vs proveedor personalizado
Add provider usa el catálogo instalado: endpoint, protocolo y lista de modelos vienen predefinidos para proveedores conocidos.
Add a custom provider es para una pasarela de empresa, un servidor self-hosted o un proveedor ausente del catálogo. El Provider ID debe ser lowercase y es permanente: lo usan las peticiones, sesiones guardadas, modelos por defecto y referencias de credenciales.
- Para renombrar un provider, crea uno nuevo y borra el anterior.
- El display name, base URL, protocolo, credencial y modelos sí son editables.
- Fetch available models consulta el endpoint compatible `GET /models`; si falla o no existe, añade modelos manualmente.
Modalidades de entrada
Un modelo escrito a mano se considera text-only salvo que declares lo contrario, porque DSH no puede saber por sí mismo si tu endpoint acepta imágenes.
Para modelos vision en proveedores personalizados, la documentación oficial indica declarar `input: [text, image]` en `$DSH_HOME/settings.yaml`. DeepSeek chat-completions se documenta como text-only en esta guía.
llm-pi-ai:
providers:
vision-gateway:
apiKeyEnv: GATEWAY_API_KEY
api: openai-completions
baseURL: https://vision.example/v1
models:
- id: vision-preview
input: [text, image]Errores habituales de modelos
Antes de cambiar prompts o permisos, diagnostica el provider. La guía oficial enumera errores concretos que conviene reconocer.
- `MISSING_CREDENTIAL`: guarda la clave en Models o proporciona la variable de entorno referenciada.
- `UNKNOWN_MODEL`: selecciona un modelo configurado o añádelo al provider personalizado.
- `GET /models` devuelve 401: revisa credencial; si el endpoint no soporta discovery, escribe modelos manualmente.
- Imagen rechazada antes de enviar: el modelo no declara modalidad image.
Coste real en DSH
El coste no es solo precio por token. En un agente cuentan los turnos, el contexto repetido, la caché, las herramientas fallidas, los reintentos y la revisión humana posterior.
DSH cobra sentido cuando conservas el Trajectory y las métricas de cada sesión: tokens de entrada y salida, cache hit rate, tiempo total, modo usado y número de aprobaciones.
Registro de comparación: modelo: modo: Standard / Code / Minimal / Creator prompt exacto: tokens entrada: tokens salida: cache hit rate: tiempo total: reintentos: resultado aceptado: si / no coste estimado:
Modelos locales quedan para otra fase
Esta fase no enseña instalación, seguridad de red, GPU ni troubleshooting de runtimes locales. Eso pertenece al curso de IA local de Aulafy.
En DSH solo nos interesa la idea arquitectónica: un modelo local puede entrar como proveedor compatible si ya tienes ese servidor funcionando y validado. La configuración del servidor local se estudia aparte para no mezclar dos tutoriales distintos.
- Aquí: seleccionar y medir proveedores dentro de DSH.
- IA local: instalar, servir modelos, exponer endpoint, GPU y privacidad local.
- Fase 8: límites de modelos DeepSeek locales y cuantización desde el punto de vista de DSH.
Si has guardado la evidencia de esta lección, continúa con «Modos de ejecución: cómo elegirlos». Si no, repite la comprobación antes de avanzar.