Elegir un modelo: de frontera, barato y abierto
El mejor modelo para una tarea es el más barato que pasa tus pruebas. El precio, la velocidad y la privacidad importan tanto como los puntajes de benchmark, y los modelos al estilo DeepSeek vuelven concreto ese trade-off.
Piensa en niveles, no en marcas
- Modelos de frontera (las mejores ofertas de Anthropic, OpenAI, Google): los mejores en trabajo largo, ambiguo y con varios archivos, y en recuperarse de errores. Mayor precio por token. Úsalos para planificar, bugs difíciles y código sensible a la seguridad.
- Variantes rápidas y pequeñas de los mismos proveedores: mucho más baratas y veloces, buenas para ediciones con una instrucción clara, pruebas, renombrados y resúmenes.
- Modelos open-weight y de bajo costo (DeepSeek, Qwen, Kimi, GLM y otros): a menudo cercanos a la frontera en benchmarks de código por una fracción del precio, y algunos pueden ejecutarse en tu propio hardware. La calidad varía según la tarea y el harness, así que mide con tu código.
- Modelos locales: nada sale de la máquina; útiles para código privado y trabajo sin conexión. Limitados por tu hardware, por lo que suelen ser más pequeños y lentos que los alojados.
Sobre DeepSeek en particular
DeepSeek es una familia de modelos, no una herramienta de código. Lo usas a través de un harness que pueda llegar a él: su propia API, un enrutador como OpenRouter, un host en la nube o un runtime local si ejecutas tú mismo los pesos abiertos. El mismo modelo puede comportarse de forma bastante distinta según el harness.
Dos preguntas deciden si se ajusta a tu proyecto. Primero, la calidad: ejecuta tus propias tareas y pruebas en lugar de confiar en un leaderboard. Segundo, los datos: cuando usas el servicio alojado del proveedor, tu código y tus prompts se procesan bajo los términos de privacidad y la jurisdicción de ese servicio. Muchas empresas restringen o prohíben enviar código propietario a algunos servicios alojados. Lee la política vigente, revisa las reglas de tu empresa y considera un host de confianza o ejecutar tú mismo los pesos abiertos cuando el código sea sensible.
Una política de enrutamiento que funciona
No elijas un solo modelo para todo. Usa un modelo potente para planificar y revisar, uno más barato para ejecutar ediciones bien especificadas, y las pruebas como juez. Muchos harnesses permiten definir un modelo por defecto y sobrescribirlo por agent o por tarea. El ejemplo de abajo es ilustrativo: las claves exactas difieren según la herramienta.
planning: { model: frontier, why: "ambigüedad y arquitectura" }
implementing: { model: fast-or-open, why: "spec clara, las pruebas verifican" }
review: { model: frontier-from-a-different-vendor, why: "segunda opinión independiente" }
sensitive-code:
allowed_providers: ["self-hosted", "company-approved-cloud"]
forbidden: ["consumer chat endpoints", "unreviewed third-party routers"]Mide antes de comprometerte
- Arma un pequeño benchmark privado con tareas reales de tu repositorio (una corrección de bug, una funcionalidad, un refactor) con pruebas que decidan aprobado o reprobado.
- Compara el costo por tarea resuelta, no el precio por token: un modelo barato que necesita tres intentos puede costar más que uno potente que acierta de una vez.
- Registra los modos de falla: APIs inventadas, ediciones rotas, rendirse pronto, ignorar instrucciones.
- Vuelve a ejecutar cuando aparezca un modelo nuevo o cambie tu harness; los resultados caducan en meses.
- Revisa el manejo de datos de cada provider en la cadena, incluidos los enrutadores que reenvían tus prompts a otra parte.
conexiones en el mapa
- Modelo, harness y providersepara el modelo enElegir un modelo: de frontera, barato y abierto
- Elegir un modelo: de frontera, barato y abiertoalimentaCuándo usar qué
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
Estudia antes
Desbloquea
pon a prueba lo que entendiste
Cargando preguntas…