深入理解 DeepSeek 与企业实践（一）：蒸馏、部署与评测

• 推理模型的定义，是指 AI 领域能模拟人类逻辑思维与推理的模型，如 Deepseek - R1。它基于深度学习架构，融合多领域技术，经大量数据训练构建知识表征，运用强化学习在 “尝试 - 反馈” 中优化策略，在处理复杂问题时 主动探索、逻辑推导。

• 非推理模型如 DeepSeek - V3，是大语言稠密模型，更多基于已学习到的语言模式和统计规律处理任务。

从 Deepseek 模型的发展可以看出，R1 并非由某一种或两种训练方法堆积而成，而是从 V1 开始，经由多个版本的模型互相构建、融合多种训练方法、逐步进化而来的推理模型。更值得称赞的是，DeepSeek-R1 秉持着开源精神，免费开放给全球开发者使用，让更多的研究人员、企业可以更低门槛使用先进的模型，推动了全球AI技术发展，被图灵奖得主、Facebook 首席人工智能科学家杨立昆称赞为 “开源战胜闭源”。

（3）什么是模型蒸馏

因为Deepseek-R1的参数量非常大，部署要求非常高，为了在小参数模型中引入长思维链推理能力，DeepSeek 团队引入了蒸馏技术。模型蒸馏就像是一场知识的传承，我们以 Deepseek-R1-Distill-Qwen2.5-7B 为例简单阐述蒸馏过程。

1. 选择对象：首先选择一名优秀的学生Qwen，打算对它进行推理增强训练。强大的 R1会作为 “老师模型”，有着丰富的知识储备和卓越的推理能力。

2. 准备工作：在蒸馏过程开启时，需准备大量训练数据，这些数据是模型学习的基础，随后将教师模型 R1 与学生模型 Qwen 同时置于训练环境中。

3. 训练过程：教师模型 R1 对输入数据进行处理并生成输出，其输出包含了模型对数据特征的提取与理解。学生模型 Qwen 在学习原始数据的同时，会通过损失函数计算自身输出与教师模型输出的差异，就像学生模仿老师解题思路一样，不断调整自身参数以最小化这种差异。例如在分类任务中，教师模型输出各类别的概率分布，学生模型则努力模仿该分布，从而学习到教师模型的知识与推理模式。经过多轮迭代训练，学生模型 Qwen 的推理能力得到显著提升，最终生成有推理能力的 Qwen 模型。

   
   

模型蒸馏具有多方面优势。从成本与效率角度看，小型模型经蒸馏后可具备接近大型模型的性能，降低企业部署成本，提高推理速度，减少对大规模计算资源的依赖，但它的本质上仍然是 Qwen 或 Llama，因此需要对模型进行仔细的理解和评测，才能满足实际的业务需求。

在追求模型高效运行的道路上，还有一项关键技术同样致力于此，那就是“量化”。

二、量化技术概述：平衡性能与效率

根据前文我们已经知道真正的 DeepSeek-R1 为 671B 参数的版本（网上也被称为“满血版”），很多网上教程的版本教大家通过 ollama run deepseek-r1  下载的其实是一个经过蒸馏加微调训练出来的 Qwen2.5 7B， 所以这个模型的“智力”和我们在 DeepSeek 官网上对话的模型会相差甚大，再仔细观察会发现这个模型只有 4.7GB，也就是说这是一个经过较大力度量化的模型，这对模型的“智力”无疑会进一步雪上加霜。

（2）什么是量化？

量化是指将模型中的权重和激活值从高精度（如 FP32、BF16）转换为低精度（如 INT8 或 INT4 等）表示的方法。通过减少每个参数占用的位宽，可以显著降低模型的存储和计算需求。

量化模型可以大幅减少显存占用和计算量，使得在普通 GPU 甚至 CPU 上部署大型模型成为可能。然而，过度的量化可能导致模型精度的下降，特别是在处理需要精确计算和推理的任务时。

（3）为何推荐 BF16 和 INT8？

对于 Reasoning 模型，由于输出的 Token 序列较长，且对精度要求较高，通常推荐使用 FP16 或 INT8 量化方式。这些量化方法在显著降低计算资源需求的同时，能够较好地保持模型的性能。

（4）量化程度与精度损失的关系

需要注意的是，在新的量化工具（例如 Llama.cpp）中，对于量化做了非常精细的处理， 例如对部分层做不同精度（4 位、6 位、32 位）的量化，因此还会衍生出 Q4_K_M、Q6 等各种量化，但本质上依然是精度、速度、资源占用之间的平衡。

（5）在 DeepSeek 模型中的应用

由于 DeepSeek 原始模型尺寸巨大，即使在 Int4 下，显存需求依然非常高，MoE 架构、推理模型对量化也带来了许多新的挑战。为此，可以尝试使用 1.58、2.51  混合量化、动态量化等更高级的量化方法，具体效果以及上下文的量化我们会在后面的文章中进行阐述。

但在对模型进行量化后，我们有时会发现显存还是不够，或者模型跑起来之后输出内容会被截断，这就涉及到大模型的另一个重要参数——“上下文窗口”。

三、上下文窗口的重要性与显存估算

在上面的视频中，模型还没有思考完成，但是后续就不再继续输出了，这是因为模型回答已经达到了其“最长输出”的上限。对于 DeepSeek 的官方 API 来说，最大思维链长度为 32K，最大输出为 8K，就其原始模型来说，最大可以提供约 164K 的上下文，也就是大约能理解和输出总和差不多 10~16 万字。但在提供超长上下文的背后其实是大量的资源消耗，因此一些 API 可能不会开放最大的输出和上下文能力。对于以往的大部分非推理模型来说，可能 4K 的上下文足以满足单次对话的需求，但是对于推理模型来说，由于“思考”需要占用上下文，因此 4K 上下文可能连单次会话都不够用，对于用户使用产生明显的困扰。

（2）什么是模型的上下文窗口？

上下文窗口指模型在一次推理过程中能够处理的最大 Token 数量，平均一个 Token 能对应多少汉字对于不同的模型略有区别。上下文长度越长，模型能够记忆和理解的文本信息就越多，这对于长文本生成和复杂任务处理尤为重要，特别是较大规模的代码生成、专业内容的理解分析等。

上下文长度对模型效果的影响

• 上下文不足的影响： 模型可能无法记住对话的早期内容，导致回答前后不一致或被截断。

• 推理模型的需求： 由于需要在回答中展示推理过程，输出的 Token 数量较多，更长的上下文能够提升模型的表现。

  
  

（3）显存大小如何估算

模型的显存占用主要由以下部分组成：

(4)DeepSeek 相关各类模型规模和量化方式下的显存需求概览

四、在 ZStack AIOS 平台

部署 DeepSeek-R1-Distill-Qwen-7B

（1）硬件环境

• GPU 类型： NVIDIA GPU，显存 24GB * 2，35.58 TFLOPS@BF16

• CPU： 采用 VM 部署，CPU 分配 8vCPU

• 内存： 采用 VM 部署，内存分配 32GB RAM

• 操作系统： 采用 ZStack AIOS 内置模板，Helix8.4r 系统

  
  

（2）部署步骤

1. 使用 ZStack AIOS 选择模型并进行加载

2. 指定运行该模型的GPU规格和计算规格后即可部署

1. 在体验对话框中可以尝试对话体验或者通过 API 接入到其他应用

（3）性能指标

• 显存占用： 部署后显存占用约为 41.6 GB，符合预期（推理代码会分配大约95%的显存用于推理服务）

实际性能可能因硬件配置和模型优化程度而有所不同。

五、模型能力评测：

DeepSeek-R1-Distill-Qwen-7B

（1）MMLU 得分对比

MMLU（Massive Multitask Language Understanding）是衡量模型多任务理解能力的权威基准。我们对比了蒸馏前后的 7B 模型在 MMLU 上的表现。

• 数字谜题：蒸馏模型能够正确解答复杂的数字规律题，而原始模型表现较为逊色。

  考虑以下数列：
  2, 3, 5, 9, 17, 33, 65, ...
  这个数列遵循一个特定的模式。请回答以下问题：
  数列的下一个数是多少？

• 比较大小：在涉及多重条件的大小比较问题上，蒸馏模型给出了正确的推理过程和答案。

  在一个班级里，有四个学生：安娜、贝蒂、查理和大卫。已知以下信息：
  安娜比贝蒂高。
  查理不是最高的，也不是最矮的。
  大卫比查理矮。
  贝蒂不是最矮的。
  请回答以下问题：
  谁是最高的？

• 推理题目：蒸馏模型能够清晰地展示推理步骤，可以检查推理过程是否异常，结果上都符合预期。

  前提：
  1．有五栋五种颜色的房子
  2．每一位房子的主人国籍都不同
  3．这五个人每人只喝一种饮料，只抽一种牌子的香烟，只养一种宠物
  4．没有人有相同的宠物，抽相同牌子的香烟，喝相同的饮料
  
  提示：
  1．英国人住在红房子里
  2．瑞典人养了一条狗
  3．丹麦人喝茶
  4．绿房子在白房子左边5．绿房子主人喝咖啡
  6．抽 PALL MALL 烟的人养了一只鸟
  7．黄房子主人抽 DUNHILL 烟
  8．住在中间那间房子的人喝牛奶
  9．挪威人住第一间房子
  10．抽混合烟的人住在养猫人的旁边
  11．养马人住在抽 DUNHILL 烟的人旁边
  12．抽 BLUE MASTER 烟的人喝啤酒
  13．德国人抽 PRINCE 烟
  14．挪威人住在蓝房子旁边
  15．抽混合烟的人的邻居喝矿泉水
  问题是：谁养鱼？

  
  

（3）代码与 SQL 生成

• 代码生成：蒸馏模型在生成 Python代码时，语法正确率和逻辑正确率都有提升。

  实现一个Python类 `DataStream`，用于处理实时数据流。这个类需要支持以下功能：
  1. 初始化时接受一个整数 `k`，表示我们只关心最近 `k` 个元素。
  2. 方法 `add(value)`：添加一个新的值到数据流中。
  3. 方法 `getMedian()`：返回最近 `k` 个元素的中位数。如果 `k` 是偶数，返回两个中间数的平均值。
  4. 所有操作的时间复杂度应该为 O(log k) 或更优。
  
  要求：
  1. 实现 `DataStream` 类的构造函数和上述两个方法。
  2. 使用适当的数据结构来实现高效的插入和中位数计算。
  3. 处理边界情况，如当前元素数量少于 `k` 的情况。4. 提供简短的注释解释您的实现思路。
  
  示例用法：
  ```python
  stream = DataStream(3)
  stream.add(1)
  stream.add(2)
  print(stream.getMedian())  # 输出：1.5
  stream.add(3)
  print(stream.getMedian())  # 输出：2
  stream.add(4)
  print(stream.getMedian())  # 输出：3

• SQL 生成：在根据自然语言描述生成 SQL 查询时，蒸馏模型生成的 SQL 更加准确，可直接用于数据库查询。

  背景：
  数据库中有以下相关表：
  1. ModelVO表：
     - uuid (主键), name, description, modelCenterUuid, size, createDate 等字段
     - size 字段单位为字节(Byte)
     - createDate 为模型创建的时间戳
  2. ModelCenterVO表：
     - uuid (主键), name, description 等字段
  3. ModelServiceVO表：
     - uuid (主键), name, description, createDate 等字段
     - createDate 为模型服务创建的时间戳
  问题1：请编写一个SQL查询，统计每个模型中心（ModelCenter）在过去30天内创建的模型（Model）的总大小（size之和）。结果应包含模型中心的名称、创建的模型数量和总大小（以GB为单位，保留两位小数），并按总大小降序排列。只显示总大小超过1GB的结果。
  
  问题2:请编写一个SQL查询，计算每周新增的模型服务（ModelService）数量。结果应该显示每周的开始日期（周一）、该周新增的模型服务数量，以及到该周为止的累计模型服务总数。查询结果应该按周开始日期升序排序，并且只显示最近12周的数据。
  
  这两个问题现在包含了必要的表结构信息，可以更好地测试SQL生成模型的能力。它们要求正确处理日期函数、聚合函数、单位转换，以及可能需要使用子查询或窗口函数。这样的查询可以有效验证模型生成的SQL是否准确且可直接用于数据库查询。

  
  

（4）RAG（Retrieval-Augmented Generation）场景测试

为了测试蒸馏模型和原模型相比在 RAG 知识库场景上是否会有提高，我们尝试了将 DeepSeek V3、DeepSeek R1 两篇技术报告（分别为22页 8802 词、53页 22330 词）导入到 AIOS 平台的 Dify 知识库中，之所以选这两篇文章是因为这两篇文章是没有被收入到模型的预训练参数中的，模型需要通过对文章进行理解来回答，无法凭借自身知识进行回答，此外为了模拟用户直接体验的效果，没有对 Dify 的默认 system prompt 进行优化，所有模型上下文设置为 8K，没有额外设置温度、Top K 等参数。每次用户问题提问数次，人工评价答案取平均值。

得益于 ZStack AIOS 智塔的专有环境和性能调优，文档的向量化、模型回答都会非常快。以下是知识库处理的效果：

和知识库对话的效果也很迅速：

此时的后台监控记录：

我们从不同维度测试了RAG场景下、7B模型蒸馏前后的回答表现：

• 结论：从我们的测试结果上看，7B 蒸馏模型的输出结构性上大部分情况下优于原模型，往往会分点阐述结论，在回答对事实的依照程度上差不太多，无论是蒸馏模型还是原模型在大部分情况下都能较好的依照事实（召回上下文）回答，当然这也可能与我们采取的数据有关，在其他数据上可能会产生不同的结论。在回答长度上，蒸馏模型回答长度会增加大约 20%， 这个增加幅度是略低于预期的，可能是因为两个模型都采用了 8K 的上下文，这对推理模型来说有些不太够用，在回答时间上，蒸馏模型回答时间会增加约 70%，相对来说成本是比较高的。

六、蒸馏版 7B 模型的适用场景与优势

• 资源受限环境：可在普通 GPU，甚至 CPU 上运行，部署成本低。

• 实时交互应用：推理速度快，响应时间短，适用于聊天机器人等场景。

• 需要一定推理能力的任务：相比原始模型，蒸馏模型在逻辑推理、代码生成等任务上有明显提升。

  
  

（2）优点 

• 成本低： 相对全参数版本，部署和运行成本降低。

• 速度快： 推理速度较快，满足实时性要求。

• 部署灵活： 支持量化版本，可在多种硬件平台上运行。

  
  

（3）限制 

• 性能提升有限： 相比大型模型，在某些复杂任务上能力仍有不足。

• 不完全适合 RAG： 从 MMLU 得分我们可以发现，蒸馏后的推理模型在事实性问题得分反而下降，在 RAG 测试中也一定程度上复现了这一问题，模型有时可能会过度推理导致偏离了事实，此外由于响应时间的增加，蒸馏版 7B 模型可能不完全适合 RAG 场景。

七. 展望：更大参数模型的部署策略

• 更大参数的蒸馏模型： 如 DeepSeek-R1-Distill-Qwen-32B 的部署和应用效果。

• DeepSeek 原始模型的量化部署： 如何在有限资源下部署如 671B 规模的模型。

• 全精度部署策略： 在高性能计算环境下，如何充分发挥大型模型的能力。

通过对比不同规模和精度的模型，我们希望为企业级应用提供更加全面和细致的部署方案，帮助更多行业快速落地大语言模型技术，实现商业价值。

结语

本文从 DeepSeek 模型的演进出发，探讨了蒸馏和量化在模型部署中的重要作用。通过具体的数据和测试结果，我们看到了蒸馏版 7B 模型在推理能力和部署成本之间取得的良好平衡。希望本篇文章能为您在大语言模型的企业级应用中提供有益的参考。