produits · ai
Tout ce qui se trouve entre votre modèle et votre produit.
Appeler un modèle est facile ; passer d'un prompt dans un notebook à un workload en production ne l'est pas. Le tier AI comble ce fossé — routage, exécution, orchestration et retrieval, conçus comme un seul système.
gateway
Une porte pour chaque modèle.
Pointez votre code sur un seul endpoint et appelez les modèles par alias. Derrière chaque alias, une chaîne ordonnée d'upstreams, essayée en ordre de fallback — une panne d'upstream devient une décision de routage, pas une salle de crise.
Connectez les endpoints de modèles que vous utilisez déjà ; leurs identifiants vivent en références de Secrets, jamais en clair dans la config.
Le code appelle un modèle par son nom ; vous décidez quelle chaîne d'upstreams le sert. Changez la chaîne, pas le code.
Chaque modèle indique s'il sert réellement — vérifié depuis le chemin de données, pas présumé depuis une entrée de config.
Plafonnez requêtes ou tokens par key, par fenêtre. La limite s'applique là où l'appel aboutit, pas dans un dashboard que personne ne regarde.
Chaque complétion est attribuée à la key qui l'a émise, et les rollups détaillent l'usage par key et par modèle.
Envoyez un prompt à travers le Gateway et voyez la réponse, sans quitter la console.
pour l'équipe finance
L'usage des modèles cesse d'être un mystère et devient une métrique attribuée et plafonnée — par key, par modèle, par fenêtre.
sandboxes
Faites pour disparaître.
Certains travaux ne devraient jamais se survivre. Les sandboxes lancent du code non fiable, des runs d'évaluation et des fragments batch avec une time-to-live optionnelle — et sont détruites quand ils sont finis.
Quand l'horloge s'arrête, la sandbox aussi.
Une action à part entière, pas un script de nettoyage.
Une sandbox reçoit exactement les secrets et permissions qui lui ont été accordés — rien d'ambiant, rien d'hérité.
Input, output et statut sur la même timeline que tout ce que la plateforme exécute.
Du vrai calcul quand il le faut, disparu ensuite — une seule histoire d'exécution, pas deux.
workflows
Orchestration durable sur toute la plateforme.
Les workflows enchaînent les capacités de la plateforme en graphes d'étapes versionnés : appeler un modèle via le gateway, exécuter une commande dans une sandbox, interroger un index, attendre, brancher, recommencer.
Mettre à jour un workflow publie une nouvelle version — l'historique en cours reste honnête.
Chaque étape est checkpointée au fil du run, si bien qu'un long pipeline survit aux interruptions et reprend où il s'était arrêté.
Les runs apparaissent sur une timeline en direct avec leur statut ; annulez ceux qui ne doivent pas finir.
Lancez un run avec une entrée JSON et suivez-le sur la timeline des runs.
pour l'équipe engineering
La reconstruction nocturne d'index, la préparation multi-étapes, le sweep d'évaluation — ils deviennent des graphes reviewables et rejouables au lieu d'un folklore de cron fragile.
knowledge graphs
Vos données, en relations.
Le retrieval ne devrait pas exiger un stack séparé. Knowledge Graphs transforme les données que vous détenez déjà en entités et relations requêtables — sans que la plateforme n'en prenne jamais la garde.
Pointez les données que vous détenez déjà ; rien ne bouge, rien n'est copié ailleurs.
Modélisez le domaine en nœuds et arêtes typées — la traversée est la requête.
Une construction en étapes, déclarative, des données brutes au graphe requêtable — reprenable, répétable, visible.
Parcourez les voisins depuis n'importe quel nœud, directement dans la console, avant de le confier à un run.
Le retrieval est une étape du graphe, pas une quête annexe en scripts.
pour l'équipe data
Le substrat de retrieval est une surface produit — déclarations, pipelines et requêtes — pas un tas de scripts ad hoc.
vector indexes
La similarité, en index.
La recherche sémantique sur votre contenu, traitée comme de l'infrastructure : déclarée, versionnée, reconstruite par des workflows — jamais régénérée par qui a encore le script.
Un index est une ressource nommée dans votre projet — typée, inspectable et possédée.
Mélangez recherche par plus proches voisins et filtres structurés, pour que les réponses restent dans la bonne voie.
Les constructions d'index sont des workflows — versionnés, reprenables, visibles sur la timeline des runs.
Un index indique s'il sert réellement — vérifié, pas supposé.
pour l'équipe plateforme
La recherche cesse d'être un stack à part et devient une ressource de plus, comptable dans le projet.
contact
Parlez-nous de faire tourner Quark.
Parlez-nous de vos charges — nous vous montrerons ce que votre propre cloud peut faire.