Blaze · The Token Factory

One API. Tokens on demand. No capacity planning.

Blaze provides API access to open-weight models. Your application sends a request and receives a model response — there is no GPU capacity to source and no serving stack to build.

  • OpenAI-compatible endpoint
  • Text, voice, OCR, multi-modal, diffusion
  • Indian data centres
  • Billed in INR

What is Blaze?

Blaze is a model inference API from E2E Networks. It provides a single API for the open-weight models in the Blaze catalogue — text, voice, OCR, multi-modal and diffusion. An application sends a request and receives a model response. Capacity, availability, serving, optimisation and endpoint operations are provided by the platform. Blaze runs on E2E Networks infrastructure located in Indian data centres and is billed in INR.

Two ways to run inference

What do you stop operating when inference moves to an API?

The same workload can be served by infrastructure you run or by an API you call. These are the pieces of work that move.

Running inference yourself, compared with running inference through Blaze.
ConcernRunning inference yourselfRunning inference through Blaze
GPU capacitySource, qualify and provision GPU capacitySend a request to the API and receive a response
Contracts & utilisationReserve or lease capacity, and manage contracts and utilisationCapacity and availability are operated by the platform
Serving stackBuild the serving stack — serving, batching, quantisation, kernels, scalingServing and optimisation are provided in the platform
TuningTune latency, throughput and cost on an ongoing basisModels can be switched without changing your own infrastructure
Endpoint operationsOperate autoscaling, failure handling, upgrades and capacity planningEndpoint operations are handled by the platform
AnalyticsBuild your own token-level analytics and monitoringToken-level usage, performance and cost analytics are provided

What Blaze provides

What you get from the platform

  • One API

    A single API for the models in the Blaze catalogue — text, voice, OCR, multi-modal and diffusion — reached through an OpenAI-compatible endpoint.

  • Model routing

    Requests are placed across model endpoints by the platform’s routing layer rather than being pinned to a static endpoint per model.

  • Runtime features for agentic workloads

    Session persistence, hierarchical context memory and long-context handling are provided in the runtime, so an agent framework does not have to implement them itself.

  • Token analytics

    Token-level usage, performance and cost data are available through the platform, rather than something you instrument and store yourself.

  • Location and billing

    Blaze runs on E2E Networks infrastructure located in Indian data centres and is billed in INR.

  • Custom inference stack

    Model configurations are benchmarked and tuned across the GPU architectures in the fleet, with KV offload and context transfer across variants in the same model family.

The catalogue

Which models are available on Blaze?

The catalogue covers text, voice, OCR, multi-modal and diffusion models — among them Gemma 4B, Qwen 3.5-9B, Qwen3.8 Flash and Qwen3.8 Max, DeepSeek V4 Flash, Kimi K3 from Moonshot AI, GLM 5.3, IBM Granite 4.2 8B and Tencent’s Hy-MT2 translation models, alongside the sovereign Indic models Sarvam 30B and Sarvam 100B.

The Model APIs screen in the Blaze console: a search field above a table of models, each row showing the model name and API alias, its creator, capability tags such as Vision, Tools, JSON and Reasoning, and its context window and maximum output length. A left sidebar links to Model APIs, Routing, API keys, Analytics, General settings and Billing.
Models are listed in the console with the API alias you pass, what each one can do, and how much context it accepts — so a model can be matched to a workload before any code is written.
A sample of the Blaze catalogue, as listed in the console. Context and maximum output are in tokens.
ModelCreatorCapabilitiesContextMax output
Granite 4.2 8Bibm-granite/granite-4.2-8bIBMToolsJSONReasoning131,072117,964
Qwen3.8 Flashqwen/qwen3.8-flashQwenVisionToolsJSONReasoning1,000,000131,072
GLM 5.3 Flashz-ai/glm-5.3-flashZ.aiVisionToolsJSONReasoning1,310,720131,072
GLM 5.3 Flash (batch)z-ai/glm-5.3-flash:batchZ.aiVisionToolsJSONReasoning1,048,575943,717
DeepSeek V4 Flash Vision Expdeepseek/deepseek-v4-flash-vision-expDeepSeekVisionToolsReasoning1,048,576384,000
Hy-MT2-1.8Btencent/hy-mt2-1.8bTencentText only8,1924,096

The full catalogue, with the current list of models and their capabilities, is in the Model APIs section of the Blaze console.

Model routing

How do you call Blaze without pinning a model?

Call the same OpenAI-compatible endpoint you would use for a single model, and set the x-model: auto header — either as a default header on the client or per request. The routing layer then places each request across model endpoints instead of you naming one up front.

The Routing screen in the Blaze console, titled Auto Router. It explains that setting the x-model: auto header lets Blaze choose a model for each request.
from openai import OpenAI

client = OpenAI(
    api_key="BLAZE_API_KEY",
    base_url="https://blaze.e2enetworks.net/v1",
    default_headers={
        "x-model": "auto",
    },
)

response = client.chat.completions.create(
    model="auto",
    messages=[{"role": "user", "content": "Extract the payment terms from this clause."}],
)
print(response.choices[0].message.content)
import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.BLAZE_API_KEY,
  baseURL: "https://blaze.e2enetworks.net/v1",
  defaultHeaders: {
    "x-model": "auto",
  },
});

const response = await client.chat.completions.create({
  model: "auto",
  messages: [{ role: "user", content: "Extract the payment terms from this clause." }],
});
console.log(response.choices[0].message.content);
curl https://blaze.e2enetworks.net/v1/chat/completions \
  -H "Authorization: Bearer $BLAZE_API_KEY" \
  -H "Content-Type: application/json" \
  -H "x-model: auto" \
  -d '{
        "model": "auto",
        "messages": [
          { "role": "user", "content": "Extract the payment terms from this clause." }
        ]
      }'
The Auto Router screen in the Blaze console, with the request it describes. An existing OpenAI client is pointed at the Blaze base URL; the header does the rest.
x-model: auto
Blaze selects a model for each request instead of you naming one. Send it as a default header on the client, or per request.
Base URL
https://blaze.e2enetworks.net/v1 — the OpenAI-compatible path, so existing clients need a base URL and a key, not a rewrite.

Under the hood

What is inside the inference stack?

Experience the bleeding-edge inference research. Blaze is a custom inference stack with optimised kernels, the latest decoding techniques and advanced caching baked in.

Questions about Blaze

What Blaze is, which models it serves, and how requests are routed.

Blaze is a model inference API from E2E Networks. It provides a single API for the open-weight models in the Blaze catalogue, covering text, voice, OCR, multi-modal and diffusion models. An application sends a request and receives a model response. Capacity, serving and endpoint operations are provided by the platform.

The Blaze catalogue covers text, voice, OCR, multi-modal and diffusion models, including Gemma 4B, Qwen 3.5-9B, Qwen3.8 Flash and Qwen3.8 Max, DeepSeek V4 Flash, Kimi K3 from Moonshot AI, GLM 5.3, IBM Granite 4.2 8B, Tencent Hy-MT2 translation models, and the sovereign Indic models Sarvam 30B and Sarvam 100B. The current list is shown in the Model APIs section of the Blaze console.

Yes. Blaze exposes an OpenAI-compatible endpoint, so an existing OpenAI client can be pointed at the Blaze base URL. In Python, this means setting base_url on the OpenAI client and supplying a Blaze API key; the rest of the chat completions call is unchanged.

Requests are placed across model endpoints by the Blaze routing layer rather than being pinned to a static endpoint per model. A caller can name a model, or send the header x-model: auto and have the platform select a model for each request. Models can be switched without changes to the caller’s own infrastructure.

Session persistence, hierarchical context memory and long-context handling are provided in the Blaze runtime, so an agent framework does not have to implement them itself. Several models in the catalogue also expose tool calling, JSON output and reasoning, and context windows above one million tokens.

Blaze runs on E2E Networks infrastructure located in Indian data centres and is billed in INR.

Running inference yourself means sourcing and provisioning GPU capacity, managing capacity contracts and utilisation, building a serving stack covering batching, quantisation, kernels and scaling, tuning latency, throughput and cost, and operating autoscaling, failure handling and upgrades. On Blaze these are operated by the platform and reached through the API.

Token-level usage, performance and cost data are available through the platform in the Analytics section of the Blaze console, rather than being something the caller instruments and stores itself.

Blaze uses a custom inference stack. Model configurations are benchmarked and tuned across the GPU architectures in the fleet, requests are placed by the platform’s orchestration layer, and KV offload and context transfer are supported across variants within the same model family, including FP8 and BF16.

Blaze · The Token Factory

Send a request. Get a response.

Tell us about the workload and we will set you up with access to the Blaze API and the console.