“DeepSeek是什么框架”这个问题我在技术群里被问了不下二十遍。更准确地说大家真正想问的是DeepSeek背后那套技术栈到底是怎么搭的从模型训练、推理部署、API接入到Agent框架和业务系统集成这些词经常混在一起导致很多人以为“DeepSeek框架”是个类似Vue或Spring Boot那样的东西。这篇文章就把DeepSeek框架和技术栈这件事拆开讲清楚从底层PyTorch基础框架、MoE架构到vLLM、MindIE、Ollama部署再到API调用、Codex接入、Agent框架、harness是什么顺便把若依、Spring Boot这些业务框架和大模型之间的关系捋顺。适合想接入DeepSeek的开发者、准备本地部署的运维以及想搞明白这套体系到底怎么回事的技术爱好者。1. 先厘清概念DeepSeek这套技术栈到底包含哪几层1.1 “DeepSeek框架”这个说法为什么会让人困惑因为“框架”这个词在大模型语境里有两个完全不同的含义。一个是深度学习框架比如PyTorch、TensorFlow这是用来训练和推理模型的底层工具。另一个是应用开发框架比如Spring Boot、Vue、若依这种用来搭建业务系统的脚手架。DeepSeek本身是一个大语言模型不是任何一种意义上的框架。它既不能像Spring Boot那样帮你快速建一个Web项目也不能像PyTorch那样直接拿来训练你自己的网络。“DeepSeek框架”严格来说不是一个官方概念。但为什么大家会搜这个词因为围绕DeepSeek确实存在一整套工程体系这套体系可以被称作“DeepSeek技术栈”。从最底层的模型底座到训练框架再到推理部署工具然后到上层的API、Agent框架、IDE插件每一层都有各自的选型。热搜词里既有“pytorch基础框架”又有“springboot框架”“若依框架”还有人问“deepseek harness是什么”都说明大家是在用各自的背景去理解同一套东西。1.2 技术栈分四层别混着看我习惯把DeepSeek技术栈拆成四个层面来理解层级作用典型代表模型层真正干活的模型本体DeepSeek-V3、DeepSeek-R1、各种蒸馏小模型底座框架层训练模型、支撑模型运行的底层框架PyTorch、Transformer架构、分布式训练框架推理与部署层把模型跑起来、对外提供服务vLLM、MindIE、Ollama、llama.cpp、Docker应用集成层把模型接进产品、工具、业务流程OpenAI兼容API、Agent框架、IDE插件、业务系统可以打个比方DeepSeek模型相当于一台发动机PyTorch是生产这台发动机的机床和工艺vLLM或者MindIE是把发动机装到车架上并接好传动系统的环节而Ollama、Docker是整车组装Agent框架和业务系统则是驾驶舱、仪表盘和行车电脑。这个分层看起来简单但非常重要。算法工程师关心的是底座框架层怎么用PyTorch把MoE模型训出来运维和架构师关心的是推理部署层怎么让模型在有限的显存里跑得又快又稳后端开发关心的是应用集成层怎么调API、怎么做Agent、怎么把大模型嵌进若依这种业务系统里。把层分清楚之后很多争论其实都是“拿着应用层的需求去问模型层的问题”。2. 底子是什么训练与推理框架的选型逻辑2.1 训练侧为什么是PyTorch以及MoE架构是什么DeepSeek系列模型是典型的Decoder-only Transformer架构训练底层基于PyTorch生态。这不是偶然选择。PyTorch用动态计算图调试和改结构都特别方便研究社区里几乎所有的模型代码、论文附带实现、预训练工具都是PyTorch系。在大模型这个赛道上选PyTorch基本等于选择了最大的生态遇到问题搜一下就能找到解决方案不用自己从零踩坑。另一个关键设计是MoE混合专家架构。通俗地说一个MoE模型内部不是一个完整的大网络每次都处理所有输入而是分成若干个“专家子网络”每次只激活其中一小部分。DeepSeek-V3在训练时用MoE大幅降低了计算成本推理时也只有相关专家被激活所以能以更低的成本跑更大的模型。这也是为什么前阵子大家都在讨论“低成本训练大模型”MoE是核心技术之一。训练框架方面除了PyTorch本身还需要分布式训练组件比如FSDP、DeepSpeed这类并行策略工具用于把模型切到多张卡上训练。这部分日常开发和普通业务关系不大但如果你要基于DeepSeek的开源权重做继续训练或者微调就得面对这一层。2.2 推理侧训练框架不能直接拿来当部署工具很多人误以为模型训练完直接用PyTorch加载权重就能对外提供服务。不是不行但效果很差。训练和推理的目标完全不同训练看重吞吐和梯度同步推理看重延迟、显存效率和并发能力。所以推理侧有专门的一类框架。目前大家用到最多的三个是vLLM用PagedAttention管理KV Cache支持continuous batchingGPU利用率高是目前做OpenAI兼容服务的主流选择。MindIE这是热词里出现过的推理引擎主要面向特定硬件加速生态能把PyTorch模型迁移到专用加速卡上做高性能推理适合国产算力环境。llama.cpp主打CPU也能跑、消费级显卡也能跑配合GGUF量化格式是本地部署和边缘设备的常用方案。选型逻辑不难。手上有NVIDIA数据中心级显卡、要正式对外提供高并发服务优先vLLM。如果是特定品牌的加速硬件看一下MindIE这类专用引擎的适配情况。如果只是用家里游戏显卡跑一跑或者想在Mac上本地体验Ollama和llama.cpp更省心。2.3 蒸馏模型是本地部署的主力还有一件事值得单独说DeepSeek R1提出了一个很有用的思路用强化学习让大模型具备推理能力然后通过知识蒸馏把这些能力“压缩”到较小的模型里。所以你会看到DeepSeek-R1-Distill-Qwen-7B、14B、32B这些开源权重。这些蒸馏版小模型才是广大开发者本地部署的主力因为满血版模型需要超大显存普通团队根本撑不住而蒸馏版在普通显卡上就能跑起来虽然参数小了但推理时“先思考再回答”的行为模式还在。这意味着选型时你不需要一上来就追求最大模型先明确需求是想要通用对话、代码生成还是数学推理再决定用几B参数的版本以及用哪种量化格式。这个顺序和很多人习惯的“先下模型再说”正好相反但实测下来能少走很多弯路。3. 部署到自己的环境本地推理栈的搭建与性能取舍3.1 快速体验路线Ollama拉起一个7B模型如果你只是想在本机快速体验DeepSeek的对话能力或者想验证某个想法直接用Ollama是最快的。# 安装Ollama后拉取DeepSeek R1蒸馏模型 ollama pull deepseek-r1:7b # 启动交互式对话 ollama run deepseek-r1:7b跑起来之后Ollama会在本地启动一个服务默认监听11434端口。这个服务兼容OpenAI API格式可以直接用下面的命令验证curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:7b, messages: [{role: user, content: 用一句话解释什么是MoE}] }注意几个细节。Ollama的模型默认存放在用户目录下的.ollama/models里重装系统前记得备份。默认只监听127.0.0.1如果你要让局域网内其他机器访问需要设置环境变量OLLAMA_HOST0.0.0.0。还有一点很多人第一次在OpenAI SDK里用Ollama时把base_url写成了http://localhost:11434少了/v1后缀导致404这是非常典型的低级错误。3.2 生产级路线vLLMDocker做服务化部署当你要把DeepSeek真正接入业务系统、应对并发请求Ollama通常会遇到性能瓶颈这时候就要上vLLM。docker run --gpus all \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --served-model-name deepseek \ --max-model-len 32768 \ --gpu-memory-utilization 0.9启动后用curl http://localhost:8000/v1/models检查服务状态能看到模型列表就说明服务起来了。几个参数值得展开说说--max-model-len模型能接受的最大上下文长度。设太大显存会爆设太小长对话会被截断。需要根据你的显卡显存和实际使用场景来定。--gpu-memory-utilization控制显存利用率。我一般留10%左右的余量给CUDA context和其他开销直接拉满反而容易OOM。--tensor-parallel-size如果有多张显卡可以设置为显卡数量让模型切分到多卡上并行推理。踩过的一个坑是模型加载成功但并发一上来就频繁报错。后来查下来是max-model-len设得太高KV Cache占用过大导致并发请求时显存不够分配。把长度从65536降到32768再把并发请求数控制在合理范围内问题就消失了。部署大模型服务这事显存就是硬约束所有的调优最终都是在跟显存博弈。3.3 显存估算与量化取舍本地部署前先算一笔账。一个FP16精度的7B模型权重大约占用14GB显存实际上推理还要额外存KV Cache通常建议准备20GB以上。量化可以把显存需求大幅压缩常见的部署组合可以这样估算模型规格FP16显存需求INT4/GPTQ量化后适合场景7B约14GB约5-6GB普通游戏显卡、代码生成、日常问答14B约28GB约10-12GB24GB显存显卡、复杂推理32B约64GB约20-22GB多卡环境、更高质量回答671B满血版上千GB不现实企业级多机多卡集群所以普通人本地部署基本都选蒸馏版小模型加量化。量化的损失在日常对话和代码任务上感知不明显但在数学、逻辑推理这类对精度敏感的任务上建议至少用INT8或者干脆保留FP16。另外GGUF、AWQ、GPTQ是不同的量化方案简单选型标准是llama.cpp/Ollama用GGUFvLLM上用AWQ或GPTQ。3.4 MindIE部署要关注算子兼容性热词里出现的“mindie框架”如果你用的是特定加速卡会接触到。MindIE本质上是面向AI硬件的推理引擎PyTorch模型可以通过它做高性能推理和vLLM在NVIDIA卡上的定位类似。部署前一定先查官方算子支持列表如果你的模型里用了未适配的算子中途会报兼容性错误。对大多数普通开发者来说先用Ollama或vLLM跑通再考虑MindIE这个顺序比较务实。4. 开发者接入的三种姿势API、开源模型、框架集成4.1 官方APIOpenAI SDK直接调注意base_url和模型名DeepSeek的API兼容OpenAI格式所以不需要额外装SDK直接用OpenAI的Python包就能接入。最基本的调用长这样from openai import OpenAI client OpenAI( api_key你的API Key, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个乐于助人的助手}, {role: user, content: 介绍一下DeepSeek的推理服务怎么搭} ], streamFalse ) print(resp.choices[0].message.content)很多人第一次调用失败通常就两个原因。第一个是base_url配错漏掉或者多加路径导致404。第二个是模型名写错官方API的对话模型是deepseek-chat推理模型是deepseek-reasoner并不是“deepseek-v3”这种写法。流式输出也是刚需。把streamTrue传进去响应会变成迭代器你可以逐段拿到内容实现打字机效果。在聊天类产品里体验差距非常明显。另外建议把max_tokens设置为一个合理值不设置的话默认可能较短长回答容易被截断。4.2 Codex和VSCode接入本质都是配一个OpenAI兼容端点“codex接入deepseek”这个热词实际操作不复杂。Codex CLI这类工具都支持自定义模型提供商你把模型端点指向DeepSeek的API或者本地服务就行。类似地在VSCode里用Cline、Continue这类插件接DeepSeek也是同样的逻辑——在provider配置里填一个自定义的兼容端点填上模型名和key。{ apiProvider: openai, apiBaseUrl: http://localhost:11434/v1, apiKey: ollama, model: deepseek-r1:7b }我实测的体验是本地部署的小模型在IDE里做代码补全和简单重构完全够用但做大规模代码理解时云端API的上下文能力和响应质量明显更高。建议IDE插件面向日常开发用本地模型遇到复杂任务再切云端API。4.3 DeepSeek Harness是什么和Hermes有什么关系“deepseek harness”这个热词让不少人很困惑。Harness在英文里是“马具、安全带”的意思在LLM工程里它的含义是“把模型运行起来的脚手架工具”。一个eval harness通常负责模型加载、数据集读取、参数配置、输出解析这些事让你能自动化地测试模型在某个评测集上的表现。所以“DeepSeek harness”可以理解成专门用来运行和评估DeepSeek模型的框架工具它不是模型本身也不是推理服务而是一个测试外壳。至于“deepseek hermes”这是社区里一个容易被混淆的叫法。Hermes本身是一个比较有名的开源模型微调配方/风格社区会把它用在各种基础模型上做二次微调于是就有了类似“Hermes版DeepSeek”的模型。这些与官方发布的模型不是一回事下载前一定仔细看模型卡说明确认权重来源和授权方式别把社区适配版当成官方版本用。4.4 Agent框架模型负责思考框架负责行动Agent框架是现在最热的方向之一。大模型本身只能“输出下一段文本”但Agent框架可以让它“决定调用什么工具、查看什么结果、再决定下一步做什么”形成完整的“思考-行动-观察”循环。LangGraph、Dify、Coze这些都属于Agent/智能体框架台词是“把大模型变成能干活的应用”。我做过一个极简的Agent循环不用任何框架也能跑通def run_agent(user_input, tools, max_steps5): messages [{role: user, content: user_input}] for _ in range(max_steps): response client.chat.completions.create( modeldeepseek-chat, messagesmessages ) content response.choices[0].message.content action parse_action(content) # 从输出中解析要调用的工具 if action is None: return content result tools[action[name]](**action[args]) messages.append({role: assistant, content: content}) messages.append({role: user, content: f工具返回结果{result}}) return 达到最大步数这个循环的核心就是把工具返回结果拼接回messages再让模型继续推理。理解了这一点再去看LangGraph里的StateGraph、节点、边就容易多了无非是把上面的循环结构化和可视化。做Agent时有个细节很容易被忽略如果你用的是R1这类带思维链的推理模型模型的输出里会有一段“思考过程”和最终答案。接工具调用逻辑时要解析最终答案里的工具参数不要把思考过程直接拼进工具调用上下文否则会把Agent带偏。5. 别把“业务框架”和“模型框架”混为一谈5.1 若依、Spring Boot、pytest、Playwright分别是什么角色热词里有一批看起来和DeepSeek关系不大但又高频出现的框架若依、Spring Boot、pytest、Playwright、字符设备驱动框架、Linux多进程通信框架、QGraphicsScene/View框架。这些不是DeepSeek技术栈的组成部分它们分属完全不同的领域。若依RuoYi是基于Spring Boot的快速开发脚手架用来快速搭建后台管理系统。它和DeepSeek的关系是你可以做一个基于若依的系统在系统里调用DeepSeek的API给业务加上AI能力。Spring Boot是Java系的后端框架适合做API网关、权限控制、业务编排。如果把DeepSeek接入正式业务经常需要Spring Boot做一个中间层把前端请求、密钥管理、限流、日志都收敛起来再转发到DeepSeek服务。pytest是Python的测试框架你可以用它写DeepSeek API的接口自动化测试比如批量校验返回格式、断言关键词、做回归。Playwright是浏览器端到端测试工具适合测试AI应用的前端交互比如自动打开聊天页面、输入问题、等待流式回复、断言页面内出现答案。字符设备驱动、Linux多进程通信、QGraphicsScene/View则属于系统编程和桌面应用开发领域和DeepSeek没有直接耦合。如果你做的是一个C桌面应用想接大模型能力走HTTP API就行了不需要也不能在驱动层和模型直接交互。5.2 一张“技术栈地图”把各层关系理清与其被一堆术语绕晕不如直接看这张图。我按“从业务到模型”的顺序列出来名称类型和DeepSeek的关系Vue/React前端框架做AI应用界面通过HTTP调用后端若依/Spring Boot业务后端框架做权限、鉴权、API转发承载业务逻辑LangGraph/Dify/CozeAgent/智能体框架编排模型的工具调用、记忆、多步任务OpenAI兼容API接口协议DeepSeek API和本地服务都兼容这个协议vLLM/MindIE/Ollama推理引擎/部署工具把模型跑起来并提供服务DeepSeek-V3/R1/蒸馏版大语言模型负责理解和生成PyTorch/Transformers深度学习框架模型训练和底层运行依赖pytest/Playwright测试框架对AI应用做接口测试和端到端测试框架选型的第一原则从来不是“谁火选谁”而是围绕业务目标。你要做一个内部知识库问答系统那么核心选型是向量数据库、RAG框架和DeepSeek API你要做一个可复用AI能力的后台那么核心是Spring Boot或者若依这类业务后端把模型调用封装成内部服务你要做Agent自动化那么核心才是LangGraph这类编排框架。先把业务问题定义清楚技术栈自然就收敛了。6. 实测中的高频报错与排查链路6.1 “request extension preparation failed”的排查过程这个报错在本地部署场景里出现频率很高。我遇到的一次是vLLM服务在并发请求稍微上来之后日志里持续刷这个错误客户端表现为请求直接失败。完整排查链路是这样的看服务日志。vLLM通常会在报错前一行打出具体原因比如“input length exceeds max_model_len”或“CUDA out of memory”。看显存占用。执行nvidia-smi如果显存剩余很少基本可以判断是KV Cache分配失败。检查输入token长度。长文档场景下用户一个请求可能塞了几万token直接超过了max-model-len。如果是超长问题要么调大--max-model-len要么限制用户的输入长度通常后者更现实。如果是并发问题降低--gpu-memory-utilization以下的并发请求数或者在前面加一层限流。这个报错很折磨人的地方在于它的字面意思是“请求扩展准备失败”看起来像某个扩展组件出问题实际上绝大多数情况是资源问题。所以排查顺序一定是先看资源和长度再去看框架配置。别一上来就重装服务、换版本那基本都是浪费时间。6.2 “达到对话长度上限请开启新对话”怎么破这个提示来自DeepSeek官方Web端但底层逻辑在API调用里同样存在模型的上下文窗口有限塞满了就必须清空或压缩。很多人第一次遇到会以为是Bug其实不是。解决办法有三种一种是手动新开对话最简单但会丢失上下文。第二种是摘要压缩法在对话接近上限之前让模型把前面的历史总结成一段摘要然后把摘要作为新对话的system消息再接新的对话。第三种是滑动窗口法只保留最近N轮消息更早的用一句摘要代替。def build_messages(history, recent_n10): # 对超过recent_n的历史做摘要 summary summarize_early_history(history[:-recent_n]) recent history[-recent_n:] if summary: system_msg {role: system, content: f之前的对话总结{summary}} return [system_msg] recent return recent我实测下来“摘要最近K轮”的组合在几十轮的长对话里效果最好既不会完全丢失早期信息又能控制token总量。6.3 “怎么继承上一个对话”的真正答案“DeepSeek怎么继承上一个对话”这个热词答案其实很简单模型本身不会主动记住任何历史。所谓继承对话是调用方把历史消息作为messages数组原样传给API模型根据这些历史上下文来生成回答。messages [ {role: system, content: 你是DeepSeek助手}, {role: user, content: 帮我推荐一个本地部署方案}, {role: assistant, content: 如果你显存有限推荐Ollama加上7B蒸馏模型}, {role: user, content: 那这个方案需要多大显存} ]API内部没有记忆它每次读到的都是整个messages数组。所以你如果要实现真正的记忆能力需要在应用层自己存历史。本地部署也是一样需要自己维护会话ID和历史消息的存储可以是Redis、数据库或者文件。还有个容易被忽略的点token不是按“字”算的一个汉字大约对应1到1.5个token。即使模型支持128K上下文也不建议真把128K全塞满至少要留30%左右的余量给模型回复生成。否则就会出现客户端还在传历史服务端已经够长直接拒绝的情况和“对话长度上限”报错一个道理。实际上把DeepSeek从“网页聊天”升级成“业务系统能力”的过程中最花时间的往往不是模型本身而是这些细碎的工程问题显存怎么规划、上下文怎么管理、历史怎么存储、工具调用怎么解析。把这些捋顺了你会发现DeepSeek技术栈并没有多玄乎底层是PyTorch生态中间是推理引擎和部署工具上层是API和Agent框架每一层都有成熟方案按自己的算力和业务场景去选就对了。
DeepSeek技术栈全解：从PyTorch底座到Agent框架
“DeepSeek是什么框架”这个问题我在技术群里被问了不下二十遍。更准确地说大家真正想问的是DeepSeek背后那套技术栈到底是怎么搭的从模型训练、推理部署、API接入到Agent框架和业务系统集成这些词经常混在一起导致很多人以为“DeepSeek框架”是个类似Vue或Spring Boot那样的东西。这篇文章就把DeepSeek框架和技术栈这件事拆开讲清楚从底层PyTorch基础框架、MoE架构到vLLM、MindIE、Ollama部署再到API调用、Codex接入、Agent框架、harness是什么顺便把若依、Spring Boot这些业务框架和大模型之间的关系捋顺。适合想接入DeepSeek的开发者、准备本地部署的运维以及想搞明白这套体系到底怎么回事的技术爱好者。1. 先厘清概念DeepSeek这套技术栈到底包含哪几层1.1 “DeepSeek框架”这个说法为什么会让人困惑因为“框架”这个词在大模型语境里有两个完全不同的含义。一个是深度学习框架比如PyTorch、TensorFlow这是用来训练和推理模型的底层工具。另一个是应用开发框架比如Spring Boot、Vue、若依这种用来搭建业务系统的脚手架。DeepSeek本身是一个大语言模型不是任何一种意义上的框架。它既不能像Spring Boot那样帮你快速建一个Web项目也不能像PyTorch那样直接拿来训练你自己的网络。“DeepSeek框架”严格来说不是一个官方概念。但为什么大家会搜这个词因为围绕DeepSeek确实存在一整套工程体系这套体系可以被称作“DeepSeek技术栈”。从最底层的模型底座到训练框架再到推理部署工具然后到上层的API、Agent框架、IDE插件每一层都有各自的选型。热搜词里既有“pytorch基础框架”又有“springboot框架”“若依框架”还有人问“deepseek harness是什么”都说明大家是在用各自的背景去理解同一套东西。1.2 技术栈分四层别混着看我习惯把DeepSeek技术栈拆成四个层面来理解层级作用典型代表模型层真正干活的模型本体DeepSeek-V3、DeepSeek-R1、各种蒸馏小模型底座框架层训练模型、支撑模型运行的底层框架PyTorch、Transformer架构、分布式训练框架推理与部署层把模型跑起来、对外提供服务vLLM、MindIE、Ollama、llama.cpp、Docker应用集成层把模型接进产品、工具、业务流程OpenAI兼容API、Agent框架、IDE插件、业务系统可以打个比方DeepSeek模型相当于一台发动机PyTorch是生产这台发动机的机床和工艺vLLM或者MindIE是把发动机装到车架上并接好传动系统的环节而Ollama、Docker是整车组装Agent框架和业务系统则是驾驶舱、仪表盘和行车电脑。这个分层看起来简单但非常重要。算法工程师关心的是底座框架层怎么用PyTorch把MoE模型训出来运维和架构师关心的是推理部署层怎么让模型在有限的显存里跑得又快又稳后端开发关心的是应用集成层怎么调API、怎么做Agent、怎么把大模型嵌进若依这种业务系统里。把层分清楚之后很多争论其实都是“拿着应用层的需求去问模型层的问题”。2. 底子是什么训练与推理框架的选型逻辑2.1 训练侧为什么是PyTorch以及MoE架构是什么DeepSeek系列模型是典型的Decoder-only Transformer架构训练底层基于PyTorch生态。这不是偶然选择。PyTorch用动态计算图调试和改结构都特别方便研究社区里几乎所有的模型代码、论文附带实现、预训练工具都是PyTorch系。在大模型这个赛道上选PyTorch基本等于选择了最大的生态遇到问题搜一下就能找到解决方案不用自己从零踩坑。另一个关键设计是MoE混合专家架构。通俗地说一个MoE模型内部不是一个完整的大网络每次都处理所有输入而是分成若干个“专家子网络”每次只激活其中一小部分。DeepSeek-V3在训练时用MoE大幅降低了计算成本推理时也只有相关专家被激活所以能以更低的成本跑更大的模型。这也是为什么前阵子大家都在讨论“低成本训练大模型”MoE是核心技术之一。训练框架方面除了PyTorch本身还需要分布式训练组件比如FSDP、DeepSpeed这类并行策略工具用于把模型切到多张卡上训练。这部分日常开发和普通业务关系不大但如果你要基于DeepSeek的开源权重做继续训练或者微调就得面对这一层。2.2 推理侧训练框架不能直接拿来当部署工具很多人误以为模型训练完直接用PyTorch加载权重就能对外提供服务。不是不行但效果很差。训练和推理的目标完全不同训练看重吞吐和梯度同步推理看重延迟、显存效率和并发能力。所以推理侧有专门的一类框架。目前大家用到最多的三个是vLLM用PagedAttention管理KV Cache支持continuous batchingGPU利用率高是目前做OpenAI兼容服务的主流选择。MindIE这是热词里出现过的推理引擎主要面向特定硬件加速生态能把PyTorch模型迁移到专用加速卡上做高性能推理适合国产算力环境。llama.cpp主打CPU也能跑、消费级显卡也能跑配合GGUF量化格式是本地部署和边缘设备的常用方案。选型逻辑不难。手上有NVIDIA数据中心级显卡、要正式对外提供高并发服务优先vLLM。如果是特定品牌的加速硬件看一下MindIE这类专用引擎的适配情况。如果只是用家里游戏显卡跑一跑或者想在Mac上本地体验Ollama和llama.cpp更省心。2.3 蒸馏模型是本地部署的主力还有一件事值得单独说DeepSeek R1提出了一个很有用的思路用强化学习让大模型具备推理能力然后通过知识蒸馏把这些能力“压缩”到较小的模型里。所以你会看到DeepSeek-R1-Distill-Qwen-7B、14B、32B这些开源权重。这些蒸馏版小模型才是广大开发者本地部署的主力因为满血版模型需要超大显存普通团队根本撑不住而蒸馏版在普通显卡上就能跑起来虽然参数小了但推理时“先思考再回答”的行为模式还在。这意味着选型时你不需要一上来就追求最大模型先明确需求是想要通用对话、代码生成还是数学推理再决定用几B参数的版本以及用哪种量化格式。这个顺序和很多人习惯的“先下模型再说”正好相反但实测下来能少走很多弯路。3. 部署到自己的环境本地推理栈的搭建与性能取舍3.1 快速体验路线Ollama拉起一个7B模型如果你只是想在本机快速体验DeepSeek的对话能力或者想验证某个想法直接用Ollama是最快的。# 安装Ollama后拉取DeepSeek R1蒸馏模型 ollama pull deepseek-r1:7b # 启动交互式对话 ollama run deepseek-r1:7b跑起来之后Ollama会在本地启动一个服务默认监听11434端口。这个服务兼容OpenAI API格式可以直接用下面的命令验证curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:7b, messages: [{role: user, content: 用一句话解释什么是MoE}] }注意几个细节。Ollama的模型默认存放在用户目录下的.ollama/models里重装系统前记得备份。默认只监听127.0.0.1如果你要让局域网内其他机器访问需要设置环境变量OLLAMA_HOST0.0.0.0。还有一点很多人第一次在OpenAI SDK里用Ollama时把base_url写成了http://localhost:11434少了/v1后缀导致404这是非常典型的低级错误。3.2 生产级路线vLLMDocker做服务化部署当你要把DeepSeek真正接入业务系统、应对并发请求Ollama通常会遇到性能瓶颈这时候就要上vLLM。docker run --gpus all \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --served-model-name deepseek \ --max-model-len 32768 \ --gpu-memory-utilization 0.9启动后用curl http://localhost:8000/v1/models检查服务状态能看到模型列表就说明服务起来了。几个参数值得展开说说--max-model-len模型能接受的最大上下文长度。设太大显存会爆设太小长对话会被截断。需要根据你的显卡显存和实际使用场景来定。--gpu-memory-utilization控制显存利用率。我一般留10%左右的余量给CUDA context和其他开销直接拉满反而容易OOM。--tensor-parallel-size如果有多张显卡可以设置为显卡数量让模型切分到多卡上并行推理。踩过的一个坑是模型加载成功但并发一上来就频繁报错。后来查下来是max-model-len设得太高KV Cache占用过大导致并发请求时显存不够分配。把长度从65536降到32768再把并发请求数控制在合理范围内问题就消失了。部署大模型服务这事显存就是硬约束所有的调优最终都是在跟显存博弈。3.3 显存估算与量化取舍本地部署前先算一笔账。一个FP16精度的7B模型权重大约占用14GB显存实际上推理还要额外存KV Cache通常建议准备20GB以上。量化可以把显存需求大幅压缩常见的部署组合可以这样估算模型规格FP16显存需求INT4/GPTQ量化后适合场景7B约14GB约5-6GB普通游戏显卡、代码生成、日常问答14B约28GB约10-12GB24GB显存显卡、复杂推理32B约64GB约20-22GB多卡环境、更高质量回答671B满血版上千GB不现实企业级多机多卡集群所以普通人本地部署基本都选蒸馏版小模型加量化。量化的损失在日常对话和代码任务上感知不明显但在数学、逻辑推理这类对精度敏感的任务上建议至少用INT8或者干脆保留FP16。另外GGUF、AWQ、GPTQ是不同的量化方案简单选型标准是llama.cpp/Ollama用GGUFvLLM上用AWQ或GPTQ。3.4 MindIE部署要关注算子兼容性热词里出现的“mindie框架”如果你用的是特定加速卡会接触到。MindIE本质上是面向AI硬件的推理引擎PyTorch模型可以通过它做高性能推理和vLLM在NVIDIA卡上的定位类似。部署前一定先查官方算子支持列表如果你的模型里用了未适配的算子中途会报兼容性错误。对大多数普通开发者来说先用Ollama或vLLM跑通再考虑MindIE这个顺序比较务实。4. 开发者接入的三种姿势API、开源模型、框架集成4.1 官方APIOpenAI SDK直接调注意base_url和模型名DeepSeek的API兼容OpenAI格式所以不需要额外装SDK直接用OpenAI的Python包就能接入。最基本的调用长这样from openai import OpenAI client OpenAI( api_key你的API Key, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个乐于助人的助手}, {role: user, content: 介绍一下DeepSeek的推理服务怎么搭} ], streamFalse ) print(resp.choices[0].message.content)很多人第一次调用失败通常就两个原因。第一个是base_url配错漏掉或者多加路径导致404。第二个是模型名写错官方API的对话模型是deepseek-chat推理模型是deepseek-reasoner并不是“deepseek-v3”这种写法。流式输出也是刚需。把streamTrue传进去响应会变成迭代器你可以逐段拿到内容实现打字机效果。在聊天类产品里体验差距非常明显。另外建议把max_tokens设置为一个合理值不设置的话默认可能较短长回答容易被截断。4.2 Codex和VSCode接入本质都是配一个OpenAI兼容端点“codex接入deepseek”这个热词实际操作不复杂。Codex CLI这类工具都支持自定义模型提供商你把模型端点指向DeepSeek的API或者本地服务就行。类似地在VSCode里用Cline、Continue这类插件接DeepSeek也是同样的逻辑——在provider配置里填一个自定义的兼容端点填上模型名和key。{ apiProvider: openai, apiBaseUrl: http://localhost:11434/v1, apiKey: ollama, model: deepseek-r1:7b }我实测的体验是本地部署的小模型在IDE里做代码补全和简单重构完全够用但做大规模代码理解时云端API的上下文能力和响应质量明显更高。建议IDE插件面向日常开发用本地模型遇到复杂任务再切云端API。4.3 DeepSeek Harness是什么和Hermes有什么关系“deepseek harness”这个热词让不少人很困惑。Harness在英文里是“马具、安全带”的意思在LLM工程里它的含义是“把模型运行起来的脚手架工具”。一个eval harness通常负责模型加载、数据集读取、参数配置、输出解析这些事让你能自动化地测试模型在某个评测集上的表现。所以“DeepSeek harness”可以理解成专门用来运行和评估DeepSeek模型的框架工具它不是模型本身也不是推理服务而是一个测试外壳。至于“deepseek hermes”这是社区里一个容易被混淆的叫法。Hermes本身是一个比较有名的开源模型微调配方/风格社区会把它用在各种基础模型上做二次微调于是就有了类似“Hermes版DeepSeek”的模型。这些与官方发布的模型不是一回事下载前一定仔细看模型卡说明确认权重来源和授权方式别把社区适配版当成官方版本用。4.4 Agent框架模型负责思考框架负责行动Agent框架是现在最热的方向之一。大模型本身只能“输出下一段文本”但Agent框架可以让它“决定调用什么工具、查看什么结果、再决定下一步做什么”形成完整的“思考-行动-观察”循环。LangGraph、Dify、Coze这些都属于Agent/智能体框架台词是“把大模型变成能干活的应用”。我做过一个极简的Agent循环不用任何框架也能跑通def run_agent(user_input, tools, max_steps5): messages [{role: user, content: user_input}] for _ in range(max_steps): response client.chat.completions.create( modeldeepseek-chat, messagesmessages ) content response.choices[0].message.content action parse_action(content) # 从输出中解析要调用的工具 if action is None: return content result tools[action[name]](**action[args]) messages.append({role: assistant, content: content}) messages.append({role: user, content: f工具返回结果{result}}) return 达到最大步数这个循环的核心就是把工具返回结果拼接回messages再让模型继续推理。理解了这一点再去看LangGraph里的StateGraph、节点、边就容易多了无非是把上面的循环结构化和可视化。做Agent时有个细节很容易被忽略如果你用的是R1这类带思维链的推理模型模型的输出里会有一段“思考过程”和最终答案。接工具调用逻辑时要解析最终答案里的工具参数不要把思考过程直接拼进工具调用上下文否则会把Agent带偏。5. 别把“业务框架”和“模型框架”混为一谈5.1 若依、Spring Boot、pytest、Playwright分别是什么角色热词里有一批看起来和DeepSeek关系不大但又高频出现的框架若依、Spring Boot、pytest、Playwright、字符设备驱动框架、Linux多进程通信框架、QGraphicsScene/View框架。这些不是DeepSeek技术栈的组成部分它们分属完全不同的领域。若依RuoYi是基于Spring Boot的快速开发脚手架用来快速搭建后台管理系统。它和DeepSeek的关系是你可以做一个基于若依的系统在系统里调用DeepSeek的API给业务加上AI能力。Spring Boot是Java系的后端框架适合做API网关、权限控制、业务编排。如果把DeepSeek接入正式业务经常需要Spring Boot做一个中间层把前端请求、密钥管理、限流、日志都收敛起来再转发到DeepSeek服务。pytest是Python的测试框架你可以用它写DeepSeek API的接口自动化测试比如批量校验返回格式、断言关键词、做回归。Playwright是浏览器端到端测试工具适合测试AI应用的前端交互比如自动打开聊天页面、输入问题、等待流式回复、断言页面内出现答案。字符设备驱动、Linux多进程通信、QGraphicsScene/View则属于系统编程和桌面应用开发领域和DeepSeek没有直接耦合。如果你做的是一个C桌面应用想接大模型能力走HTTP API就行了不需要也不能在驱动层和模型直接交互。5.2 一张“技术栈地图”把各层关系理清与其被一堆术语绕晕不如直接看这张图。我按“从业务到模型”的顺序列出来名称类型和DeepSeek的关系Vue/React前端框架做AI应用界面通过HTTP调用后端若依/Spring Boot业务后端框架做权限、鉴权、API转发承载业务逻辑LangGraph/Dify/CozeAgent/智能体框架编排模型的工具调用、记忆、多步任务OpenAI兼容API接口协议DeepSeek API和本地服务都兼容这个协议vLLM/MindIE/Ollama推理引擎/部署工具把模型跑起来并提供服务DeepSeek-V3/R1/蒸馏版大语言模型负责理解和生成PyTorch/Transformers深度学习框架模型训练和底层运行依赖pytest/Playwright测试框架对AI应用做接口测试和端到端测试框架选型的第一原则从来不是“谁火选谁”而是围绕业务目标。你要做一个内部知识库问答系统那么核心选型是向量数据库、RAG框架和DeepSeek API你要做一个可复用AI能力的后台那么核心是Spring Boot或者若依这类业务后端把模型调用封装成内部服务你要做Agent自动化那么核心才是LangGraph这类编排框架。先把业务问题定义清楚技术栈自然就收敛了。6. 实测中的高频报错与排查链路6.1 “request extension preparation failed”的排查过程这个报错在本地部署场景里出现频率很高。我遇到的一次是vLLM服务在并发请求稍微上来之后日志里持续刷这个错误客户端表现为请求直接失败。完整排查链路是这样的看服务日志。vLLM通常会在报错前一行打出具体原因比如“input length exceeds max_model_len”或“CUDA out of memory”。看显存占用。执行nvidia-smi如果显存剩余很少基本可以判断是KV Cache分配失败。检查输入token长度。长文档场景下用户一个请求可能塞了几万token直接超过了max-model-len。如果是超长问题要么调大--max-model-len要么限制用户的输入长度通常后者更现实。如果是并发问题降低--gpu-memory-utilization以下的并发请求数或者在前面加一层限流。这个报错很折磨人的地方在于它的字面意思是“请求扩展准备失败”看起来像某个扩展组件出问题实际上绝大多数情况是资源问题。所以排查顺序一定是先看资源和长度再去看框架配置。别一上来就重装服务、换版本那基本都是浪费时间。6.2 “达到对话长度上限请开启新对话”怎么破这个提示来自DeepSeek官方Web端但底层逻辑在API调用里同样存在模型的上下文窗口有限塞满了就必须清空或压缩。很多人第一次遇到会以为是Bug其实不是。解决办法有三种一种是手动新开对话最简单但会丢失上下文。第二种是摘要压缩法在对话接近上限之前让模型把前面的历史总结成一段摘要然后把摘要作为新对话的system消息再接新的对话。第三种是滑动窗口法只保留最近N轮消息更早的用一句摘要代替。def build_messages(history, recent_n10): # 对超过recent_n的历史做摘要 summary summarize_early_history(history[:-recent_n]) recent history[-recent_n:] if summary: system_msg {role: system, content: f之前的对话总结{summary}} return [system_msg] recent return recent我实测下来“摘要最近K轮”的组合在几十轮的长对话里效果最好既不会完全丢失早期信息又能控制token总量。6.3 “怎么继承上一个对话”的真正答案“DeepSeek怎么继承上一个对话”这个热词答案其实很简单模型本身不会主动记住任何历史。所谓继承对话是调用方把历史消息作为messages数组原样传给API模型根据这些历史上下文来生成回答。messages [ {role: system, content: 你是DeepSeek助手}, {role: user, content: 帮我推荐一个本地部署方案}, {role: assistant, content: 如果你显存有限推荐Ollama加上7B蒸馏模型}, {role: user, content: 那这个方案需要多大显存} ]API内部没有记忆它每次读到的都是整个messages数组。所以你如果要实现真正的记忆能力需要在应用层自己存历史。本地部署也是一样需要自己维护会话ID和历史消息的存储可以是Redis、数据库或者文件。还有个容易被忽略的点token不是按“字”算的一个汉字大约对应1到1.5个token。即使模型支持128K上下文也不建议真把128K全塞满至少要留30%左右的余量给模型回复生成。否则就会出现客户端还在传历史服务端已经够长直接拒绝的情况和“对话长度上限”报错一个道理。实际上把DeepSeek从“网页聊天”升级成“业务系统能力”的过程中最花时间的往往不是模型本身而是这些细碎的工程问题显存怎么规划、上下文怎么管理、历史怎么存储、工具调用怎么解析。把这些捋顺了你会发现DeepSeek技术栈并没有多玄乎底层是PyTorch生态中间是推理引擎和部署工具上层是API和Agent框架每一层都有成熟方案按自己的算力和业务场景去选就对了。