Are Turkey's domestic LLMs enough? BILGE, KUMRU, MAIN and multi-model strategy

How the question "are domestic LLMs enough?" should be framed

Public institutions researching domestic large language models usually ask a single question: will a model developed in Turkey do the institution's work? That question has no one-word answer, because an institution's "work" is not a single task.

Most of the daily volume an institution produces consists of short, repetitive tasks: labelling an incoming petition by subject, summarizing a document, extracting fields from a form, searching an archive. The same institution also has tasks that require comparing a set of regulations running to hundreds of pages and producing a multi-step conclusion. These two groups of tasks require different model scales.

The question to ask is therefore not "which model is best" but "which task belongs to which model". This article compares three language model initiatives developed in Turkey using only publicly available, dated data, and then shows that an institution usually needs a portfolio of models rather than a single model.

• For short, high-volume tasks the deciding factors are latency and unit cost.
• For long-context tasks the deciding factors are the context window and reasoning capacity.
• For the highest classification levels of data the deciding factor is network topology, not model scale.
• Because institutions have all three needs at once, a single-model setup usually leaves one of them unmet.

Large language models developed in Turkey: the public record

Three initiatives with publicly available technical information stand out among the large language models developed in Turkey: BILGE, developed by TÜBİTAK BİLGEM (Scientific and Technological Research Council of Türkiye, Informatics and Information Security Research Center); Kumru, developed by VNGRS; and the MAIN platform, developed by HAVELSAN. All three are offered under different access models, and that difference directly determines which one a public institution can actually use today.

TÜBİTAK BİLGEM stated BILGE's access status in a 14 June 2026 announcement with this sentence: "Bilge henüz genel kullanıma açılmış bir hizmet değildir" ("Bilge is not yet a service opened to general use"). In the same statement the institution said that applications offered under the BILGE name on the internet or on various platforms, or associated with BILGE, should not be regarded as official services provided by TÜBİTAK BİLGEM, and added that information on access procedures would be shared only through the official channels of TÜBİTAK and the Ministry of Industry and Technology. On 30 July 2026 it was announced that BILGE would be opened to developers, but no date was given in that announcement.

Public sources disagree on BILGE's parameter scale. Reports dated 29 June 2026 stated that the BILGE family spans a parameter scale from 1 billion to 122 billion, that models with 1.9 billion and 27 billion parameters exist, and that a 122 billion parameter model is under development. A separate report dated 30 July 2026 cited a figure of 37 billion parameters. This article does not treat either figure as authoritative; both are reported with their dates. The verifiable performance figure for BILGE is a score of 44.44 out of 50 in a cultural translation evaluation, in which up to 41 percent higher performance was reported in the cultural translation category (29 June 2026). The model was trained on 1 trillion words of raw data.

Kumru, developed by VNGRS, was announced on 10 October 2025. Kumru-7B is described as a 7.4 billion parameter model pre-trained from scratch entirely for Turkish; pre-training used 500 GB of cleaned and deduplicated Turkish text and 300 billion tokens. The model has a reported context window of 8,192 tokens and is reported to run on GPUs with 16 GB of VRAM. For Kumru's Turkish-specific tokenizer, the Kumru-2B model card records this measurement: other open-source models spend between 38 percent and 98 percent more tokens than Kumru despite having larger vocabulary sizes. The two models differ on access: Kumru-2B is published on Hugging Face under the Apache 2.0 license, while Kumru-7B is offered for on-premises deployment and its Hugging Face repository required authentication when checked on 13 August 2026.

MAIN, developed by HAVELSAN, is positioned as an enterprise AI platform rather than a language model. The name comes from the initials of "Multifunctional Artificial Intelligence Network". It includes a 9 billion parameter model built from open-source components following a year of research and development by HAVELSAN engineers; alongside that model, the platform runs an architecture that orchestrates models of different scales together and engages the capacity a given task requires. The MAIN V2.0 announcement dated 4 December 2025 described the architecture as "güvenli, modüler ve kapalı ağlarda çalışabilen mimarisiyle" ("with its secure, modular architecture capable of operating on closed networks"); core module features listed include role-based access, fully closed-network operation and security controls. MAIN V2.0 modules include language, speech, analytics, agent, human resources, code assistant and tactical modules, with the language module reporting text comprehension, translation and summarization in more than 200 languages. MAIN placed first in the "Best in AI-Ready Platform" category at the IDC Future Enterprise Awards 2025.

Alongside these three initiatives, TÜBİTAK operates the ARF high-performance computing cluster, commissioned for developing and scaling AI models. The ARF-ACC system placed 145th on the TOP500 list announced on 18 November 2025, up from 266th on the June 2025 list. 192 NVIDIA H200 GPUs were added to the system in 2025. This article makes no claim about which model was trained on which infrastructure; the ARF data is included only to indicate the scale of training capacity available in the country.

Model scale by task type and what a Turkish-specific model contributes

The AI workload of a public institution is not uniform, and model selection becomes predictable in both quality and cost once it is made per task class. The table below matches task types to model scales and indicates whether a model trained specifically for Turkish contributes measurably to that task.

The most concrete contribution of Turkish-specific training appears in tokenization efficiency. Because Turkish is an agglutinative language, general-purpose tokenizers split the same text into more pieces, which means the same document consumes more tokens. Token count directly affects both cost and how much text fits into the context window. For long-context work, multi-step reasoning, code generation and multilingual tasks, however, the deciding factors are model scale and the breadth of training data rather than language adaptation.

Because an institution's task list is distributed across both groups, an architecture built on a single model either spends more resources than necessary on high-volume simple tasks or runs into the context window on heavy ones.

The advantage a closed-network deployment has that a gateway cannot provide

A public institution that builds its own closed-network infrastructure gains an advantage LLMTR cannot offer: the ability to operate entirely disconnected from the internet. This is not a shortcoming of LLMTR but an architectural fact. LLMTR is an API gateway, and reaching a gateway requires network connectivity. For the highest classification levels of data, the correct answer is a deployment that runs on the institution's own hardware and never leaves the internal network.

The options that meet this need are visible in the public record. The HAVELSAN MAIN announcement dated 4 December 2025 lists "tamamen kapalı ağda çalışma" (fully closed-network operation) among core module features, and describes the platform architecture as secure, modular and capable of operating on closed networks. Kumru-2B, published on Hugging Face under Apache 2.0, can be downloaded to an institution's own servers and run without external connectivity; Kumru-7B is reported to run on GPUs with 16 GB of VRAM, a figure that lowers the hardware threshold for a closed-network deployment.

The costs an institution assumes with a closed-network deployment are equally clear and should be priced in from the outset by the procurement unit: acquisition and depreciation of GPU hardware, manual handling of model updates, capacity planning during scaling, and model variety limited to what the institution has deployed itself. These costs do not make closed-network deployment the wrong choice; they raise the question of which data classes justify them.

In practice most institutions need a data classification rather than a single answer: the highest classification levels stay on the closed network, while the remaining task volume is processed in a layer permitted to make external connections. Managing those two layers together is the subject of the next section.

• A closed-network deployment is the correct architecture for data classes that must never leave the internal network, and no gateway can provide it.
• In return, the institution assumes the burden of hardware, updates and capacity planning.
• Not all of an institution's task volume carries the same classification level; an undifferentiated "everything on the closed network" decision applies the same cost to low-classification tasks as well.
• In a two-layer setup, what matters is a written definition of which data is processed in which layer.

The implementation layer for a multi-model strategy: one surface, a different model per task

A multi-model strategy means routing different tasks to different models and doing so through a single integration surface. The implementation cost of the strategy comes from setting up a separate SDK, separate authentication and separate billing for each model; once that cost disappears, choosing a model per task becomes a configuration decision.

LLMTR provides a single OpenAI-compatible /v1 surface for this purpose. The application sets base_url and the API key once, after which only the model identifier changes per task. Turkey-hosted models and global provider models are called from the same catalog under the same schema, so assigning a task to a model is a parameter change rather than a code change.

The example below shows a high-volume short task and a long-context task routed to two different models within the same code. Both calls are made with the same key and appear in a single usage report.

• When the model identifier is held as a configuration value, task-to-model assignment can change without a code deployment.
• Running the same test set across two models lets the institution compare using its own data.
• If a small model produces sufficient results for a task class, running that task on a large model raises cost without a corresponding return.
• Internal search and embedding tasks run under a separate model identifier and are measured separately.

Switching between a Turkey-hosted model and a global model by changing only the model identifier in the same code (OpenAI Python SDK)

import os
from openai import OpenAI

# One client, one surface: base_url and key are set once.
client = OpenAI(
    api_key=os.environ["LLMTR_API_KEY"],  # placeholder: supply your own key
    base_url="https://llmtr.com/v1",
)

# Per-task model choice: the code stays the same, only the model id changes.
TR_HOSTED = "llmtr/qwen3-5-4b"           # small model hosted in Turkey
WIDE_CONTEXT = "anthropic/claude-opus-5"  # long context and multi-step analysis


def ask(model: str, system: str, content: str) -> str:
    response = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": system},
            {"role": "user", "content": content},
        ],
        max_tokens=1024,
    )
    return response.choices[0].message.content


petition_text = open("petition.txt", encoding="utf-8").read()
regulation_text = open("regulation.txt", encoding="utf-8").read()

# High-volume, short task: model hosted in Turkey
label = ask(
    TR_HOSTED,
    "Label the subject of the incoming petition with a single word.",
    petition_text,
)

# Long regulatory comparison: wide-context model
analysis = ask(
    WIDE_CONTEXT,
    "Compare the two regulation texts and list the differences item by item.",
    regulation_text,
)

print(label)
print(analysis)

How LLMTR addresses this need

LLMTR is not an alternative to domestic language models but the implementation layer for a multi-model strategy. What an institution usually needs is not to "pick a model" but to use several models at once under the same authentication and the same reporting structure. LLMTR provides that layer through a single OpenAI-compatible /v1 surface.

Eight models hosted in Turkey can be called directly from the catalog: llmtr/gemma-4, llmtr/qwen3-6-35b, llmtr/medgemma-4b, llmtr/trendyol-7b, llmtr/magibu-11b-v8, llmtr/embeddinggemma-300m, llmtr/qwen3-5-4b and llmtr/ornith-1-35b. Alongside these, models from global providers such as OpenAI, Anthropic, Google, xAI, Qwen and Mistral are called from the same catalog under the same schema. An institution can route high-volume, low-classification tasks to a small Turkey-hosted model and long-context tasks to a wide-context model, and see both in a single usage report.

Three points matter for institutional use. First, each unit can hold its own API key, with its own rate limit, its own spending cap and its own usage report, so budget is tracked per unit. Second, user prompts and model response bodies are not written to the usage and billing database; customer API keys are stored as SHA-256 hashes rather than plaintext, and provider API keys are held only in environment variables. Third, the pricing structure is explicit: an 8% platform margin applies to credit top-ups, and no margin is added to model prices.

The limit stated in the fourth section applies here as well: for data classes that must run entirely disconnected from the internet, LLMTR is not the right layer, and that data should remain in the institution's own closed-network deployment. The need LLMTR addresses is running the remaining task volume through a single integration without giving up model variety. If a model such as BILGE, which is not yet open to general use, becomes accessible later, the task-to-model structure the institution has built is preserved; the only thing that changes is the model identifier assigned to the relevant task class.

In institutional procurement language this is assessed under headings such as "yapay zekâ yazılımı kiralama" (artificial intelligence software leasing) or "yapay zekâ hizmet alımı" (artificial intelligence service procurement); in the technical team's language it is API-based token usage. Both descriptions refer to the same deployment.

Sources

The figures, dates and quotations in this article were verified against the public sources below. Last checked: 13 August 2026. No parameter, date or performance claim that could not be verified has been included; where sources disagree, the disagreement is reported as such.

This content is informational and does not constitute legal advice. The final assessment rests with the institution's compliance and legal units.

• TÜBİTAK statement on BILGE access status, 14 June 2026 — gazeteoksijen.com
• BILGE model family, parameter scale and cultural translation evaluation, 29 June 2026 — dunya.com
• Announcement that BILGE will be opened to developers, with a 37 billion parameter figure, 30 July 2026 — alomaliye.com
• Kumru announcement, parameter count and training data figures, 10 October 2025 — webrazzi.com
• Kumru-2B model card, Apache 2.0 license and tokenizer efficiency measurement — huggingface.co
• HAVELSAN MAIN V2.0 module structure and closed-network architecture announcement, 4 December 2025 — havelsan.com
• MAIN V2.0 presentation and IDC Future Enterprise Awards 2025 result, 23 November 2025 — aa.com.tr
• ARF-ACC system ranking on the TOP500 list of 18 November 2025 — tubitak.gov.tr
• LLMTR model catalog and models hosted in Turkey — llmtr.com

Building a task-to-model map in a public institution

Steps for a public institution to match its own task inventory against classification level and model scale, and move to a multi-model setup.

1. Build a task inventory. List one by one the tasks the institution plans to run with AI, and record for each the estimated monthly volume, the average input length and the expected response time. Without these three figures a model scale decision cannot be made.
2. Separate tasks by classification level. Classify each task by the classification level of the data it processes, and move tasks whose data must never leave the internal network into a separate list. That list defines the scope of the closed-network deployment, and the remaining list defines the scope of the gateway layer.
3. Identify candidate models per task class. Shortlist Turkish-specific or Turkey-hosted models of 1-8 billion parameters for short, high-volume tasks, and large-scale models with wide context windows for tasks requiring long context and multi-step analysis. Record the access model and license for each candidate as well.
4. Compare using the institution's own data. Prepare a fixed test set drawn from the institution's real documents for each task class and run the candidate models against the same test set. Record not only accuracy but also input token counts, response times and unit cost.
5. Issue per-unit keys and caps. For tasks that will run on the gateway layer, issue a separate API key per unit and define a rate limit and a spending cap for each key. Usage reports can then be read per unit, and any budget overrun stays confined to a single unit.
6. Measure and revise the mapping regularly. Review the usage report monthly by task class, and update the model identifier whenever a task turns out to produce sufficient results on a smaller model. When the model identifier is held as a configuration value, this change requires no code deployment.

Frequently asked questions

Do domestic large language models meet a public institution's needs?

The answer depends on the task type. For short, high-volume tasks such as petition classification, summarization and field extraction, Turkish-specific models in the 1-8 billion parameter range produce sufficient results and consume less compute. For multi-step analysis across a regulatory corpus of hundreds of pages, code generation or multilingual content, the deciding factors are the context window and model scale. Because most institutions have both groups of tasks at once, a single-model setup usually leaves one side unmet.

Is BILGE currently available for use?

In an announcement dated 14 June 2026, TÜBİTAK BİLGEM used the sentence "Bilge henüz genel kullanıma açılmış bir hizmet değildir" ("Bilge is not yet a service opened to general use") and stated that applications offered under the BILGE name on the internet should not be regarded as the institution's official services. On 30 July 2026 it was announced that the model would be opened to developers, but no date was given. Information on access procedures was said to be shared only through the official channels of TÜBİTAK and the Ministry of Industry and Technology.

How many parameters does BILGE have?

Public sources give differing figures. Reports dated 29 June 2026 stated that the BILGE family spans a parameter scale from 1 billion to 122 billion, that models with 1.9 billion and 27 billion parameters exist, and that a 122 billion parameter model is under development. A report dated 30 July 2026 cited 37 billion parameters. Because the difference between these sources cannot be resolved with publicly available information, no single figure should be treated as authoritative.

Can a public institution run Kumru on its own servers?

Kumru-2B is published on Hugging Face under the Apache 2.0 license and can be downloaded and run on an institution's own servers. Kumru-7B is offered for on-premises deployment and its Hugging Face repository required authentication when checked on 13 August 2026; that model requires commercial contact with the provider. Kumru-7B is reported to run on GPUs with 16 GB of VRAM.

Should an institution choose a closed-network deployment or an API gateway?

These two options are not alternatives to each other but answers for different data classes. For the highest classification levels of data, which must run entirely disconnected from the internet, the institution's own closed-network deployment is the correct architecture, and an API gateway cannot provide it. For the institution's remaining task volume, a gateway layer provides access to many models without the burden of hardware procurement and model updates. The institution should classify its data first and then choose a layer for each class.

Does a Turkish-specific tokenizer really affect cost?

Yes, because billing is based on token counts and the amount of text that fits into the context window is also measured in tokens. Because Turkish is an agglutinative language, general-purpose tokenizers split the same text into more pieces. According to the measurement on the Kumru-2B model card, other open-source models spend between 38 percent and 98 percent more tokens than Kumru despite having larger vocabulary sizes. For institutions processing high volumes of Turkish text, that difference passes directly into unit cost.

Related posts

• How to build an in-house AI assistant: architecture decisions for public institutions
• Can a Turkish public institution use ChatGPT or the OpenAI API? The KVKK cross-border transfer framework

• Model catalog
• Pricing
• Chat Completions guide
• Python SDK example