Tutoriales de VPS
Pasarela de API de IA autoalojada en un VPS (2026): One-API / New-API, modelos unificados, gestión de claves, limitación de velocidad y facturación
¿Quieres unificar OpenAI, Claude, Gemini, DeepSeek, Qwen, Doubao y otros modelos detrás de un único punto de entrada de API? Este artículo explica cuándo tiene sentido una pasarela de API de IA autoalojada en un VPS, cómo elegir entre One-API y New-API, el despliegue con Docker Compose, la configuración de canales, la gestión de claves, la limitación de velocidad, los registros y una lista de comprobación de seguridad.
La mayoría de la gente empieza a integrar API de IA escribiendo directamente en el código la dirección de OpenAI, Claude o Gemini. Con pocos proyectos no hay problema, pero cuando tienes tres o cuatro proveedores de modelos, dos o tres proyectos y una docena de claves de API, todo empieza a desordenarse:
- Un proyecto usa el formato de OpenAI y otro el de Claude;
- Un compañero tiene la clave maestra y a fin de mes nadie sabe quién gastó qué;
- DeepSeek es barato, pero a veces quieres un fallback automático a otro modelo;
- Quieres distribuir claves a clientes o herramientas internas sin exponer las claves reales del proveedor;
- El presupuesto es limitado y quieres cuotas, límites de velocidad y registros por clave.
Ahí es donde entra la pasarela de API de IA. En pocas palabras, montas tu propio "punto de entrada de modelos": el backend se conecta a varios proveedores y el frontend expone una sola dirección de API unificada. A partir de entonces, el lado de la aplicación solo necesita cambiar base_url en lugar de editar código por todas partes.
En 2026, las dos opciones más habituales para autoalojar una pasarela de API de IA en la comunidad de habla china siguen siendo One-API y New-API. One-API es el proyecto veterano: ligero y fácil de entender. New-API es una bifurcación activa derivada de One-API, con más funciones, soporte de conversión de protocolos entre OpenAI, Claude, Gemini y otros, y mejor encaje para escenarios multiusuario, multicanal y multimodelo.
Empecemos por la conclusión: no todo el mundo necesita autoalojarla.
Si solo usas ChatGPT a nivel personal, o llamas de vez en cuando a DeepSeek desde un script, la API oficial es suficiente. Autoalojar una pasarela solo añade una capa de mantenimiento.
Pero estas situaciones encajan muy bien:
| Escenario | Valor de una pasarela autoalojada |
|---|---|
| Varios proveedores de modelos | Gestionar OpenAI, Claude, Gemini, DeepSeek, Qwen, Doubao y otros canales desde un único punto de entrada |
| Uso compartido entre varios proyectos | Emitir una clave independiente por proyecto y desactivarla por separado si algo falla |
| Uso interno del equipo | Ver consumo, cuotas y de dónde viene el gasto |
| Redistribución a clientes | No exponer las claves de API reales del proveedor |
| Control de costes | Definir cuotas, límites de velocidad y permisos de modelos por clave |
| Capa de compatibilidad | Permitir que herramientas que solo admiten el formato OpenAI accedan a más modelos |
El uso más típico que he visto: New-API se ejecuta en un VPS y el Dify, LobeChat, las tareas de script y los bots de atención al cliente de la empresa pasan todos por este punto de entrada unificado. En el panel ves de un vistazo cuántos tokens usa cada uno. Si un canal falla, le bajas el peso o lo desactivas temporalmente, y el código de la aplicación no necesita cambios.
Los dos proyectos tienen nombres muy parecidos, pero su posicionamiento ya no es exactamente el mismo.
| Comparación | One-API | New-API |
|---|---|---|
| Público objetivo | Quien quiere algo ligero, simple y estable | Quien quiere más modelos, un panel más completo y mantenimiento más activo |
| Madurez del proyecto | Proyecto veterano con lógica clara | Comunidad más activa, iteración de funciones más rápida |
| Despliegue | Docker / binario único | Docker / Docker Compose / panel / clúster |
| Soporte de protocolos | Principalmente compatible con OpenAI | Conversión multiprotocolo más potente para OpenAI, Claude, Gemini y más |
| Complejidad funcional | Menor | Mayor |
| Licencia | MIT | AGPL-3.0 |
Mi recomendación es directa:
- Uso personal, solo unificar unos cuantos endpoints compatibles con OpenAI: One-API basta;
- Uso en equipo con varios modelos, varias claves, estadísticas de consumo y conversión de protocolos: prioriza New-API;
- Desarrollo secundario comercial o distribución de código cerrado: revisa bien la licencia; New-API es AGPL-3.0, no pases por alto este detalle.
El repositorio oficial de One-API es songquanpeng/one-api, y el de New-API más activo actualmente es QuantumNous/new-api. Antes de desplegar, conviene leer el README y la documentación oficial, porque las variables de entorno, los nombres de imagen y el soporte de bases de datos cambian según la versión.
La pasarela de API de IA no ejecuta modelos, solo reenvía solicitudes y registra consumo, así que no exige mucho al VPS. Lo que realmente cuesta dinero son los modelos del proveedor, no la pasarela.
Sugiero elegir así:
| Uso | Configuración recomendada |
|---|---|
| Uso personal | 1 núcleo y 1 GB puede funcionar; 2 GB es más estable |
| Equipo interno pequeño | Empezar con 2 núcleos y 2 GB |
| Distribución multiusuario + MySQL | 2 núcleos y 4 GB es más cómodo |
| Alta concurrencia o servicio comercial | Base de datos separada + proxy inverso + monitorización; no escatimes y aguantes a pulso |
Con 20 GB de disco basta para empezar. No guardes los registros indefinidamente, o en unos meses verás que la base de datos es mucho más grande que el programa.
Se recomienda Ubuntu 22.04/24.04 o Debian 12. El despliegue con contenedores es lo más cómodo y facilita la migración posterior.
A continuación uso New-API como ejemplo. One-API funciona de forma similar, solo cambian ligeramente las imágenes y las variables de entorno.
Primero prepara el directorio:
mkdir -p /opt/new-api
cd /opt/new-api
Escribe un docker-compose.yml mínimo que funcione:
services:
new-api:
image: calciumion/new-api:latest
container_name: new-api
restart: unless-stopped
ports:
- "3000:3000"
environment:
- SQL_DSN=root:change_this_password@tcp(mysql:3306)/new-api
- TZ=Asia/Shanghai
depends_on:
- mysql
mysql:
image: mysql:8
container_name: new-api-mysql
restart: unless-stopped
environment:
- MYSQL_ROOT_PASSWORD=change_this_password
- MYSQL_DATABASE=new-api
- TZ=Asia/Shanghai
volumes:
- ./mysql:/var/lib/mysql
Arráncalo:
docker compose up -d
docker compose logs -f new-api
Luego visita:
http://你的服务器IP:3000
Tras el primer inicio de sesión, haz tres cosas de inmediato:
- Cambiar la contraseña de administrador predeterminada;
- Desactivar el registro público que no necesites;
- Configurar un proxy inverso y HTTPS; no dejes el puerto 3000 expuesto a largo plazo.
Si usas Nginx, puedes hacer el proxy inverso así:
server {
listen 80;
server_name api.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Luego obtén un certificado con Certbot o acme.sh. No pongas producción solo sobre HTTP.
Desplegar la pasarela es solo el primer paso; el tiempo real se va en la configuración de canales.
Los canales habituales se pueden agrupar así:
| Tipo de canal | Ejemplos | Puntos a tener en cuenta |
|---|---|---|
| OpenAI oficial | GPT-4o, GPT-4.1, etc. | Caro pero estable; ojo con los límites de facturación |
| Compatible con OpenAI | DeepSeek, Moonshot, OpenRouter, etc. | La URL base es distinta; los nombres de modelo deben coincidir |
| Claude | Anthropic Claude | El protocolo no es idéntico al de OpenAI; New-API lo simplifica |
| Gemini | Google Gemini | Algunos modelos tienen contexto largo, pero revisa bien los límites de velocidad |
| Modelos nacionales | Qwen, Doubao, Zhipu, Wenxin, etc. | La autenticación y los nombres de modelo suelen ser distintos; no copies los parámetros de OpenAI a ciegas |
Al configurar, agrupa por "propósito" en lugar de meter todos los canales de golpe:
- Chat de bajo coste: DeepSeek / Qwen / Doubao;
- Escritura de alta calidad: Claude / GPT;
- Procesamiento de contexto largo: Gemini / modelos de contexto largo de Claude;
- Entorno de pruebas: modelos baratos con cuota limitada;
- Entorno de producción: canales estables con claves separadas.
Así la resolución de problemas será mucho más fácil después.
El mayor beneficio de autoalojar una pasarela para mucha gente no es ahorrar dinero, sino "recuperar el control de los permisos".
La forma correcta es:
- Las claves de API reales del proveedor solo viven en el panel de la pasarela;
- Emitir una clave independiente por proyecto, usuario y entorno;
- Definir en las claves cuotas, fechas de caducidad y permisos de modelos;
- Registrar el consumo por separado según el uso, por ejemplo
dify-prod,lobechat-home,crawler-test; - Si algo falla, desactivar una sola clave sin afectar a otros proyectos.
No uses una sola clave para todo. Sobre todo si pones claves en proyectos frontend, repositorios públicos de GitHub o plugins de terceros, la filtración es solo cuestión de tiempo.
Si solo lo usas tú, los límites de velocidad pueden ser laxos. Pero en cuanto lo use otra gente, la limitación debe estar activada.
Sugiero controlar desde estas dimensiones:
| Control | Sugerencia |
|---|---|
| Solicitudes por minuto | Evitar que scripts en bucle agoten las cuotas |
| Cuota diaria | Evitar que un solo usuario consuma todo el presupuesto |
| Permisos de modelos | Los usuarios normales solo usan modelos baratos; los caros se autorizan aparte |
| Peso de canales | Priorizar canales baratos y usar los caros como respaldo |
| Reintentos de fallos | No reintentar sin fin; los 429 del proveedor solo empeoran |
Un problema real: un script tenía mal escrita la lógica de reintento ante excepciones y, tras un 500 del endpoint del modelo, reintentaba decenas de veces por segundo. Sin limitación de velocidad en la pasarela, la factura del proveedor sería espantosa. Con pasarela, como mucho esa clave queda limitada y no se arrastra todo el sistema.
La mayoría de las herramientas compatibles con OpenAI solo necesitan dos cambios:
API Key: 你在网关里生成的 Key
Base URL: https://api.example.com/v1
Por ejemplo, en Python:
from openai import OpenAI
client = OpenAI(
api_key="sk-your-gateway-key",
base_url="https://api.example.com/v1"
)
response = client.chat.completions.create(
model="deepseek-chat",
messages=[{"role": "user", "content": "写一段 VPS 备份脚本说明"}]
)
print(response.choices[0].message.content)
Herramientas como Dify, LobeChat, Cherry Studio o LibreChat también suelen permitir configurar una dirección compatible con OpenAI. Rellena la dirección de tu pasarela y podrás unificar varios modelos detrás de ella.
Una pasarela de API de IA expuesta a internet no tiene menos riesgo que un sitio web normal. Como mínimo, haz esto:
- Contraseña fuerte en el panel de administración y activa 2FA si puedes;
- No expongas el panel en la ruta predeterminada, o añade otra capa con Cloudflare Access / Basic Auth;
- Añade limitación de velocidad básica en la capa de Nginx;
- Abre solo 80/443, no expongas 3000 directamente;
- No uses el
change_this_passworddel ejemplo como contraseña de la base de datos; - Haz copias de seguridad periódicas de MySQL;
- Registra el consumo anómalo, por ejemplo un pico repentino en una clave concreta;
- Configura también alertas de presupuesto en las plataformas del proveedor; no confíes solo en la pasarela.
Ejemplo sencillo de limitación de velocidad en Nginx:
limit_req_zone $binary_remote_addr zone=aiapi:10m rate=10r/s;
server {
listen 443 ssl http2;
server_name api.example.com;
location / {
limit_req zone=aiapi burst=20 nodelay;
proxy_pass http://127.0.0.1:3000;
}
}
No es una defensa universal, pero bloquea parte del mal uso de scripts y escaneos de bajo coste.
La pasarela en sí se puede reconstruir; lo más importante es la base de datos.
Sugiero hacer una copia de seguridad al día:
mkdir -p /opt/backups/new-api
docker exec new-api-mysql mysqldump \
-uroot \
-p'change_this_password' \
new-api > /opt/backups/new-api/new-api-$(date +%F).sql
Luego sincroniza fuera del servidor con rclone o almacenamiento de objetos. No guardes las copias solo en el mismo VPS; si el disco muere, es como si no tuvieras copia.
La migración suele ser en tres pasos:
- Instalar Docker en el servidor nuevo;
- Copiar
docker-compose.ymly los datos/copia de MySQL; - Cambiar el DNS al servidor nuevo.
Si el negocio es importante, restaura primero en la máquina nueva y confirma que el panel, las claves, los canales y los registros funcionan, y luego cambia el dominio.
El proveedor lo llama deepseek-chat y tu aplicación escribe gpt-4, así que por supuesto da error. Confirma primero la asignación de modelos en la pasarela y luego cambia la configuración de la aplicación.
Algunos proxies inversos o CDN almacenan la respuesta en búfer, lo que convierte la salida en streaming en una descarga de golpe. En Nginx puedes desactivar el buffering del proxy:
proxy_buffering off;
Los 429 suelen ser límites de velocidad o problemas de saldo del proveedor. Mira primero los registros del canal y luego los de la aplicación; no reinicies el contenedor de inmediato.
Revisa estos tres puntos:
docker compose ps
ss -lntp | grep 3000
ufw status
Que el contenedor esté sano no significa que el puerto sea accesible; revisa también el firewall y el grupo de seguridad del proveedor cloud.
Si solo quieres unificar rápidamente varias API de IA, te sugiero ir directamente a New-API. Tiene funciones más completas y una comunidad más activa, lo que encaja con el entorno de uso mixto de varios modelos de 2026.
Si te importan mucho la simplicidad, la ligereza y una licencia permisiva, One-API sigue siendo usable. Solo que más adelante puede que te encuentres con que las funciones no bastan y la conversión de protocolos no es lo bastante cómoda.
La forma más sólida de implantarlo es:
- Empezar con un VPS de 2 núcleos y 2 GB;
- Desplegar New-API + MySQL con Docker Compose;
- Proxy inverso Nginx + HTTPS;
- Emitir una clave separada por proyecto;
- Activar cuotas, limitación de velocidad y registros;
- Copia de seguridad diaria de la base de datos;
- Configurar también alertas de presupuesto en las plataformas del proveedor.
Una pasarela de API de IA no es para presumir. Lo que realmente resuelve es el problema de "cada vez más modelos, claves cada vez más desordenadas y facturas cada vez más feas". Si ya integras API de IA en varios proyectos, dedicar ahora media hora a montar una capa de pasarela te ahorrará mucho tiempo de diagnóstico y gestión después.