Yazar: @atilayberber
Toplulukta sık duyduğum bir hikâye var: Ekip bir F2 kapasitesi alıyor, Copilot’u açıyor, ilk gün herkes heyecanlı. Üç gün sonra sabah raporları açılmıyor, refresh’ler kuyrukta bekliyor ve kimse ne olduğunu anlamıyor. Sorun Copilot’un “pahalı” olması değil; Copilot’un kapasiteden nasıl beslendiğini bilmeden açılmış olması.
Bu rehberde Copilot’un Fabric kapasitesinden nasıl tükettiğini, bunu nasıl hesaplayacağınızı, Copilot’u üretim yükünden nasıl izole edeceğinizi ve maliyeti kontrol altında tutmak için hangi ayarları kullanacağınızı adım adım anlatıyorum.
Kısaca: Bu yazıda neler var?
- Copilot’u kullanmak için gereken minimum kapasite ve lisanslar
- Copilot tüketiminin formülü: token, CU saniyesi ve önbellek indirimi
- Smoothing ve throttling: “üç gün sonra yavaşlama” neden olur?
- Gerçek sayılarla F2 ve F64 hesap örnekleri
- Üç mimari seçenek ve Fabric Copilot capacity kurulumu
- Capacity Metrics app, surge protection ve pilot grup ile maliyet kontrolü
- Yöneticiler için kontrol listesi ve sık yapılan hatalar
Önce temel: Copilot için neye ihtiyacınız var?
Copilot in Fabric (Power BI, Data Factory, Data Engineering, Data Science ve diğer iş yükleri dahil) ücretli bir kapasite üzerinde çalışır. Microsoft Learn’deki güncel gereksinimler şöyle:
- Kapasite: Ücretli bir Fabric kapasitesi (F2 ve üzeri) ya da Power BI Premium kapasitesi (P1 ve üzeri).
- Bölge: Kapasitenin Copilot’un desteklendiği bir bölgede olması gerekir.
- Workspace: Copilot kullanılan öğe, Copilot’un açık olduğu bir kapasiteye atanmış workspace’te olmalı. Pro ve PPU workspace’leri Copilot’u doğrudan desteklemez; bunun yolu aşağıda anlatacağım Fabric Copilot capacity.
- Power BI Desktop: Desktop’ta Copilot kullanırken Copilot açık bir workspace seçersiniz; tüketim o workspace’in kapasitesine yazılır.
- Tenant ayarları: “Users can use Copilot and other features powered by Azure OpenAI” ayarı açık olmalı. Kapasitenin bölgesinde Azure OpenAI yoksa, verinin bölge dışında işlenmesine izin veren cross-geo ayarı da gerekebilir.
İki önemli not: Birincisi, Microsoft’a göre Copilot ücretli kapasitesi (F2+) olan tenant’larda varsayılan olarak açık. Yani siz bir şey yapmasanız da kullanıcılarınız Copilot’a erişebiliyor olabilir. İkincisi, lisans tarafını kapasiteyle karıştırmayın: F64 altındaki kapasitelerde rapor izleyicilerin de Power BI Pro lisansına ihtiyacı var. Copilot kapasite tüketir, lisans ihtiyacını ortadan kaldırmaz.
Copilot maliyeti nereden gelir?
Copilot için ayrı bir lisans ya da ayrı bir fatura kalemi satın almıyorsunuz. Her prompt ve her cevap, raporlarınız, refresh’leriniz, notebook’larınız ve pipeline’larınızla aynı havuzdan, yani kapasitenizin Capacity Unit (CU) bütçesinden tüketiyor. Capacity Metrics app’te bu tüketim “Copilot in Fabric” operasyon adıyla görünüyor.
Ölçü birimi token. Kabaca 1.000 token yaklaşık 750 kelimeye denk geliyor. Microsoft Learn’deki güncel oranlar şöyle:
| Bileşen | Birim | Tüketim |
|---|---|---|
| Girdi (prompt) | 1.000 token | 100 CU saniyesi |
| Önbellekten gelen girdi | 1.000 token | 10 CU saniyesi |
| Çıktı (cevap) | 1.000 token | 400 CU saniyesi |
Buradan iki pratik sonuç çıkıyor:
- Çıktı, girdiden dört kat pahalı. “Bu sayfadaki her görseli ayrıntılı açıkla” gibi uzun cevap üreten istekler, kısa ve net isteklerden belirgin şekilde daha fazla tüketir.
- Önbellek otomatik ve ciddi bir indirim. Bir istek, yakın zamandaki bir istekle aynı başlangıcı paylaşıyorsa (sistem talimatları, şema bağlamı, sohbet geçmişi), ortak kısım 100 yerine 10 CU saniyesiyle faturalanır. Bunun için bir şey ayarlamanız gerekmiyor.
Bir uyarı: İnternette dolaşan bazı örnek hesaplar, Microsoft’un 2024’te yayımladığı daha eski oranları kullanıyor. Kendi hesabınızı yaparken her zaman Microsoft Learn’deki güncel tabloyu baz alın; Microsoft oranların değişebileceğini ve değişiklikleri sürüm notlarında duyuracağını belirtiyor.
Smoothing ve throttling: “Üç gün sonra yavaşladı” neden olur?
Copilot operasyonları Fabric’te background (arka plan) iş olarak sınıflanıyor. Bu, iyi ve kötü haberi aynı anda getiriyor:
- İyi haber: Background işlerin tüketimi 24 saate yayılır (smoothing). Öğlen yoğun bir Copilot kullanımı anında kapasiteyi kilitlemez; Fabric yoğun saatlerde daha fazla isteği karşılayabilir.
- Kötü haber: Yayılan tüketim kaybolmaz, gelecek saatlerin bütçesinden düşülür. Copilot her gün kapasitenin taşıyabileceğinden fazla tüketiyorsa, borç birikir.
Fabric’in throttling politikası bu borca göre kademeli devreye girer. Kapasite önümüzdeki 10 dakikanın bütçesini tükettiğinde interaktif işler (rapor sorguları) gecikmeye başlar; borç bir saati aşınca interaktif istekler reddedilir; 24 saati aşınca background işler (refresh, pipeline ve Copilot dahil) de reddedilir. Kapasite tükendiğinde tüm operasyonlar durur.
“Üç gün sonra yavaşladı” hikâyesinin açıklaması bu: F2 gibi küçük bir SKU’da her gün biraz fazla tüketiliyor, smoothing bunu birkaç gün maskeliyor, sonra birikmiş borç sabah raporlarını yavaşlatıyor. Sorun o sabah değil, önceki günlerde başlamış oluyor.
Gerçek sayılarla hesap: F2 ve F64
Microsoft’un kendi örneğini temel alalım: Bir Copilot isteği ortalama 2.000 girdi ve 500 çıktı token’ı kullansın.
(2.000 × 100 + 500 × 400) / 1.000 = 400 CU saniyesi / istek
400 / 60 = 6,67 CU dakikası ≈ 0,11 CU saatiŞimdi bunu kapasitelerin günlük bütçesiyle karşılaştıralım. Bir F SKU’su, adındaki sayı kadar CU sağlar ve bir günde 86.400 saniye var:
| Kapasite | Günlük bütçe | Sadece Copilot çalışsaydı (400 CU sn/istek) |
|---|---|---|
| F2 | 2 × 86.400 = 172.800 CU sn | ≈ 432 istek/gün |
| F8 | 691.200 CU sn | ≈ 1.728 istek/gün |
| F64 | 5.529.600 CU sn | ≈ 13.824 istek/gün |
F64 satırı Microsoft Learn’deki örnekle birebir aynı. Ama tabloyu okurken kritik nokta şu: Bu sayılar kapasitede başka hiçbir şey çalışmıyorsa geçerli. Gerçekte o bütçe refresh’ler, rapor sorguları ve veri işleriyle paylaşılıyor. F2’de günlük refresh’leriniz kapasitenin yarısını kullanıyorsa, Copilot için kalan pay yaklaşık 200 isteğe düşüyor. 20 kişilik bir ekip, kişi başı günde 10 prompt ile bu sınırı rahatça aşar.
Önbellek hesabı da değiştirir. Aynı sohbet içinde devam eden bir istekte 2.000 girdi token’ının 1.500’ü önbellekten gelirse:
(500 × 100 + 1.500 × 10 + 500 × 400) / 1.000 = 265 CU saniyesi / istekYani aynı istek yaklaşık üçte bir daha ucuz. Kullanıcılara “her soruda yeni sohbet açın” demek yerine, ilgili soruları aynı oturumda sormalarını önermek maliyeti düşürür.
Peki bu kaç para?
Microsoft’un Central US fiyat örneğinde CU saati kullandıkça öde modelinde 0,18 dolar, rezervasyonla 0,107 dolar. 0,11 CU saatlik bir istek kullandıkça öde fiyatıyla yaklaşık 2 cent’e denk geliyor. Tek istek ucuz; asıl maliyet, Copilot yüzünden bir üst SKU’ya geçmek zorunda kalmanız. F2’den F4’e geçmek kapasite faturasını iki katına çıkarır. Fiyatlar bölgeye göre değişir; kendi bölgenizin fiyatını Azure fiyat sayfasından kontrol edin. Copilot isteği başka bir bölgede işlense bile, faturalama kapasitenizin bölgesinin fiyatıyla yapılır.
Üç mimari seçenek
| Seçenek | Nasıl çalışır? | Ne zaman? | Risk |
|---|---|---|---|
| Tek kapasite | Raporlar, veri işleri ve Copilot aynı havuzu paylaşır | Küçük ekip, düşük ve öngörülebilir Copilot kullanımı | Copilot yoğunluğu üretim raporlarını yavaşlatabilir |
| Fabric Copilot capacity | Bir kapasite Copilot kapasitesi yapılır; seçilen kullanıcıların tüm Copilot tüketimi oraya yazılır | Copilot’u üretim yükünden izole etmek ve tek yerden izlemek istediğinizde | Ek bir kapasitenin maliyeti; bazı sınırlamalar |
| Daha büyük SKU | Tek havuz, daha fazla CU | Copilot ve veri işleri birlikte büyüdüğünde, F64 avantajları da hesaba girdiğinde | Copilot kullanımı plansızsa büyük SKU da dolabilir |
Fabric Copilot capacity: Copilot’u izole etmenin yolu
Varsayılan durumda Copilot tüketimi, kullanıcının içeriğinin bulunduğu kapasiteye yazılır. Kuruluşunuzda birden çok kapasite varsa maliyet dağılır ve kimin ne harcadığını görmek zorlaşır. Fabric Copilot capacity bu tüketimi tek bir kapasitede toplar: Atanan kullanıcılar Copilot’u ya da data agent’ları nerede kullanırsa kullansın, tüketim Copilot kapasitesine yazılır.
Bunun üç önemli faydası var:
- İzolasyon: Pazartesi sabahı Copilot’la rapor sayfası üreten analistler, üretim raporlarının kapasitesini tüketmez.
- Kapsam: Power BI Desktop’taki Copilot ve Pro, PPU, Trial workspace’lerindeki Copilot kullanımı da bu kapasiteye faturalanabilir. F64 altındaki kapasitelerde Data Factory, Data Engineering, Data Warehouse, Data Science, Real-Time Intelligence ve Activator’daki Copilot ile data agent’lar da desteklenir.
- Görünürlük: Copilot maliyetini tek bir kapasitenin metriklerinde görürsünüz.
Kurulum adımları
- Fabric yöneticisi, Admin portal’da Copilot’u ilgili kullanıcılar (tercihen bir güvenlik grubu) için açar.
- Fabric yöneticisi, kapasite yöneticilerinin kapasitelerini Copilot kapasitesi olarak işaretlemesine izin verir. “Capacities can be designated as Fabric Copilot capacities” ayarı Şubat 2026’dan itibaren tüm tenant’larda varsayılan olarak açık geliyor.
- Kapasite yöneticisi, kapasite ayarlarında bir kullanıcı grubunu bu kapasitenin Copilot kullanıcıları olarak atar.
- Kullanıcıların ek bir şey yapması gerekmez; faturalama otomatik olarak Copilot kapasitesine yönlenir.
Bilmeniz gereken sınırlamalar
- Copilot kapasitesi en az F2 veya P1 olmalı.
- Sadece tenant’ın ana (home) bölgesinde destekleniyor.
- Bir kullanıcı yalnızca bir Copilot kapasitesine bağlanabilir. Birden fazlasına atanırsa en son oluşturulan kapasite geçerli olur.
- Kullanıcıya atanan Copilot kapasitesi, workspace’in kendi kapasitesinin önüne geçer.
- Embedded lisans modundaki kapasiteler desteklenmiyor.
- Fabric AI functions bu kapasitede desteklenmiyor; onlar workspace’in kapasitesinden tüketmeye devam eder.
- Copilot kapasitesinin yöneticisi, kullanım kayıtlarındaki öğe ve workspace metadata’sını görebilir. Hangi ekibin bu rolü üstleneceğini veri yönetişimi açısından baştan konuşun.
Maliyeti kontrol altında tutmak: dört adım
1. Ölçün: Capacity Metrics app
Fabric Capacity Metrics app’te “Copilot in Fabric” operasyonunu filtreleyin ve şu soruları cevaplayın: Copilot toplam CU’nun yüzde kaçı? En çok hangi öğe ve hangi kullanıcı tüketiyor? Tüketim günün hangi saatlerinde yoğunlaşıyor? Önizlemedeki Item History görünümü, workspace ve öğe bazında 30 günlük tüketimi gösteriyor; trend görmek için ideal.
2. Sınırlayın: surge protection
Background işler için surge protection genel kullanımda; kapasite belirli bir doluluğa ulaştığında yeni background işleri erken reddederek derin throttling’i önler. Workspace düzeyinde surge protection (önizleme) bir adım öteye gidiyor: Bir workspace’in 24 saatlik kayan pencerede kapasitenin belirli bir yüzdesinden fazlasını tüketmesini engelleyebilir, eşiği aşan workspace’i geçici olarak bloke edebilirsiniz. Kritik workspace’leri “mission critical” olarak işaretlerseniz bu kuraldan muaf tutulurlar.
Ekim 2026 Power BI güncellemesindeki bir iyileştirme de burada önemli: Semantic model’ler artık uzun süren işlemlerin CU tüketimini iş bitince değil, iş sürerken raporluyor. Böylece surge protection pahalı işleri daha erken fark ediyor; geç gelen throttling reddi azalıp, baştan reddedilen ya da geciktirilen işlerin payı artıyor. Refresh hata alarmlarınızda bir değişiklik gördüyseniz sebebi bu olabilir.
3. Kimin kullandığını seçin: pilot grup
Microsoft’un da önerdiği yol bu: Copilot’u tüm tenant’a açmak yerine bir güvenlik grubuyla pilot başlatın. Senaryo bazında tüketimi ölçün (örneğin yoğun trafikli bir dashboard’daki AI narrative görseli ya da abonelik özetleri), sonuçları kullanıcı sayısına göre ölçekleyin, sonra genişletin. Plansız geniş dağıtım kapasiteyi hızla tüketebilir.
4. Boyutlandırın: SKU estimator
Yeni bir kapasite almadan önce Fabric SKU estimator (önizleme) ile tahmin alın. Pilot dönemden elde ettiğiniz “kişi başı günlük Copilot CU” rakamını tahmine ekleyin. Tahmin aracı size bir başlangıç noktası verir; gerçek rakamı Metrics app söyler.
Kullanıcı tarafında maliyeti düşüren alışkanlıklar
- Kısa ve hedefli istekler: “Bu sayfayı özetle” yerine “Bölge bazında satış düşüşünün nedenini üç maddede özetle” gibi istekler hem daha iyi sonuç verir hem daha az çıktı token’ı üretir.
- Aynı oturumda devam edin: Önbellek indirimi ortak bağlamı olan ardışık isteklerde devreye girer.
- Modeli Copilot’a hazırlayın: Açıklamaları olan, adları anlaşılır bir semantic model, Copilot’un daha az deneme yanılma ile doğru cevaba ulaşmasını sağlar. Bu konuyu semantic model açıklamaları yazısında ele almıştım.
- Yüksek trafikli raporlarda dikkat: Yüzlerce kişinin açtığı bir dashboard’a eklenen her AI görseli, her açılışta tüketim üretir.
Yöneticiler için kontrol listesi
- Copilot tenant ayarı tüm kuruluşa mı, bir güvenlik grubuna mı açık?
- Cross-geo ayarları kuruluşunuzun veri yerleşimi politikasıyla uyumlu mu?
- Copilot tüketimi hangi kapasiteye yazılıyor? Üretim kapasitesine mi, ayrı bir Copilot kapasitesine mi?
- Capacity Metrics app’te Copilot için haftalık bir kontrol rutini var mı?
- Kritik workspace’ler mission critical olarak işaretli mi, düşük öncelikli olanlara limit konmuş mu?
- Kapasite throttling’e girdiğinde kimin haberi oluyor? (Bir sonraki yazının konusu: izleme ve alarmlar.)
Sık yapılan hatalar
- Trial kapasitede test edip üretimde şaşırmak: Copilot için ücretli kapasite gerekiyor; trial deneyimi gerçek tüketimi göstermez.
- Kapasiteyi duraklatıp Copilot’un neden çalışmadığını aramak: Kapasite duraklatılınca Copilot da durur.
- Copilot kapasitesinin AI functions’ı da kapsadığını sanmak: Kapsamıyor.
- Sadece günlük toplamlara bakmak: Smoothing yüzünden sorunlar birkaç gün gecikmeli görünür; trendi izleyin.
Sonuç
Copilot’un gerçek maliyeti lisans değil, kapasite. Tek bir istek birkaç cent tutar; ama planlanmamış kullanım üretim raporlarınızı yavaşlatır ya da sizi bir üst SKU’ya iter. Önerim net: Pilot bir grupla başlayın, tüketimi Metrics app’te ölçün, kullanım büyüdüğünde Copilot’u Fabric Copilot capacity ile izole edin ve surge protection ile sınır koyun. Böylece sürpriz fatura ve “raporlar neden yavaş” şikâyeti aynı gün kapınızı çalmaz.
Sizin kurumunuzda Copilot tüketimi hangi kapasiteye yazılıyor? Yorumlarda ya da LinkedIn’de paylaşın.
Kaynaklar
- Copilot in Fabric consumption (Microsoft Learn)
- Fabric Copilot capacity (Microsoft Learn)
- Enable Copilot in Fabric (Microsoft Learn)
- Fabric Copilot Pricing: An End-to-End example (Microsoft Fabric Blog)
- Workspace-level surge protection (Fabric Updates Blog)
- MC1217152: Copilot capacity designation enabled by default
HABERDAR OL
Yeni rehberler, kategorilere ayrılmış tek bir e-postada.
Her pazartesi, o hafta yayımlanan yazılar konu başlıklarına göre derlenmiş olarak gelen kutunda. Yeni yazı yoksa e-posta da yok.
1 yorum