AI Model Selection Guide: DeepSeek vs. Qwen3 in Practice

Why an LLM Course Shouldn't Focus on Just One Model

"Why doesn't your course cover DeepSeek^Ad?" This was the question Bilibili creator Mingjing and Diandian heard most often when launching the new version of their LLM course. His answer was direct: A competent LLM developer can't afford to focus on just one model.

This point deserves elaboration. When enterprises make technology choices, leadership may ask at any moment, "Which is more suitable for this project—DeepSeek V3 or the Qwen3 series?" If you've only worked with one model, you simply can't answer such questions. The creator admitted in the video that his previous course was titled New LangChain LangGraph MCP Agent and Workflow Development—the title didn't mention DeepSeek at all, yet the course still covered it. Similarly, OpenAI, Claude, and Qwen3 were all included.

This "de-model-centric" course design philosophy reflects a reality: the LLM ecosystem changes too fast. Binding a course to a specific model means it could be obsolete six months later. Mastering selection and migration skills has more long-term value than memorizing the API parameters of any single model.

DeepSeek's Two Models: Key Differences Between V3 and R1

The creator focused on dissecting DeepSeek's two main models. One is DeepSeek-V3 (called DeepSeek-Chat in the API), and the other is DeepSeek-R1 (called DeepSeek-Reasoner in the API). The names look like just different version numbers, but their behavior in application development differs significantly.

The key point: DeepSeek-R1 does not support Function Calling and JSON Output by default. These two capabilities are practically essential for agent development and workflow orchestration. If you directly use R1 for tool calls, you'll likely encounter errors—not because the model is broken, but because you're using the wrong model.

The creator specifically emphasized that "not supported by default" doesn't mean "never supported." Function Calling is essentially a capability proposed by OpenAI, and any model can acquire it through fine-tuning. In his deployment cases with government agencies and hospitals, he saw R1 fine-tuned to support tool calling. So when selecting models, distinguish between "out-of-the-box" and "modifiable" capabilities.

So which one should you use in actual development? The creator's recommendation: Prioritize DeepSeek-V3 version 0324. V3 versions before March 24 had a loop-calling issue during Function Calling—he encountered this problem himself. This issue has been fixed since version 0324, and stability has improved considerably.

An Unexpected Update from a Supplementary Recording

Something interesting happened during video recording. The creator had just stated that R1 didn't support Function Calling by default, and less than a week later, on May 28, DeepSeek released a minor update for R1 (0528), with the official website explicitly stating support for Function Calling and JSON Output. He immediately recorded a supplement and found it "really quite useful" in practice.

Then on May 29, a distilled model appeared—DeepSeek-R1-0528-Qwen3-8B. The creator's impression was that in some scenarios, this distilled model was even more useful than the original Qwen3 released on April 29. It supports both deep thinking and Function Calling, and has optimizations for MCP.

This supplementary recording is itself a perfect footnote: the information half-life in the LLM field is extremely short. Technology selection can't rely solely on static documentation—you need to continuously track version updates.

Function Calling is the core mechanism for LLMs to interact with external tools. Developers use JSON Schema to describe available functions (e.g., checking weather, querying databases), and the model outputs structured call requests based on user intent. The application executes them and returns results to the model. It transforms LLMs from "just chatting" into agents that can actually operate external systems. JSON Output requires the model to return content strictly in a specified JSON format for easy programmatic parsing. Both are foundational infrastructure for workflow orchestration and Agent development. Support varies greatly across models: some work out of the box, some require fine-tuning, and some don't support them at all. When selecting models, these two capabilities must be checked as hard requirements.

Two Qwen3 Capabilities That Caught Developers' Eyes

Qwen3 was released in the early hours of April 29. After using it for half a month, the creator identified two capabilities he considers truly differentiated.

First, thinking mode can be switched programmatically. DeepSeek's deep thinking mode requires users to manually toggle a button on the web page, but Qwen3 allows developers to seamlessly switch between thinking and non-thinking modes at the code level by passing parameters. Turn it on for complex logical reasoning, turn it off for simple Function Calling or MCP calls—flexibility is significantly improved for application development.

Second, enhanced agent capabilities. The creator cited official statements that Qwen3 strengthens precise integration with external tools in both thinking and non-thinking modes, and reinforces MCP support. His own assessment: among open-source models, Qwen3's support for MCP, Function Calling, and agents is "the best, bar none." This judgment carries personal experience bias, but he added a qualifier—limited to the open-source domain.

MoE vs. Dense: Qwen3's Architecture Layers

The Qwen3 series has two architectures internally. The MoE architecture is represented by the flagship models Qwen3-235B and the 30B version; others like 8B, 14B, and 1.5B use Dense architecture. The creator didn't do a detailed benchmark comparison—his attitude was "to each their own," valuing practical experience differences more.

This pragmatic orientation is worth noting. Score gaps on model leaderboards are often diluted by data quality, prompt design, and engineering optimization in specific business scenarios. When selecting models, rather than obsessing over fractions of a point, it's better to first validate your own use cases.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic to standardize how LLMs connect to external data sources and tools. Think of it as the "USB interface for AI applications": tool providers expose capabilities according to the MCP specification, and models or Agent frameworks discover and invoke them in a unified way, avoiding the need to write adapter code for each tool individually. MCP reduces the integration cost of connecting agents to external systems and makes migration between different models smoother. That's why a model's support for MCP has become an important dimension for evaluating its agent capabilities—and why the original article emphasizes that Qwen3 "has optimizations for MCP."

MoE (Mixture of Experts) is a sparse activation architecture: the model contains multiple "expert" sub-networks and a routing mechanism. Each inference activates only a few experts, so the total parameter count can be very large while actual computation remains relatively manageable—balancing capability and cost. Dense architecture activates all parameters for every inference, with a simple structure and low deployment barrier—commonly used for small-parameter models. This explains why Qwen3 uses MoE for flagship models to pursue capability ceilings, and Dense for smaller规格 like 8B and 14B to ensure ease of use. Understanding this layering helps select appropriate model sizes based on compute budgets and scenario requirements.

Technology Stack and Selection Logic Covered in the Course

Based on the course outline disclosed by the creator, the content includes LLM fundamentals, Agent development, LLM frameworks, RAG support libraries, model fine-tuning, private deployment, and more. This combination essentially corresponds to the core skill requirements for current LLM application engineer positions.

One signal he repeatedly conveys: Domestic models like DeepSeek and Qwen3 serve as primary case studies, but foreign models like OpenAI and Claude are also used. Claude 3.5, 3.7, GPT-4o, and o3 are all within the course scope. This "multi-model parallel" teaching approach is closer to real work scenarios than single-model tutorials—after all, it's increasingly common for enterprise projects to mix multiple vendors' models due to cost, compliance, or performance reasons.

For learners, rather than asking "which model should I learn to get a job," ask "can I quickly migrate between different models?" API forms are converging, and concepts like Function Calling, structured output, and MCP are cross-model universal—the underlying capabilities are the truly transferable assets.

FAQ

Does DeepSeek-R1 now support Function Calling?

According to the supplementary information in the video, starting from R1 version 0528, Function Calling and JSON Output are officially supported. Earlier versions required fine-tuning to acquire this capability.

How to choose between Qwen3 and DeepSeek?

If you value out-of-the-box agent support and programmatic thinking mode switching, Qwen3's open-source models perform outstandingly; if your team is already in the DeepSeek ecosystem, V3 version 0324 is stable enough to support workflow development. For actual selection, it's recommended to run small-scale comparative tests using your own business use cases.

Which model should beginners learn first for LLM development?

The creator's course design philosophy can serve as a reference: don't bind to a single model, start with selection methodology, and get exposure to both domestic and international mainstream models. Understand universal concepts like Function Calling, RAG, and Agent first, then move to specific model APIs—migration costs will be much lower.