Scalable Inference Architectures for Compound AI Systems: A Production Deployment Study
Dit artikel presenteert een studie van een productiedeployering van een modulaire, platformonafhankelijke inferentie-architectuur bij Salesforce die schaalbare, kosteneffectieve en laag-latente levering van samengestelde AI-systemen zoals Agentforce en ApexGuru mogelijk maakt, met aanzienlijke verbeteringen in doorvoer, tail-latentie en operationele kosten, terwijl unieke uitdagingen zoals multi-model fan-out en cascaderende koude starts worden aangepakt.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je een drukke, high-end restaurant runt dat Agentforce heet. In het verleden had dit restaurant één grote, massale keuken (een "statische" opstelling) waar één chef-kok alles probeerde te doen: groenten snijden, biefstukken grillen, desserts bakken en afwassen. Als het restaurant druk werd, raakte de keuken verstopt. Als de chef een pauze nodig had om uit te rusten (een "cold start"), stopte het hele restaurant met het serveren van eten. En het ergste van alles was dat je het salaris van de chef 24/7 moest betalen, zelfs als niemand at.
Dit artikel beschrijft hoe Salesforce hun "restaurant" herbouwde om Compound AI Systems aan te kunnen. In plaats van één grote keuken, bouwden ze een modulair, on-demand netwerk voor levensmiddelenbezorging.
Hier is hoe ze dat deden, uitgelegd in eenvoudige termen:
1. Het Probleem: De "One-Size-Fits-All" Keuken
Moderne AI-toepassingen (zoals Agentforce of ApexGuru) zijn complex. Wanneer een klant een vraag stelt, vraagt het systeem niet één robot om te antwoorden. Het is meer als een team van specialisten die samenwerken:
- Specialist A (Embedding Model) zoekt de geschiedenis van de klant op.
- Specialist B (LLM) schrijft het antwoord.
- Specialist C (SQL Executor) controleert de database.
- Specialist D (Classifier) beslist wat de klant eigenlijk wil.
In de oude "statische" opstelling zaten al deze specialisten in dezelfde ruimte op dezelfde hardware.
- De Bottleneck: Als de databasespecialist traag was, werd de hele bestelling vertraagd.
- De Verspilling: Je moest alle specialisten wakker en klaar houden 24/7, zelfs als alleen de "snij-specialist" om 3 uur 's nachts nodig was.
- De "Cold Start"-Nachtmerrie: Als het restaurant een uur gesloten was en weer opende, moest elke specialist wakker worden, rekken en hun gereedschap klaarzetten. De klant moest wachten op de traagste die wakker werd voordat er eten werd geserveerd.
2. De Oplossing: Een "Slim Bezorgnetwerk"
Salesforce bouwde een nieuwe architectuur die fungeert als een slimme, dynamische bezorgservice.
- De Bestellingnemer (Prediction Service): Wanneer een klant bestelt, stuurt een slimme dispatcher de bestelling niet naar één grote keuken. In plaats daarvan breekt hij de bestelling op in delen en stuurt deze naar de specifieke specialisten die het beste geschikt zijn voor de taak.
- Onafhankelijke Schaalbaarheid: Als 100 mensen "biefstuk" bestellen (LLM-aanroepen), huurt het systeem direct 100 biefstukchefs in. Als slechts 5 mensen "salade" bestellen (embedding-aanroepen), huurt het slechts 5 saladechefs in. Ze vechten niet om ruimte in dezelfde keuken.
- Serverless (Pay-As-You-Go): De specialisten zitten niet in een gebouw te wachten op bestellingen. Ze zijn "cloudwerkers" die alleen verschijnen wanneer een bestelling binnenkomt en vertrekken wanneer ze klaar zijn. Je betaalt alleen voor de minuten dat ze daadwerkelijk werken.
3. Het Oplossen van het "Wakker Worden"-Probleem (Cascading Cold Starts)
Het artikel ontdekte een lastig probleem: In een compound-systeem zijn de specialisten afhankelijk van elkaar. Specialist A moet klaar zijn voordat Specialist B kan beginnen.
- De Oude Manier: Als het restaurant weer opent, wordt Specialist A wakker (30 seconden), dan wordt Specialist B wakker (150 seconden), dan wordt Specialist C wakker (20 seconden). De klant wacht in totaal 180 seconden.
- De Nieuwe "Pre-Warming"-Truc: Het systeem is slim genoeg om het recept te kennen. Zodra Specialist A wordt aangeroepen, wekt het systeem tegelijkertijd Specialist B en C op op de achtergrond.
- Het Resultaat: In plaats van 180 seconden te wachten, wacht de klant slechts ongeveer 65 seconden. Het artikel zegt dat dit de "wakker word"-tijd met 65% heeft verkort.
4. De Resultaten: Sneller, Goedkoper en Soepeler
Na het draaien van dit nieuwe systeem gedurende meer dan een jaar met echte klanten, gebeurde het volgende:
- Snelheid: De "tail latency" (de worst-case wachttijd voor trage klanten) daalde met 50%. Bestellingen die eerder 37 seconden duurden, duren nu ongeveer 10–11 seconden.
- Capaciteit: Het systeem kan 3,9 keer meer bestellingen tegelijk afhandelen in vergelijking met de oude keuken.
- Kosten: Omdat ze stopten met het betalen voor werkloze werknemers, bespaarden ze 30–40% op de kosten.
- Betrouwbaarheid: Als één specialist ziek wordt (faalt), zet het systeem niet het hele restaurant stil. Het routeert de bestelling gewoon om die persoon heen (bijvoorbeeld: "We kunnen de database niet controleren, dus laten we gewoon een algemeen antwoord geven"). Het restaurant blijft 95% van de tijd open, zelfs als onderdelen stuk gaan.
5. Belangrijkste Lessen (De "Geheimen van de Chef")
De auteurs deelden een paar grote inzichten voor iedereen die deze systemen bouwt:
- Cold starts vermenigvuldigen zich, ze tellen niet gewoon op. Als je een keten van taken hebt, stapelt de wachttijd zich op. Je moet de hele keten tegelijk wakker maken, niet één voor één.
- Kijk naar de hele pijplijn, niet alleen naar individuele werknemers. Een werknemer kan op zichzelf snel zijn, maar als ze vastzitten in het wachten op iemand anders, is de hele bestelling traag. Je moet het "grote plaatje" van de bestelling zien.
- Test onderdelen individueel. Omdat het systeem modulair is, kun je alleen de "saladechef" vervangen door een nieuwe zonder de "biefstukchef" te ontslaan. Dit stelt hen in staat hun AI-modellen in dagen te verbeteren in plaats van weken.
- Graceful degradation is beter dan perfectie. Als een klein deel van het systeem faalt, moet het hele ding niet crashen. Het is beter om een iets minder gedetailleerd antwoord te geven dan helemaal geen antwoord.
Samenvatting
Dit artikel gaat over de overstap van een stijve, dure "één-keuken"-AI-opstelling naar een flexibel, "gig-economy"-achtig netwerk. Door elke AI-tool te behandelen als een aparte, on-demand werknemer die direct omhoog of omlaag geschaald kan worden, maakte Salesforce hun AI-agents sneller, goedkoper en veel betrouwbaarder voor duizenden enterprise-gebruikers.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.