'OpenAI wil gebruik van zijn AI-modellen goedkoper maken voor ontwikkelaars'

OpenAI is van plan om het voor ontwikkelaars goedkoper te maken om zijn AI-modellen te gebruiken voor het maken van softwareapplicaties. Dat beweert Reuters op basis van gesprekken met ingewijden. De AI-reus zou meer bedrijven willen overhalen om zijn technologie te gebruiken.

Volgende maand wil OpenAI enkele updates uitbrengen die onder meer het gebruik van de AI-modellen goedkoper moet maken, schrijft Reuters. Er zou bijvoorbeeld 'geheugenopslag' toegevoegd worden aan de ontwikkelaarstools voor gebruik van zijn AI-modellen. Hiermee kunnen de kosten voor ontwikkelaars theoretisch gezien tot twintig keer zo laag uitvallen, beweert het persbureau. De 'stateful'-api moet de gespreksgeschiedenis van api-verzoeken onthouden, waardoor ontwikkelaars een stuk minder nieuwe inquiry's hoeven te doen om hetzelfde resultaat te bereiken. Dat zou de kosten 'significant' kunnen verlagen.

Een veelgehoorde klacht vanuit klanten zou namelijk zijn dat de kosten voor het gebruik van de geavanceerde AI-modellen snel kunnen oplopen. De nieuwe functies moeten meer bedrijven ervan overtuigen om met OpenAI's technologie chatbots en andere AI-toepassingen te maken, zeggen bronnen tegen Reuters. Hiermee zou OpenAI willen bereiken dat het bedrijf niet enkel populair is onder consumenten, maar ook onder ontwikkelaars. Dat laatste wil naar verluidt nog niet helemaal lukken. Zo zouden de plug-ins van ChatGPT inmiddels nog maar zeer weinig gebruikt worden door zakelijke klanten.

Naast updates om het gebruik voor ontwikkelaars rendabeler te maken, moeten er tegelijk ook updates komen die meer functies voor deze gebruikersgroep beschikbaar stellen. Als voorbeeld wordt de 'vision api' genoemd. Die stelt ontwikkelaars in staat om applicaties te ontwikkelen waarmee afbeeldingen geanalyseerd en beschreven kunnen worden. Eerder werd deze functie al voor ChatGPT uitgebracht. De updates worden naar verwachting aangekondigd op het ontwikkelaarscongres van OpenAI op 6 november in San Francisco, aldus Reuters.

Reacties (31)

[KoenLemmen]

Als dit betekent dat ik niet steeds voor de hele context moet betalen, gaat dit inderdaad een grote en zeer interessante verandering zijn. Ik vind het zo jammer dat je elke keer opnieuw moet betalen voor je hele context. Het is vaak veel goedkoper om een nieuwe context te beginnen of je eerste bericht te bewerken dan bijvoorbeeld een nieuw bericht met extra informatie te sturen. Ik zou de API zeker op grotere schaal willen inzetten, maar als ik elke keer betaal voor tokens waar ik eigenlijk al een keer eerder voor heb betaald, wordt dat steeds duurder naarmate de conversatie langer doorgaat. Het ontmoedigt ook kleine berichten; "Thanks" sturen (1 token) aan het einde van een enorm gesprek kost je in verhouding heel veel. Dit soort cases allemaal opvangen met programmeren doet het doel van de AI een beetje teniet.

[Caelorum]

De prijs van de tokens zit hem in het tokenizen, maar zeker ook die tokens meegeven aan het daadwerkelijke model. Dat laatste kunnen ze niets aan doen. Als je die informatie mee wilt geven, zodat het gebruikt kan worden voor je antwoord, zullen ze altijd die kosten hebben. (totdat iemand iets beters vind dan deze huidige LLM modellen).
Het enige wat je zelf als ontwikkelaar kan doen is de informatie in een vector database gooien zodat je de context klein en to the point kan houden bij het doorgeven + bepaalde zaken eruit filteren zoals die thanks op het einde. Wat ook kan helpen is het antwoord realtime tokenizen met een approx. implementatie van openai en dan de verwachte kosten berekenen en tonen aan de gebruiker. Mogelijk kan je die nog een incentive geven om iets meer kort en bondig dingen te vragen.

[MSalters]

Aan dat laatste kunnen ze zeker wél wat doen. Het punt is dat het model al eens eerder diezelfde prefix aan tokens heeft gezien, en het model tot dat punt doorgerekend heeft. Als je die intermediate state cachet, dan kun je vanaf dat punt doorrekenen.

Om het voorbeeld van hierboven aan te halen, "Thanks" kun je ook parsen zonder de vorige 10.000 woorden opnieuw door het model te halen, mits je de state na 10.000 woorden hebt gecached.

Dit hoeft overigens geen API change met zich mee te brengen; OpenAI kan ook de tokenlijst intern hashen en als cache key gebruiken. De API change scheelt alleen netwerk traffic, geen GPU rekentijd.

[Caelorum]

Nee, als je temperature op 0 zet is dat misschien het geval, maar alle andere settings zal het model niet meer deterministisch zijn. En je wil dat ook niet op 0 zetten tenzij je enorm robot-achtoge responses wil krijgen. Dat "beetje" randomness zorgt er juist voor dat een model als chatgpt atuurlijker aanvoelt en ook meteen waarom cachen geen nut meer heeft. (Nog even los van dat je aan de api meerdere antwoorden tegelijkertijd kan vragen)

[MSalters]

DIe "temperature" is niets magisch - state is state. Als je die state bewaart, dan kun je daarop verder gaan. Hoe die state precies verandert, en waardoor, dat maakt daarvoor niet uit.

[Caelorum]

Die temperature zorgt ervoor dat er random waardes worden gebruikt zodat niet telkens de statistisch meest waarschijnlijke volgende woord wordt gekozen. Dus dat cachen is leuk, maar dan kan je dus ook nooit een ander antwoord krijgen.
Maar een beter probleem is dat als je die state wel gaat cachen dat elke aanroep met dezelfde waarden een andere cache entry zou moeten krijgen wil je die functionaliteit wel behouden. Kan je de benodigde opslag daarvoor indenken?

Het is gewoon niet fatsoenlijk haalbaar zonder dat de prijs enorm omhoog moet gaan. Precies waarvoor je caching wilt implementeren.

[MSalters]

Dat is inderdaad precies het idee - dat je géén andere antwoorden krijgt in een bestaande conversatie, met terugwerkende kracht, door caching. Die termperature gebruik je alleen voor het volgende antwoord - dus die "Thanks" na de eerste duizend tokens.

En de cache kosten? Dat hangt af van de model state, die niet publiek is. Op basis van weights gok ik een paar megabyte. Dus met een 1 TB SSD kun je er al vele tienduizenden cachen.

[djwice]

Het gaat hier om een stochastisch model, dat betekent dat een trekking met dezelfde input niet per definitie het zelfde antwoord oplevert.

"Thanks" kan sarcasme betekenen of blijheid of neutraal, of een standaard onbeduidende reactie, dat hangt af van de context van het gesprek.

De interpretatie van het hele context kan theoretisch dus wijzigen door dat ene, een woordiger antwoord.

[KoenLemmen]

Ik begrijp dat meer tokens samengaan met hogere computationele kosten en het dus logisch is dat deze worden doorberekend naar de gebruiker, dat maakt het natuurlijk niet minder jammer. Echter, als OpenAI mij uit noodzaak wil chargen voor de volledige voorgaande conversatie - inclusief hun eigen soms erg lange antwoorden - vind ik dat ze best wat meer tools mogen aanbieden om ontwikkelaars daarin te ondersteunen. Je noemt zelf al enkele oplossingen, maar het blijft een uitdaging om efficiëntie en kostenbeheersing te balanceren zonder de kwaliteit van de interacties te verminderen, die noodzaak ziet OpenAI zelf ook als ze stappen nemen om het goedkoper te maken op basis van feedback van de zakelijke kant. Als de API zowel nuttig als kostenefficiënt moet zijn, zou er een mechanisme moeten zijn dat ontwikkelaars helpt om te navigeren door complexe conversaties zonder dat de rekening de pan uit rijst.

[Artimunor]

precies dit, en dat je ook de hele geschiedenis telkens weer mee moet sturen, en dan gaat editen optimizen is heel irritant.

[Orangelights23]

GPT-4 is al vele malen goedkoper duurder dan GPT3/GPT3.5, maar het is nog lastig in te schatten wat de daadwerkelijke kosten zijn omdat het tellen van tokens niet geheel duidelijk is voor eindgebruikers. Binnen mijn oude organisatie werd al veel met OpenAI gedaan en zijn er applicaties ontwikkeld, maar het werd experimenteren werd al snel een halt toegeroepen door de grote stijging van kosten. Is wel een maand of drie geleden, zou kunnen dat de kosten inmiddels aangepast zijn.

Typo natuurlijk, bedoelde duurder dan goedkoper. En ik heb nog met OpenAI om de tafel gezeten om dit te bespreken, hehe...

[Reactie gewijzigd door Orangelights23 op 23 juli 2024 11:29]

[jketelaar]

GPT3.5 is volgens mij een stuk goedkoper dan GPT-4? (https://openai.com/pricing)

[Orangelights23]

Helemaal correct, heb mijn reactie aangepast omdat ik het omgedraaid had. In ons geval hadden wij een grote korting bedongen op GPT-4 en is het goedkoper.

[servicedb]

Aan wat voor app werk je dan?

[Orangelights23]

Ik niet, maar de organisatie waar ik voor werk. We gebruiken het al voor interne documentatie, samenvattingen van meetings, suggesties aan klanten, enzovoorts. Denk dat we sinds begin dit jaar zo’n 27 initiatieven hebben voor zowel interne als externe toepassingen. Heeft er onder andere toe geleid dat ik mijn team heb verkleind en we twee klantenservice contracten op hebben kunnen zeggen. Gaat om miljoenen aan besparingen - nu al.

[Ritseb]

GPT3.5 Turbo is echt vele malen goedkoper.

GPT4 8K context $0.03 / 1K tokens $0.06 / 1K tokens
GPT 3.5 Turbo 4K context $0.0015 / 1K tokens $0.002 / 1K tokens

[BramVroy]

Geen idee vanwaar dat komt wat jij zegt. 3.5 is veel goedkoper, en ze zijn enorm transparent over hun tokenisatie. Je kan ook de kosten programmatisch berekenen met hun python tiktoken library.

[Orangelights23]

Zie edit, had het verkeerd opgeschreven. In ons geval was GPT-4 goedkoper.

Stuk over kosten gaat niet om de kostprijs waar ik op doelde. Door onze toepassingen en ontwikkelde applicaties is het lastig om overzicht te houden qua kosten, aangezien steeds meer developers toepasten binnen hun activiteiten. Gaat dus meer om wildgroei.

[Coy]

Om heel eerlijk te zijn denk ik dat de drempel eerder moet zijn dat je vertrouwelijke info toevertrouwd aan een blackbox AI model waarbij het nog maar de vraag is of er voldaan kan worden aan gegevensbeschermingsverplichtingen omdat wat je er in stopt er niet zomaar meer uit kan halen.

[Yaz]

Gelukkig kan je via Azure private instances krijgen van OpenAI. Dit gebruiken wij en alle data blijft van ons en wordt niet gedeelt.

[svane]

Met OpenAI Enterprice gebruiken ze je data ook niet.

Dus als dat je voornaamste reden is hoef je niet per se alles op Azure neer te zetten

[BoomSmurf]

Azure is wel een stukje makkelijker binnen te komen dan OpenAI Enterprise.

[thePiett]

Iets van een cache laag bovenop de API drukt natuurlijk de kosten, maar uiteraard ook het energiegebruik. Prima ontwikkeling lijkt me.

[servicedb]

Een cache bovenop de API gaat niet helpen, ai modellen kennen een behoorlijke dynamiek.

[MSalters]

Uit eigen ervaring kan ik vertellen dat het zeker wel uitmaakt. Die AI modellen worden vanuit persistent storage naar een GPU/TPU geladen. Direct na een AI query zou je een ander AI model naar die GPU kunnen laden, maar je kunt ook die GPU even in een "cache" houden voor het geval dat iemand anders hetzelfde AI model wil gebruiken. Hoe vaak moet je wisselen tussen GPT-4 32K en GPT-4 8K ?

[servicedb]

Dan zit je al onder de API. ThePiett heeft het er over om het bovenop te plaatsen.

[Jim80]

Commerciëel heel slim natuurlijk. Stimuleer volop het maken van producten om vervolgens de hoofdprijs aan de eindgebruiker te kunnen rekenen.

[Menesis]

naja geld is voor ons op het werk niet de reden om geen gebruik te maken van hun API. Dat is het feit dat je data naar de US stuurt.
Beter is om een eigen instance op Azure te runnen, maar ook dat dekt alle risico's natuurlijk niet.. On premise zou mooi zijn.

[satya]

Microsoft heeft een azure gpt variant voor gebruik binnenshuis dacht ik.

https://azure.microsoft.c.../openai-service/#Security

[roawser]

Wel goed natuurlijk en eigenlijk onmisbaar. Op dit moment is ChatGTP eigenlijk een superslimme goudvis. Ik heb dingen geprobeerd als "als ik de grondwet noem, moet je je inbeelden dat ik je alle 142 artikelen letterlijk gegeven heb" maar dat werkte nog niet al te succesvol. Het zou mooi zijn als je zelf in een eigen namespace o.i.d eenvoudig begrippen kon definiëren, en die gebruiken. Finetuning is daar toch niet echt geschikt voor.

[SPee]

Dit is wel een goede manier om te voorkomen dat er (veel) concurrentie bij komt.
Zorg dat je product betaalbaar (genoeg) bljjft, zodat men niet naar alternatieven gaat zoeken of maken, maar jouw product gebruikt.
Hierdoor heb je niet opeens een opensource variant die even goed is als jouw commerciele versie.