本文由莫潇羽@无忆研习社(www.wuyi.wiki)原创撰写，转载请注明出处。本文将从技术原理到实战部署，全面解析DeepSeek团队最新开源的DeepSeek-OCR2模型，帮助各位开发者和技术爱好者深入理解这一革命性的视觉语言模型。
写在前面的话
各位朋友好，我是无忆研习社的站长莫潇羽。就在前不久，DeepSeek团队再次给我们带来了一个重磅开源项目——DeepSeek-OCR2。作为一名长期关注AI技术发展的技术博主，我在第一时间对这个项目进行了深入研究和实际部署测试。今天，我将把我的研究心得和实践经验整理成这篇详细的技术解析文章，希望能帮助大家真正理解这个模型背后的技术原理，并能够顺利完成本地部署。
说实话，当我第一次看到DeepSeek-OCR2的技术报告时，我被其中提出的"因果流"（Causal Flow）概念深深吸引了。这不仅仅是一个OCR模型的简单升级，而是对视觉语言模型处理图像方式的一次根本性重新思考。在过去的几天里，我反复阅读了官方论文，并在自己的服务器上进行了多轮测试，现在我有信心向大家系统性地介绍这个技术。
在开始正文之前，我想先和大家分享一个有趣的观察：当我们人类阅读一份复杂的文档时，我们的眼睛并不是机械地从左上角扫到右下角的，而是会根据文档的结构和内容逻辑，自然而然地调整阅读顺序。比如，我们会先看标题了解主题，然后浏览小标题把握结构，接着才深入阅读正文内容。如果遇到表格，我们可能会按列或按行来阅读数据。这种灵活的阅读方式，正是DeepSeek-OCR2试图让AI学会的能力。
第一部分：为什么需要新的视觉编码方式
传统视觉语言模型的固有局限
在深入了解DeepSeek-OCR2之前，我们需要先理解当前主流视觉语言模型（Vision Language Model，简称VLM）存在的一个根本性问题。莫潇羽@无忆研习社在研究过程中发现，这个问题其实一直困扰着业界，只是很少有团队真正去解决它。
目前市面上的绝大多数VLM，在处理图像时都采用一种叫做"光栅扫描"（Raster-Scan）的方式。什么是光栅扫描呢？简单来说，就是按照固定的顺序——从左到右、从上到下——逐行扫描图像中的每一个像素块。这种方式非常直观，也很容易实现，因为它本质上就是把一张二维的图片"压扁"成一个一维的序列，然后喂给后续的语言模型进行处理。
但问题在于，图像中的信息并不是按照这种线性顺序组织的。举个最简单的例子：一份学术论文的页面，通常包含标题、作者信息、摘要、正文、脚注、参考文献等多个部分，还可能有图表、公式、分栏排版等复杂元素。当传统VLM用光栅扫描的方式处理这样一页内容时，它会把标题的第一个字和第二行某个正文的字连在一起，把表格的第一列和旁边的正文混在一起。这样产生的序列，完全丢失了文档原本的逻辑结构。
这种处理方式会导致几个严重的问题。首先是语义混乱，模型很难理解哪些内容是连续的、相关的，哪些内容虽然在空间上相邻但其实属于不同的语义单元。其次是阅读顺序错误，当我们需要把识别结果转换成文本时，输出的顺序往往是混乱的，需要大量的后处理工作来重新排列。最后是对复杂版面的处理能力差，遇到多栏排版、嵌套表格、图文混排等情况时，传统模型的表现往往会大幅下降。
人类视觉的启发
说到这里，莫潇羽@无忆研习社想和大家分享一些关于人类视觉系统的知识。人类的视觉处理其实是一个非常复杂的过程，远不是简单的"扫描"可以描述的。
当我们看一张图片或一页文档时，我们的眼睛会进行快速的扫视运动（saccade），在不同的区域之间跳跃。我们的视觉注意力会自然地被某些显著的元素所吸引，比如更大的字体、不同的颜色、特殊的形状等。在阅读文档时，我们会根据文档的视觉层次结构来组织我们的阅读顺序，先抓住大纲，再深入细节。这种处理方式的核心特点是：它是语义驱动的，而不是空间位置驱动的。
DeepSeek团队正是从这个角度出发，提出了"因果流"的概念。所谓因果流，就是让模型学会根据图像的语义内容来动态调整处理顺序，而不是死板地按照固定的空间位置来扫描。这是一个非常深刻的洞察，也是DeepSeek-OCR2最核心的创新点。
从DeepSeek-OCR到DeepSeek-OCR2的进化
在介绍DeepSeek-OCR2之前，我们有必要先回顾一下它的前身——DeepSeek-OCR。这个模型在2025年10月首次发布，当时就引起了业界的广泛关注。莫潇羽@无忆研习社当时也第一时间对其进行了测试和研究。
DeepSeek-OCR的核心创新是提出了"上下文光学压缩"（Contexts Optical Compression）的概念。简单来说，它尝试用视觉模态来压缩文本信息，从而大幅减少处理长文档时需要的token数量。这个思路本身就非常有创意——既然图像可以包含大量的文字信息，那么用少量的视觉token来表示这些文字，不就实现了一种高效的压缩吗？
DeepSeek-OCR的实验数据表明，在10倍压缩率下，模型仍能保持超过96%的OCR准确率。即使在20倍压缩率下，准确率也能维持在60%左右。这个结果证明了视觉压缩作为一种处理长文本的方式是可行的。
然而，DeepSeek-OCR虽然在压缩效率上取得了突破，但它仍然继承了传统VLM的光栅扫描方式。这意味着，对于复杂版面的文档，它仍然存在阅读顺序混乱的问题。
DeepSeek-OCR2的发布，正是为了解决这个核心问题。通过引入DeepEncoder V2架构和因果流机制，新模型在保持高压缩率的同时，显著提升了对复杂版面的处理能力，特别是在阅读顺序的准确性上取得了大幅进步。
第二部分：DeepEncoder V2架构深度解析
整体架构设计思想
DeepSeek-OCR2的核心创新集中在编码器部分，也就是DeepEncoder V2。莫潇羽@无忆研习社在仔细研读论文后，对这个架构的设计有了比较清晰的理解，下面我将尽量用通俗的语言向大家解释它的工作原理。
DeepEncoder V2继承了上一代DeepEncoder的整体框架——由编码器和解码器两部分组成。编码器负责把图像转换成一系列的视觉token，解码器则根据这些token和文本提示来生成最终的输出。但关键的区别在于，V2版本对编码器内部的结构进行了重大改造。
在DeepEncoder V1中，视觉编码的核心组件是CLIP（Contrastive Language-Image Pretraining）模型。CLIP是一个通过对比学习训练的视觉编码器，它能够把图像映射到与语言模型共享的语义空间中。这种设计在当时是非常先进的，也被许多其他VLM所采用。
但DeepSeek团队发现，CLIP虽然善于提取图像的全局语义特征，但它并不具备对视觉token进行"重新排序"的能力。换句话说，CLIP输出的token序列，其顺序仍然是由原始图像的空间位置决定的，而不是由语义内容决定的。
为了解决这个问题，DeepEncoder V2做了一个大胆的决定：用一个轻量级的大语言模型（LLM）来替换CLIP。具体来说，它使用了Qwen2-0.5B这个只有5亿参数的小型LLM。这个决定乍看之下有些反直觉——为什么要用语言模型来处理视觉信息？但仔细思考就会发现，LLM天生具备一种CLIP所不具备的能力：因果推理。
LLM是通过预测下一个token来训练的，这种训练方式使它学会了根据前面的内容来理解和生成后面的内容。当我们把这种能力迁移到视觉处理中时，模型就有可能学会根据图像的语义结构来重新组织视觉token的顺序。这就是"因果流"概念的技术基础。
视觉分词器的设计
DeepEncoder V2的第一个组成部分是视觉分词器（Vision Tokenizer）。这个组件的作用是把原始图像转换成初步的视觉token，供后续的LLM编码器进行处理。
视觉分词器沿用了上一代的基本设计，采用SAM-base模型加两层卷积的架构。SAM（Segment Anything Model）是Meta发布的一个通用分割模型，其中的视觉编码器部分具有很强的特征提取能力。DeepSeek选择使用SAM-base版本，这个版本的参数量约为8000万，在性能和效率之间取得了很好的平衡。
在视觉分词器的工作流程中，输入图像首先经过SAM-base的视觉编码器进行特征提取，得到高维的特征图。然后，这个特征图会经过两层卷积进行下采样和维度调整。在DeepEncoder V2中，最终卷积层的输出维度被设置为896，这与后续Qwen2-0.5B模型的隐藏层维度保持一致。
值得注意的是，DeepEncoder V2相比V1版本，将最终卷积层的输出维度从1024降低到了896。莫潇羽@无忆研习社分析认为，这个改动是为了与Qwen2模型的架构更好地匹配，减少不必要的维度转换开销。
经过视觉分词器处理后，一张高分辨率的图像会被转换成数百到数千个视觉token。这些token包含了图像中的局部细节信息，为后续的语义重排提供了原材料。
LLM风格编码器的工作机制
接下来是DeepEncoder V2最核心的创新部分——LLM风格的编码器。这个编码器使用Qwen2-0.5B作为基础架构，但在注意力机制的设计上做了非常精妙的改造。
传统的LLM（如GPT系列）使用的是纯粹的因果注意力（Causal Attention），也就是说，每个位置的token只能"看到"它前面的token，而看不到后面的token。这种设计是为了支持自回归生成——模型需要按顺序生成token，每生成一个token时只能依赖已经生成的内容。
但在视觉编码的场景中，这种纯粹的因果注意力可能不是最优的选择。因为图像中的信息是同时呈现的，左边的内容和右边的内容都是已知的，没有必要人为地限制模型只能看到"前面"的内容。
另一方面，常规的ViT（Vision Transformer）使用的是双向注意力（Bidirectional Attention），每个位置的token可以与所有其他位置的token进行交互。这种设计有利于全局建模，但它完全没有因果性，无法实现语义重排。
DeepEncoder V2的解决方案是引入一种"双流注意力"（Dual-Stream Attention）机制，巧妙地结合了上述两种注意力的优点。
具体来说，DeepEncoder V2的输入由两部分组成：一是来自视觉分词器的原始视觉token，二是一组可学习的"查询token"（Query Tokens）。这两部分的处理方式是不同的。对于原始视觉token，模型使用双向注意力来处理它们。这意味着每个视觉token都可以与所有其他视觉token进行信息交互，就像在ViT中一样。这保证了模型能够捕获图像的全局信息，理解不同区域之间的关系。
而对于查询token，模型使用因果注意力来处理。每个查询token只能"看到"它前面的查询token，以及所有的视觉token。这种设计使得查询token形成了一个有序的序列，第一个查询token基于全局视觉信息选择最应该"首先关注"的内容，第二个查询token在此基础上选择"接下来应该关注"的内容，以此类推。
这个设计的巧妙之处在于，它通过注意力掩码（Attention Mask）在一个统一的模型中实现了两种不同的处理模式。如果我们把注意力掩码可视化，会看到它由两个明显的区域组成：左侧是全连接的区域，对应视觉token之间的双向注意力；右侧是三角形的区域，对应查询token之间的因果注意力。这种设计非常优雅，既利用了LLM的因果推理能力，又保持了视觉建模所需要的全局感知能力。
因果流查询机制详解
理解了双流注意力的基本原理后，我们来更深入地探讨因果流查询机制的工作细节。莫潇羽@无忆研习社认为这是DeepSeek-OCR2最值得学习的技术创新点。
查询token是一组可学习的向量，它们在训练过程中会自动学习到"如何从视觉信息中提取和重组内容"的知识。你可以把它们想象成一群"阅读代理"，每个代理负责去图像中"挑选"一部分内容。
在推理时，第一个查询token会"审视"整张图像的视觉token，然后"决定"先关注哪个区域的内容。这个"决定"是通过注意力权重来体现的——查询token会给不同的视觉token分配不同的注意力权重，权重越高的视觉token代表该区域的内容越应该被优先处理。
第二个查询token在做"决定"时，不仅可以看到所有的视觉token，还可以看到第一个查询token已经"关注"了什么。基于这些信息，它会选择"接下来"应该关注的内容。这就是因果性的体现——后面的查询token的"决定"是基于前面查询token的"决定"来做出的。
通过这种机制，一系列的查询token共同完成了对图像内容的"语义重排"。最终输出的token序列，不再是按照空间位置排列的，而是按照语义逻辑排列的。比如，对于一个包含标题、正文、表格的文档页面，重排后的序列可能是：先是标题对应的token，然后是正文对应的token，最后是表格对应的token，即使在原始图像中表格可能位于页面中部。
这个过程可以类比为人类阅读时的信息整合过程。当我们阅读一个复杂文档时，虽然眼睛在页面上跳跃，但我们的大脑会把获取的信息按照逻辑顺序组织起来，形成连贯的理解。DeepEncoder V2通过因果流查询机制，让AI也具备了类似的能力。
两级级联的因果推理
DeepSeek-OCR2的因果推理实际上是两级级联的。第一级是在编码器中，通过因果流查询机制对视觉token进行语义重排；第二级是在解码器中，LLM基于重排后的视觉token进行自回归生成。
这种两级设计的优势在于，它把"理解图像结构"和"生成文本输出"这两个任务进行了解耦。编码器专注于理解图像的语义结构并进行信息重组，解码器专注于把重组后的信息转换成人类可读的文本。每个组件都可以针对自己的任务进行优化，而不会相互干扰。
值得一提的是，DeepSeek-OCR2的解码器并没有进行重大升级，仍然沿用上一代的DeepSeek-3B-MoE架构。这是一个参数规模约30亿的MoE（Mixture of Experts）模型，在推理时只激活约5亿参数。这个设计选择表明，DeepSeek团队认为编码器的改进是更关键的，而解码器已经足够强大。
莫潇羽@无忆研习社认为，这种"重编码轻解码"的设计思路是很有远见的。因为编码器的输出质量直接决定了解码器能够获得什么样的输入信息。如果编码器输出的token序列是混乱的，那么即使解码器再强大，也很难生成正确顺序的文本。反过来，如果编码器已经把信息整理得井井有条，那么解码器的任务就变得相对简单了。
第三部分：训练策略与数据工程
三阶段训练流程
DeepSeek-OCR2的训练采用了精心设计的三阶段流程，每个阶段都有明确的目标和策略。莫潇羽@无忆研习社认为，理解这个训练流程对于想要深入研究该模型或者尝试自己微调的开发者来说非常重要。
第一阶段是编码器预训练。在这个阶段，目标是让视觉分词器和LLM风格的编码器获得基础的特征提取、token压缩和token重排能力。训练方法遵循了DeepSeek-OCR和Vary等前人工作的经验，使用语言建模目标来训练。
具体来说，会把DeepEncoder V2与一个轻量级的解码器耦合在一起，通过预测下一个token的方式进行联合优化。训练使用了768×768和1024×1024两种分辨率的数据。视觉分词器的初始权重来自上一代DeepEncoder，而LLM风格编码器的初始权重来自Qwen2-0.5B-base。
这个阶段使用AdamW优化器，学习率采用余弦退火策略，从1e-4降至1e-6。训练在160台A100 GPU上进行，批大小为640，总共进行40k次迭代。采用8K长度的序列打包技术，约处理了1亿个图文对样本。预训练完成后，只保留编码器参数用于后续阶段。
第二阶段是查询增强。这个阶段的目标是进一步加强编码器的token重排能力，同时增强视觉知识的压缩。在这个阶段，会把预训练好的DeepEncoder V2与最终的解码器DeepSeek-3B-A500M整合成完整的流水线。
训练时会冻结视觉分词器（SAM-conv结构），联合优化LLM编码器和LLM解码器。这个阶段采用4阶段流水线并行策略：视觉分词器在PP0，LLM风格编码器在PP1，DeepSeek-LLM的12层分布在PP2-3。训练同样使用160台GPU，配置40个数据并行副本，全局批大小为1280，学习率在15k次迭代中从5e-5退火至1e-6。
第三阶段是解码器持续训练。为了更快地消耗训练数据，这个阶段会冻结DeepEncoder V2的所有参数，只更新DeepSeek-LLM的参数。这种做法有两个好处：一是在相同全局批大小下训练速度提升了一倍多，二是有助于LLM更好地理解DeepEncoder V2重排后的视觉token。
这三个阶段的设计体现了"渐进式训练"的思想。从基础能力的建立，到特定能力的增强，再到组件间协同的优化，每个阶段都建立在前一阶段的基础之上。这种训练策略在大规模模型训练中是很常见的，但能够设计得如此清晰和有效，还是需要深厚的工程经验。
数据来源与构建
数据是深度学习模型的命脉，DeepSeek-OCR2在数据方面延续了上一代的数据来源，同时引入了一些改进。莫潇羽@无忆研习社了解到，数据工程是DeepSeek团队投入大量精力的领域。
训练数据主要由三个部分组成。第一部分是OCR 1.0数据，这是基础的文字识别数据，包含大量的文档图像和对应的文字标注。第二部分是OCR 2.0数据，包含更复杂的图像解析任务，如图表、化学公式、平面几何等。第三部分是通用视觉数据，用于注入通用的图像理解能力。在混合训练数据中，OCR数据占比约80%，通用视觉数据占20%。
关于文档数据，DeepSeek团队从互联网收集了3000万页多样化的PDF数据，涵盖约100种语言。其中中文与英文约2500万页，其他语言约500万页。对于这些数据，团队构建了两类标注：粗标注和细标注。
粗标注使用fitz库直接从PDF中抽取文本，主要目的是教会模型识别光学文本，特别是小语种。细标注则更加精细，包含中文与英文各200万页，使用先进的版面模型（如PP-DocLayout）和OCR模型（如MinerU、GOT-OCR2.0）生成检测与识别交错的数据。
对于小语种的处理，团队采用了一个有趣的"模型飞轮"策略。首先利用版面模型的泛化能力进行检测，然后用fitz制作小块数据来训练一个GOT-OCR2.0模型，再用这个模型为更多的小块打标，最终生产了60万条小语种数据样本。
在训练时，通过不同的提示词来区分粗标注和细标注数据。这种设计允许模型在同一个训练过程中学习多种粒度的任务，从简单的文字识别到复杂的结构化解析。
第四部分：性能评测与对比分析
OmniDocBench基准测试结果
要评估一个OCR模型的实际能力，需要在标准的基准测试上进行系统性的评估。DeepSeek团队选择了OmniDocBench v1.5作为主要评测基准。莫潇羽@无忆研习社认为这是一个非常合理的选择，因为OmniDocBench是目前最全面的文档理解评测基准之一。
OmniDocBench v1.5包含1355页文档，覆盖中英文两种语言的9大主要类别，包括杂志、学术论文、研究报告等。评测指标包括整体准确率、各类别准确率、以及特别重要的阅读顺序（R-order）指标。
在使用最少视觉token上限（256-1120个）的情况下，DeepSeek-OCR2取得了91.09%的综合得分。与上一代DeepSeek-OCR基线模型相比，在采用相似训练数据来源的前提下，性能提升了3.73%。这个提升看起来可能不是特别惊人，但考虑到基线模型本身就已经是SOTA水平，这个提升是相当显著的。
更值得关注的是阅读顺序指标。在R-order的编辑距离（Edit Distance）指标上，DeepSeek-OCR2从前代的0.085显著降低到了0.057。编辑距离越低，说明模型输出的阅读顺序与真实顺序越接近。这个指标的大幅改善，直接验证了DeepEncoder V2的因果流机制在处理复杂版面时的有效性。
与闭源模型的对比
开源模型能否与闭源的商业模型竞争，一直是AI社区关注的话题。DeepSeek-OCR2在这方面给出了令人印象深刻的答案。
在与Gemini-3 Pro的对比中，两个模型都使用约1120个视觉token的情况下，DeepSeek-OCR2的文档解析编辑距离为0.100，而Gemini-3 Pro为0.115。这意味着在相同的计算预算下，开源的DeepSeek-OCR2在文档解析的准确性上超越了闭源的Gemini-3 Pro。
莫潇羽@无忆研习社认为，这个对比结果具有重要的意义。它说明通过精心的架构设计和训练策略，开源模型完全可以达到甚至超越闭源模型的水平。这对于那些出于数据安全或成本考虑而必须使用本地部署的企业来说，是一个非常好的消息。
当然，我们也应该客观地看到DeepSeek-OCR2的局限性。论文中提到，在文字密度极高的报纸版面上，DeepSeek-OCR2的识别效果不如在其他类型文档上表现好。这可能是因为报纸的分栏排版和小字体对模型提出了更高的要求。
实际生产环境中的表现
除了标准基准测试，DeepSeek团队还披露了模型在实际生产环境中的表现数据。这些数据对于评估模型的实用价值非常重要。
在处理在线用户日志图像时，OCR结果的重复率从上一代的6.25%降低到了4.17%。在PDF数据生产场景中，重复率从3.69%降低到了2.88%。重复率的降低意味着模型生成的文本更加干净、准确，这对于作为LLM训练数据的清洗流水线来说价值巨大。
另外一个重要的指标是处理速度。根据官方数据，使用单张A100-40G显卡，DeepSeek-OCR系列模型每日可处理超过20万页文档。这个处理能力对于需要大规模文档数字化的企业来说是完全够用的。
莫潇羽@无忆研习社在自己的测试中也验证了这一点。在配备RTX 4090的测试机上，处理一张1024×1024分辨率的文档图像，平均耗时约2-3秒。这个速度对于大多数应用场景来说都是可以接受的。
第五部分：本地部署完整指南
硬件环境要求
经过莫潇羽@无忆研习社的多次测试，我总结了DeepSeek-OCR2本地部署的硬件要求。
在GPU方面，推荐使用NVIDIA A100或者消费级的RTX 4090、RTX 4080等显卡。最低显存要求约7GB，但为了获得更好的性能和支持更高分辨率的输入，建议使用16GB以上显存的显卡。需要注意的是，最新的RTX 50系列显卡（如RTX 5090）由于PyTorch和vLLM对sm_120架构的支持尚不完善，暂时不推荐使用。
CPU方面没有特别严格的要求，主流的多核处理器都可以胜任。内存建议32GB以上，因为加载模型和处理大型文档时会消耗较多内存。存储方面，模型文件约需要10GB空间，建议使用SSD以加快模型加载速度。
操作系统方面，强烈建议使用Linux（推荐Ubuntu 22.04或24.04）。虽然Windows也可以运行基于Transformers的推理代码，但vLLM加速推理目前仅支持Linux。Mac用户可以使用MPS后端，但性能会有所下降。
环境配置步骤
下面我将详细介绍环境配置的具体步骤。这部分内容是莫潇羽@无忆研习社亲自验证过的，按照这些步骤操作应该可以顺利完成部署。
首先需要确保CUDA环境正确安装。DeepSeek-OCR2官方推荐使用CUDA 11.8版本。可以通过以下命令检查CUDA版本：
nvcc --version如果没有安装CUDA或版本不匹配，需要从NVIDIA官网下载对应版本进行安装。
接下来创建Python虚拟环境。推荐使用conda进行环境管理：
conda create -n deepseek-ocr2 python=3.12 -y
conda activate deepseek-ocr2然后安装PyTorch。必须安装与CUDA版本匹配的PyTorch版本：
pip install torch==2.6.0 torchvision==0.21.0 torchaudio==2.6.0 --index-url https://download.pytorch.org/whl/cu118克隆项目代码仓库：
git clone https://github.com/deepseek-ai/DeepSeek-OCR-2.git
cd DeepSeek-OCR-2安装项目依赖：
pip install -r requirements.txt安装Flash Attention加速组件，这对于提升推理速度非常重要：
pip install flash-attn==2.7.3 --no-build-isolation如果需要使用vLLM进行高性能推理（仅Linux），还需要安装vLLM。由于版本兼容性问题，需要安装特定版本的预编译包。可以从官方GitHub仓库下载对应的whl文件：
pip install vllm-0.8.5+cu118-cp38-abi3-manylinux1_x86_64.whl安装过程中如果出现关于transformers版本的依赖冲突警告，可以忽略，不会影响实际运行。
模型下载方式
模型权重可以从Hugging Face或魔搭社区（ModelScope）下载。以下是两种下载方式的详细说明。
从Hugging Face下载。如果网络环境允许直接访问Hugging Face，可以在代码中直接指定模型名称，首次运行时会自动下载：
model_name = 'deepseek-ai/DeepSeek-OCR-2'也可以使用huggingface-cli手动下载到本地：
pip install huggingface_hub
huggingface-cli download deepseek-ai/DeepSeek-OCR-2 --local-dir ./deepseek-ocr2从魔搭社区下载。对于国内用户，使用ModelScope可能会有更好的下载速度：
pip install modelscope
modelscope download --model deepseek-ai/DeepSeek-OCR-2 --local_dir ./deepseek-ocr2模型文件总大小约10GB，请确保有足够的磁盘空间和耐心等待下载完成。
基础推理代码示例
完成环境配置和模型下载后，就可以运行推理代码了。下面是使用Transformers库进行推理的完整示例，莫潇羽@无忆研习社已经测试验证过这段代码。
from transformers import AutoModel, AutoTokenizer
import torch
import os
# 设置使用的GPU
os.environ["CUDA_VISIBLE_DEVICES"] = '0'
# 模型路径，可以是Hugging Face模型名或本地路径
model
