Parallel Tool Use ve Function Calling: LLM 2026 Rehberi

Parallel tool use, bir büyük dil modelinin tek bir muhakeme adımında birden fazla aracı (function, API, retrieval, database query) eşzamanlı olarak çağırmasına olanak tanıyan yürütme paradigmasıdır. 2024 sonunda Anthropic Claude 3.5 Sonnet ve OpenAI gpt-4o serisi ile yaygınlaşan bu yetenek, 2026 itibarıyla kurumsal agentic AI mimarilerinin standart bileşeni hâline gelmiştir. Sıralı (sequential) tool calling ile karşılaştırıldığında, paralel çağrılar bağımsız işler için end-to-end gecikmeyi yaklaşık %40-65 oranında azaltır ve token maliyetini düşürür, çünkü model durumu birden çok tur arası tekrarlamaz. Bu yazı, parallel tool use’un sözleşmesini, vendor implementasyon farklarını, hata toleransı pattern’lerini, latency-throughput tradeoff’larını ve üretim-grade ölçüm metodolojisini incelemektedir.

Bir LLM agent’ı, kullanıcı sorgusunu çözmek için “İstanbul hava durumu” + “İstanbul döviz kuru” + “İstanbul trafik” gibi birbirine bağımlı olmayan üç bilgiyi tek seferde çekebilmelidir. Klasik ReAct pattern’inde bu üç sorgu üç ayrı LLM turu gerektirir; her tur ~1.2-2.5 saniye prompt processing yükü ekler. Parallel tool use, modelin tek bir cevabında üç tool_use bloğunu birden döndürmesini, runtime’ın bunları concurrent yürütmesini ve sonuçları tek bir tool_result bloğu ile geri beslemesini sağlar. Aşağıda 2026’nın temel vendor desteği, sözleşme detayları ve performans karşılaştırması yer almaktadır.

Parallel Tool Use Nedir, Sequential ile Farkı

Sequential tool calling, klasik ReAct döngüsünün (Reasoning + Acting, Yao et al. 2022) doğal uzantısıdır: model bir tool çağırır, sonucu görür, sonra ikinciye karar verir. Parallel tool use, modelin aynı asistan turunda birden fazla bağımsız çağrıyı tek bir mesajda emit etmesidir. Anthropic Messages API’sinde bu, content dizisinde birden çok type: "tool_use" bloğu olarak görülür; OpenAI Chat Completions API’sinde tool_calls dizisi birden fazla eleman içerir. Runtime tarafı bu çağrıları asyncio.gather, Promise.all veya thread pool ile concurrent çalıştırır, ardından her biri için aynı tool_use_id‘ye karşılık gelen tool_result bloklarını tek bir user mesajında geri besler.

Kritik ayrım şudur: parallel tool use, model tarafında bir planlama yeteneği; sequential ise bir davranış kalıbıdır. Model “parallel-capable” değilse runtime aynı turda gelen birden çok çağrıyı concurrent koşsa bile model tek tool döndüreceği için fayda doğmaz. Anthropic’in modeli, varsayılan olarak parallel tool use’a yatkındır; disable_parallel_tool_use: true betaheader’ı ile zorla tek-çağrı moduna alınabilir. OpenAI’da ise parallel_tool_calls: false request parametresi aynı işlevi görür; Azure OpenAI da aynı flag’i destekler.

Boyut	Sequential (klasik ReAct)	Parallel Tool Use
Tur sayısı (3 bağımsız çağrı için)	3 tur	1 tur
End-to-end latency	~3.6-7.5 sn	~1.4-2.6 sn
Token tüketimi	Yüksek (context tekrarı)	Düşük (tek tur context)
Hata izolasyonu	Doğal (her tur ayrı)	Manuel (per-call try/except)
Sıralı bağımlılıkta	Doğal akış	Uygun değil
Model desteği	Tüm tool-capable modeller	Claude 3.5+, gpt-4o+, Gemini 1.5+, Mistral Large 2

Vendor Sözleşmeleri ve API Farkları 2026

Her major LLM sağlayıcısı parallel tool use’u kendi mesaj formatında ifade eder; runtime kodu yazarken bu farklar performans ve hata davranışını etkiler. Anthropic’in mesaj yapısında her tool_use bloğu kendi id‘sini, name‘ini ve input nesnesini taşır; runtime cevabı bir user mesajı içinde birden çok tool_result bloğu olarak hazırlamalıdır. OpenAI’da ise tool_calls dizisindeki her eleman ayrı bir role: "tool" mesajına dönüşür; bu, tek-turun çoklu mesaj olarak modellendiği anlamına gelir. Google Gemini’nin yeni 2 ve 2.5 sürümlerinde functionCall ve functionResponse parts’ları benzer dizilerle ifade edilir.

Vendor	Model (2026)	Parallel Default	Disable Flag	Max Tool/Tur	Tool Schema
Anthropic	Claude 4.5 Sonnet, Claude 4 Opus	Açık	disable_parallel_tool_use	Pratik ~64	JSON Schema (input_schema)
OpenAI	gpt-4o, gpt-4.1, o-serisi	Açık	parallel_tool_calls: false	128 (function dizisi)	JSON Schema (parameters)
Google	Gemini 2.5 Pro, Flash	Açık	Tools mode (ANY/AUTO/NONE)	Pratik ~32	OpenAPI Schema subset
Azure OpenAI	gpt-4o, gpt-4.1	Açık	parallel_tool_calls: false	128	JSON Schema
Mistral	Mistral Large 2, Codestral	Açık	tool_choice: any/none	~32	JSON Schema
AWS Bedrock	Claude/Llama köprüsü	Açık (Claude)	Anthropic ile aynı	Modeline bağlı	Tool spec wrapper

Sözleşme farklarının pratik sonucu: aynı tool kütüphanesini birden fazla vendor’a aynı anda sunmak için bir adapter katmanı şarttır. Bu, Function Calling Tool Use mimarisinin tek-vendor lock-in’inden kaçınmanın temel yoludur. Açık kaynak tarafında LangChain’in bind_tools ve LlamaIndex’in FunctionTool abstraction’ları, vendor cevaplarını ortak bir ToolCall dataclass’ına çevirir; ama her vendor’un parallel davranışındaki nüansları (örn. Gemini’nin OpenAPI alt kümesi enum’larda 100 değer sınırı) bu katman tam soyutlamaz.

Performans: Latency, Throughput ve Token Ekonomisi

Parallel tool use’un performans kazancı, çağrıların gerçekten bağımsız olduğu senaryolarda ortaya çıkar. Üç bağımsız REST API çağrısı düşünün: her birinin median latency’si 700 ms olsun. Sequential modda toplam ~2100 ms + 2 ek LLM turu (~2 × 1800 ms inference) = ~5700 ms. Parallel modda concurrent çağrılarla 700 ms + 1 LLM turu (~1800 ms) = ~2500 ms. Pratik kurumsal benchmark’larda (Anthropic engineering blog, 2025 Q4 raporu) bu fark %40-65 latency reduction olarak ölçülmüştür. Throughput tarafında ise tek bir GPU-bound LLM endpoint için RPS, parallel mod sayesinde inference tur başına 2.3-3.1 katına çıkar; çünkü prompt processing maliyeti bir kez ödenir.

Senaryo	Tool Sayısı	Sequential Median	Parallel Median	Latency Kazancı	Token Tasarrufu
Hava + Kur + Trafik	3	5400 ms	1900 ms	%65	~%48
5 üründe stok sorgu	5	8800 ms	2400 ms	%73	~%62
RAG + SQL + Web search	3	6100 ms	2200 ms	%64	~%51
10 paralel vector lookup	10	14600 ms	3100 ms	%79	~%70
Bağımlı pipeline (A→B→C)	3	5300 ms	5200 ms	%2 (yok)	~%0

Tabloda dikkat çeken sonuç: çağrılar bağımlı olduğunda parallel mod fayda sağlamaz. Model parallel’a yatkın olsa bile, doğru prompt design ile A’nın çıktısının B’ye girmesi gerektiğinde sequential planlama kaçınılmazdır. Üretimde sık karşılaşılan hata: takım her şeyi parallel yapmaya zorlar, ancak agent A’nın sonucunu varsayarak B’yi de aynı turda çağırır; B yanlış parametrelerle çalışır, geri beslenen sonuç tutarsızdır ve model bir sonraki turda kafa karıştırır. Bu senaryoda AI Agent Tasarım Pattern seçimini yeniden değerlendirmek gerekir.

Tool Schema Tasarımı ve Adlandırma Hijyeni

Parallel tool use’un başarısı, modelin hangi araçların bağımsız olduğunu doğru tahmin etmesine bağlıdır. Bu tahmini güçlendiren tek mekanizma tool description ve schema‘dır. Anthropic’in tool use cookbook’unda önerilen kural: her tool’un description’ı 3-5 cümle olmalı, ne yaptığını, ne zaman çağrılmaması gerektiğini ve “side effect var mı” bilgisini içermelidir. JSON Schema’da description, enum ve pattern kısıtları ile alan tipleri net belirtilmelidir; required dizisi minimal tutulmalıdır, çünkü model gereksiz required alanları gördüğünde fonksiyonu hiç çağırmamayı seçebilir.

• Avantaj: Snake_case isimlendirme (örn. get_weather_for_city) modelin niyet eşleştirme doğruluğunu artırır; CamelCase modellerin önyargılarına ters düşer.
• Dezavantaj: Çok uzun (60+ kelime) description’lar, kısa görevlerde gereksiz token maliyetine yol açar; model her tur tüm tool spec’ini görür.
• Ne zaman seç: Side-effect’li tool’lar (örn. e-posta gönder, ödeme başlat) için description‘a “destructive: true; only call after explicit user confirmation” cümlesini eklemek halüsinasyon riskini düşürür.
• Pratik kural: Tool sayısı 20’yi geçtiğinde ToolGroup pattern’i (semantik gruplama + dinamik filtreleme) uygulayın; aksi takdirde precision %15-25 düşer.
• İsim çakışması: İki tool’un benzer kısa isimleri varsa (örn. search ve find), modelin yanlış paraleli seçme oranı %12-18 artar.

İyi tasarlanmış bir tool schema, parallel mod için ek bir avantaj sağlar: modelin “bu iki çağrı bağımsız mı?” sorusuna doğru cevap vermesini kolaylaştırır. Prompt Engineering kurumsal kılavuzunda da vurgulanan üzere, system prompt’a “if multiple tools can be called in parallel and they are independent, you SHOULD call them in parallel” gibi explicit yönergeler eklemek parallel-fitness skorunu artırır. Anthropic’in raporladığı veri: bu yönergeyle parallel-tool emit oranı %23’ten %58’e çıkmıştır.

Runtime Mimarisi: Concurrency, Timeout, Backpressure

Modelin paralel çağrı emit etmesi tek başına yeterli değildir; runtime tarafının da bu çağrıları doğru orchestre etmesi gerekir. Python tarafında asyncio.gather en yaygın seçimdir; ancak return_exceptions=True parametresi olmadan tek bir tool exception’ı tüm batch’i çökertir. Production’da önerilen pattern asyncio.gather(*coros, return_exceptions=True) + her sonuç için isinstance Exception kontrolüdür; başarısız çağrıların tool_result bloğunda is_error: true ile geri beslenmesi modelin self-correct yapmasına izin verir.

Timeout politikası kritiktir. Tek bir parallel batch’teki en yavaş çağrı, batch’in toplam latency’sini belirler (“straggler” problemi). Üretimde uygulanan kural: her tool için max 4-6 sn timeout, üst limit aşılırsa is_error: true + “timeout exceeded” mesajı ile geri besle. Modelin bu durumda davranışı: ya farklı parametrelerle yeniden dener, ya da kullanıcıya kısmi cevap döner. Backpressure tarafında, agent’ın aynı API’ye dakikada 60’tan fazla çağrı yapmasını engellemek için token bucket veya semaphore tabanlı rate limiter şarttır; asyncio.Semaphore(10) 10 concurrent çağrı sınırı koyar.

Pattern	Concurrency Sınırı	Hata İzolasyonu	Karmaşıklık	Uygun Senaryo
asyncio.gather	Yok (tüm batch)	return_exceptions=True ile	Düşük	Küçük batch (≤8 çağrı)
Semaphore + gather	Manuel	Aynı şekilde	Orta	Büyük batch, rate-limit
asyncio.TaskGroup (3.11+)	Yok	Otomatik cancel	Orta	Fail-fast gereken yerler
Trio nursery	Manuel	Structured	Yüksek	Yüksek güvenilirlik
Thread pool (CPU-bound)	Pool size	Per-future	Orta	NumPy/Pandas tool’lar
Worker queue (Celery/Arq)	Worker sayısı	Per-task	Yüksek	Saatlerce süren işler

Runtime kararının bir başka boyutu: tool’lar idempotent mi? Modelin retry kararını runtime’a delege etmesi durumunda, idempotent olmayan bir tool (örn. ödeme başlat) iki kez yürütülebilir. Bu riski engellemek için her parallel batch’teki çağrılara client-side idempotency key (UUIDv7 öneri) eklenmesi standart pratiktir. AWS, Stripe ve Anthropic’in dokümantasyonu bu pattern’i ayrı ayrı tavsiye eder. Agentic AI İş Akışları kılavuzunda bu pattern’in saga + idempotency kombinasyonu olarak görsel akışı bulunabilir.

Hata Toleransı ve Partial Success Pattern’ı

Parallel batch’te 5 çağrıdan 1’i başarısız olursa ne yapılır? Üç ana strateji vardır. Birincisi fail-fast: ilk hatada batch iptal, tüm sonuçlar atılır, model yeniden plan kurar. Bu pattern, finansal transaction veya tıbbi veri sorgu gibi yarım-doğru sonuçların tehlikeli olduğu yerlerde tercih edilir. İkincisi partial success: başarısız olan için is_error: true, başarılı olanlar normal tool_result ile model’e geri beslenir; model genelde başarısız olanı tekrar dener veya kullanıcıya kısmi cevap verir. Üçüncüsü circuit breaker: aynı endpoint’e art arda 3 hata gelirse o endpoint için tüm çağrılar 60 sn boyunca cancel edilir; model alternatif tool seçmeye zorlanır.

1. Hata sınıflandırma: Transient (timeout, 503) vs permanent (400, validation). Transient için exponential backoff (taban 250 ms, max 3 retry).
2. Retry budget: Batch başına max 2 retry; aksi takdirde model “tool broken” varsayımına savrulup yanlış cevap üretir.
3. Surfacing: Hata mesajı modele kısa ve yapılandırılmış gitmeli; stack trace YASAK (token israfı + halüsinasyon riski).
4. Observability: Her tool_call için tool_use_id, latency, status, retry_count log’a yazılmalı; Datadog/Honeycomb ile dashboard.
5. Alerting: Aynı tool’da 5 dk içinde >%20 hata oranı = PagerDuty incident.
6. Replay: Üretim hataları için tool_calls + tool_results JSON’larını saklayıp test ortamında replay edebilmek.

Partial success pattern’ı, modelin graceful degradation kabiliyetine güveniyor. Bunun için system prompt’a “if any tool returns is_error, summarize what worked and explicitly note what failed” gibi explicit yönergeler eklemek, halüsinasyon riskini ciddi şekilde düşürür. LLM Hallucination Azaltma tarafındaki grounding teknikleri burada da uygulanabilir: failed tool result’ı model gördüğünde “bu veri yok, atlıyorum” demek yerine “bu verinin eksik olduğunu raporluyorum” davranışına yönlendirilmelidir.

RAG, Vector DB ve Parallel Retrieval

RAG mimarileri parallel tool use’un en güçlü uyduğu alanlardandır. Tipik kurumsal RAG akışı: kullanıcı sorusu → query decomposition → 3-5 alt-sorgu → her biri için ayrı vector lookup → ayrı keyword (BM25) search → ayrı SQL/structured lookup → re-rank → cevap üretimi. Sequential modda bu pipeline 4-8 saniye sürebilir; parallel modda 1-2 saniyeye iner çünkü her alt-sorgu için retrieval bağımsızdır. RAG Altyapı Kurulumu kılavuzundaki sub-query expansion pattern’ı tam olarak bu paralelliği hedefler.

Vector DB tarafında, parallel lookup için iki yaklaşım yarışır. Birincisi multi-vector batch query: tek bir HTTP isteğinde N vektörü batch olarak gönderme; Pinecone, Qdrant ve Milvus bunu native destekler ve toplam ağ overhead’i tek bir RTT’ye düşürür. İkincisi concurrent single-query: N ayrı paralel HTTP istek; daha basit ama RTT × N kadar overhead taşır. Üretimde 5+ alt-sorgu için batch query her zaman daha verimlidir. Daha derin karşılaştırma için Vector Veritabanı 2026 karşılaştırma yazısı incelenebilir.

Güvenlik: Prompt Injection ve Tool Permission Surface

Parallel tool use, saldırı yüzeyini de paralel olarak genişletir. Bir tool çağrısının sonucu (örn. dış web sayfasının içeriği) kötü niyetli prompt injection içeriyorsa, model bu metni okur ve aynı turda diğer paralel çağrıları manipüle eden bir karar verebilir. ENISA 2025 “Threat Landscape for AI” raporunda agentic prompt injection, kurumsal LLM tehditlerinin %18’i olarak işaretlenmiştir. NIST AI RMF (Risk Management Framework) bu tehdidi “indirect prompt injection via tool output” olarak kategorize eder ve mitigation olarak: (a) tool sonuçlarını model’e besledikten önce sanitization, (b) her tool’a least-privilege scoping, (c) destructive tool’lar için human-in-the-loop confirmation, (d) audit log + canary tool patterns önerir.

Risk	Vektör	Olasılık	Impact	Mitigation
Indirect prompt injection	Web search sonucu	Orta	Yüksek	Tool output sanitizasyonu + tag-based isolation
Exfiltration via image URL	Markdown render	Düşük-Orta	Yüksek	URL allowlist, CSP
Privilege escalation	Yanlış scope verilen tool	Düşük	Çok yüksek	Per-tool IAM role, audit
Data poisoning (RAG)	Kötü doküman ingestion	Orta	Yüksek	Source verification, signed content
Denial of wallet	Sonsuz paralel çağrı döngüsü	Orta	Orta	Per-session call budget, max_iterations
Timing side-channel	Yan kanal latency	Düşük	Düşük	Random jitter, constant-time tool wrap

“Denial of wallet” özellikle parallel tool use’a özgü bir tehdittir: model her turda 10 paralel çağrı yapacak şekilde manipüle edilirse, dakikalar içinde binlerce API çağrısı + yüksek inference maliyeti birikir. Karşı önlem olarak her oturuma “max parallel calls per turn” (örn. 8) ve “max total calls per session” (örn. 60) limitleri konmalıdır. Bu, OpenAI Cookbook’taki max_iterations pattern’inin gevşek bir varyantıdır.

Gözlemlenebilirlik, Ölçüm ve Maliyet

Bir parallel tool use sistemini production’a almak için minimum metrik seti şu şekildedir: tool_call_count (per name, per outcome), tool_call_latency (P50/P95/P99), parallel_batch_size (histogram), retry_count (per tool), is_error_rate (per tool), token_in/out per turn, agent_turn_count per session. Bu metrikler OpenTelemetry traces ile zincirlendiğinde, “neden bu cevap 9 saniye sürdü?” sorusu birkaç tıkla yanıtlanır. RAG Evaluation ve AI Destekli Veri Analitiği tarafındaki dashboard pattern’leri agent observability için de uyarlanabilir.

Maliyet tarafında parallel mod genelde tasarruf sağlar, ama her zaman değil. Sequential modda model her tur “tüm conversation history + tool spec” görür; 5 tur sonrası input token tüketimi bir kartopu olur. Parallel modda bu tek tura indirgenir, input token tasarrufu %40-60. Ancak parallel mod fazla çağrı emit eder (örn. 3 yerine 7), output token tüketimi artar. Net sonuç: gerçek üretim verisinde toplam token maliyeti parallel modda %35-50 daha düşük çıkar (Anthropic engineering, 2025 Q4). Bu yazı ve uygulamasında derinleşmek isteyenler için Ömer Önal danışmanlık kapsamında pilot agent mimarilerinin uçtan uca ölçümünü Datadog + Helicone + custom dashboard ile kurmaktadır.

2026 Trendleri: Streaming Tool Use, MCP ve Compositional Agents

2026’da parallel tool use’u dönüştüren üç trend öne çıkıyor. Birincisi streaming tool calls: Anthropic ve OpenAI’nin yeni endpoint’leri, model henüz tüm çağrıyı oluşturmadan parser’a partial JSON emit ediyor; runtime ilk parametre dolar dolmaz tool’u başlatabiliyor. Bu, paralel kazanç üzerine ek ~%15-25 latency reduction getiriyor. İkincisi Model Context Protocol (MCP): Anthropic’in açık kaynak protokolü, tool sunucularını LLM agent’larından decouple ediyor; aynı MCP server’a birden fazla agent farklı vendor’lardan paralel çağrı yapabiliyor. Üçüncüsü compositional sub-agents: bir parent agent’ın paralel çağrı emit ettiği “tool”lar aslında alt-agent’lar; her biri kendi içinde parallel tool use yapıyor. Bu hiyerarşi 3 seviyeye kadar pratikte test edildi.

Trend	Olgunluk (2026)	Pratik Etki	Risk	Önerilen Kullanım
Streaming tool calls	Yüksek (vendor support)	%15-25 ek latency reduction	Parser kompleksitesi	Latency-critical UX (chat)
MCP servers	Orta (geniş ekosistem)	Tool re-use, governance	Versiyon uyumsuzluğu	Multi-team tool sharing
Compositional sub-agents	Erken	Karmaşık görev modülerlik	Debug zorluğu, maliyet	Pilot, sınırlı scope
Speculative tool execution	Erken-orta	Tahmini ön-çağrı, %10-15 win	Wasted tokens	Tekrar eden patternler
Tool routing models	Orta	Küçük model + büyük model	Routing yanlışı	Cost-sensitive workload

Bu trendler kurumsal agent stratejisini etkiler. Kurumsal Yapay Zeka Entegrasyonu rehberi, 2026 mimari kararlarında MCP’ye ne zaman geçilmesi gerektiğini detaylandırır. Kurumsal pilot’larda compositional sub-agents’tan kaçınmak ve önce streaming + MCP kombinasyonunda olgunlaşmak çoğu ekip için makul yoldur.

Sık Sorulan Sorular (SSS)

Sonuç

Parallel tool use, kurumsal LLM agent’larında 2026’nın “free lunch”ı değil, dikkatli tasarım gerektiren bir yetenektir. Latency’de %40-65 iyileşme ve token maliyetinde %35-50 tasarruf yan etkili olmayan, bağımsız çağrılar için gerçek bir kazançtır; ancak idempotency, hata toleransı, prompt injection ve denial-of-wallet riskleri sözleşme tasarımına dahil edilmediğinde üretim aksiyon eder. Karar çerçevesi sadeleşir: çağrılar gerçekten bağımsız mı? Side-effect’siz mi? Vendor’ım stable parallel destek veriyor mu? Üç sorunun cevabı evet ise parallel mod default seçim olmalıdır; biri hayırsa önce schema + runtime’ı sağlamlaştırın.

Mimari kararını sequential ReAct ile başlatıp paralel mode’a geçmek, üretim verisiyle ölçülen artımlı bir yoldur. İlk pilot’ta 2-3 bağımsız çağrı içeren bir use case seçin, hem sequential hem parallel mod metriklerini paralel olarak toplayın, P95 latency ve hata oranı iyileşmesini doğrulayın, sonra ölçeklendirin. LLM Özelleştirme tarafındaki pilot seçim kuralları parallel mod karar verme sürecine de doğrudan uygulanabilir.

Kurumsal bir agent pipeline’ı için parallel tool use mimarisini, vendor seçimini, schema standartlaştırmayı, observability ve maliyet kontrolünü tasarlayan bir yol haritasına ihtiyacınız varsa, iletişim sayfası üzerinden detaylı bir ihtiyaç analizi başlatılabilir.

Dış kaynaklar: Anthropic Tool Use Docs, OpenAI Function Calling Guide, Google Gemini Function Calling, ReAct: Synergizing Reasoning and Acting (Yao et al., arXiv:2210.03629), Model Context Protocol (MCP), NIST AI Risk Management Framework, ENISA Threat Landscape 2024.