Infraestructura LLM
Diseñar un broker LLM sin vender humo de arbitraje
Problema
La idea inicial suena simple: poner una API compatible con OpenAI delante de varios proveedores y enrutar solicitudes según costo, latencia o calidad. La parte peligrosa es creer que eso basta como producto. Los proveedores cambian modelos, límites y términos; un broker serio no puede depender de evadir cuotas ni de prometer tokens casi gratis.
Decisión
El repo lo plantea como una v1 ejecutable: FastAPI expone /v1/chat/completions, los clientes usan
aliases públicos como auto, fast y smart, y LiteLLM queda como capa de
routing y fallback. El usuario no compra un proveedor específico; compra una interfaz estable.
Para cobro, el núcleo es un credit_ledger en Postgres. La API estima costo antes de llamar al modelo,
valida saldo y luego debita contra el uso real reportado. Redis + ARQ separan la ejecución batch, y el bot de
Telegram funciona como canal de onboarding sin llevar un saldo paralelo.
Tradeoffs
- La v1 prioriza contrato y contabilidad sobre features llamativas como streaming.
- El topup en USDC está modelado, pero la conciliación onchain real sigue siendo requisito de producción.
- Los aliases simplifican UX, pero el pricing final debe bajar a proveedor/modelo para evitar margen opaco.
- Batch es una oportunidad real si cobra por conveniencia y prioridad, no solo por proxy de tokens.
Validación
El código ya deja algunos contratos verificables: tests para resolver aliases y multiplicador premium, health check de API, helpers deterministas del bot y un flujo que registra cada request como queued, completed o failed antes de tocar el ledger.
También hay una lista explícita de riesgos: migrar modelos deprecados, proveedores vivos en LiteLLM, billing exacto, rate limits, streaming, observabilidad y panel interno. Esa lista es parte del valor: evita presentar un scaffold como si fuera infraestructura productiva.
Resultado
- Scaffold con FastAPI, Postgres, Redis, ARQ, SQLAlchemy/Alembic, LiteLLM y bot Telegram.
- Superficie compatible con OpenAI para integrarse con SDKs y agentes existentes.
- Modelo contable basado en ledger en vez de balance materializado como única fuente.
- Roadmap claro hacia integración onchain, pricing exacto, rate limiting y ejecución batch real.
Siguiente
La conclusión técnica y comercial es la misma: el broker horizontal solo tiene sentido como infraestructura. El producto más defendible aparece al montar workflows verticales encima, donde se cobra por resultado, trazabilidad y conveniencia, no por milisegundos de arbitraje.