DeepSeek V4 splits into Pro and Flash: what actually changes in your API calls
DeepSeek's V4 splits into Pro and Flash on a 16T-param open-weight base — here's what breaks in your API calls and which tier is worth the VRAM.
Short version: DeepSeek's V4 line is now two SKUs — V4-Pro and V4-Flash — sitting on the same 16T-parameter open-weight base, and the split forces an API migration whether you want one or not. Pro is the big-context, high-quality tier; Flash is the cheap, low-latency one. If you're running local, Flash is the only one most people will realistically fit, and even that is a stretch.
The migration is the part that'll actually cost you an afternoon. This isn't a drop-in version bump.
What changes in your API calls?
The model ID string is the obvious one — you can't just leave `deepseek-v3` in your config and expect it to route. You now pick a tier explicitly, and the endpoints diverge. That means every hardcoded model name, every cost-tracking dashboard keyed on the old ID, and every eval harness that pins a model string needs a pass.
The quieter breakage is behavioral. Pro and Flash don't return identical outputs for the same prompt, so if you've got prompt templates tuned against V3 you're re-testing them, not migrating them. Temperature and stop-token behavior shift enough between tiers that a prompt calibrated on Pro can go off the rails on Flash. Budget for a re-run of your regression set before you flip production traffic.
If you route by task — cheap model for classification, big model for reasoning — the two-tier split is genuinely useful because it maps to how you'd already segment traffic. If you were using one model for everything, you now have a decision to make on every call.
Which one is worth the VRAM?
For local runners, the 16T headline number is mostly a flex. A 16T-param base is not something you're loading on a 4090, or a rack of them. Flash exists precisely so open-weight people have something runnable, and even quantized it wants serious hardware. Pro is a datacenter animal — assume you're renting, not owning.
My read: if you're on r/LocalLLaMA benchmarking against closed frontier models, Flash is your comparison point, not Pro. Comparing Pro to GPT-class models and then claiming "open weights caught up" is a bit of a cheat when nobody on that subreddit can actually host Pro at full precision. The original breakdown lays out the tier differences if you want the parameter-by-parameter split.
Should you migrate now?
Not on a Friday. The API surface changed enough that this is a scheduled migration with a re-eval, not a hotfix. If V3 is serving your traffic fine and you're not blocked on context length or cost, wait a release cycle and let the endpoint quirks settle. The people who should move now are the ones hitting V3 context limits or paying too much for tasks Flash would handle at a fraction of the cost.
Verdict: worth it for task-routed setups where the Pro/Flash split matches your traffic tiers. Skip it if you're a single-model shop that just wants numbers to go up — the migration tax isn't paid back by a version bump alone. And for local hosting, treat Flash as the real product and Pro as a cloud-only benchmark you'll read about but never run.