VoltageGPU vs OpenAI Platform API

Requests pass through our relay, which sees them in clear (TLS ends at our host). To keep plaintext off our servers, run your own inference server in a Confidential VM and terminate TLS inside its trust domain.

OpenAI's Platform API is the protocol shape every modern LLM SDK was written against: a POST to /v1/chat/completions with a messages array, an OpenAI-style streaming SSE response, /v1/embeddings for vector workloads, /v1/images/generations for image generation, and a Bearer-token auth header. The shape is so dominant that "OpenAI-compatible" is now the de-facto standard interface for hosted inference, Together, Anyscale, Groq, Mistral La Plateforme, Fireworks, DeepInfra, and a dozen others all expose the same routes against different model catalogues. VoltageGPU is in that group for chat completions, by design; its embeddings and image routes answer 503 because no TEE model serves them.

In practice the migration from OpenAI to VoltageGPU is a base_url change and an API-key swap. The Python SDK becomes `OpenAI(base_url="https://api.voltagegpu.com/v1", api_key=os.environ["VOLTAGE_API_KEY"])` and the rest of the application code is untouched. The Node, Go, and Java OpenAI SDKs work the same way because the protocol shape is identical. Existing code that builds prompts, parses tool-calling responses, and consumes streaming tokens continues to run unchanged. The model identifier is what differs, a TEE model id from /v1/models such as `model="google/gemma-4-31B-turbo-TEE"` instead of `model="gpt-4o-mini"`, and everything downstream of the response object stays the same. Requests pass through our relay, which sees them in clear (TLS ends at our host). To keep plaintext off our servers, run your own inference server in a Confidential VM and terminate TLS inside its trust domain.

What changes is not the SDK contract but everything that happens after the HTTP request hits the server. On the OpenAI side the request lands inside OpenAI's Azure-hosted infrastructure, runs on a closed-weight proprietary model, and the operator (OpenAI, Inc., a US Delaware corporation) is contractually bound but technically able to introspect the workload. On the VoltageGPU side the request lands on our relay (VOLTAGE EI, a French sole proprietorship), which forwards it in clear to an open-weight model running inside an Intel TDX enclave at our inference provider in the US; GET /v1/attestation returns the TDX quotes and NVIDIA GPU evidence of the serving instances. The SDK call is the same line of code. The trust model is not.

It would be intellectually dishonest to write a comparison page against the OpenAI Platform API without saying clearly that OpenAI is the dominant API for good reasons. GPT-4o is one of the strongest general-purpose models on the market with native vision, audio input, function-calling, and a tool-use fidelity that the open-weight ecosystem has not fully matched. The o1 and o1-mini reasoning models, and the GPT-5 family released in 2025–2026, are closed-weight architectures that cannot be replicated by any open-weight provider at parity because the weights are not public. If a workload was written specifically against gpt-4o's tool-calling behavior, against o1's extended-reasoning quality on mathematical or coding problems, or against the vision/audio capabilities of GPT-4o, OpenAI is the only place those exact models exist.

The Platform API also wins on catalogue breadth in the proprietary tier. DALL·E for image generation, Whisper for speech-to-text, the TTS voices, the assistants API, the realtime API, the moderation API, the fine-tuning API for gpt-4o-mini and gpt-3.5-turbo, these are first-party products with deep optimization and SLA backing that OpenAI ships as a coherent platform. For teams whose product is built on those specific surfaces, VoltageGPU does not offer a like-for-like replacement and the honest answer is that OpenAI is the right tool.

Where the comparison flips is workload class, not workload quality. For mid-size general inference, the 32B-class conversational workloads, retrieval-augmented chat, summarization, classification, structured extraction, code completion, and the long tail of inference work where an open-weight Qwen3 or Gemma 4 31B is fully sufficient, the open-weight quality has caught up enough that the model itself is no longer the differentiator. At that point the decision moves to operator, jurisdiction, attestation, and price. That is where VoltageGPU is built to win, and where the next section gets specific.

On the cheap conversational tier gpt-4o-mini ships at $0.15 per million input tokens and $0.60 per million output tokens. Compare it with our smallest TEE models in the live table above: which side costs less depends on how much output your workload generates. The other difference is structural: gpt-4o-mini runs on standard Azure with no TEE and no hardware attestation; our models run inside Intel TDX, with an attestation of the serving instances.

On the mid-size general-purpose tier the gap is wide. gpt-4o lists at $2.50 input / $10.00 output per million tokens; the closest open-weight comparable on the VoltageGPU side is gemma-4-31B-turbo-TEE, live price in the table above. The gap is structural, not promotional: open-weight inference has a lower marginal cost than proprietary closed-weight inference. The trade-off is model class, gpt-4o is a stronger general-purpose model than gemma-4-31B-turbo, so the comparison only matters if the open-weight quality is sufficient for the workload, which for the bulk of mid-size general inference it now is.

On the frontier reasoning tier the gap becomes extreme. OpenAI o1 lists at $15.00 input / $60.00 output per million tokens. The closest VoltageGPU frontier model is Qwen3.5-397B-A17B-TEE, live price in the table above. The honest caveat is that o1 is a closed-weight reasoning architecture with extended-thinking quality that open-weight 397B MoE models have not unambiguously matched on every benchmark, for problem classes where o1's reasoning quality is genuinely required and irreplaceable, paying o1's premium is rational. For problem classes where the workload was reaching for o1 because it was the default frontier endpoint and a strong open-weight 397B MoE would solve the same problem, the cost decision is one-sided. The model in Intel TDX and the attestation of its instances come in the same per-token price.