Al implementar agentes locales en Windows, la estructura más sencilla generalmente no es distribuir el servicio modelo, Docker, terminal y herramientas de codificación en Windows, WSL y múltiples entornos virtuales, sino colocarlos en la misma distribución WSL2 de Ubuntu:
|
|
De esta manera, Ollama y el Agente se comunican directamente a través de localhost en WSL, y la ruta, los permisos y los registros están todos en el entorno Linux. El lado de Windows puede continuar accediendo al proyecto mediante Windows Terminal, VS Code Remote WSL o Explorer.
Hablemos primero de la conclusión.
La ruta mínima disponible es:
|
|
No le dé al Agente local todos los permisos desde el principio y no busque primero el modelo más grande. Es más importante utilizar primero un proceso de verificación de modelo que pueda ejecutarse de manera estable que lidiar primero con agentes complejos, puertos remotos y orquestación de múltiples agentes.
Paso 1: instale WSL2 y Ubuntu
Ejecute en Administrador PowerShell en Windows:
|
|
Después de reiniciar, Ubuntu se instalará de forma predeterminada. Cuando abra Ubuntu por primera vez, siga las instrucciones para crear un nombre de usuario y contraseña de Linux.
Confirme que la distribución utiliza WSL2:
|
|
Si la distribución anterior sigue siendo la versión 1, puedes convertir:
|
|
Ingrese a Ubuntu:
|
|
La mayoría de los comandos posteriores se ejecutan en la terminal de Ubuntu, no en PowerShell.
Paso 2: preparar el entorno básico de Ubuntu
Después de ingresar a WSL, primero actualice el sistema:
|
|
Confirmar entorno:
|
|
Se recomienda que el proyecto se coloque en el sistema de archivos de Linux, por ejemplo:
|
|
No ejecute entornos virtuales Git, Node.js, Python de alta frecuencia ni dependencias a gran escala en /mnt/c/.... El acceso entre sistemas de archivos puede ser más lento en algunas tareas de desarrollo y es más probable que encuentre diferencias en permisos y escucha de archivos. Cuando necesite abrir un proyecto desde Windows, puede utilizar la función WSL remoto de VS Code.
Paso 3: Instale y verifique Ollama dentro de WSL
Siga el método de instalación de Ollama Linux:
|
|
Primero inicie el servicio en la terminal actual:
|
|
Abra otra terminal WSL, descargue y pruebe un modelo:
|
|
La selección del modelo debe estar determinada por la memoria de su GPU o CPU/memoria. Cuando no haya GPU disponible, use un modelo más pequeño para verificar el proceso primero; No confunda “se pueden descargar archivos de modelos grandes” con “esta máquina puede realizar inferencias sin problemas”.
Confirmar estado del servicio y modelo:
|
|
Si ollama run no puede generar una salida estable, primero resuelva el problema del modelo, la memoria de video, el controlador o la memoria y luego conéctese al Agente.
Paso 4: compruebe si la GPU WSL está realmente disponible
Cuando tengas una GPU NVIDIA, ejecuta dentro de WSL:
|
|
Poder mostrar la tarjeta gráfica no significa que Ollama haya usado la GPU, pero al menos prueba que WSL ve el controlador. Después de iniciar el modelo, ejecute:
|
|
Observe si el modelo usa GPU y si aumenta la memoria de video.
Si nvidia-smi no existe o se informa un error, primero verifique el controlador NVIDIA, la versión WSL y la compatibilidad con GPU de Windows. No se apresure a instalar el controlador de Linux de escritorio repetidamente en Ubuntu. La compatibilidad con GPU de WSL tiene su propio enlace de controlador.
Paso 5: Permitir que Codex use Ollama local
Codex ofrece modo OSS con la opción de Ollama o LM Studio como proveedor local. Una vez que Codex esté instalado y ejecutable dentro de WSL, vaya al directorio de su proyecto:
|
|
Se recomienda comenzar con permisos de solo lectura por primera vez:
|
|
Primero dé una tarea que no modifique el archivo:
|
|
Después de confirmar que el modelo local puede comprender el almacén y que la respuesta es estable, utilice el permiso de escritura del espacio de trabajo según sea necesario. No te saltes Git, las pruebas y los permisos sólo porque es un modelo local.
Si desea utilizar Ollama como proveedor local predeterminado, agregue ~/.codex/config.toml en la configuración del Codex a nivel de usuario:
|
|
Luego use el siguiente comando:
|
|
Tenga en cuenta que la configuración relacionada con el proveedor debe colocarse en la configuración a nivel de usuario, no en .codex/config.toml en el proyecto. La configuración del proyecto no debe cambiar de forma encubierta el proveedor del modelo de su máquina.
Paso 6: habilite systemd cuando se requieran servicios para residentes
Las nuevas instalaciones de WSL Ubuntu normalmente ya utilizan systemd por defecto. Primer control:
|
|
Si systemd no está habilitado en la distribución actual, edite:
|
|
participar:
|
|
Luego regrese a Windows PowerShell:
|
|
Marque systemctl status nuevamente después de volver a ingresar a Ubuntu.
La posibilidad de convertir a Ollama en un servicio residente depende del método de instalación y de si necesita una API de backend. Cuando comienza a aprender, es más fácil mantener una terminal ollama serve para ver los registros; una vez que se confirme que es estable, use systemd para administrar el servicio.
Rutas, puertos y API dentro de WSL
Por defecto, el servicio Ollama utiliza:
|
|
Si el agente, el script y Ollama están todos en la misma distribución WSL, esta dirección local se usará primero y no es necesario abrir primero el puerto LAN.
API de prueba:
|
|
Cuando es necesario llamarlo en programas de Windows, teléfonos móviles u otros dispositivos en la red de área local, el método de exposición de la red, el proxy inverso y la autenticación deben diseñarse por separado. No asigne puertos del modelo local expuestos directamente a la red pública.
Calificaciones de recursos recomendadas
| Situación del hardware | Formas sugeridas de empezar |
|---|---|
| Sin gráficos discretos, memoria de 8 GB a 16 GB | Modelos pequeños, análisis de sólo lectura, resúmenes y guiones sencillos. |
| Memoria de vídeo de 8GB | Modelo cuantificado 7B/8B, contexto de usuario único de corto a medio |
| Memoria de vídeo de 12 GB a 16 GB | 8B es más cómodo, puedes probar modelos cuantitativos más grandes con precaución |
| Memoria de vídeo de más de 24 GB | Considere modelos más grandes, contextos más largos o tareas de agentes locales más complejas |
Un modelo más grande no significa un Agente más confiable. Para los agentes locales, la estabilidad de la ejecución de comandos, el contexto, las capacidades de llamada de herramientas y los métodos de división de tareas también afectan los resultados.
La trampa más fácil de caer
1. Windows y WSL ejecutan cada uno un conjunto de Ollama
Esto le dificultará saber a qué servicio está realmente conectado el Agente. Para la implementación inicial, se recomienda ejecutar solo un conjunto de Ollama dentro de WSL y todas las pruebas se completan en el mismo terminal WSL.
2. Ejecute todas las tareas de desarrollo en /mnt/c
Accesible, pero puede no ser ideal según la instalación, la escucha de archivos, el rendimiento de Git y el comportamiento de los permisos de Linux. Priorizar proyectos activos en ~/projects.
3. El modelo local permite escribir archivos desde el principio.
Primero use --sandbox read-only para verificar si el modelo comprende la tarea. Una vez que ingrese a la fase de modificación, también debe dejar que le explique el plan antes de verificar las diferencias, ejecutar pruebas y usar Git para conservar los puntos de respaldo.
4. No hay autenticación después de abrir el puerto.
Una vez que a una API local se le permite el acceso LAN, ya no es sólo un “servicio en su propia computadora”. Como mínimo, limite las fuentes del firewall y agregue autenticación y HTTPS en la capa de proxy inverso si es necesario.
5. Pensar que si la instalación es exitosa, se ejecutará automáticamente en segundo plano.
El proceso de primer plano sale cuando se cierra WSL o se detiene la distribución. Cuando se requieran API a largo plazo, primero confirme systemd, el estado del servicio y las políticas operativas de Windows/WSL.
Resumir
Windows WSL implementa agentes locales. La primera versión más confiable es:
|
|
Mantener el modelo, el agente y el código en el mismo entorno WSL puede reducir los problemas de rutas, puertos y permisos a más de la mitad. Espere hasta que el proceso mínimo esté estable antes de considerar Docker, enrutamiento multimodelo, RAG o acceso remoto.
referirse a: