LLM faturan\u0131z neden bekledi\u011finizden y\u00fcksek geliyor? Yapay zeka maliyetlerini art\u0131ran gizli etkenleri, token t\u00fcketimini ve optimizasyon y\u00f6ntemlerini ke\u015ffedin.<\/p>\n
Yapay zeka devrimi, g\u00fcn\u00fcm\u00fczde i\u015fletmelerin operasyonel s\u00fcre\u00e7lerini h\u0131zland\u0131rmak ve kullan\u0131c\u0131 deneyimini benzersiz k\u0131lmak i\u00e7in muazzam f\u0131rsatlar sunmaktad\u0131r. \u00d6zellikle b\u00fcy\u00fck dil modelleri (LLM), m\u00fc\u015fteri hizmetlerinden veri analizine kadar bir\u00e7ok alanda devrim yaratm\u0131\u015ft\u0131r. Ancak, bir\u00e7ok geli\u015ftirici ve i\u015fletme sahibi, bu modelleri canl\u0131ya ald\u0131ktan sonra kar\u015f\u0131la\u015ft\u0131klar\u0131 ilk fatura ile b\u00fcy\u00fck bir \u015fok ya\u015famaktad\u0131r. Genellikle ka\u011f\u0131t \u00fczerinde yap\u0131lan hesaplamalar\u0131n \u00e7ok \u00fczerinde gelen, hatta beklenenin \u00fc\u00e7 kat\u0131n\u0131 a\u015fan LLM maliyetleri, projelerin s\u00fcrd\u00fcr\u00fclebilirli\u011fini ciddi \u015fekilde tehdit etmektedir. Peki, ba\u015flang\u0131\u00e7ta olduk\u00e7a ekonomik g\u00f6r\u00fcnen bu API entegrasyonlar\u0131 nas\u0131l oluyor da bir anda kontrol edilemeyen bir maliyet canavar\u0131na d\u00f6n\u00fc\u015f\u00fcyor?<\/p>\n
Bu makalede, LLM faturan\u0131z\u0131n kontrolden \u00e7\u0131kmas\u0131n\u0131n arkas\u0131ndaki temel teknik nedenleri derinlemesine inceleyece\u011fiz. \u00d6zellikle token t\u00fcketiminin karma\u015f\u0131k yap\u0131s\u0131ndan RAG (Retrieval-Augmented Generation) sistemlerinin getirdi\u011fi ek y\u00fcklere, otonom ajanlar\u0131n d\u00f6ng\u00fcsel hatalar\u0131ndan optimize edilmemi\u015f prompt mimarilerine kadar her detay\u0131 ele alaca\u011f\u0131z. Bununla birlikte, b\u00fct\u00e7enizi korurken yapay zekan\u0131n g\u00fcc\u00fcnden maksimum d\u00fczeyde nas\u0131l yararlanabilece\u011finizi ad\u0131m ad\u0131m \u00f6\u011freneceksiniz. Haz\u0131rsan\u0131z, yapay zeka projelerinde b\u00fct\u00e7e dostu ve y\u00fcksek performansl\u0131 sistemler tasarlaman\u0131n s\u0131rlar\u0131n\u0131 ke\u015ffedelim.<\/p>\n
Yapay zeka modelleriyle \u00e7al\u0131\u015f\u0131rken b\u00fct\u00e7e y\u00f6netiminin temelini anlamak, beklenmeyen maliyet art\u0131\u015flar\u0131n\u0131 engellemenin ilk ad\u0131m\u0131d\u0131r. Klasik bulut bili\u015fim hizmetlerinin aksine, b\u00fcy\u00fck dil modeli servis sa\u011flay\u0131c\u0131lar\u0131 \u00fccretlendirmeyi sunucu \u00e7al\u0131\u015fma s\u00fcresine g\u00f6re de\u011fil, i\u015flenen veri miktar\u0131na g\u00f6re yaparlar. Bu veri miktar\u0131 ise literat\u00fcrde “token” ad\u0131 verilen \u00f6zel birimlerle \u00f6l\u00e7\u00fclmektedir. Dolay\u0131s\u0131yla, ne kadar \u00e7ok token i\u015flenirse, ay sonunda kar\u015f\u0131la\u015faca\u011f\u0131n\u0131z fatura da o denli y\u00fcksek olacakt\u0131r.<\/p>\n
Token kavram\u0131, en basit tan\u0131m\u0131yla, metinlerin yapay zeka modelleri taraf\u0131ndan anlamland\u0131r\u0131labilecek en k\u00fc\u00e7\u00fck par\u00e7alara b\u00f6l\u00fcnm\u00fc\u015f halidir. \u0130ngilizce dilinde bir token yakla\u015f\u0131k olarak 4 karaktere veya 0.75 kelimeye denk gelmektedir. Ancak, T\u00fcrk\u00e7e gibi sondan eklemeli dillerde bu durum olduk\u00e7a farkl\u0131 ve dezavantajl\u0131 bir yap\u0131 sunar. \u00d6rne\u011fin, \u0130ngilizce “running” kelimesi tek bir token olarak i\u015flenebilirken, T\u00fcrk\u00e7e “ko\u015fuyorduk” kelimesi ek yap\u0131lar\u0131ndan dolay\u0131 \u00fc\u00e7 veya d\u00f6rt farkl\u0131 token olarak b\u00f6l\u00fcnebilmektedir. Bu nedenle, T\u00fcrk\u00e7e dilinde geli\u015ftirilen projelerde token t\u00fcketimi do\u011fal olarak daha y\u00fcksek olmaktad\u0131r.<\/p>\n
Buna ek olarak, API sa\u011flay\u0131c\u0131lar\u0131 girdi (input) ve \u00e7\u0131kt\u0131 (output) tokenlar\u0131 i\u00e7in farkl\u0131 tarifeler uygulamaktad\u0131r. Genellikle \u00e7\u0131kt\u0131 tokenlar\u0131, modelin \u00fcretim a\u015famas\u0131nda daha fazla hesaplama g\u00fcc\u00fc gerektirmesi sebebiyle girdi tokenlar\u0131na k\u0131yasla \u00fc\u00e7 kat daha pahal\u0131d\u0131r. Ancak, sistem tasarlan\u0131rken genellikle sadece \u00e7\u0131kt\u0131 maliyetine odaklan\u0131l\u0131r ve devasa girdi maliyetleri g\u00f6z ard\u0131 edilir. \u00d6zellikle ba\u011flam penceresi (context window) b\u00fcy\u00fcd\u00fck\u00e7e, her yeni istekte t\u00fcm ge\u00e7mi\u015f konu\u015fman\u0131n modele tekrar g\u00f6nderilmesi gerekir. Bu durum, do\u011frusal olmayan, aksine katlanarak artan bir maliyet yap\u0131s\u0131 yarat\u0131r.<\/p>\n
Bir\u00e7ok yaz\u0131l\u0131m ekibi, LLM maliyetleri hesaplamas\u0131 yaparken sadece kullan\u0131c\u0131lar\u0131n g\u00f6nderdi\u011fi sorular\u0131 ve modelin verdi\u011fi k\u0131sa yan\u0131tlar\u0131 hesaba katar. Fakat ger\u00e7ek d\u00fcnya senaryolar\u0131nda durum \u00e7ok daha karma\u015f\u0131kt\u0131r. Faturan\u0131z\u0131n bekledi\u011finizin \u00fc\u00e7 kat\u0131na \u00e7\u0131kmas\u0131na neden olan ba\u015fl\u0131ca gizli fakt\u00f6rleri \u015fu \u015fekilde detayland\u0131rabiliriz:<\/p>\n
\u0130lk olarak, sistem y\u00f6nergeleri (system prompts) ve arka plan bilgileri her istekte tekrarlan\u0131r. Modele kimlik kazand\u0131rmak, yan\u0131t format\u0131n\u0131 belirlemek (\u00f6rne\u011fin JSON \u00e7\u0131kt\u0131s\u0131 istemek) ve s\u0131n\u0131rlar\u0131n\u0131 \u00e7izmek i\u00e7in yaz\u0131lan uzun sistem promptlar\u0131, her API \u00e7a\u011fr\u0131s\u0131nda faturan\u0131za eklenir. \u00d6rne\u011fin, 1500 tokenl\u0131k bir sistem promptunuz varsa ve kullan\u0131c\u0131yla 10 ad\u0131ml\u0131 bir sohbet ger\u00e7ekle\u015ftiriliyorsa, sadece sistem promptu y\u00fcz\u00fcnden her ad\u0131mda katlanarak artan binlerce token \u00f6dersiniz. Bu durum, arka planda \u00e7al\u0131\u015fan g\u00f6r\u00fcnmez bir maliyet motoru gibidir.<\/p>\n
\u0130kinci olarak, RAG (Retrieval-Augmented Generation) sistemlerinin getirdi\u011fi veri y\u00fck\u00fc maliyetleri katlamaktad\u0131r. RAG mimarisinde, kullan\u0131c\u0131n\u0131n sorusuna do\u011fru yan\u0131t verebilmek i\u00e7in bir veri taban\u0131ndan ilgili belgeler \u00e7ekilir ve bu belgeler promptun i\u00e7ine g\u00f6m\u00fcl\u00fcr. E\u011fer arama algoritman\u0131z optimize edilmemi\u015fse ve her soru i\u00e7in binlerce kelimelik dok\u00fcmanlar\u0131 modele iletiyorsa, girdi token t\u00fcketiminiz tavan yapacakt\u0131r. \u00d6zellikle gereksiz detaylar i\u00e7eren uzun belgeler, modelin hem kafas\u0131n\u0131 kar\u0131\u015ft\u0131r\u0131r hem de b\u00fct\u00e7enizi t\u00fcketir.<\/p>\n
\u00dc\u00e7\u00fcnc\u00fc olarak, otonom ajanlar\u0131n (agents) kendi aralar\u0131ndaki d\u00f6ng\u00fcsel konu\u015fmalar\u0131 ve ara\u00e7 (tool) kullan\u0131m s\u00fcre\u00e7leridir. Bir g\u00f6revi tamamlamak i\u00e7in kendi kendine kararlar alan ajanlar, bazen bir hata d\u00f6ng\u00fcs\u00fcne (infinite loop) girerek saniyeler i\u00e7inde y\u00fczlerce API \u00e7a\u011fr\u0131s\u0131 yapabilir. Bu durum, siz fark\u0131na bile varmadan b\u00fct\u00e7enizin saatler i\u00e7inde t\u00fckenmesine neden olur. Dolay\u0131s\u0131yla, ajan tabanl\u0131 sistemlerde s\u0131k\u0131 denetim mekanizmalar\u0131 kurulmad\u0131\u011f\u0131 takdirde faturan\u0131n katlanmas\u0131 ka\u00e7\u0131n\u0131lmazd\u0131r.<\/p>\n
Konuyu somutla\u015ft\u0131rmak ad\u0131na, e-ticaret siteleri i\u00e7in ak\u0131ll\u0131 m\u00fc\u015fteri destek botu geli\u015ftiren hayali bir giri\u015fimin ya\u015fad\u0131\u011f\u0131 senaryoyu inceleyelim. Bu giri\u015fim, ayl\u0131k ortalama 10.000 kullan\u0131c\u0131 sohbeti alaca\u011f\u0131n\u0131 \u00f6ng\u00f6rm\u00fc\u015f ve b\u00fct\u00e7esini ba\u015flang\u0131\u00e7ta buna g\u00f6re planlam\u0131\u015ft\u0131r.<\/p>\n
Ba\u015flang\u0131\u00e7ta yap\u0131lan basit hesaplamada, her kullan\u0131c\u0131n\u0131n ortalama 100 kelime yazaca\u011f\u0131 ve botun da 100 kelime yan\u0131t verece\u011fi varsay\u0131lm\u0131\u015ft\u0131r. Toplamda sohbet ba\u015f\u0131na 200 kelime (yakla\u015f\u0131k 270 token) \u00fczerinden bir maliyet \u00e7\u0131kar\u0131lm\u0131\u015ft\u0131r. Ancak, canl\u0131ya ge\u00e7i\u015f sonras\u0131nda ger\u00e7ek senaryo \u015fu \u015fekilde ger\u00e7ekle\u015fmi\u015ftir:<\/p>\n
A\u015fa\u011f\u0131daki tablo, bu giri\u015fimin teorik tahmini ile ger\u00e7ekte kar\u015f\u0131la\u015ft\u0131\u011f\u0131 ac\u0131 tabloyu net bir \u015fekilde ortaya koymaktad\u0131r:<\/p>\n
| Parametre<\/th>\n | Teorik Tahmin (Beklenen)<\/th>\n | Ger\u00e7ekle\u015fen Senaryo (\u00d6denen)<\/th>\n<\/tr>\n<\/thead>\n |
|---|---|---|
| Sohbet Ba\u015f\u0131na Mesaj Say\u0131s\u0131<\/td>\n | 1 Mesaj<\/td>\n | 5 Mesaj (Ortalama)<\/td>\n<\/tr>\n |
| Sistem Promptu Geni\u015fli\u011fi<\/td>\n | 150 Token<\/td>\n | 1,500 Token (Biriken ge\u00e7mi\u015f dahil)<\/td>\n<\/tr>\n |
| RAG Dok\u00fcman Y\u00fck\u00fc<\/td>\n | 0 Token<\/td>\n | 1,200 Token (Her aramada eklenen veriler)<\/td>\n<\/tr>\n |
| Sohbet Ba\u015f\u0131na Toplam Token<\/td>\n | 270 Token<\/td>\n | 8,500 Token (K\u00fcm\u00fcle edilmi\u015f toplam)<\/td>\n<\/tr>\n |
| Ayl\u0131k Toplam Maliyet (10.000 Sohbet)<\/td>\n | ~500 USD<\/td>\n | ~1,580 USD<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Bu vaka analizinden anla\u015f\u0131laca\u011f\u0131 \u00fczere, \u00f6zellikle sohbet ge\u00e7mi\u015finin verimsiz y\u00f6netilmesi ve RAG sisteminden gelen gereksiz veri y\u0131\u011f\u0131nlar\u0131, faturan\u0131n tam 3.1 kat\u0131na \u00e7\u0131kmas\u0131na neden olmu\u015ftur. Bu durum, yaz\u0131l\u0131m mimarisinde optimizasyonun ne denli hayati oldu\u011funu g\u00f6stermektedir.<\/p>\n RAG Sistemlerinde A\u015f\u0131r\u0131 Bilgi Y\u00fcklemesi Maliyeti Nas\u0131l Etkiler?<\/h3>\nRAG mimarileri, modellerin g\u00fcncel ve \u00f6zel verilere eri\u015fmesini sa\u011flad\u0131\u011f\u0131 i\u00e7in g\u00fcn\u00fcm\u00fczde vazge\u00e7ilmezdir. Ancak, bu sistemlerde yap\u0131lan en b\u00fcy\u00fck hata, “ne kadar \u00e7ok veri g\u00f6nderirsem o kadar iyi yan\u0131t al\u0131r\u0131m” yan\u0131lg\u0131s\u0131d\u0131r. Vekt\u00f6r veri taban\u0131ndan d\u00f6nen en yak\u0131n 5 veya 10 dok\u00fcman par\u00e7as\u0131n\u0131 (chunk) do\u011frudan modele beslemek, faturan\u0131z\u0131 do\u011frudan \u015fi\u015firir. Bu durum, hem maliyeti art\u0131r\u0131r hem de modelin oda\u011f\u0131n\u0131 kaybetmesine yol a\u00e7ar.<\/p>\n Bunun yerine, dok\u00fcmanlar\u0131n\u0131z\u0131 daha k\u00fc\u00e7\u00fck ve anlaml\u0131 par\u00e7alara b\u00f6lmeli (chunking strategy), sadece en y\u00fcksek benzerlik skoruna sahip olanlar\u0131 modele g\u00f6ndermelisiniz. Ayr\u0131ca, “Reranking” (yeniden s\u0131ralama) algoritmalar\u0131 kullanarak, modele g\u00f6nderilecek dok\u00fcman say\u0131s\u0131n\u0131 minimumda tutabilirsiniz. B\u00f6ylece, hem modelin yan\u0131t kalitesi artacak hem de girdi token maliyetleriniz ciddi oranda d\u00fc\u015fecektir.<\/p>\n LLM Maliyetlerini Azaltmak \u0130\u00e7in Hangi Yaz\u0131l\u0131msal Optimizasyonlar Yap\u0131lmal\u0131d\u0131r?<\/h2>\nY\u00fcksek LLM maliyetleri asla kader de\u011fildir. Do\u011fru yaz\u0131l\u0131msal mimari ve optimizasyon stratejileriyle faturan\u0131z\u0131 yar\u0131 yar\u0131ya, hatta bazen %70 oran\u0131nda d\u00fc\u015f\u00fcrmeniz m\u00fcmk\u00fcnd\u00fcr. Bunun i\u00e7in uygulayabilece\u011finiz en etkili y\u00f6ntemleri \u015fu \u015fekilde s\u0131ralayabiliriz:<\/p>\n \u0130lk olarak, anlamsal \u00f6nbellekleme (Semantic Caching) mekanizmas\u0131n\u0131 devreye almal\u0131s\u0131n\u0131z. Geleneksel \u00f6nbellekleme sistemleri birebir ayn\u0131 sorgular\u0131 yakalarken, anlamsal \u00f6nbellekleme benzer anlama gelen sorular\u0131 tespit eder. \u00d6rne\u011fin, “\u015eifremi nas\u0131l s\u0131f\u0131rlar\u0131m?” sorusu ile “\u015eifre s\u0131f\u0131rlama ad\u0131mlar\u0131 nelerdir?” sorusu ayn\u0131 anlama gelir. E\u011fer bu sorular\u0131n yan\u0131t\u0131 daha \u00f6nce \u00fcretilmi\u015fse, LLM API’sine gitmeden do\u011frudan \u00f6nbellekten yan\u0131t verilebilir. Bu y\u00f6ntem, \u00f6zellikle s\u0131k\u00e7a sorulan sorular\u0131n yo\u011fun oldu\u011fu m\u00fc\u015fteri hizmetleri sistemlerinde maliyetleri dramatik \u015fekilde d\u00fc\u015f\u00fcr\u00fcr.<\/p>\n \u0130kinci olarak, konu\u015fma ge\u00e7mi\u015fini y\u00f6netirken “kayan pencere” (sliding window) veya \u00f6zetleme (summarization) tekniklerini kullanmal\u0131s\u0131n\u0131z. T\u00fcm konu\u015fma ge\u00e7mi\u015fini her istekte g\u00f6ndermek yerine, sadece son 3 mesaj\u0131 g\u00f6nderebilir veya ge\u00e7mi\u015f konu\u015fmay\u0131 periyodik olarak \u00f6zetleyip tek bir paragraf halinde ba\u011flama ekleyebilirsiniz. B\u00f6ylece, konu\u015fma uzad\u0131k\u00e7a artan token t\u00fcketiminin \u00f6n\u00fcne ge\u00e7mi\u015f olursunuz.<\/p>\n Python ile Token T\u00fcketimi Nas\u0131l Hesaplan\u0131r?<\/h3>\nMaliyetleri optimize etmenin ilk kural\u0131, ne harcad\u0131\u011f\u0131n\u0131z\u0131 tam olarak \u00f6l\u00e7mektir. Python ekosisteminde, OpenAI modelleri i\u00e7in token hesaplamas\u0131n\u0131 API’ye istek atmadan \u00f6nce lokal olarak yapman\u0131z\u0131 sa\u011flayan harika bir k\u00fct\u00fcphane vard\u0131r: A\u015fa\u011f\u0131daki kod \u00f6rne\u011finde, bir metnin ka\u00e7 token t\u00fcketti\u011fini nas\u0131l hesaplayabilece\u011finizi ve maliyet analizi yapabilece\u011finizi g\u00f6rebilirsiniz:<\/p>\n Bu basit script sayesinde, kullan\u0131c\u0131 isteklerini API’ye g\u00f6ndermeden \u00f6nce filtreleyebilir, \u00e7ok uzun girdileri s\u0131n\u0131rland\u0131rabilir ve b\u00fct\u00e7e a\u015f\u0131m\u0131n\u0131 engelleyecek kurallar tan\u0131mlayabilirsiniz. \u00d6zellikle kullan\u0131c\u0131lar\u0131n sisteme \u00e7ok uzun metinler yap\u0131\u015ft\u0131rmas\u0131n\u0131 engelleyerek maliyet g\u00fcvenli\u011fi sa\u011flayabilirsiniz.<\/p>\n E\u011fer temel optimizasyonlar\u0131 tamamlad\u0131ysan\u0131z ve hala y\u00fcksek maliyetlerle m\u00fccadele ediyorsan\u0131z, daha ileri d\u00fczey mimari de\u011fi\u015fiklikleri d\u00fc\u015f\u00fcnmenin vakti gelmi\u015f demektir. Bu a\u015famada sisteminizi daha ak\u0131ll\u0131 ve dinamik hale getirmeniz gerekir.<\/p>\n Bunlardan ilki, “Model Y\u00f6nlendirme” (Model Routing) mekanizmas\u0131d\u0131r. Her g\u00f6rev i\u00e7in en pahal\u0131 ve en geli\u015fmi\u015f modeli (\u00f6rne\u011fin GPT-4o veya Claude 3.5 Sonnet) kullanmak zorunda de\u011filsiniz. Basit s\u0131n\u0131fland\u0131rma, veri formatlama veya k\u0131sa yan\u0131t \u00fcretme gibi g\u00f6revleri GPT-4o-mini veya Llama 3 gibi \u00e7ok daha ucuz modellere y\u00f6nlendirebilirsiniz. Sadece karma\u015f\u0131k ak\u0131l y\u00fcr\u00fctme (reasoning) gerektiren ad\u0131mlarda b\u00fcy\u00fck modelleri tetikleyen bir y\u00f6nlendirici yaz\u0131l\u0131m yazmak, maliyetlerinizi optimize etmenin en profesyonel yoludur.<\/p>\n Di\u011fer bir strateji ise ince ayar (Fine-Tuning) yapmakt\u0131r. \u00c7ok uzun promptlar ve \u00f6rnekler (few-shot prompting) kullanarak b\u00fcy\u00fck bir modele ne yapaca\u011f\u0131n\u0131 \u00f6\u011fretmek yerine, daha k\u00fc\u00e7\u00fck ve ucuz bir modele kendi verilerinizle ince ayar yapabilirsiniz. B\u00f6ylece, her istekte uzun y\u00f6nergeler g\u00f6ndermek zorunda kalmazs\u0131n\u0131z ve k\u00fc\u00e7\u00fck modelden b\u00fcy\u00fck model kalitesinde \u00e7\u0131kt\u0131lar alabilirsiniz. Bu hem yan\u0131t s\u00fcresini (latency) d\u00fc\u015f\u00fcr\u00fcr hem de maliyetleri minimize eder.<\/p>\n B\u00fcy\u00fck dil modellerinin maliyet y\u00f6netimi, s\u00fcrekli izleme ve optimizasyon gerektiren dinamik bir s\u00fcre\u00e7tir. Do\u011fru mimari ad\u0131mlar\u0131 atarak faturan\u0131z\u0131 kontrol alt\u0131na alabilir ve projelerinizi \u00f6l\u00e7eklenebilir k\u0131labilirsiniz. \u0130\u015fte bu s\u00fcre\u00e7te en \u00e7ok merak edilen sorular ve yan\u0131tlar\u0131:<\/p>\n \u0130lk olarak, sisteminizdeki token t\u00fcketimini izlemeye ba\u015flamal\u0131s\u0131n\u0131z. Hangi kullan\u0131c\u0131lar\u0131n veya hangi mod\u00fcllerin en \u00e7ok token t\u00fcketti\u011fini tespit etmek i\u00e7in loglama altyap\u0131s\u0131 kurun. Ard\u0131ndan, en \u00e7ok t\u00fcketen alanlarda anlamsal \u00f6nbellekleme (semantic caching) uygulay\u0131n.<\/p>\n \u00c7\u00fcnk\u00fc mevcut LLM’lerin tokenizasyon (kelimeleri par\u00e7alara ay\u0131rma) algoritmalar\u0131 a\u011f\u0131rl\u0131kl\u0131 olarak \u0130ngilizce verilerle e\u011fitilmi\u015ftir. T\u00fcrk\u00e7e gibi eklemeli dillerdeki kelimeler daha fazla k\u00fc\u00e7\u00fck par\u00e7aya (token) b\u00f6l\u00fcn\u00fcr. Bu durum, ayn\u0131 uzunluktaki bir T\u00fcrk\u00e7e metnin, \u0130ngilizce metne g\u00f6re yakla\u015f\u0131k 1.5 ila 2 kat daha fazla token t\u00fcketmesine yol a\u00e7ar.<\/p>\n Her zaman de\u011fil. Llama veya Mistral gibi a\u00e7\u0131k kaynakl\u0131 modelleri kendi sunucular\u0131n\u0131zda bar\u0131nd\u0131rmak, API \u00fccretini s\u0131f\u0131rlasa da ciddi bir GPU altyap\u0131 ve bak\u0131m maliyeti getirir. E\u011fer trafik hacminiz \u00e7ok y\u00fcksekse a\u00e7\u0131k kaynakl\u0131 modeller daha ekonomiktir; ancak d\u00fc\u015f\u00fck ve d\u00fczensiz trafiklerde API kullanmak genellikle daha ucuzdur.<\/p>\n Dok\u00fcmanlar\u0131n\u0131z\u0131 200-500 tokenl\u0131k k\u00fc\u00e7\u00fck par\u00e7alara (chunks) b\u00f6lmek en ideal yakla\u015f\u0131md\u0131r. Ayr\u0131ca, modele sadece sorunun cevab\u0131n\u0131 bar\u0131nd\u0131rma olas\u0131l\u0131\u011f\u0131 en y\u00fcksek olan ilk 2 veya 3 par\u00e7ay\u0131 g\u00f6ndermek, girdi token maliyetlerini minimize etmenizi sa\u011flar.<\/p>\n |