Token Nedir? Yapay Zeka API Maliyeti Nasıl Hesaplanır?

Token nedir?

Token, bir büyük dil modelinin metni okurken ve yazarken kullandığı en küçük parçadır. Bir token bazen tam bir kelime, bazen kelimenin bir hecesi, bazen de tek bir noktalama işaretidir. API sağlayıcıları faturayı bu parçaların sayısına göre keser.

Bu tanım basit görünür, ancak maliyetin tamamı bu kavramın üzerine kurulur. Modele gönderdiğiniz her soru, her ek belge ve her talimat token olarak sayılır. Modelin yazdığı cevap da token olarak sayılır.

Dolayısıyla "bu işe ne kadar ödeyeceğim?" sorusunun cevabı, "kaç token harcayacağım?" sorusundan geçer. Bu yazıda token nedir sorusunu sade anlatıyoruz, sonra varsayımsal bir örnek hesap yapıyoruz. Ardından maliyeti düşürmenin yollarını ve bütçe kontrolünü ele alıyoruz.

Not: Bu yazı genel bilgi içindir. Birim fiyatlar ve model özellikleri sık değişir, bu nedenle güncel değerleri sağlayıcının resmi sayfasından kontrol etmenizi öneririz.

Token ile kelime aynı şey midir?

Hayır, aynı şey değildir. Model metni önce küçük parçalara böler. Bu işleme tokenizasyon denir. Sık geçen kısa kelimeler genellikle tek token olur. Nadir, uzun veya birleşik kelimeler ise birkaç parçaya ayrılır.

Örneğin "ev" gibi kısa bir kelime tek parça kalabilir. Buna karşılık "değerlendirilebilirlik" gibi uzun bir kelime birkaç parçaya bölünebilir. Sayılar, boşluklar, emojiler ve kod parçaları da kendi token sayılarını getirir.

Pratikte şu üç noktayı aklınızda tutun:

• Kelime sayısı ile token sayısı birebir eşleşmez.
• Metin türü sonucu değiştirir. Düz yazı, tablo, kod ve JSON farklı yoğunlukta token üretir.
• Her model ailesi kendi tokenizasyon yöntemini kullanır, yani aynı metin iki modelde farklı sayıda token tutabilir.

Kısacası "bin kelime = şu kadar token" gibi sabit bir oran vermek yanıltıcıdır. Kesin sayıyı görmek için sağlayıcının sunduğu sayaç aracını kullanın. OpenAI'nin tokenizer sayfası bu amaçla kullanılan örneklerden biridir.

Tokenizasyon pratikte nasıl çalışır?

Tokenizasyon, metni önceden öğrenilmiş bir parça listesine göre bölmektir. Bu liste sözlük gibi düşünülebilir. Model her metni bu listedeki parçalarla eşleştirir ve her parçaya bir numara verir. Model aslında kelimeleri değil, bu numaraları işler.

Bu yüzden aynı kelime farklı bağlamda farklı bölünebilir. Başında boşluk olan bir kelime ile satır başındaki aynı kelime ayrı parça olabilir. Büyük harfle yazılmış hali de ayrı sayılabilir. Küçük farklar toplamda fark yaratır.

Token nedir sorusunu mühendislik açısından cevaplarsak, token modelin sözlüğündeki bir giriş numarasıdır. İş açısından ise faturanın ölçü birimidir. Bu iki bakışı birleştirmek, doğru bütçe yapmanın ilk adımıdır.

Uygulamada şunu unutmayın: Biçimlendirme de token tüketir. Fazla boşluk, uzun tablo çizgileri, tekrar eden başlıklar ve gereksiz JSON alanları sayıyı artırır. Girdiyi temiz ve sade tutmak hem maliyeti hem hatayı azaltır.

Token nedir sorusunun Türkçe ve Almanca boyutu: dil sayıyı etkiler mi?

Etkileyebilir. Tokenizasyon yöntemleri çoğunlukla İngilizce metinlerin yoğun olduğu verilerle şekillenir. Bu nedenle İngilizce metin genellikle daha az parçaya bölünür. Türkçe ve Almanca gibi çekim ekleri ve birleşik kelimeleri bol diller ise aynı anlamı anlatmak için sıklıkla daha fazla token tutabilir.

Türkçede bir kelimeye birkaç ek eklendiğinde kelime birden fazla parçaya ayrılabilir. Almancada "Kundenzufriedenheitsumfrage" gibi uzun bileşik kelimeler de benzer şekilde bölünür. Ayrıca özel karakterler (ğ, ş, ı, ä, ö, ü, ß) bazı tokenizasyon yöntemlerinde ek parça gerektirebilir.

Burada kesin bir oran vermiyoruz, çünkü oran modele ve metne göre değişir. Doğru yaklaşım şudur: Kendi metninizi, kullanacağınız modelin sayaç aracında deneyin. Böylece gerçek ihtiyacınızı görürsünüz.

Bu durumun iş tarafındaki sonucu açık. Türkçe veya Almanca müşteri mesajlarını işleyen bir sistem kuruyorsanız, bütçenizi İngilizce örneklerden çıkardığınız sayılarla yapmayın. Kendi dilinizdeki gerçek mesajlarla küçük bir deneme yapın.

Bağlam penceresi nedir ve token ile ilişkisi nasıldır?

Bağlam penceresi, modelin tek bir istekte aynı anda "görebildiği" toplam token miktarıdır. Bu miktara hem sizin gönderdiğiniz girdi hem de modelin üreteceği çıktı dahildir. Pencere dolarsa model eski kısımları göremez veya istek hata verir.

Bir sohbet uygulaması yaptığınızı düşünün. Her yeni mesajda önceki konuşmayı da göndermeniz gerekebilir. Yani konuşma uzadıkça her istek daha çok token taşır. Maliyet de buna paralel artar.

Bağlam penceresinin büyüklüğü modele göre değişir ve hızla eskiyen bir bilgidir. Bu yüzden rakam yazmıyoruz. Güncel sınırı sağlayıcının model sayfasından kontrol edin.

Büyük pencere, büyük belgeleri tek seferde göndermenin ücretsiz olduğu anlamına da gelmez. Her gönderdiğiniz token için ödeme yaparsınız. Üstelik çok uzun bağlamlarda modelin önemli ayrıntıları kaçırma riski de artabilir. Bu nedenle yalnızca gerekli parçayı göndermek hem ucuz hem verimli bir yöntemdir. Şirket belgeleriyle çalışan sistemlerde bunu RAG yaklaşımı çözer: tüm belgeyi değil, soruyla ilgili parçaları gönderirsiniz.

Girdi tokenı ile çıktı tokenı arasındaki fark nedir?

Girdi tokenı, modele gönderdiğiniz her şeydir: talimat, soru, örnekler, önceki konuşma ve eklediğiniz belgeler. Çıktı tokenı ise modelin yazdığı cevaptır. İkisi de sayılır, fakat çoğu sağlayıcı bu ikisi için farklı birim fiyat uygular.

Genel uygulamada çıktı tokenı girdi tokenından daha pahalı olur. Çünkü modelin yeni metin üretmesi, mevcut metni okumasından daha fazla hesaplama gerektirir. Oranı sağlayıcı belirler ve değişebilir, dolayısıyla fiyat sayfasına bakmanız gerekir.

Bu ayrım pratikte önemli bir ipucu verir. Uzun cevap isteyen işlerde maliyetin ağırlığı çıktıya kayar. Uzun belge özetleyen ama kısa cevap veren işlerde ağırlık girdiye kayar. İki durumda da optimizasyon farklı yerden başlar.

Bazı modeller "düşünme" veya "akıl yürütme" adımları için ayrı token harcayabilir. Bu tokenlar ekranda görünmese de faturaya yansıyabilir. Bu nedenle kullandığınız modelin dokümantasyonunda bu konuyu mutlaka okuyun.

API faturası nasıl oluşur?

API faturası temelde basit bir çarpımdır: Harcanan token sayısı çarpı birim fiyat. Girdi ve çıktı ayrı hesaplanır, sonra toplanır. Her istekte sağlayıcı yanıtın içinde kullanılan token sayısını da döndürür. Bu bilgi hesabınızı doğrulamak için en güvenilir kaynaktır.

Formülü şöyle yazabiliriz:

• Girdi maliyeti = girdi token sayısı ÷ 1 milyon × girdi birim fiyatı
• Çıktı maliyeti = çıktı token sayısı ÷ 1 milyon × çıktı birim fiyatı
• Toplam = girdi maliyeti + çıktı maliyeti

Sağlayıcılar fiyatı çoğunlukla "bir milyon token başına" gösterir. Ancak bu birim de sabit değildir. Bazı sağlayıcılar farklı birim kullanabilir. Bu yüzden fiyat sayfasındaki ölçüye dikkat edin.

Ek kalemler de olabilir. Örneğin önbellek kullanımı, toplu işleme indirimi, görsel veya ses girdisi ve model içi araç çağrıları ayrı fiyatlanabilir. Genel prensip aynıdır, ama kalemlerin adı ve fiyatı sağlayıcıya göre değişir.

Örnek hesap: müşteri destek botunun aylık maliyeti nasıl çıkar?

Aşağıdaki hesap tamamen varsayımsaldır. Birim fiyatlar gerçek bir sağlayıcıya ait değildir. Amaç yalnızca mantığı göstermektir. Gerçek fiyatı sağlayıcının fiyat sayfasından kontrol edin. Token nedir sorusunu bilmek, bu hesabın ilk adımıdır.

Varsayımlarımız şunlar olsun (örnek hesap):

• Aylık 10.000 sohbet olsun.
• Her sohbette ortalama 1.500 girdi tokenı ve 400 çıktı tokenı olsun.
• Varsayımsal fiyat: 1 milyon girdi tokenı için 2 birim, 1 milyon çıktı tokenı için 8 birim olsun.

Hesap şöyle ilerler:

Gördüğünüz gibi çıktı sayısı girdinin çok altında kalsa da çıktı maliyeti girdi maliyetine yakın çıktı. Çünkü çıktı birim fiyatı daha yüksek varsaydık. Bu, çıktıyı kısa tutmanın neden önemli olduğunu gösterir.

Şimdi aynı senaryoyu ikinci bir varsayımla deneyelim. Girdinin 1.000 tokenlık sabit kısmı (sistem talimatı ve kurallar) önbellekten geliyor olsun. Önbellekten gelen kısmın birim fiyatının normal girdinin onda biri olduğunu varsayalım. Bu yalnızca bir örnektir, gerçek oranı sağlayıcıdan öğrenin.

Önbellekli kısım 10 milyon token eder ve 2 birim tutar. Kalan 5 milyon girdi tokenı 10 birim tutar. Çıktı 32 birim olarak kalır. Yeni toplam 44 birim olur. Yani yalnızca sabit talimatı önbelleğe alarak varsayımsal faturayı yaklaşık dörtte bir oranında azaltmış olduk.

Görsel, ses ve belge girdileri nasıl sayılır?

Birçok model yalnızca metin değil, görsel, ses veya PDF gibi girdileri de kabul eder. Bu girdiler de sonunda token olarak hesaplanır. Ancak dönüşüm yöntemi sağlayıcıya ve modele göre değişir. Örneğin bir görselin token karşılığı, boyutuna ve ayrıntı ayarına bağlı olabilir.

Bu nedenle çok sayıda görsel veya uzun belge işleyen bir sistemde ilk denemeyi küçük tutun. Birkaç örnek dosya gönderin ve yanıttaki kullanım bilgisini inceleyin. Ardından bu ortalamayı aylık hacimle çarpın.

Belgelerde ek bir tuzak var. Taranmış bir PDF'i görsel olarak göndermek, metnini önceden çıkarıp göndermekten farklı bir maliyet çıkarabilir. Metin çıkarma adımı zaten mümkünse, önce metni ayıklayıp yalnızca gerekli bölümleri göndermek çoğu zaman daha ekonomiktir.

Belge işleme projelerinde ekibimiz önce veri akışını çizer, sonra token tahminini yapar. İlgili çözüm için yapay zeka ile belge işleme sayfamıza bakabilirsiniz.

Token nedir diye soranlar gerçek sayıyı önceden nasıl tahmin eder?

Token nedir bilgisini sayıya çevirmek için üç yöntem işinize yarar. Birincisi sağlayıcının sayaç aracına örnek metinlerinizi yapıştırmaktır. İkincisi API çağrısı sonrasında yanıttaki kullanım alanına bakmaktır. Üçüncüsü bazı sağlayıcıların sunduğu "token say" uç noktasını kullanmaktır. Örneğin Google'ın Gemini belgeleri token sayımını anlatır, Anthropic belgeleri ise ayrı bir sayım yöntemi sunar.

Tahmin için şu adımları izleyin:

1. En az 20 gerçek örnek mesaj veya belge seçin.
2. Her birini sayaçtan geçirip ortalama ve en yüksek değeri not edin.
3. Sistem talimatınızın token sayısını ayrıca ölçün.
4. Beklediğiniz cevap uzunluğunu belirleyip çıktı sayısını tahmin edin.
5. Formülle aylık hacmi çarpın ve %20 ile %30 arası tampon ekleyin.

Tampon oranı bizim saha tecrübemize dayalı bir başlangıç önerisidir, garanti değildir. İlk ay gerçek kullanıma bakıp güncelleyin. Böylece tahmin ile fatura arasındaki sapmayı küçültürsünüz.

Token maliyetini düşürmenin yolları nelerdir?

Beş ana yöntem var. Hepsi bir araya geldiğinde etki büyür. Ancak her proje için sıralama farklıdır, dolayısıyla önce ölçüm yapmanızı öneririz.

• Kısa ve net prompt: Gereksiz tekrarları ve uzun giriş cümlelerini çıkarın.
• Önbellek: Sabit talimatı ve ortak bağlamı önbelleğe alın.
• Uygun model seçimi: Basit işlere küçük, karmaşık işlere güçlü model verin.
• Toplu işleme: Anlık cevap gerektirmeyen işleri toplu gönderin.
• Çıktı sınırı: Maksimum çıktı uzunluğunu ve biçimini belirleyin.

Sıradaki başlıklarda her birine ayrı ayrı bakıyoruz. Prompt yazımının kendisi için prompt mühendisliği rehberimizi da okuyabilirsiniz.

Kısa prompt yazmak maliyeti ne kadar düşürür?

Her istekte gönderdiğiniz sabit metin, aylık hacimle çarpılır. Bu yüzden 500 tokenlık gereksiz bir talimat, 10.000 istekte 5 milyon token ek yük demektir. Küçük görünen fazlalık, ölçekte büyük kalem olur.

Kısaltırken kaliteyi korumak için şunları deneyin:

• Aynı kuralı iki kez yazmayın.
• Uzun açıklama yerine kısa ve açık maddeler kullanın.
• Örnek sayısını azaltın, yalnızca en öğretici iki veya üç örneği bırakın.
• Çıktı biçimini tek cümleyle tarif edin.

Ancak aşırı kısaltmak da hata getirir. Talimat belirsizleşirse model yanlış cevap verir ve yeniden deneme gerekir. Yeniden deneme de token harcar. Bu nedenle kısaltmayı değiştirdiğiniz her sürümde örnek sorularla test edin.

Önbellek (prompt caching) nasıl işe yarar?

Önbellek, her istekte tekrar eden başlangıç bölümünün sağlayıcı tarafında hatırlanmasıdır. Aynı uzun talimatı veya belgeyi defalarca gönderiyorsanız, o kısım için genellikle daha düşük bir birim fiyat ödersiniz. Bazı sağlayıcılarda bu otomatik, bazılarında ise elle ayarlanır.

Önbellekten en çok yararlanan senaryolar şunlardır:

• Uzun sistem talimatı olan müşteri destek botları
• Aynı politika belgesine sürekli soru soran iç asistanlar
• Aynı kod tabanı üzerinde çalışan geliştirici araçları

Önbelleğin çalışması için sabit kısmı isteğin en başına koymanız gerekir. Değişken kısmı, yani kullanıcının sorusunu sona ekleyin. Süre sınırı, minimum uzunluk ve fiyat farkı sağlayıcıya göre değişir. Bu ayrıntıları resmi dokümantasyondan kontrol edin.

Uygun model seçimi maliyeti nasıl etkiler?

Token nedir bilen ekipler model seçiminin etkisini hızla görür. Etkisi büyüktür. Sağlayıcılar genellikle küçük, orta ve büyük olmak üzere farklı seviyelerde modeller sunar. Büyük modeller daha pahalıdır. Küçük modeller ise sınıflandırma, kısa özet, etiketleme ve basit yönlendirme gibi işlerde yeterli olabilir.

Biz projelerde şu sırayı öneriyoruz:

1. Önce küçük modelle deneyin.
2. Kaliteyi 20 örnekle ölçün.
3. Yetersizse bir üst seviyeye geçin.
4. Karışık iş akışında basit adımları küçük, zor adımları güçlü modele verin.

Burada belirli bir modeli ya da sağlayıcıyı öne çıkarmıyoruz. Çünkü model listesi hızla eskir ve "en iyi" seçim işinize göre değişir. Önemli olan, her adım için yeterli olan en ucuz seçeneği bulmaktır. Kurumsal projelerde bu seçimi yapay zeka entegrasyonu aşamasında birlikte planlıyoruz.

Toplu işleme ve çıktı sınırı nedir?

Toplu işleme, aynı anda çok sayıda isteği tek paket halinde göndermektir. Sonucu hemen beklemeyen işler için uygundur. Örneğin gece boyunca bin ürün açıklamasını sınıflandırmak buna iyi bir örnektir. Bazı sağlayıcılar bu yöntem için indirimli fiyat sunar, ancak sonuçlar daha geç gelir.

Çıktı sınırı ise modelin üreteceği cevabın üst uzunluğunu belirler. Bu sınırı koymazsanız model gereğinden uzun yazabilir. Üstelik çıktı tokenı genellikle daha pahalıdır.

Çıktıyı kontrol etmek için şunları yapın:

• Maksimum çıktı token değerini işin ihtiyacına göre ayarlayın.
• "En fazla üç cümle" gibi net bir uzunluk talimatı verin.
• Mümkünse JSON gibi kısa ve yapılı bir biçim isteyin.
• Gereksiz nezaket cümlelerini ve tekrarları yasaklayın.

Çok düşük bir sınır cevabı yarıda kesebilir. Bu yüzden sınırı gerçek örneklerdeki en uzun cevaba göre biraz üstte tutun.

Kaliteyi bozmadan token tasarrufu nasıl yaparsınız?

Tasarruf, kaliteden vazgeçmek anlamına gelmemeli. Her değişikliği küçük bir test setiyle ölçün. Örneğin 20 gerçek soruyu önce mevcut kurguyla, sonra kısaltılmış kurguyla çalıştırın. Cevapları yan yana okuyun ve fark görmüyorsanız yeni sürümü benimseyin.

Test setinizde zor örnekler de olsun. Belirsiz bir soru, çok uzun bir mesaj ve yanlış yazılmış bir cümle iyi birer sınavdır. Kısaltılmış talimat bunlarda da iyi sonuç veriyorsa güvenle kullanabilirsiniz.

Bir de şunu hesaba katın: Hatalı cevap, yeniden denemeye ve insan müdahalesine yol açar. Bu da en az token kadar pahalıdır. Yani en ucuz kurgu her zaman en düşük token sayılı kurgu değildir. Doğru ölçü, doğru sonucun toplam maliyetidir.

Değişiklikleri kayıt altına alın. Hangi sürümün ne kadar token harcadığını ve kaç örnekte başarılı olduğunu basit bir tabloda tutun. Böylece üç ay sonra "neden böyle yaptık?" sorusuna net cevabınız olur.

Abonelik ile API arasındaki fark nedir?

Abonelik, sohbet arayüzünü sabit bir aylık ücretle kullanmanızdır. API ise yazılımınızı modele bağlayan bağlantıdır ve kullandığınız token kadar ödersiniz. İkisi çoğunlukla ayrı ürün olarak fiyatlanır. Birinin aboneliği diğerinin kullanım hakkını kendiliğinden getirmeyebilir.

Bir ekip yalnızca yazı yazmak ve fikir üretmek için kullanıyorsa abonelik genellikle yeterlidir. Müşteriye dönük bir bot, otomatik raporlama veya iş akışı kuracaksanız API gerekir. API'nin kurulumunu adım adım görmek için OpenAI API kullanım rehberimize bakın. Kapsam ve limitler sağlayıcıya göre değiştiği için güncel koşulları resmi sayfadan kontrol edin.

Hız limiti ile token limiti aynı şey midir?

Hayır, bunlar farklı kavramlardır. Token limiti, tek bir istekte işlenebilecek toplam miktarı veya bir dönemde harcayabileceğiniz miktarı ifade edebilir. Hız limiti ise belirli bir sürede gönderebileceğiniz istek ya da token sayısını sınırlar.

Sağlayıcılar genellikle dakika başına istek ve dakika başına token gibi ölçüler kullanır. Limitler hesap seviyenize ve modele göre değişir. Dolayısıyla rakamları sağlayıcının panelinden ve dokümantasyonundan kontrol etmeniz gerekir.

Hız limitine takıldığınızda sistem hata döndürür. Bu durumda her şeyi hemen yeniden denemek iyi bir çözüm değildir. Bekleme süresini kademeli artıran bir yeniden deneme düzeni kurun. Böylece hem limite çarpmaz hem de gereksiz maliyet üretmezsiniz.

Üstelik hız limiti, bütçe limitinin yerine geçmez. Hız limiti sistemi yavaşlatır, bütçe limiti ise harcamayı durdurur. İkisini birlikte kurmak en sağlıklı yoldur.

Bütçe limiti ve izleme nasıl kurulur?

Kontrolsüz bir döngü ya da kötü niyetli kullanım, birkaç saatte beklenmedik bir fatura çıkarabilir. Bu yüzden canlıya çıkmadan önce üç katmanlı bir koruma kurmanızı öneriyoruz.

1. Sağlayıcı tarafında limit: Panelde aylık harcama sınırı ve uyarı eşiği tanımlayın. Ayarın adı sağlayıcıya göre değişir, resmi yardım sayfasına bakın.
2. Uygulama tarafında limit: Kullanıcı başına günlük istek ve token üst sınırı koyun.
3. Kendi kayıtlarınız: Her istekte dönen kullanım bilgisini veritabanına yazın.

İzleme için günlük olarak şu dört değere bakın: toplam girdi tokenı, toplam çıktı tokenı, istek başına ortalama maliyet ve en pahalı on istek. Beklenmedik sıçrama ilk gün yakalanırsa genellikle küçük bir düzeltmeyle çözülür.

API anahtarını ayrıca koruyun. Anahtarı web sayfasının koduna veya herkese açık depoya koymayın. Sunucu tarafında saklayın ve gerektiğinde yenileyin.

Hangi hatalar faturayı şişirir?

Sahada en sık gördüğümüz hatalar şunlardır. Hepsi önlenebilir.

• Tüm sohbet geçmişini her seferinde göndermek: Eski mesajları özetleyin veya kırpın.
• Belgeyi bütün olarak göndermek: Yalnızca ilgili bölümleri seçin.
• Hata durumunda sonsuz yeniden deneme: Deneme sayısına üst sınır koyun.
• Test ortamında canlı model kullanmak: Test için küçük model ve kısa örnek tercih edin.
• Çıktı uzunluğunu sınırlamamak: Model gereğinden uzun yazar.
• Kullanıcı başına limit koymamak: Tek bir kullanıcı bütçeyi tüketebilir.

Bu hataların çoğu ilk haftada fark edilmez. Çünkü hacim düşüktür. Ancak trafik arttığında aynı hata ölçekle büyür. Dolayısıyla ilk günden izleme panosu kurmak, sonradan yangın söndürmekten ucuzdur.

Token maliyetini iş hedefleriyle nasıl ilişkilendirirsiniz?

Yalnızca "aylık ne kadar harcadık?" sorusu eksik kalır. Daha iyi soru şudur: "Her çözülen destek talebi, her üretilen taslak ya da her nitelikli başvuru bize kaç token tutuyor?" Böylece maliyeti iş sonucuna bağlarsınız.

Pazarlama tarafında aynı mantığı zaten kullanıyorsunuz. Reklamda tıklama başına maliyeti ve reklam harcaması getirisini izlersiniz. Yapay zeka maliyetine de aynı disiplini uygulayın. Hesaplamak için ROAS hesaplayıcımızı ve Google Ads bütçe hesaplama aracımızı kullanabilirsiniz. Tıklama maliyetini hatırlamak isterseniz CPC rehberimiz yardımcı olur.

Örnek senaryo: Bir e-ticaret ekibi ürün açıklamalarını yapay zekayla yazdırıyor olsun. Ekip, üretilen her açıklamanın ortalama token maliyetini ve düzenleme süresini ölçer. Sonra bu iki değeri, açıklamayı elle yazmanın maliyetiyle karşılaştırır. Karar bu karşılaştırmaya göre verilir. Bu bir örnek senaryodur, gerçek bir müşteri sonucu değildir.

Küçük bir işletme için gerçekçi bütçe nasıl planlanır?

Token nedir öğrenmek tek başına yetmez, planlamak da gerekir. Küçük işletmelerde amaç mükemmel tahmin değil, kontrollü deneme olmalıdır. Önce tek bir kullanım senaryosu seçin. Örneğin sık sorulan sorulara cevap veren bir WhatsApp asistanı ya da haftalık raporu özetleyen bir iş akışı olabilir.

Sonra üç aylık basit bir plan yapın:

• İlk ay: Küçük hacimle deneyin, gerçek token verisini toplayın.
• İkinci ay: Prompt'u kısaltın, önbellek ve çıktı sınırını devreye alın.
• Üçüncü ay: Maliyeti iş sonucuyla karşılaştırın ve karar verin.

Bu planın her aşamasında sağlayıcı panelinde bir harcama sınırı bulunsun. Böylece en kötü senaryo bile sınırlı kalır. Ayrıca aylık maliyeti, çözülen iş sayısına bölerek "iş başına maliyet" hesaplayın.

Rakamı ne olursa olsun, sonucu bir garanti olarak okumayın. Saha tecrübemize dayalı yöntem budur, ama her işletmenin hacmi ve dili farklıdır. Kendi verinizle ölçmek en güvenli yoldur. Yatırım getirisini düşünmek isterseniz yapay zeka danışmanlığı sayfamıza göz atın.

Ekip olarak nereden başlamanızı öneririz?

Önce küçük başlayın, ölçün, sonra büyütün. Bizim izlediğimiz sıra şöyledir:

1. İş hedefini ve başarı ölçütünü yazın.
2. Gerçek örneklerle token sayısını ölçün.
3. En küçük yeterli modelle prototip kurun.
4. Sabit talimatı kısaltın ve önbelleğe uygun hale getirin.
5. Çıktı sınırını ve biçimini belirleyin.
6. Sağlayıcı ve uygulama düzeyinde bütçe limiti koyun.
7. İlk ay günlük izleyin, sonra haftalık izlemeye geçin.

Kurumsal bir sistem planlıyorsanız Talha Aslan ve ekibi olarak yapay zeka otomasyon hizmetimizle bu adımları birlikte uygulayabiliriz. Dışarıya veri göndermek istemeyen ekipler için yerel LLM kurulumu de bir seçenektir. Büyük dil modellerinin temelini görmek için LLM rehberimize bakabilirsiniz.

Not: Bu yazı genel bilgilendirme amaçlıdır ve hukuki danışmanlık değildir. Kişisel veri içeren metinleri bir API'ye gönderiyorsanız KVKK yükümlülüklerinizi bir hukuk uzmanıyla netleştirin.