Separare i requisiti del modello dalla preferenza di hosting
Il self-hosting dà al tuo team la responsabilità dello stack di servizio, della capacità, degli aggiornamenti e della disponibilità. Può essere appropriato per pesi personalizzati o vincoli infrastrutturali che un servizio API non affronta.
Limita inoltre la scelta del modello ai modelli che puoi ottenere e utilizzare. Un modello proprietario disponibile solo come servizio non può diventare self-hosted semplicemente perché l'applicazione utilizza un formato API comune.
Utilizza l'accesso API per un elenco di modelli più ampio
TextCortex riunisce GPT, Claude e Gemini insieme a Kimi, GLM, DeepSeek e MiMo dietro un'unica integrazione. La tua applicazione può selezionare modelli diversi senza distribuire uno stack di servizio separato per ciascuno.
Per l'inferenza dell'UE, utilizzare un percorso idoneo ospitato dall'UE. L’hosting gestito necessita ancora di un chiaro accordo di elaborazione, ma il team dell’applicazione non deve fornire l’infrastruttura GPU del modello.
Includere il lavoro operativo nel confronto
Confronta lo stesso carico di lavoro e lo stesso obiettivo di affidabilità su entrambe le opzioni.
- Pianificazione della capacità e risorse inattive.
- Aggiornamenti, implementazione e rollback del modello.
- Limiti di richiesta, monitoraggio e risposta agli incidenti.
- Qualità del modello richiesta e accesso al modello proprietario.
- Tempo di progettazione e costi di utilizzo.
Un'architettura ibrida può essere deliberata
Un'applicazione può mantenere un modello self-hosted specializzato mentre utilizza un'API per altre attività. Mantieni esplicite le decisioni di routing e misura entrambi i percorsi utilizzando gli stessi risultati dell'attività.
Esplora API del modello TextCortex e guida al percorso per decidere quali carichi di lavoro appartengono a ciascun percorso.