Transformers documentation
Sürekli toplu işleme
Sürekli toplu işleme
Continuous batching, her üretim adımında batch'i dinamik olarak yeniden zamanlamaya alarak GPU kullanım oranını en üst düzeye çıkarır. İstekler tamamlandıkça, tüm batch'in bitmesini beklemeden yeni istekler anında katılır. GPU dolu kalır ve throughput yüksek seyreder.
Üretim dağıtımları için transformers serve kullanın. ContinuousBatchingManager üzerine inşa edilir ve OpenAI ile uyumlu bir HTTP uç noktası sunar.
generate_batch
Sürekli toplu işleme (continuous batching), generate_batch() üzerinden desteklenir. Tokenize edilmiş istem (prompt) listesini iletin ve tamamlandıklarında tümü için sonuçları alın. generate_batch, zamanlamayı (scheduling) içsel olarak yönetir ve tüm istekler tamamlanana kadar bloklanır.
Sunum ve akış (streaming) kullanım senaryoları için istekleri yönetmek üzere doğrudan ContinuousBatchingManager sınıfını kullanın.
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
from transformers.generation import ContinuousBatchingConfig, GenerationConfig
model = AutoModelForCausalLM.from_pretrained(
"Qwen/Qwen3-4B",
attn_implementation="flash_attention_2",
device_map="auto",
dtype=torch.bfloat16,
)
tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen3-4B")
prompts = [
"What's up?",
"Name a cat breed.",
"Write a detailed history of quantum mechanics.",
]
inputs = [tokenizer.encode(p) for p in prompts]
generation_config = GenerationConfig(
max_new_tokens=64,
eos_token_id=tokenizer.eos_token_id,
)
outputs = model.generate_batch(inputs=inputs, generation_config=generation_config)
for request_id, output in outputs.items():
text = tokenizer.decode(output.generated_tokens, skip_special_tokens=True)
print(f"[{request_id}] {text}")ContinuousBatchingManager
ContinuousBatchingManager arka plan iş parçacığı çalıştırır ve istekleri gönderip sonuçları bağımsız olarak almanıza olanak tanır. Her üretim adımında, tamamlanan istekleri kontrol eder ve partiyi katılmak üzere yeni istekleri zamanlar. Bu, akış (streaming), gerçek zamanlı sunum veya istekler geldikçe gönderme senaryoları için faydalıdır.
continuous_batching_context_manager() kullanarak yöneticiyi güvenli bir şekilde başlatın ve durdurun. Aşağıdaki örnek, değişken uzunlukta girdiler içerir. En kısa prompt tamamlandığı anda, daha uzun promptlar üretmeye devam ederken batch’ten ayrılır. Statik batching ile hepsini aynı uzunluğa kadar doldurmanız (padding) gerekirdi. Continuous batching, tamamlanan promptu serbest bırakır ve bir sonraki promptu hemen işlemeye başlayabilirsiniz.
with model.continuous_batching_context_manager(generation_config=generation_config) as manager:
manager.add_request(
input_ids=tokenizer.encode("Write a detailed history of quantum mechanics."),
request_id="long",
max_new_tokens=512,
)
manager.add_request(
input_ids=tokenizer.encode("What's up?"),
request_id="short_0",
max_new_tokens=32,
)
manager.add_request(
input_ids=tokenizer.encode("Name a cat breed."),
request_id="short_1",
max_new_tokens=32,
)
for result in manager:
text = tokenizer.decode(result.generated_tokens, skip_special_tokens=True)
print(f"[{result.request_id}] {text}")Ayrıca yaşam döngüsünü kendiniz yönetmek için init_continuous_batching() çağrısını da yapabilirsiniz.
manager = model.init_continuous_batching(generation_config=generation_config)
manager.start()
# submit and retrieve requests...Yöneticinin kapatılması
Yönetici, arka plan iş parçacığı çalıştırır ve dağıtık kaynakları tutar. Kapanış, işlenmekte olan işlemlerle ne yapacağınızı seçebilmeniz için iki aşamada gerçekleşir.
Arka plan iş parçacığını durdurmak için stop() çağrısını yapın. Varsayılan olarak, yönetici yeni gönderimleri kabul etmeyi durdurur ve iş parçacığı çıkış yapmadan önce kuyruktaki ve etkin olan isteklerin tamamlanmasını bekler.
manager.stop()
Bekleyen işleri derhal bırakmak için hard_stop=True parametresini iletin. Kuyruktaki ve aktif istekler, tamamlanmak yerine RuntimeError ile başarısız olur.
manager.stop(hard_stop=True)stop çağrıldıktan sonra, add_request() ve add_requests() yeni gönderimleri reddeder ve bir uyarı kaydeder. Aynı yöneticiyle başka bir üretim oturumu çalıştırmak için start fonksiyonunu tekrar çağırabilirsiniz.
Dağıtık kaynakları serbest bırakmak için destroy() çağrısını yapın. destroy, yönetici hâlâ çalışıyorsa önce onu durdurur ve yönetici sonrasında yeniden başlatılamaz. Sürekli toplama (continuous batching) işlemini, sürecin yaşam süresi boyunca tamamladığınızda kullanın.
manager.destroy()
continuous_batching_context_manager() bu süreci yönetir. Çıkışta stop çağrılır ve persistent_manager=True parametresini geçirerek yöneticiyi bir sonraki oturum için modelde önbelleğe almadığınız sürece destroy çağrılır.
İstek ekleme
add_request() tek bir isteği gönderir. Bir request_id sağlayın veya yöneticinin bir tane otomatik olarak oluşturmasına izin verin.
manager.add_request(input_ids=input_ids, request_id="my_request")add_requests() bir partiyi tek seferde gönderir. Blok paylaşımı etkin olduğunda, önek önbellek isabetlerini en üst düzeye çıkarmak için girdileri otomatik olarak sıralar.
manager.add_requests(inputs=inputs)
Bir isteği cancel_request() ile iptal edin.
manager.cancel_request(request_id="my_request")İstek başına örneklem parametreleri
per_request_processors etkinleştirilerek, aynı ileri geçiş içinde temperature, top_k ve top_p parametreleri istek başına bağımsız olarak uygulanabilir; bu sayede farklı istekler için farklı örneklem parametreleri kullanılabilir (örneğin yaratıcı, yüksek sıcaklıklı çıktılar ile hassas, düşük sıcaklıklı çıktılar).
cb_config = ContinuousBatchingConfig(per_request_processors=True)
# each request gets its own sampling parameters
manager.add_request(input_ids=inputs_a, temperature=0.9, top_p=0.95)
manager.add_request(input_ids=inputs_b, temperature=0.1, top_k=10)GenerationConfig içindeki her parametre, ilgili logits işleyicisinin çalışma zamanında oluşturulabilmesi için varsayılan olmayan bir değer olmalıdır. Örneğin, istek başına sıcaklık kontrolünü desteklemek için temperature değerini None veya 1 dışında bir değere ayarlayın. Sıcaklığı 1 olan istekler daha sonra yine de oluşturulabilir.
Sonuçları getirme
Sonuçlar geldikçe almak için yönetici üzerinde yineleyin.
for result in manager:
print(tokenizer.decode(result.generated_tokens, skip_special_tokens=True))get_result(), çıktı kuyruğundan bir sonraki sonucu alır. Belirli bir isteği filtrelemek için request_id parametresini iletin. Kuyruktaki bir sonraki sonuç eşleşmezse, sonuç yeniden kuyruğa eklenir ve yöntem None döndürür.
# next available result
result = manager.get_result()
# filter for a specific request
result = manager.get_result(request_id="my_request")Akış
Bir isteğe streaming=True ayarlayın, ardından token'lar oluşturuldukça kısmi çıktıları döngüye almak için request_id_iter() kullanın.
from transformers.generation.continuous_batching import RequestStatus
manager.add_request(input_ids=input_ids, request_id="streamed", streaming=True)
for chunk in manager.request_id_iter(request_id="streamed"):
token = tokenizer.decode(chunk.generated_tokens[-1:], skip_special_tokens=True)
print(token, end="", flush=True)
if chunk.status == RequestStatus.FINISHED:
breakContinuousBatchingConfig
ContinuousBatchingConfig, KV önbelleğini, zamanlamayı, CUDA grafiklerini, bellek kullanımını ve daha fazlasını kontrol eder. generate_batch veya init_continuous_batching() fonksiyonlarına continuous_batching_config argümanı olarak, GenerationConfig'den ayrı olarak iletin. Bu iki yapılandırma farklı şeyleri tanımlar. GenerationConfig model odaklıdır ve örneklemeyi ile durdurma parametrelerini içerirken, ContinuousBatchingConfig donanım odaklıdır ve bellek ile zamanlama parametrelerini içerir.
GenerationConfig üzerinde
continuous_batching_configayarlamak artık kullanılmamaktadır,FutureWarningüretir ve v5.19 sürümünde kaldırılacaktır.
Varsayılan olarak max_batch_tokens değeri 8192'dir; bu değer kullanılabilir GPU belleğiyle sınırlıdır ve asla 256'nın altına düşmez, num_blocks ise kalan belleği doldurur. Uygun özellikleri seçmenize yardımcı olması için aşağıdaki tabloyu kullanın.
| Özellik | Bellek | Geçirgenlik | Gecikme |
|---|---|---|---|
max_memory_percent / page_size | ✓ KV bütçesini kontrol eder | ||
max_batch_tokens | ↑ daha büyük giriş tamponları | ✓ daha büyük prefill toplulukları | ✓ Prefill sınırlı olduğunda TTFT |
scheduler | ✓ zamanlama politikası | ✓ TTFT | |
| CUDA grafikleri | ↑ grafik depolama | ✓ daha az dağıtım maliyeti | ✓ |
| Eşzamanlı toplu işleme | ↑ ~2× G/B tamponları | ✓ CPU/GPU çakışması | |
| Derleme | ↑ yalnızca warmup-time | ✓ daha hızlı ileri geçişler | ✓ |
| Hızlı çözümleme yolu | ↑ istek başına blok tablosu | ✓ daha hızlı yalnızca çözümlü adımlar | ✓ |
| CPU'ya aktarma | ↑ sabitlenmiş CPU belleği | ✓ bazı yeniden ön işlemleri atlar | |
| Önek önbellekleme | ↓ paylaşılan KV blokları | ✓ gereksiz ön işleme (prefill) adımlarını atlar | ✓ TTFT |
| Sayfalı dikkat | ↓ parçalanma yok | ✓ dinamik parti üyeliği | |
| Kayan pencere | ↓ katman başına sınırlı KV | ||
| İstek başına işleyiciler | ✓ batch başına karışık örneklem parametreleri | ||
max_requests_per_batch | ↓ caps logits tamponunu | ✓ batch boyutunu sınırlar | |
safety_margin | ✓ decode gecikmesini korur |
from transformers.generation import ContinuousBatchingConfig
cb_config = ContinuousBatchingConfig(
max_memory_percent=0.8,
page_size=256, # KV cache page size in tokens
scheduler_type="fifo", # "fifo" or "prefill_first"
)
outputs = model.generate_batch(
inputs=inputs,
generation_config=generation_config,
continuous_batching_config=cb_config,
)KV önbellek sayfa boyutu
page_size, bir katman için tam dikkat sayfasının KV'nin kaç token'ını tutacağını belirler. En az 4 olmalıdır, aksi takdirde başlatma işlemi ValueError fırlatır. Varsayılan 256 değeri, çoğu iş yükü için uygundur.
block_sizeparametresi kullanımdan kaldırılmış vepage_sizeile değiştirilmiştir.
Daha büyük bir sayfa boyutu, kayıt tutma işlemlerini azaltır ancak bir dizgi sayfanın ortasında durduğunda alan israfına yol açar. Daha küçük sayfalar daha az alan israf eder ancak daha fazla kayıt tutma gerektirir. Genellikle page_size değerini ayarlamanıza gerek yoktur. İş yükünüzde birçok kısa istek varsa, daha küçük bir değer deneyin. Birkaç çok uzun istek varsa, daha büyük bir değer deneyin. Sayfaların, blokların ve parçaların nasıl bir arada çalıştığını görmek için Bellek yönetimi bölümüne bakın.
cb_config = ContinuousBatchingConfig(page_size=128)Prefill toplu işlem boyutu
max_batch_tokens, tek bir ileri geçiş için token bütçesini, yani modelin aynı anda işlediği en fazla sorgu token sayısını belirler. Daha büyük bir bütçe, her prefill işlemine daha fazla prompt token sığdırarak prompt ağırlıklı iş yüklerinde prefill verimliliğini artırır ve ilk token'a kadar geçen süreyi kısaltır. Zamanlayıcı, bütçeyi aşan promptları adımlar arasında böler. Aşırı boyutlu promptların nasıl işlendiğini görmek için chunked prefill bölümüne bakın.
Varsayılan olarak max_batch_tokens değeri 8192'dir. Bu değer, parti başına girdi tensörlerinin KV önbelleğini sıkıştırmaması için kullanılabilir GPU belleğiyle sınırlıdır ve asla 256'nın altına düşmez. Boş belleği az olan bir GPU'da bu sınır, değeri 8192'nin altına çeker.
max_batch_tokens ve num_blocks aynı bellek bütçesinden beslenir, bu nedenle birbirleriyle ters orantılıdır. Daha büyük bir token bütçesi, daha büyük giriş tamponları ayırır ve eşzamanlı veya uzun istekler için daha az KV önbellek bloğu bırakır. Daha fazla bellek mevcut olduğunda prefill verimliliğini artırmak için max_batch_tokens değerini yükseltin; daha fazla KV bloğu için bellek açmak veya bellek taşması (out-of-memory) hatalarından kaçınmak için ise düşürün.
cb_config = ContinuousBatchingConfig(max_batch_tokens=16384)Toplu işlem ve zamanlama sınırları
max_requests_per_batch, tek bir ileri geçişte (forward pass) çalıştırılacak istek sayısını sınırlar. Model, batch token sayısı ve sözlük (vocabulary) boyutuyla boyutlandırılmış bir logits tensörü üretir ve örneklemeye (sampling) hazırlanmak için fp32 tipine dönüştürülür; bu işlem bellek kullanımını ikiye katlar. Her istek yalnızca bir sonraki token tahminine ihtiyaç duyduğundan, daha düşük bir sınır bu tensörün boyutunu küçültür ve büyük sözlüklere sahip, prefill ağırlıklı batchlerde bellek taşması (out-of-memory) hatalarını önler. Varsayılan olarak bu değer, gönderilen prompt sayısına eşitlenir; 1024 yedek değeri kullanılır ve ardından max_batch_tokens ile num_blocks değerlerine sığacak şekilde sınırlandırılır.
cb_config = ContinuousBatchingConfig(max_requests_per_batch=256)safety_margin, aktif istekler için boş önbellek kapasitesinin bir kısmını ayırır. Boş kapasite safety_margin (toplam önbellek boyutunun bir oranı) değerinin altına düştüğünde, zamanlayıcı yeni prefill kabul etmeyi durdurur ve yalnızca halihazırda devam eden çözümleme isteklerini sürdürür. Bu, yeni istekleri başlatmaktan ziyade aktif işleri tamamlamaya öncelik vererek çözümleme gecikmesini korur ve offloading işlemini erteler. Değer, 0 ile 1 arasında olmalıdır; 0 değeri payı devre dışı bırakır.
cb_config = ContinuousBatchingConfig(safety_margin=0.15)Varsayılan değer zamanlayıcıya bağlıdır. FIFO zamanlayıcı için 0.15, prefill_first için ise 0.0'dır. Payın zamanlamayla nasıl etkileşime girdiğini görmek için Kabul bölümüne bakın.
Log olasılıkları
ContinuousBatchingConfig, return_logprobs=True olduğunda üretilen her token’ın log olasılığını döndürür. Bu, logprobs’ların bazı eğitim döngülerine girdi olarak kullanıldığı RL için faydalıdır.
cb_config = ContinuousBatchingConfig(return_logprobs=True)
# generate_batch()
for request_id, output in outputs.items():
for token_id, log_prob in zip(output.generated_tokens, output.logprobs):
token = tokenizer.decode([token_id])
print(f"{token} | logprob: {log_prob}")CUDA grafikleri
CUDA grafikleri, GPU yürütme grafiğini bir kez kaydedip eşleşen şekillere sahip toplamlar için yeniden oynatarak CPU dağıtım maliyetini ortadan kaldırır. Bunları açıkça use_cuda_graph=True ile etkinleştirin.
cb_config = ContinuousBatchingConfig(use_cuda_graph=True)Aktif olduğunda, yönetici sorgu ve KV uzunluklarını sabit aralıklara doldurarak (padding) şekillerin tekrar etmesini ve grafiklerin yeniden kullanılmasını sağlar. q_padding_interval_size ve kv_padding_interval_size değerlerinin daha küçük olması, padding kaynaklı israf edilen hesaplama gücünü azaltır; ancak bu, grafiğin kaydetmesi ve saklaması gereken benzersiz şekillerin sayısını artırır ve bu da daha fazla bellek maliyeti demektir.
cb_config = ContinuousBatchingConfig(
use_cuda_graph=True,
q_padding_interval_size=64,
kv_padding_interval_size=16384,
)Eşzamanlı toplu işleme
Async batching, bir sonraki batch'in CPU'da zamanlamasını mevcut batch'in GPU'daki hesaplamasıyla üst üste bindirir. CUDA grafikleri gerektirir ve girdi tensörleri için kullanılan VRAM'i yaklaşık olarak ikiye katlar.
cb_config = ContinuousBatchingConfig(
use_cuda_graph=True,
use_async_batching=True,
)Derleme
default_compile_level, modelin ileri yönlü geçişlerine torch.compile uygular. Derleme, üretim sırasında daha hızlı ileri yönlü geçişler elde etmek için tek seferlik bir ısınma maliyeti öder. Daha yüksek seviyeler daha agresif optimizasyon çalıştırır; bu da verimliliği artırır ancak ısınma süresini uzatır. Testler ve ölçüm tekrarı için seviyeyi düşük tutun; ısınma maliyetinin birçok istek üzerinden geri kazanıldığı uzun süreli sunum iş yükleri için ise yükseltin.
Seviye 0 ile 3 arasında değişir. 0 seviyesi varsayılandır ve derlemeyi tamamen atlar.
| Seviye | mode | dynamic | Taviz |
|---|---|---|---|
| 0 | — | — | Derleme yok (varsayılan), en hızlı başlatma |
| 1 | default | True | Orta düzey hızlanma, kısa ısınma |
| 2 | max-autotune-no-cudagraphs | True | Daha fazla hızlanma, daha uzun ısınma |
| 3 | max-autotune-no-cudagraphs | False | En yüksek veri aktarımı, en uzun ısınma süresi |
cb_config = ContinuousBatchingConfig(default_compile_level=1)Seviye, varlen ve decode yürütme yollarına varsayılan bir CompileConfig sağlar. Yalnızca açık bir yapılandırması olmayan yola uygulanır; bu nedenle varlen_compile_config ve decode_compile_config ayarlandığında önceliklidir. FlashAttention altında, max_length_k sık yeniden derlemeye neden olduğu için varlen yolu derlemeyi atlar; bu durumda seviye yalnızca decode yolunu etkiler.
Hızlı çözümleme yolu
Bir batch yalnızca decode istekleri içerdiğinde (her dizi için bir sorgu tokenı), yönetici değişken uzunluklu çekirdek yerine flash_attn_with_kvcache çekirdeğine yönlendirme yapabilir. Bu, çekirdeğin manuel bir güncelleme yerine blok tablosu üzerinden sayfalı KV önbelleğini yerinde okuyup yazması nedeniyle varlen yolundan daha hızlıdır. Çekirdek düzeyindeki ayrıntılar için Sayfalı dikkat bölümüne bakın.
Hızlı yol, istek başına blok tablosunu boyutlandıran max_blocks_per_request ile boyutlandırılır. Varsayılan olarak bu değer otomatik çıkarılır. Yöneticide max_prompt_length ve max_generated_length ayarlanırsa, blok tablosu en uzun diziyi sığacak şekilde boyutlandırılır. Aksi takdirde, yedek bir varsayılan değer (istek başına 32 blok) kullanılır.
Blok tablosunu açıkça boyutlandırmak için max_blocks_per_request değerini belirli bir değere ayarlayın. Bu, istek başına maksimum dizin uzunluğunu biliyorsanız ve blok tablosu bellek maliyetini sınırlamak istiyorsanız faydalıdır.
cb_config = ContinuousBatchingConfig(max_blocks_per_request=64)Hızlı yolu devre dışı bırakmak ve her partiyi varlen çekirdeğinden geçirmek için max_blocks_per_request=0 değerini ayarlayın. Bu, varsayılan öncesi davranışı geri getirir ve hızlı yolun dikkat uygulamanız için kullanılamadığı durumlarda faydalıdır (yönetici, alttaki çekirdeğin kullanılamadığını algıladığında bunu otomatik olarak devre dışı bırakır).
cb_config = ContinuousBatchingConfig(max_blocks_per_request=0)Hızlı yol, iki cihaz ve dikkat uygulaması kombinasyonu için kullanılabilir olan flash_attn_with_kvcache çekirdeğine dayanır.
| Cihaz | attn_implementation |
|---|---|
| CUDA | flash_attention_2 veya flash_attention_3 |
| XPU | flash_attention_2 |
Diğer herhangi bir kombinasyon için veya çekirdek içe aktarılamadığında, yönetici varlen yoluna geri döner. Yalnızca max_blocks_per_request parametresini açıkça ayarladığınızda bir uyarı kaydeder.
Full attention, kernel block tablolarını destekler; sliding attention ise desteklemez. Modelde sliding attention katmanları varsa (full attention kullanan hibrit modeller dahil), başlatma işlemi max_blocks_per_request değerini 0 olarak zorlar ve sizin belirlediğiniz sıfırdan farklı bir değer geçersiz kılınır. Yönetici, modelin bazı attention türlerinin kernel block tablolarını desteklememesi nedeniyle decode fast path'inin kullanılamadığını günlüğe yazar.
CPU'ya aktarma
CPU offloading, GPU KV önbelleği dolduğunda, atılan KV önbelleği bloklarını önceden ayrılmış sabitlenmiş (pinned) CPU tamponuna kopyalar. Önbellek alanı müsait hale geldiğinde, yönetici blokları GPU'ya geri kopyalar ve isteği, prompt'unu ve üretilen token'ları yeniden hesaplamadan devam ettirir.
cpu_offload_space değerini GiB cinsinden CPU takas alanına ayarlayın. Varsayılan değer olan 0.0, CPU dışa aktarmayı devre dışı bırakır.
cb_config = ContinuousBatchingConfig(cpu_offload_space=8.0)Varsayılan olarak, psutil yüklüyse cpu_offload_space_safety_threshold=0.8, istenen alanı kullanılabilir sistem RAM'inin %80'i ile sınırlar. Takas havuzunu güvenlik eşiğine göre boyutlandırmak için cpu_offload_space=None olarak ayarlayın.
Tensor paralel zaman aşımı
Tensor paralelliği altında, yönetici, istek gönderimlerini, iptallerini ve kapanışı rank'lar arasında koordine etmek için bir CPU iletişim grubu oluşturur. cpu_group_timeout, bu gruptaki bir kolektifin işlem çökmeden önce ne kadar süreyle bloklanabileceğini sınırlar. Bir rank takılırsa, zaman aşımı diğerlerinin sonsuza kadar beklemesini engeller.
Nadirde kolektifler yapan iş yükleri için daha uzun bir zaman aşımı ayarlayın veya devre dışı bırakmak için None geçin.
cb_config = ContinuousBatchingConfig(cpu_group_timeout=600.0)Önek önbellekleme
Birden fazla istek, sistem istemi gibi ortak bir öneki paylaştığında, yönetici KV önbellek bloklarını yeniden hesaplamak yerine yeniden kullanır. allow_block_sharing varsayılan olarak True'dur. Önek paylaşımı, yalnızca tüm dikkat türü atayıcılar paylaşımı desteklediğinde etkin olur; bu nedenle yalnızca tam dikkat içeren modeller bunu kullanır. Saf kayan ve hibrit modeller, allow_block_sharing True olsa bile bunu devre dışı bırakır.
cb_config = ContinuousBatchingConfig(
allow_block_sharing=True, # default
)Bir dikkat arka ucunu seçin
Continuous batching, FlashAttention, SDPA ve "paged|eager" desteklenir. Modeli yüklerken attn_implementation parametresini ayarlayın.
| Arka uç | attn_implementation | Gereksinimler |
|---|---|---|
| FlashAttention 2 | “flash_attention_2” | flash-attn veya kernels paketi |
| FlashAttention 3 | “flash_attention_3” | flash-attn-3 veya kernels paketi |
| SDPA (PyTorch yerleşik) | “sdpa” | None |
| Eager | “paged|eager” | None |
model = AutoModelForCausalLM.from_pretrained(
"Qwen/Qwen3-4B",
attn_implementation="flash_attention_2",
device_map="auto",
dtype=torch.bfloat16,
)Continuous batching, FlashAttention kullanıldığında eager veya SDPA'ya kıyasla daha hızlı çalışır; bunun başlıca nedeni FlashAttention'ın bir attention mask'ine ihtiyaç duymamasıdır. Model FlashAttention'ı destekliyorsa, "eager" veya "sdpa" ile yüklenen bir model, FlashAttention 3 kurulu değilse FlashAttention 2'ye, FlashAttention 3 kuruluysa FlashAttention 3'e geçer ve bir uyarı kaydeder. Hiçbir sürüm kurulu değilse backend değiştirilmez.
Örneğin test sırasında eager veya SDPA'yı korumak için ContinuousBatchingConfig içinde auto_switch_to_flash=False değerini ayarlayın. Backend "eager" olarak kaldığında, sürekli toplama (continuous batching) bunun yerine "paged|eager" çalıştırır.
Tensor paralelliği
Tek bir GPU'ya sığamayacak kadar büyük modeller için, ağırlıkları tensor paralelliği ile cihazlar arasında bölün. Cihaz sayısını DistributedConfig(tp_size=N) ile ayarlayın. Sürekli toplu işleme (continuous batching), sayfalı KV önbelleğini (paged KV cache) her parça için boyutlandırmak üzere tensor paralel boyutunu modelden okur. Desteklenen mimariler listesi ve bölme işleminin nasıl çalıştığı hakkında Tensor parallelism bölümüne bakın.
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, DistributedConfig
from transformers.generation import ContinuousBatchingConfig, GenerationConfig
distributed_config = DistributedConfig(tp_size=4)
model = AutoModelForCausalLM.from_pretrained(
"Qwen/Qwen3-32B",
attn_implementation="flash_attention_2",
distributed_config=distributed_config,
)
tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen3-32B")
inputs = [tokenizer.encode(p) for p in ["What's up?", "Name a cat breed."]]
generation_config = GenerationConfig(max_new_tokens=64, eos_token_id=tokenizer.eos_token_id)
outputs = model.generate_batch(inputs=inputs, generation_config=generation_config)torchrun ile betiği başlatın ve --nproc-per-node değerini, paylaşımlı (shard) etmek istediğiniz GPU sayısına ayarlayın.
torchrun --nproc-per-node 4 cb_tp.py
Tensor paralel boyutu, modelin num_key_value_heads değerini (model yapılandırmasını kontrol edin) tam olarak bölmelidir. Aksi takdirde paged cache, başlangıçta bir hata üretir; bu nedenle uygun bir --nproc-per-node değeri seçin.
device_mapiledistributed_configbirlikte ayarlanmamalıdır.device_maptüm modülleri belirli GPU'lara yerleştirirken, tensor paralelliği aynı parametreleri tüm GPU'lara dağıttığı için bu iki ayar çelişir.
Kayan pencere dikkati
Kayan pencere dikkati (sliding window attention) kullanan modeller (Mistral, Gemma 2) sürekli toplu işleme (continuous batching) ile çalışır. Kayan katmanlar, küçük bir sayfa setini geri dönüştürerek yalnızca son tokenların sabit bir penceresini tutan SlidingAttentionCacheAllocator kullanır. Dikkat türü, ContinuousBatchingConfig değil, modelin layer_types veya sliding_window alanından gelir.
from transformers import AutoConfig, AutoModelForCausalLM
config = AutoConfig.from_pretrained("google/gemma-2-2b")
config.sliding_window = 4096
model = AutoModelForCausalLM.from_pretrained(
"google/gemma-2-2b",
config=config,
attn_implementation="sdpa",
device_map="auto",
dtype=torch.bfloat16,
)Önek önbellekleme ve decode hızlı yolu, tam dikkat katmanlarına da sahip hibrit modeller dahil olmak üzere, kayan dikkat mevcut olduğunda her zaman devre dışı bırakılır.
Sonraki adımlar
- Continuous batching blog yazısı, KV önbellekleme, parçalı ön doldurma ve dinamik zamanlamayı performans kıyaslaması sayılarıyla ele alır.
- Sürekli toplu işleme sisteminin nasıl çalıştığına daha derinlemesine bakmak için Continuous batching mimarisi belgesine göz atın.