DeepSeek V3 and R1 share the same pretrained checkpoint, then diverge through different post-training pipelines. V3 returns short, direct answers and supports the integration patterns most production apps already assume. R1 spends extra tokens on visible reasoning before it commits to a final answer, and that pays back on harder math and algorithmic problems.
This article walks through what each model does well and how to wire both into a single app through the AI SDK on Vercel.
Link to headingWhat is DeepSeek V3?
DeepSeek V3 is a general-purpose Mixture-of-Experts (MoE) language model that handles content generation, summarization, code completion, conversational AI, and structured output across a 128K-token context window. It's the general-purpose model in the DeepSeek lineup, and the foundation R1 was built on.
Link to headingKey V3 capabilities and release timeline
DeepSeek released V3 via API on December 26, 2024, and the model line has gone through several updates since. V3 carries 671 billion total parameters but only activates 37 billion per token, which keeps inference cost closer to a smaller dense model than the headline parameter count suggests.
The model supports system prompts, tool calling, and structured object generation by default. Agentic workflows that call functions or return structured JSON drop in without much custom plumbing.
Link to headingWho DeepSeek V3 is built for
V3 is a good default for production applications that prioritize response speed and low cost per token over deep multi-step reasoning. Chatbots, content pipelines, and code assistants for everyday tasks all run well on V3, along with any workflow that depends on tool calling or structured output.
Its 88.5 MMLU score sits in the same range as other frontier general-purpose models, so it works as a default for most end-user applications.
Link to headingWhat is DeepSeek R1?
DeepSeek R1 is a reasoning-focused model that generates an explicit reasoning trace before producing its final answer. The original R1 was released on January 20, 2025, and the R1-0528 update on May 28, 2025, pushed reasoning quality higher and added function calling and JSON output support that the original release didn't have.
Link to headingKey R1 capabilities and release timeline
R1 shares V3's architecture exactly, with 671 billion total parameters and 37 billion active per token. The behavior is what differs: R1 is trained to produce longer reasoning traces, self-correct mid-generation, and try different problem-solving strategies before committing to an answer.
DeepSeek also released six smaller distilled R1 variants ranging from 1.5B to 70B parameters, based on Qwen and Llama backbones. They inherit R1's reasoning patterns through fine-tuning on chain-of-thought (CoT) samples generated by the full model, so teams get reasoning behavior at lower compute cost.
Link to headingWho DeepSeek R1 is built for
R1 is built for work where correctness depends on multi-step reasoning. Competitive mathematics, algorithmic problem solving, and complex debugging all play to R1's strengths, especially when the reasoning trace is useful for engineers reviewing the output.
The benchmarks back this up. R1 scored 79.8% on AIME 2024 and holds a Codeforces rating of 2,029, which puts it in the same competitive band as strong human contestants. Those numbers describe the kind of problems where R1 separates from general-purpose models.
Link to headingHow DeepSeek V3 and R1 differ in architecture and training
Two models with identical weights end up behaving differently because of the post-training pipeline. The architecture is shared. The reward signals during training are not.
Link to headingShared MoE foundation
R1 and V3 use the same Mixture-of-Experts setup, with 256 routed experts per layer and 8 active per token. Multi-Head Latent Attention (MLA) keeps memory bandwidth low and per-token compute manageable for a 671B-parameter model by compressing the key-value cache into a smaller latent space.
The shared 128K-token context window and roughly 37B active parameters per token mean per-token compute costs are broadly comparable between the two. The behavioral split comes from training, not from the network itself.
Link to headingV3's pretraining and RLHF pipeline
V3 was pretrained on 14.8 trillion tokens, then refined through supervised fine-tuning followed by reinforcement learning from human feedback (RLHF) for alignment. The post-training also distilled some reasoning capability from R1, so V3 picked up reasoning patterns without going through R1's full reinforcement learning pipeline.
The result is a model whose post-training optimizes for alignment and direct answers rather than long chain-of-thought generation. V3 can reason when prompted to, but it isn't structurally rewarded to produce visible intermediate steps the way R1 is.
Link to headingR1's reinforcement learning with verifiable rewards
R1's training runs through four stages. It starts with cold-start supervised fine-tuning on a small set of high-quality chain-of-thought examples. From there, it moves to large-scale reinforcement learning using Group Relative Policy Optimization (GRPO) with verifiable rewards, comparing groups of sampled outputs for the same prompt and rewarding correctness against ground truth, plus format compliance for the reasoning output itself.
A rejection sampling stage keeps only the correct reasoning samples. A final GRPO stage then tightens the model by rewarding format and accuracy on the harder remaining problems.
Link to headingWhy R1 produces chain-of-thought and V3 doesn't
Supervised fine-tuning on curated CoT examples seeds R1's chain-of-thought behavior, and GRPO-style RL reinforces it by rewarding correct final answers. Over many training rounds, the model learns that producing richer intermediate reasoning leads to higher reward, especially on hard problems where the first guess is often wrong.
V3's training doesn't include the same reasoning-format reward, so the same network never develops the same bias toward writing things out.
Link to headingDeepSeek V3 and R1 side-by-side
Here's how the two models compare across the dimensions teams usually evaluate.
Link to headingBenchmark performance
These scores are from the DeepSeek-R1 technical report and reflect the original December 2024 (V3) and January 2025 (R1) releases.
The gap is widest on AIME 2024, where R1 more than doubles V3's score. The R1-0528 update later pushed AIME 2025 from 70.0 to 87.5, a useful sign that the reasoning model line keeps moving even when the architecture stays the same.
Link to headingCost and latency tradeoffs
The cost gap between the two models is mostly about token volume, not the per-token rate. R1's reasoning traces routinely run several times longer than a V3 answer to the same question, so a workload that looks cheap on paper can get expensive once most calls go through the reasoning path.
Latency follows the same pattern. Shorter, more direct answers make V3 feel closer to a standard chat model, while R1 takes longer per call because it writes out reasoning before the final response.
Link to headingWhen to use DeepSeek V3
V3 is the right starting point when an application needs direct answers, structured outputs, and tool calling rather than visible reasoning. The following use cases are where V3's speed and integration support are the priority:
Content generation, chat, and summarization: V3 handles text generation, document summarization, and customer-facing conversational AI without the token overhead of chain-of-thought. Quality holds up for everyday end-user work, and the response feels closer to a standard chat model.
High-volume production workloads: Workflows that depend on system prompts, tool calling, or structured JSON output match V3 cleanly. The model already supports the integration primitives that those pipelines tend to assume, which means less custom plumbing around the model itself.
Latency-sensitive endpoints: Routes deployed as Vercel Functions generally want the shorter outputs V3 produces. Users waiting on reasoning tokens see dead time on a chat UI rather than added value.
Everyday coding assistance: Bug fixes, small feature work, refactors, and explanation tasks all fit V3's strengths, where direct answers and clean diffs are more useful than long reasoning traces. Tool calling and structured output also make it easier to wire V3 into agents that read files, run commands, and apply patches.
For most user-facing surfaces, V3 is the default. R1 picks up a narrower set of problems where the reasoning trace itself is part of the answer.
Link to headingWhen to use DeepSeek R1
R1 makes sense when the answer depends on intermediate steps that engineers want to see, audit, or build on:
Multi-step math and logic: R1's 79.8% on AIME 2024 and 97.3% on MATH-500 put it in a different tier than general-purpose models for math-heavy work. R1-0528 pushed AIME 2025 from 70.0 to 87.5, the kind of jump that matters for tutoring, quantitative analysis, and any application where math correctness is the primary metric.
Algorithmic coding and debugging: A Codeforces rating of 2,029 reflects strong algorithmic capability for competitive programming and complex algorithm work. The reasoning trace also helps in code review settings, where it explains why a change is being suggested.
Cross-file debugging: When a bug runs through several files or layers of abstraction, a model that lays out its hypotheses and tests them is easier to correct mid-loop than one that returns a single answer with no visibility into how it got there.
Research, analysis, and agent planning: R1 fits the reasoning-heavy steps in agentic pipelines, including multi-step planning and hypothesis generation. The reasoning trace doubles as an audit trail when humans need to verify an agent's decisions after the fact. For tool-orchestration steps in those same pipelines, V3 is usually the better pick because it's faster and integrates more tightly with function calling and structured output.
A common production pattern is to use R1 for the planning node in an agent and V3 for the action nodes that call tools and APIs.
Link to headingBuilding with DeepSeek V3 and R1 on Vercel
The AI SDK provides a unified TypeScript interface for both models, and AI Gateway adds provider-level redundancy and unified billing for production traffic. Most of the work in production lives at the routing layer, where requests get directed to V3 or R1 based on whether the query needs multi-step reasoning, while the rest of the application stays the same.
Link to headingAccessing both models through the AI SDK
After installing @ai-sdk/deepseek, both models live behind the same provider interface. V3 uses the deepseek-chat model ID and R1 uses deepseek-reasoner. Both are also available through AI Gateway as deepseek/deepseek-v3 and deepseek/deepseek-r1.
import { deepseek } from '@ai-sdk/deepseek';
const v3 = deepseek.chat('deepseek-chat');const r1 = deepseek.chat('deepseek-reasoner');Link to headingRouting between V3 and R1 by query complexity
A small classifier upstream of the model call can send math, logic, and complex algorithmic queries to R1 while everything else, including tool-using and structured-output tasks, stays on V3. The rest of the request handler doesn't have to know which model is running.
import { deepseek } from '@ai-sdk/deepseek';import { convertToModelMessages, streamText, type UIMessage } from 'ai';
function selectModel(useReasoning: boolean) { return useReasoning ? deepseek('deepseek-reasoner') : deepseek('deepseek-chat');}
export async function POST(req: Request) { const { messages, useReasoning, }: { messages: UIMessage[]; useReasoning: boolean } = await req.json(); const result = streamText({ model: selectModel(useReasoning), messages: await convertToModelMessages(messages), }); return result.toUIMessageStreamResponse({ sendReasoning: useReasoning, });}The AI SDK R1 guide covers a more production-grade version of this pattern using Vercel Flags for runtime model switching, so teams can change routing behavior without redeploying.
Link to headingStreaming reasoning tokens in Next.js apps
R1 responses can include a separate reasoning stream alongside the final answer. Client-side code distinguishes between the two by checking the part type as it consumes the stream, which lets reasoning and the final answer render in different parts of the UI.
for await (const part of result.fullStream) { if (part.type === 'reasoning') { console.log('Reasoning:', part.text); } else if (part.type === 'text') { console.log('Answer:', part.text); }}Some providers expose reasoning as a dedicated stream part and others wrap it in text output. The AI SDK normalizes that difference, so client code can stay the same regardless of which provider serves the request.
Link to headingPick the right DeepSeek model for the job
Most production teams get more from DeepSeek by wiring both models into the same application and letting the work decide which one runs. V3 carries the everyday flows where direct answers and tool calling do the heavy lifting, while R1 handles the reasoning-heavy queries where a visible chain-of-thought changes the quality of the answer.
As the R1 keeps improving, with AIME 2025 jumping from 70.0 to 87.5 in the 0528 update alone, the line between what a fast general-purpose model and a reasoning model can handle will keep shifting. A routing-based architecture is easier to evolve than a single-model bet. Start a new project from an AI template and swap the model reference where reasoning matters.
Link to headingFrequently asked questions about DeepSeek V3 and R1
Link to headingIs DeepSeek R1 just V3 with extra training?
R1 starts from the same DeepSeek-V3-Base checkpoint as V3, so the underlying architecture is identical. The difference comes from R1's four-stage reinforcement learning pipeline using GRPO with verifiable rewards, which produces emergent chain-of-thought behavior that V3's SFT-plus-RLHF training doesn't incentivize. The two models behave differently in practice even though they share most of their weights.
Link to headingCan I use R1 and V3 together in the same application?
Yes, and that's the recommended pattern for most production apps. The AI SDK lets you switch between deepseek-chat and deepseek-reasoner by changing only the model reference, so a typical setup sends most traffic through V3 and escalates the small share of reasoning-heavy queries to R1. That keeps token costs low while preserving R1's reasoning capability for the requests that need it.
Link to headingWhich is better for coding, R1 or V3?
It depends on the type of coding work. For everyday software engineering inside an existing codebase, V3 is usually the better fit because it supports tool calling and structured output, returns answers faster, and uses fewer tokens per request. R1 pulls ahead on algorithmic reasoning and competitive programming, where its Codeforces rating of 2,029 versus V3's 1,134 reflects the gap on that specific kind of problem.
Link to headingDoes DeepSeek R1 support tool calling and structured output?
The original R1 release in January 2025 did not support tool calling or JSON output mode. The R1-0528 update on May 28, 2025 added both, which makes R1 a candidate for agentic workflows that need function calling alongside reasoning. V3 has supported both since its initial release, and remains the simpler choice when the workflow doesn't need a visible reasoning trace.