1. 从一张学习笔记说起为什么值得系统整理 DeepSeek 大模型最早接触 DeepSeek 是在一个内部技术分享群里有人丢了一张截图说某个开源模型在代码补全和数学推理上的表现已经能跟一线闭源模型掰手腕而且推理成本低得离谱。当时我的第一反应是“又一个营销噱头”直到自己把模型拉下来跑了一遍才意识到这东西确实值得认真做一份学习笔记。这份笔记不是官方文档的搬运而是我在实际部署、调用、微调、排查问题的过程中一点点攒下来的经验。它适合几类人想入门大模型但不知道从哪下手的新手、需要把大模型接入现有业务系统的工程师、以及正在评估私有化部署方案的技术负责人。DeepSeek 本质上是一个大语言模型系列覆盖了通用对话、代码生成、数学推理等多个方向。它的核心价值在于在保持较高推理质量的同时把显存占用和推理成本压到了一个相对亲民的水平。这意味着你不一定需要一整套昂贵的算力集群用消费级显卡甚至量化后的模型就能跑起来。对于中小团队来说这一点非常关键因为很多团队不是不想用大模型而是被硬件门槛和调用成本劝退了。我写这份笔记的出发点很简单网上关于 DeepSeek 的资料虽然多但大多比较零散要么是官方文档的复述要么是只讲概念不讲实操。真正落地时会遇到的一堆细节问题比如模型格式怎么选、量化到什么程度合适、API 怎么接、本地部署用什么推理框架、微调数据怎么准备反而很少有人系统讲清楚。所以我把这些内容按自己的理解重新梳理了一遍尽量做到“看完就能动手”。2. 核心概念拆解先把大模型的基础逻辑理清楚2.1 大模型到底在做什么很多人第一次接触大模型会觉得它像一个“什么都懂一点”的聊天机器人。但从技术角度看大模型的核心任务其实非常单一根据已有的 token 序列预测下一个 token 的概率分布。你输入的每一句话都会被切分成 token模型逐个预测下一个 token然后把预测结果拼回去形成完整的回复。这个过程中模型并没有真正“理解”你的意思它只是在做概率计算。但正是因为参数量足够大、训练数据足够多这种概率计算表现出了惊人的泛化能力。理解这一点很重要因为它直接决定了你后续使用模型的方式。比如为什么提示词工程有效因为你输入的 token 序列会直接影响模型对下一个 token 的预测。为什么模型会“胡说八道”因为它在某些情况下会给出概率较高但事实错误的预测。为什么上下文长度有限制因为模型能处理的 token 数量是有上限的超出部分要么被截断要么需要特殊处理。DeepSeek 系列模型在这方面遵循的是同一套底层逻辑但它在训练策略和架构上做了一些优化使得在相同参数量下推理能力和效率都有提升。具体来说它在注意力机制、位置编码、训练数据配比等方面都有自己的设计这些细节官方技术报告里有详细说明我这里不展开重点讲对使用者有直接影响的部分。2.2 模型版本与选型不是越大越好DeepSeek 目前有多个版本参数量从几 B 到几百 B 不等。新手最容易犯的错误就是“无脑选最大的”觉得参数越多效果越好。实际上模型选型要综合考虑任务复杂度、硬件条件、响应延迟和成本。我整理了一个简单的选型对照表供参考模型规模适用场景硬件门槛推理速度典型用途1B-7B简单分类、文本摘要、轻量对话消费级显卡即可很快边缘设备、本地助手7B-13B通用对话、代码补全、中等复杂度推理单卡 16G-24G较快企业内部工具、API 服务13B-70B复杂推理、长文本理解、专业领域问答多卡或量化部署中等知识库问答、代码生成70B 以上高精度推理、多模态任务专业算力集群较慢研究、高要求生产环境这张表不是绝对的因为量化技术可以大幅降低硬件门槛。比如一个 70B 的模型经过 4-bit 量化后可能只需要两张 24G 显卡就能跑起来但代价是推理质量会有一定下降。所以选型的核心原则是先明确任务需求再倒推硬件和模型规模而不是反过来。2.3 上下文长度被低估的关键参数上下文长度指的是模型一次能处理的 token 数量。这个参数在实际使用中影响非常大但很多人一开始会忽略。举个例子如果你要让模型阅读一份 50 页的 PDF 并回答问题上下文长度不够的话你只能把文档切碎分批喂给模型但这样会丢失跨段落的信息关联导致回答质量下降。DeepSeek 不同版本支持的上下文长度不同有的支持 32K有的支持 128K 甚至更长。在选择模型时如果你的业务涉及长文档处理、多轮复杂对话、代码库分析等场景上下文长度应该是优先考虑的因素之一。需要注意的是上下文长度和显存占用是正相关的。上下文越长推理时需要的显存越多。所以不是越长越好而是要根据实际需求平衡。我一般建议如果只是做短对话或单轮问答8K 到 16K 足够如果是文档分析或代码理解至少 32K 起步如果是超长文档或多轮复杂任务再考虑 128K 以上的版本。3. 本地部署实操从零把 DeepSeek 跑起来3.1 硬件与环境的准备本地部署 DeepSeek 的第一步是确认硬件条件。如果你用的是消费级显卡比如 RTX 3060 12G、RTX 4070 Ti 16G、RTX 4090 24G那么可以跑 7B 到 13B 的模型量化后甚至能跑更大的。如果是纯 CPU 环境也不是完全不能跑但速度会慢很多只适合做实验或低频调用。我自己的测试环境是一张 24G 显存的显卡加 64G 内存跑 13B 模型量化版非常流畅跑 70B 量化版也能跑但响应速度明显下降。软件环境方面我推荐用 Linux 系统因为大多数推理框架对 Linux 的支持更好。Windows 下也可以用 WSL2但会有一些性能损耗。Python 版本建议 3.10 或 3.11太新的版本可能有些依赖包还没适配。CUDA 版本要根据显卡驱动和推理框架的要求来选一般 11.8 或 12.1 比较稳妥。3.2 推理框架选型Ollama、vLLM 还是其他本地部署大模型推理框架的选择直接决定了使用体验。我试过几种主流方案各有优劣Ollama上手最简单一条命令就能拉取和运行模型适合新手快速体验。但它对并发和批量推理的支持一般更适合个人使用或低频场景。vLLM性能强支持高并发和连续批处理适合生产环境。但配置相对复杂对硬件要求也更高。llama.cpp轻量级CPU 推理优化好适合没有独立显卡的环境。但 GPU 加速支持不如前两者。Transformers Accelerate灵活性最高适合做研究和微调但部署成服务需要自己写不少代码。我的建议是如果你只是想先跑起来看看效果用 Ollama如果要部署成内部服务给团队用用 vLLM如果硬件条件有限用 llama.cpp。下面我以 Ollama 为例演示一下完整的部署流程。3.3 一步步部署 DeepSeek 模型首先安装 Ollama。Linux 下一条命令搞定curl -fsSL https://ollama.com/install.sh | sh安装完成后确认服务是否启动ollama --version然后拉取 DeepSeek 模型。Ollama 的模型库里有多个版本你可以根据硬件条件选择ollama pull deepseek-coder:6.7b这里我选的是 6.7B 的代码模型因为我的主要用途是代码补全和技术问答。拉取完成后直接运行ollama run deepseek-coder:6.7b这时候你会进入一个交互式对话界面可以直接输入问题测试。如果要在代码里调用Ollama 提供了 REST API默认监听 11434 端口curl http://localhost:11434/api/generate -d { model: deepseek-coder:6.7b, prompt: 用 Python 写一个快速排序, stream: false }这个 API 返回的是 JSON 格式解析起来很方便。如果你需要更高的并发性能可以换用 vLLM。vLLM 的部署方式略有不同需要先安装pip install vllm然后启动服务python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/deepseek-coder-6.7b-instruct \ --dtype auto \ --max-model-len 8192vLLM 默认兼容 OpenAI 的 API 格式所以如果你之前用过 OpenAI 的接口迁移成本很低。只需要把 base_url 改成你的本地地址就行。注意首次加载模型时vLLM 会下载权重文件如果网络不稳定建议提前手动下载好放到缓存目录。另外max-model-len 不要设置得太大否则会占用大量显存导致 OOM。3.4 量化让小显存也能跑大模型量化是本地部署大模型的关键技术。简单来说就是把模型权重从高精度浮点数如 FP16转换成低精度整数如 INT8、INT4从而大幅减少显存占用。代价是推理质量会有一定损失但在大多数场景下这种损失是可以接受的。我实测下来7B 模型用 FP16 需要约 14G 显存用 INT8 量化后降到约 7G用 INT4 量化后只要约 4G。这意味着如果你有一张 8G 显存的显卡跑 INT4 量化的 7B 模型完全没问题。13B 模型 FP16 需要约 26GINT4 量化后约 7G24G 显卡可以轻松跑起来。量化的方式有几种GPTQ、AWQ、GGUF 等。Ollama 默认使用的就是 GGUF 格式的量化模型你可以在拉取时指定量化版本比如deepseek-coder:6.7b-q4_0。vLLM 则支持 GPTQ 和 AWQ 量化需要在启动时指定量化参数。实操心得量化等级不是越低越好。我试过 INT4 量化的模型在简单对话上表现还行但在复杂推理任务上明显不如 INT8。所以如果你的任务对精度要求高建议至少用 INT8如果只是做简单分类或摘要INT4 也能凑合。4. API 调用与集成把 DeepSeek 接进你的系统4.1 官方 API 与本地 API 的区别DeepSeek 提供了官方 API 服务也支持本地部署后自己暴露 API。两者各有适用场景。官方 API 的好处是省去了部署和维护成本按量付费适合快速验证和低频调用。本地 API 的好处是数据不出内网适合对数据安全要求高的场景而且长期来看成本更低。官方 API 的调用方式兼容 OpenAI 格式所以如果你之前用过 OpenAI 的 SDK只需要改一下 base_url 和 api_key 就行。下面是一个 Python 示例from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlhttps://api.deepseek.com/v1 ) response client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个技术助手}, {role: user, content: 解释一下什么是注意力机制} ] ) print(response.choices[0].message.content)本地 API 的调用方式类似只需要把 base_url 改成http://localhost:11434/v1Ollama或http://localhost:8000/v1vLLMapi_key 随便填一个非空字符串即可。4.2 提示词工程让模型输出更符合预期提示词工程不是玄学它背后有明确的逻辑。模型是根据你输入的 token 序列来预测下一个 token 的所以你输入的每一个字都会影响输出。好的提示词应该包含几个要素明确的角色设定、清晰的任务描述、具体的输出格式要求、必要的上下文信息。举个例子如果你想让模型帮你写代码不要只说“写一个排序算法”而是说“你是一个 Python 专家请写一个快速排序函数要求1. 使用递归实现2. 包含类型注解3. 添加详细的注释4. 给出一个测试用例”。这样模型输出的代码质量会明显更高。我整理了一个提示词模板适用于大多数技术问答场景角色你是一个资深 [领域] 工程师 任务[具体任务描述] 要求 1. [要求1] 2. [要求2] 3. [要求3] 输出格式[JSON/Markdown/纯文本] 上下文[相关背景信息]注意提示词不是越长越好。过长的提示词会占用上下文窗口而且可能引入无关信息干扰模型判断。我一般建议把提示词控制在 500 字以内重点突出逻辑清晰。4.3 流式输出与并发处理在实际业务中流式输出和并发处理是两个绕不开的问题。流式输出可以让用户更快看到结果提升体验并发处理则决定了你的服务能同时服务多少用户。流式输出在 API 调用中通过streamTrue开启response client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: 写一首诗}], streamTrue ) for chunk in response: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end)并发处理方面vLLM 内置了连续批处理机制可以自动把多个请求合并成一个批次处理大幅提升吞吐量。如果你用的是 Ollama并发能力有限建议在前面加一层队列服务比如用 FastAPI 加 Redis 做请求排队。5. 微调实战让模型更懂你的业务5.1 什么时候需要微调微调不是万能的也不是所有场景都需要。我一般建议先尝试提示词工程和 RAG检索增强生成如果效果还是不理想再考虑微调。微调适合以下几种情况模型对特定领域的术语理解不准、输出格式总是达不到要求、需要模型模仿特定的说话风格、任务非常垂直且训练数据充足。微调的成本包括数据准备、算力消耗和调参时间。对于 7B 模型用 LoRA 微调一张 24G 显卡几个小时就能跑完一轮。对于 70B 模型可能需要多卡并行成本会高很多。所以我的建议是先从小的模型开始试验证效果后再考虑上大模型。5.2 数据准备微调成败的关键微调的效果很大程度上取决于数据质量而不是数据数量。我见过很多人收集了几万条数据但格式混乱、标注不一致结果微调出来的模型还不如原版。好的微调数据应该满足几个条件格式统一、标注准确、覆盖目标场景、难度分布合理。数据格式一般用 JSONL每行一条样本包含 instruction、input、output 三个字段{instruction: 将以下文本翻译成英文, input: 今天天气很好, output: The weather is nice today.} {instruction: 解释以下代码的功能, input: def add(a, b): return a b, output: 这个函数接收两个参数 a 和 b返回它们的和。}数据量方面对于简单任务几百到几千条就够对于复杂任务可能需要上万条。我一般建议至少准备 1000 条高质量数据然后通过交叉验证评估效果。5.3 LoRA 微调实操LoRALow-Rank Adaptation是目前最流行的微调方式因为它只需要训练少量参数显存占用低速度快。下面是一个基于 Hugging Face Transformers 和 PEFT 的微调示例from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model from datasets import load_dataset model_name deepseek-ai/deepseek-coder-6.7b-instruct tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, device_mapauto) lora_config LoraConfig( r8, lora_alpha32, target_modules[q_proj, v_proj], lora_dropout0.1, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) dataset load_dataset(json, data_filestrain.jsonl, splittrain) def tokenize_function(examples): return tokenizer(examples[instruction] examples[input], truncationTrue, max_length512) tokenized_dataset dataset.map(tokenize_function, batchedTrue) training_args TrainingArguments( output_dir./output, per_device_train_batch_size4, gradient_accumulation_steps4, num_train_epochs3, learning_rate2e-4, logging_steps10, save_steps100 ) trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_dataset ) trainer.train()这里有几个关键参数需要解释r是 LoRA 的秩越大表示可训练参数越多效果可能更好但显存占用也更高lora_alpha是缩放因子一般设为r的两倍target_modules指定要微调的层不同模型结构不同需要根据实际情况调整。实操心得微调时学习率不要设太大否则容易过拟合。我一般从 2e-4 开始试如果 loss 下降太慢就调大一点如果震荡严重就调小。另外训练数据一定要打乱顺序否则模型可能会学到错误的顺序模式。6. 常见问题与排查技巧实录6.1 部署与运行问题在实际操作中部署和运行阶段最容易出问题。我整理了一个常见问题速查表问题现象可能原因解决方法模型加载时报 OOM显存不足使用量化模型或减小 max-model-len推理速度极慢用了 CPU 推理或量化等级过低确认 GPU 是否被正确调用尝试更高精度的量化API 返回 404base_url 或端口配置错误检查服务是否启动端口是否被占用输出乱码tokenizer 不匹配确认使用的 tokenizer 与模型版本一致并发请求时崩溃显存溢出或线程安全问题降低并发数或换用 vLLM 等支持批处理的框架6.2 输出质量问题模型输出质量不达标是另一个高频问题。常见表现包括答非所问、格式混乱、重复输出、事实错误。针对这些问题我的排查思路是先检查提示词是否清晰明确很多时候问题出在输入而不是模型本身。确认模型版本是否适合当前任务比如用代码模型做文学创作效果肯定不好。调整温度参数。温度越高输出越随机温度越低输出越确定。对于需要准确性的任务建议把温度调到 0.1 到 0.3。如果以上都试过还是不行考虑微调或换更大的模型。6.3 性能优化技巧如果你已经跑通了基本流程想进一步提升性能可以尝试以下几个方向批处理把多个请求合并成一个批次充分利用 GPU 并行能力。vLLM 在这方面做得很好Ollama 则需要自己实现。KV Cache 优化大模型推理时KV Cache 会占用大量显存。可以通过 PagedAttention 等技术优化vLLM 默认就支持。模型蒸馏用大模型生成训练数据微调一个小模型在保持效果的同时降低推理成本。缓存机制对于重复的查询可以加一层缓存避免重复推理。注意性能优化不是一蹴而就的需要根据实际业务场景逐步调整。我一般建议先保证功能正确再考虑性能优化不要本末倒置。7. 企业私有化部署的几点思考企业私有化部署大模型跟个人本地部署完全是两回事。个人部署只要跑起来就行企业部署要考虑的问题多得多数据安全、并发能力、服务稳定性、成本控制、运维监控每一项都需要认真设计。数据安全方面模型权重和推理数据都不能出内网所以必须本地部署。同时要做好访问控制防止未授权调用。并发能力方面要根据业务量预估需要的 GPU 数量一般一张 24G 显卡跑 7B 模型能支撑几十个并发请求。服务稳定性方面要做好健康检查、自动重启、日志收集。成本控制方面要权衡模型规模和硬件投入不是越大越好。运维监控方面要监控 GPU 利用率、显存占用、请求延迟、错误率等指标。我参与过几个企业私有化部署项目最大的体会是技术选型只是第一步真正的挑战在于跟业务场景的磨合。模型再强如果跟业务流程脱节也发挥不出价值。所以我的建议是先找一个具体的、有价值的场景做试点跑通之后再逐步扩展。8. 学习路径与资源推荐如果你刚开始接触 DeepSeek 和大模型我建议按以下路径学习先跑通一个最简单的本地部署用 Ollama 拉一个 7B 模型体验一下基本对话和代码生成。学习提示词工程掌握如何通过输入控制输出。了解 API 调用方式尝试把模型接入自己的小工具或脚本。学习量化技术尝试在有限硬件上跑更大的模型。了解微调原理准备自己的数据集跑一次 LoRA 微调。学习推理框架的选型和优化尝试部署一个支持并发的服务。资源方面官方文档是最权威的起点技术报告能帮你理解模型的设计思路。社区里有很多实战分享但质量参差不齐建议优先看有代码、有数据、有复现步骤的内容。另外多动手比多看更重要很多问题只有自己踩过坑才能真正理解。我在实际使用中发现大模型这个东西入门容易精通难。刚开始觉得“不就是调个 API 吗”深入之后才发现涉及的知识面非常广从底层的注意力机制到推理框架的调度策略再到微调的数据工程每一个方向都够研究很久。但好消息是你不需要全部精通才能用起来。先跑通再优化逐步深入这是最务实的路径。