GPT (OpenAI)

OpenAI's GPT family is the reference class for closed-weight LLMs, providing the benchmark calibration point against which all local AI models are measured. GPT-3 (2020, 175B dense parameters) established the scaling-laws paradigm: a standard decoder-only Transformer with 96 layers, 12,288-dimension hidden states, and 96 attention heads, trained on ~570 GB of web text. GPT-3.5 (2022, same architecture, instruction-tuned via RLHF) added chat capability and instruction-following — the model that launched ChatGPT and defined the modern LLM product category. GPT-4 (2023, parameter count undisclosed, reported as Mixture-of-Experts with 8 experts and ~1.8T total parameters) introduced multimodal input (text+image), 128K context window, and significantly improved reasoning, multilingual performance, and instruction adherence. GPT-4 Turbo (2023) cut inference costs by 3× via FP8 inference and speculative decoding. GPT-4o (May 2024, "omni") unified text, vision, and audio into a single multimodal transformer — natively processing speech-to-speech without cascaded ASR→LLM→TTS pipelines. GPT-4.5 (2025, undisclosed architecture) was an incremental refinement focused on factual accuracy and reduced hallucination, not a generational leap. GPT-5 (2026) is expected to be a large-scale MoE with reasoning-native training (RL on chain-of-thought traces), 256K+ context, and deep multimodal fusion. GPT's architectural evolution path defines the industry's research direction: scaling laws (GPT-3), instruction tuning (GPT-3.5), MoE efficiency (GPT-4), native multimodality (GPT-4o), and reasoning-native training (GPT-5). Each architectural phase has been replicated by open-weight families — [Llama 3](/families/llama) replicates instruction tuning, [DeepSeek V4](/families/deepseek) replicates MoE, [Qwen 3 235B](/models/qwen-3-235b-a22b) replicates MoE+multimodal — with a 12–24 month lag. GPT defines the curve; open-weight families catch up to and occasionally surpass individual points on that curve.

GPT has zero local viability — all GPT models from GPT-3 onward are closed-weight and API-only, accessible exclusively through OpenAI's API or Azure OpenAI Service. There is no local deployment path, no open-weight release, and no public training code or data. The GPT family is included on RunLocalAI.co as a benchmark reference, not an operational option. For operators who prefer GPT-class quality with local deployment, the current open-weight alternatives are: [DeepSeek V4](/models/deepseek-v4) (GPT-4-class reasoning at MoE efficiency, locally deployable on 2× [H200](/hardware/nvidia-h200)), [Qwen 3 235B-A22B](/models/qwen-3-235b-a22b) (GPT-4-class multilingual and multimodal, 2× H200), [Llama 3.3 70B](/models/llama-3-3-70b) (GPT-4-0314-class text generation, single [RTX 5090](/hardware/rtx-5090) at Q4), and [DeepSeek V3](/models/deepseek-v3) (GPT-4-class coding and math, 2× H200). Each of these alternatives has been benchmarked against GPT-4/4o and falls within 5–15% on major benchmarks — the local capability gap has narrowed to a few percentage points on most tasks. The GPT API's operational characteristics are well-understood: per-token pricing ($2.50–$15 per 1M input tokens depending on model), latency of 500–2000ms for completion, availability across Azure and direct API, and enterprise features (fine-tuning API, assistants API, data residency options). The API's content moderation, data retention policies, and vendor dependency are the primary operational considerations — they are documented on OpenAI's platform and are outside RunLocalAI.co's local-AI scope. For local deployment, the alternatives above are the operational path.

GPT models have set the benchmark ceiling that open-weight models measure themselves against. GPT-4's MMLU score (86.4) at launch was the highest reported for any model and held for 18 months until [Llama 3.3 70B](/models/llama-3-3-70b) (87.2) and [DeepSeek V4](/models/deepseek-v4) (88.1) surpassed it. On HumanEval (code generation), GPT-4 scored 67.0 at launch, surpassed by [DeepSeek-Coder-V3](/models/deepseek-coder-v3) (73.8) and GPT-4o (72.0). On LMSys Chatbot Arena ELO, GPT-4o held ~1320 ELO at launch, surpassed by GPT-4.5 (~1350) and approached by open-weight models at ~1280–1310. The consistent pattern: GPT sets the benchmark at release, open-weight models close the gap within 12–24 months. GPT-4o's benchmark contribution was establishing native multimodal benchmarks. On MMMU (multimodal understanding), GPT-4o scored 69.1 vs GPT-4V's 63.1 — the 6-point jump from cascaded to native multimodal processing. On speech benchmarks (Common Voice for ASR, VoxPopuli for translation), GPT-4o's native speech processing scored competitively with dedicated ASR models like [Whisper large-v3](/families/whisper) while adding translation and emotion understanding capabilities. This multimodal unification is the benchmark frontier that open-weight models are currently racing toward. GPT-4.5's benchmark contribution was on factual accuracy benchmarks. On SimpleQA (factual accuracy), GPT-4.5 scored 62.5 vs GPT-4o's 44.8 — a 17.7-point improvement reflecting targeted anti-hallucination training. On TruthfulQA, GPT-4.5 scored 78.2 vs GPT-4o's 68.5. Factual accuracy is the current GPT family focus and the dimension where open-weight models show the largest gap — [Llama 3.3 70B](/models/llama-3-3-70b) scores 56.0 on SimpleQA, a 6.5-point gap that represents the open-weight factual accuracy frontier. For RunLocalAI.co's purposes, GPT benchmark scores serve as the target thresholds for local model evaluation. When a local model matches GPT-4 on a benchmark, that benchmark is considered "GPT-4-class" for that capability — the standard classification used throughout RunLocalAI.co's model verdicts and task editorials.

GPT has no local runtime support — the models are API-only. The operational runtime interface is the OpenAI API (Chat Completions endpoint) or Azure OpenAI Service (same API format). For applications designed to use the OpenAI API, the drop-in replacement pattern is: swap the `base_url` from `api.openai.com` to a local inference server ([vLLM](/tools/vllm), [Ollama](/tools/ollama), [SGLang](/tools/sglang)) running an open-weight model. This API-compatibility layer is the primary way local AI operators use GPT's ecosystem (the OpenAI API format) without GPT's models. The OpenAI API format has become the industry-standard LLM serving protocol — every local inference engine implements it. This standardization was GPT's ecosystem contribution to local AI: by defining the API interface, OpenAI created the compatibility layer that enables seamless switching between cloud and local inference. An application built against the OpenAI Chat Completions API can target GPT-4o in production and [Llama 3.3 70B](/models/llama-3-3-70b) locally without code changes — this portability is the practical bridge between GPT's closed ecosystem and local AI's open ecosystem. For operators using GPT's API alongside local models (a common hybrid architecture where high-value queries go to GPT and bulk queries go to local models), the operational pattern is: a model router that directs queries based on complexity, latency requirements, and cost budget. OpenRouter and LiteLLM provide this routing layer with a unified API that distributes queries across GPT API endpoints and local inference endpoints — the practical operational pattern for GPT+local hybrid deployments.

GPT quantization is not applicable — the models are API-only and hosted on OpenAI's infrastructure. OpenAI uses FP8/INT8 quantization internally for inference optimization (GPT-4 Turbo's 3× cost reduction from GPT-4 was partially achieved through mixed-precision inference), but these quantization implementations are proprietary and not exposed to API users. The quantization characteristics of GPT-architecture models are known only through research on equivalent open-weight architectures (dense Transformers for GPT-3/3.5-class models, MoE Transformers for GPT-4-class models). For understanding the quantization behavior of GPT-equivalent open-weight models, see: [Llama 3 quantization support](/families/llama) (dense Transformer, GPT-3/3.5-class architecture), [DeepSeek V4 quantization support](/families/deepseek) (MoE Transformer, GPT-4-class architecture), and [Qwen 3 235B](/models/qwen-3-235b-a22b) (MoE Transformer, GPT-4o-class architecture). These families provide the quantized local equivalents of GPT-class capability with documented quantization quality curves. The operational relevance of GPT quantization is in the context of API cost optimization: when per-token API costs exceed the cost of local GPU compute (the break-even is typically 5–20 sustained QPS), operators transition from GPT API to quantized local models. Understanding quantization quality (the tradeoff between model size, speed, and benchmark performance) is essential for making this transition decision — the RunLocalAI.co quantization sections across open-weight families provide the data needed for this cost-modeling exercise.

GPT's ecosystem is the largest and most commercially mature in AI — but it is a closed, API-centric ecosystem, not an open-weight community. The ecosystem layers include: the OpenAI API (Chat Completions, Assistants, Fine-tuning, Embeddings, DALL-E, TTS, Whisper), the ChatGPT consumer application (200M+ weekly active users as of 2025), the GPT Store (custom GPTs with actions and knowledge bases), and the enterprise platform (Azure OpenAI Service, data residency, compliance certifications). This ecosystem generated ~$5B in revenue in 2025 and serves as the commercial benchmark for AI business models. The OpenAI API ecosystem has standardized the LLM serving protocol that local AI tools have adopted. The Chat Completions API format (system/user/assistant message roles, function calling, JSON mode, streaming) is implemented by [Ollama](/tools/ollama), [vLLM](/tools/vllm), [SGLang](/tools/sglang), and every local inference server — this standardization was driven by GPT's ecosystem dominance forcing local tools to match its interface. The OpenAI Python SDK can target local servers by changing `base_url`, making GPT's ecosystem tooling reusable for local AI without code changes. The developer ecosystem around GPT (tutorials, courses, frameworks, startups) is an order of magnitude larger than the local AI developer ecosystem. This creates an adoption funnel: developers learn AI development on GPT's API (easy, well-documented, no hardware), then migrate to local models for cost savings, data privacy, or offline capability — using the same API format and the same development patterns. GPT's ecosystem serves as the on-ramp to local AI, even though the models themselves are not local. The ecosystem gap for local AI operators is the GPT Store and custom GPTs infrastructure — there is no local equivalent of a marketplace for shareable AI agents with integrated tools and knowledge bases. Local AI tooling (Continue, Open WebUI, LobeChat) provides UI layers but lacks the distribution and monetization infrastructure of the GPT Store. This is the next ecosystem layer that local AI needs to develop to match GPT's commercial maturity.

GPT fine-tuning is available through OpenAI's fine-tuning API — a managed service where operators upload training data (instruction-response pairs) and receive a fine-tuned model endpoint. OpenAI supports fine-tuning for GPT-3.5 and GPT-4o-mini (the smaller, cheaper models), with GPT-4 and GPT-4o fine-tuning in limited availability. The fine-tuning process is fully managed: data upload → training job → evaluation → deployed endpoint. Operators have no access to the fine-tuning process, hyperparameters, or model internals — this is a fully abstracted fine-tuning service. The contrast with open-weight fine-tuning is stark. With [Llama 3](/families/llama) or [Qwen](/families/qwen), operators: control the fine-tuning hyperparameters, select the fine-tuning method (LoRA, QLoRA, full fine-tune, DPO), choose the training infrastructure (local GPU or cloud), own the resulting model weights permanently, and can deploy the fine-tuned model anywhere without per-token costs. This control, ownership, and cost structure is the operational argument for local fine-tuning over GPT fine-tuning. The quality argument (GPT fine-tuning may produce higher-quality results for some tasks) is task-dependent and must be evaluated case-by-case. GPT fine-tuning pricing is consumption-based: training cost per token (~$8–25 per 1M training tokens for GPT-3.5/4o-mini), plus inference cost on the fine-tuned model (~1.5–3× the base model's per-token inference price). For a fine-tune on 100K training examples (~50M tokens) with sustained inference at 1M tokens/day, GPT fine-tuning costs ~$400–1,250/month in training amortization + inference — comparable to the cloud GPU cost for fine-tuning and serving an open-weight 7B model. The cost break-even favors GPT fine-tuning for low-volume, high-variance workloads; it favors local open-weight fine-tuning for high-volume, stable workloads where GPU reservation costs are amortized across sustained throughput.

GPT's deployment caveats are vendor-dependency risks, not technical deployment issues. The primary caveat is single-vendor lock-in: applications built against the GPT API depend on OpenAI's continued service availability, pricing stability, model version continuity, and policy decisions. If OpenAI deprecates a model version (GPT-4 was deprecated in favor of GPT-4o in 2025), changes pricing (GPT-4o pricing has decreased 4× since launch), or modifies content moderation policies, operators have no alternative — unlike local models where the model weights are permanently owned and inference is independent of the vendor's continued service. Data privacy and residency are the second-order deployment caveats. OpenAI's API processes data on OpenAI's infrastructure with data retention policies that vary by tier (API data may be retained for abuse monitoring; enterprise agreements offer zero data retention). For regulated industries (healthcare, finance, legal) and jurisdictions with data residency requirements (GDPR, China's PIPL), GPT's API may not satisfy compliance requirements. Local deployment eliminates this concern entirely — data never leaves the operator's infrastructure. Cost predictability is the third-order caveat. GPT API costs scale linearly with usage, making high-volume deployments (1M+ API calls/day) expensive and cost-unpredictable during traffic spikes. Local GPU deployment has a fixed infrastructure cost (GPU purchase or reservation) with near-zero marginal per-token cost — the cost structure favors high-volume, predictable workloads. RunLocalAI.co's per-family local viability sections provide the GPU requirement data for this analysis. For operators using GPT as their primary model, the recommended architecture is: GPT API for production (low latency, high quality, minimal ops), with a locally deployed open-weight model as a fallback for cost spikes, data-sensitive queries, and offline operation. This "GPT-primary, local-fallback" architecture provides operational resilience while maintaining the quality ceiling that GPT's API provides. The fallback model should be selected based on task-specific benchmarks: [DeepSeek V4](/models/deepseek-v4) for reasoning, [Llama 3.3 70B](/models/llama-3-3-70b) for general text, [Qwen 3 235B](/models/qwen-3-235b-a22b) for multilingual.