本地部署：如何本地化部署开源大模型ChatGLM3-6B

于 2025-03-14 15:34:06 发布
阅读量1.1k 收藏 20
点赞数 12
文章标签： 开源
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_33240556/article/details/146258861
版权

你好，我是程序员贵哥（抖音号：1717983460）。

前面听我讲了这么多，相信你也很想上手试一试了。从这节课开始，我们进入一个新的章节，这部分我们会学习如何部署开源大模型ChatGLM3-6B，本地搭建向量库并结合LangChain做检索增强（RAG），并且我会带你做一次微调，从头学习大模型的部署、微调、推理等过程。

这节课我们就来讲一下如何本地化部署ChatGLM3-6B（后面我们简称为6B）。讲6B之前我们先整体看一下目前国内外大模型的发展状况，以便我们进行技术选型。

大模型的选择

当前环境下，大模型百花齐放。我筛选出了一些核心玩家，你可以看一下表格。非核心的其实还有很多，这里我就不一一列举了。厂商虽然很多，但真正在研究技术的没多少，毕竟前面我们讲过，玩大模型投入非常大，光看得见的成本，包括人才、训练和硬件费用，一年就得投入几个亿，不是一般玩家能玩得起的。

图片

当然，也有不少厂商是基于LLaMA爆改的，或者叫套壳，不是真正意义上的自研大模型。

ChatGLM-6B和LLaMA2是目前开源项目比较热的两个，早在2023年年初，国内刚兴起大模型热潮时，智谱AI就开源了ChatGLM-6B，当然130B也可以拿过来跑，只不过模型太大，需要比较多的显卡，所以很多人就部署6B试玩。

从长远看，信创大潮下，国产大模型肯定是首选，企业布局AI大模型，要么选择MaaS服务，调用大厂大模型API，要么选择开源大模型，自己微调、部署，为上层应用提供服务。使用MaaS服务会面临数据安全问题，所以一般企业会选择私有化部署+公有云MaaS混合的方式来架构。在国产厂商里面，光从技术角度讲，我认为智谱AI是国内大模型研发水平最高的厂商，这也是我选择ChatGLM-6B的原因。

还有一点需要考虑，就是6B参数规模为62亿，单张3090显卡就可以进行微调（P-Turing）和推理，对于中小企业而言，简直就是福音。

图片

当然，如果企业预算充足（百万以上），可以尝试6B的老大哥GLM-130B，简称130B，千亿参数规模，推理能力更强，使用130B的话除了GPU资源费用，还需要进行商业授权，这个要注意。

图片

下面我们讲讲预算不足的情况下，怎么搞定显卡资源？

如何搞定显卡资源？

玩儿大模型第一步就是要想办法解决计算资源问题，要么CPU要么GPU，当然还有TPU，不过TPU太小众，这里我就不介绍了。我建议你想办法申请GPU，因为适合CPU计算的大模型不多，有些大模型可以在CPU上进行推理，但是需要使用低精度轻量化模型，而低精度下模型会失真，效果肯定不行，只适合简单把玩。如果要真正体验并应用到实际项目，必须上GPU。那我们可以从哪些渠道去购买GPU呢？

  1. 购买二手显卡：无论是个人使用还是企业使用，都可以考虑在网上购买二手RTX3090显卡，单卡24G显存，8000块左右，可以用于本地微调、推理。如果想用在产品上，也可以通过云服务做映射，提供简单的推理服务，但是不适合为大规模客户提供服务。
  2. 淘宝租赁显卡资源：适合个人学习使用，可以按天/周/月/年购买服务，比较灵活，成本也不高。
  3. 在线GPU租赁：比如autodl、RTX3090-24G，每月大概不到900块钱，也很划算。不仅仅可以用来本地测试，还可以用于生产环境推理，如果用在生产环境的话，最好按照实际推理需求，评估每秒推理量（具体方法我会在大模型应用架构部分讲解），搭建高可用推理环境。
  4. 各个平台免费资源：比如阿里云PAI平台、智谱AI的开放平台等，对于新人都有一定的免费GPU额度，这个方式省钱，但是不推荐，因为有时需要为平台推广拉人，也挺耗时间的。

ChatGLM3-6B部署

ChatGLM-6B目前已经发展到第3代ChatGLM3-6B，除了中英文推理，还增强了数学、代码等推理能力，我记得一年前的6B在代码或者数学方面是比较弱的。根据目前的官方信息，在语义、数学、推理、代码、知识等不同角度的数据集上测评显示，ChatGLM3-6B-Base在10B以下的基础模型中性能是最强的，除此之外，还具有8K、32K、128K等多个长文理解能力版本。下面我们就一步一步来安装部署ChatGLM3-6B，你也可以在官方文档里找到安装教程。

准备环境

操作系统推荐Linux环境，如Ubuntu或者CentOS。

图片

  • Python推荐3.10～3.11版本。
  • Transformers库推荐4.36.2版本。
  • Torch 推荐使用 2.0 及以上的版本，以获得最佳的推理性能。
克隆代码
git clone https://github.com/THUDM/ChatGLM3

图片

安装依赖

注意：要切换成国内pip源，比如阿里云，下载会快很多。

pip config set global.index-url https://mirrors.aliyun.com/pypi/simple/
cd ChatGLM3
pip install -r requirements.txt

显示以下内容表明依赖安装成功。

图片

下载模型
git clone https://huggingface.co/THUDM/chatglm3-6b

如果Huggingface下载比较慢的话，也可以选择ModelScope进行下载。下载完将chatglm3-6b文件夹重新命名成model并放在ChatGLM3文件夹下，这一步非必需，只要放在一个路径下，在下一步提示的文件里，指定好模型文件路径即可。

命令行模式启动

打开文件 basic_demo/cli_demo.py，修改模型加载路径。

MODEL_PATH = os.environ.get('MODEL_PATH', '../model')

执行 python cli_demo.py。
图片

Web控制台模式启动

打开文件 basic_demo/web_demo_gradio.py，修改模型加载路径。

MODEL_PATH = os.environ.get('MODEL_PATH', '../model')

同时修改最后一行：

demo.launch(server_name="127.0.0.1", server_port=7870, inbrowser=True, share=False)

server_name修改为本地IP，并指定端口server_port即可。也可以设置share=True，使用gradio提供的链接进行访问。

执行 python web_demo_gradio.py。

图片

默认情况下，模型以FP16精度加载，大概需要13GB显存。如果你的电脑没有GPU，只能通过CPU启动，6B也是支持的，需要大概32G的内存。我们修改一下模型加载脚本。

model = AutoModel.from_pretrained(MODEL_PATH trust_remote_code=True).float()

如果你的电脑有GPU，但是显存不够，也可以通过修改模型加载脚本，在4-bit量化下运行，只需要6GB左右的显存就可以进行流程推理。

model = AutoModel.from_pretrained(MODEL_PATH, trust_remote_code=True, ).quantize(4).cuda()

同时，官方也提供了一个全新的web demo，支持Chat、Tool、Code Interpreter，就在我们克隆下来的代码里，在文件夹composite_demo下。

cd composite_demo
pip install -r requirements.txt
export MODEL_PATH=../model
streamlit run main.py 或者 python -m streamlit run main.py

页面确实上了一个档次。

图片

接下来我简单总结一下部署过程：

  1. 安装Python环境，包含pip；
  2. 下载代码；
  3. 下载模型；
  4. 安装依赖；
  5. 修改示例代码，指定模型路径、精度等参数；
  6. 命令行启动。

整体来说，如果Python版本在3.10～3.11之间，网络环境也没问题的话，安装还是很快的，如果有GPU的话，推理效果也是很好的。在我们部署好模型之后，就可以进行推理了。推理之前，6B有几个参数可以进行设置，就是超参数，用来控制模型的推理准确度，我们知道大模型推理每次给的回答可能都和之前不一样，这也是为什么大模型不能用来处理精确度要求很高的任务的原因，比如让大模型算个税、算工资等等。

超参数介绍

ChatGLM3-6B有3个参数可以设置。

  1. max_length：模型的总token限制，包括输入和输出的tokens。
  2. temperature：模型的温度。温度只是调整单词的概率分布。它最终的宏观效果是，在较低的温度下，我们的模型更具确定性，而在较高的温度下，则不那么确定。数字越小，给出的答案越精确。
  3. top_p：模型采样策略参数。每一步只从累积概率超过某个阈值 p 的最小单词集合中进行随机采样，而不考虑其他低概率的词。只关注概率分布的核心部分，忽略了尾部。

对于以下场景，官方推荐使用这样的参数进行设置：

图片

系统设置好，我们基本就可以开始进行问答了，ChatGLM3-6B采用了一种新的Prompt格式，看上去应该是模仿的ChatGPT。下面我们介绍下这种提问格式。

新的Prompt格式

新的提示格式，主要是增加了几个角色，在对话场景中，有且仅有以下三种角色。

  • system：系统信息，出现在消息的最前面，可以指定回答问题的角色。
  • user：我们提的问题。
  • assistant：大模型给出的回复。

在代码场景中，有且仅有user、assistant、system、observation四种角色。observation是外部返回的结果，比如调用外部API，代码执行逻辑等返回的结果，都通过observation返回。observation必须放在assistant之后。

下面这个是官方提供的例子，基本把以上4种角色都解释清楚了。

<|system|>
Answer the following questions as best as you can. You have access to the following tools:
[
    {
        "name": "get_current_weather",
        "description": "Get the current weather in a given location",
        "parameters": {
            "type": "object",
            "properties": {
                "location": {
                    "type": "string",
                    "description": "The city and state, e.g. San Francisco, CA",
                },
                "unit": {"type": "string"},
            },
            "required": ["location"],
        },
    }
]
<|user|>
今天北京的天气怎么样？
<|assistant|>
好的，让我们来查看今天的天气
<|assistant|>get_current_weather


```python
tool_call(location="beijing", unit="celsius")

<|observation|>
{"temperature": 22}
<|assistant|>
根据查询结果，今天北京的气温为 22 摄氏度。

为什么会这么设计呢？

首先，当前阶段的大模型经过训练后，都可以遵守系统消息，而系统消息不算用户对话的一部分，与用户是隔离的，但是可以控制模型与用户交互的范围，比如我们在system角色里指定模型充当Java技术专家，那么就可以指导模型的输出偏向于Java技术范围。

还有一个原因就是防止用户进行输入注入攻击。在进行多轮对话的时候，每次新的对话都会把历史对话都带进去。如果我们在前面的对话中，告诉模型错误的提示，那么这些错误的提示会在后续的对话中被当作正确的上下文带进去。我们知道基于自回归的模型，会根据上下文进行内容推理，这样就可能生成错误的内容。角色可以使内容更加容易区分，增加注入攻击的复杂度。这种方式不一定能处理所有的攻击类型，类似于我们日常开发中的XSS注入，只能尽可能减少，完全避免有点难。

小结

这节课我们学习了如何部署6B。从模型的选择到环境配置再到模型启动、推理，整体来说已经比较全面了，如果你在实际操作的过程中遇到环境问题，可以自己Google一下尝试去解决。毕竟每个人的环境不一样，可能会遇到各种各样的问题，主要还是Python相关的多一些。如果这一节课有些内容你没有看懂也不用急，先把模型部署及推理这一块熟悉一下，后面我们会逐渐深入地讲解。

图片

博客
为什么世界和你的理解不一样？
05-15 351
你好，我是程序员贵哥。如果看到沟通反馈几个字，你就以为我打算在这里教一些谈话技巧，那你还真的想错了。在这个模块里，我打算与你讨论的主题是，生活在真实世界中。沟通反馈和生活在真实世界这两个话题是怎么联系到一起的呢？请听我慢慢道来。《大富翁》里的沙隆巴斯有句口头禅：人生不如意的事，十有八九！但是不知道你有没有想过这样的一个问题，为什么人生如此不如意？如果这是一篇鸡汤文，我应该告诉你世事艰辛。为什么会这样？欢迎来到真实世界，真实世界不是以美好愿望驱动的，它有着自己的运行规律。
博客
如何用最小的代价做产品？
05-15 462
产品同样需要分解，目前在探索产品的不确定性上的最佳实践是精益创业，而精益创业就包含了将庞大的产品分而治之的方式：最小可行产品（Minimum Viable Product，MVP）。最小可行产品就是“刚刚好”满足客户需求的产品。**想要在实践中运用好最小可行产品的理念，就是要用最小的代价找到一条可行的路径。**最小的代价就是能不做的事就不做，能简化的事情就简化。程序员通常愿意用自己的代码解决问题，而写代码通常是代价非常高的解决方案，它应该成为最后的产品解决方案。
博客
需求管理：太多人给你安排任务，怎么办？
05-15 338
比如，我们放任系统不做升级改造，过多的技术债会让系统的问题越来越多，新需求实现的速度越来越慢，最后几个看起来不大的需求就足以让团队加班加点，天怒人怨。把这个思路带回到我们现实的需求管理中，你会发现，其实团队面临的各种需求所采用的优先级排序方式，基本上都是按照紧急程度排列的，但它们是否真的重要呢？如果你把这个问题抛给需求的提出者，我几乎可以肯定，他们给你的答案是，他们提出的需求就是重要的。一种可能是，他们也分不清重要和紧急的差别，正如有时候我们也糊涂一样。对于这样的场景，我们要做的就是多问一些问题。
博客
程序员也可以“砍”需求吗？
05-15 227
软件开发中，需求管理是非常重要的一环。在需求管理上常见的错误是，需求管理的粒度太大，很多团队几乎是在用一个大主题在管理需求，这就让需求调整的空间变得很小。结合用户故事，我给你讲了一个好的需求管理基本单位是什么样子的，它要符合“INVEST原则”。其中的一个关键点是“小”，只有小的需求才方便管理和调整。什么样的需求才算小呢？我给你介绍了一种需求估算的方式，每个团队都可以根据自己的特点决定在自己的团队里，多大的需求算大。大需求怎么办？只要再进行分解就好了。
博客
为什么你的测试不够好？
05-15 560
你好！我是郑晔。今天是除夕，我在这里给大家拜年了，祝大家在新的一年里，开发越做越顺利！关于测试，我们前面讲了很多，比如：开发者应该写测试；要写可测的代码；要想做好 TDD，先要做好任务分解，我还带你进行了实战操作，完整地分解了一个任务。但有一个关于测试的重要话题，我们始终还没聊，那就是测试应该写成什么样。今天我就来说说怎么把测试写好。你或许会说，这很简单啊，前面不都讲过了吗？不就是用测试框架写代码吗？其实，理论上来说，还真应该就是这么简单，但现实情况却往往相反。
博客
一起练习：手把手带你分解任务
05-15 697
简单的做法就是加入一个 filter，在请求到达真正的资源代码之前先做一层过滤，在这个 filter 里面，如果待访问的地址是需要登录访问的，我们就看看用户是否已经登录，现在一般的做法是用一个 Token，这个 Token 一般会从 HTTP 头里取出来。另外，有用户登录，一般情况下，还会有一个退出的功能。另外，对比我们在分解过程中的顺序，你会看到这个完整任务清单的顺序是调整过的，你可以按照这个列表中的内容一项一项地做，调整最基本的标准是，按照这些任务的依赖关系以及前面提到的“完整地实现一个需求”的原则。
博客
大师级程序员的工作秘笈
05-15 347
TDD 在很多人眼中是不实用的，一来他们并不理解测试“驱动”开发的含义，但更重要的是，他们很少会做任务分解。而任务分解是做好 TDD 的关键点。只有把任务分解到可以测试的地步，才能够有针对性地写测试。同样听到任务分解这个说法，不同的人理解依然是不一样的。我把任务分解的结果定义成微操作，它远比大多数人理解得小。我们能将任务分解到多小，就决定了我们原子操作的粒度是多大。软件开发中的许多问题正是由于粒度太大造成的，比如，分支策略。将任务拆小，越小越好。
博客
先写测试，就是测试驱动开发吗？
05-15 448
一些优秀的程序员不仅仅在写测试，还在探索写测试的实践。有人尝试着先写测试，于是，有了一种实践叫测试先行开发。还有人更进一步，一边写测试，一边调整代码，这叫做测试驱动开发，也就是 TDD。从步骤上看，关键差别就在，TDD 在测试通过之后，要回到代码上，消除代码的坏味道。测试驱动开发已经是行业中的优秀实践，学习测试驱动开发的第一步是，记住测试驱动开发的节奏：红——绿——重构。把测试放在前面，还带来了视角的转变，要编写可测的代码，为此，我们甚至需要调整设计，所以，有人也把 TDD 称为测试驱动设计。
博客
测试也是程序员的事吗？
05-15 584
测试是软件开发重要的组成部分，测试应该是软件开发团队中所有人的事，而不仅仅是测试人员的事。因为软件变更成本会随着时间和开发阶段逐步增加，能在早期解决的问题，就不要将它延后至下一个阶段。在测试问题上，程序员有着天生的优势，会写代码，于是，程序员拥有了一个突出的强项，自动化测试。写测试应该是程序员工作完成的重要组成部分。随着人们对于测试理解的加深，各种各样的测试都出现了，也开始有了测试的分类：单元测试、集成测试、系统测试等等。越在底层测试，成本越低，执行越快；越在高层测试，成本越高，执行越慢。
博客
向埃隆·马斯克学习任务分解
05-15 526
我们从外星人探索和马斯克的火星探索入手，介绍了任务分解在人类社会诸多方面的应用，引出了分而治之这个人类面对复杂问题的基本解决方案。接着，我给你讲了这一思想在软件开发领域中的一个常见应用，分而治之的算法。虽然我们很熟悉这一思想，但在日常工作中，我们却没有很好地应用它，这也使得大多数人的工作有很大改进空间。运用这一思想的难点在于，给出一个可执行的分解。一方面，对复杂工作而言，给出一个分解是巨大的挑战；另一方面，面对日常工作，人们更容易忽略的是，分解的任务要可执行。
博客
程序员工作法
05-15 254
本课程共分为六大模块。有效工作的思考框架篇，为你提供一个可套用的思考框架，帮你在遇到问题时梳理自己真正要做的事情。同时还会给你提供践行这套框架所需的几项基本原则。以终为始篇，从完成的定义、需求的完成、代码的完成、产品特性的完成等几个方面，来帮你明确真正的目标。通过跳出角色、数字校验、沙盘推演等方式确保目标的可行性，让你的每一丝努力都不白费。任务分解篇，通过德雷克公式、埃隆·马斯克、“老虎”伍兹等案例，为你分析任务分解的重要性。通过对测试驱动开发进行完整地了解，让你更好地掌握任务分解的“度”。
博客
迭代0： 启动开发之前，你应该准备什么？
05-15 274
在这一讲中，我给你介绍了迭代0的概念，它是在正式开发迭代开始之前，进行一些基础准备的实践。我给了一份我自己的迭代0准备清单，这份清单包含了需求和技术两个大方面，你可以参照它设计你自己的迭代0清单。根据我的经验，对比这个清单，大多数新项目都在一项或几项上准备得不够充分。即便你做的不是一个从头开始的项目，对照这个清单，也会发现项目在某些项上的欠缺，可以有针对性地做一些补充。设计你的迭代0清单，给自己的项目做体检。
博客
你的工作可以用数字衡量吗？
05-15 502
随着智能时代的来临，人类社会开始逐渐认识到数据的重要性。但我们这群 IT 人在通过数据为其他人服务的同时，却很少把数字化的思维带到自己的工作范围内。这也是工作中很多“空对空”对话的根源所在。结合着“以终为始”的思考，如果我们可以在一开始，就设计好测量工作有效性的指标，那么就可以更有目的性地去工作了。而如果我们习惯了用数字去思考，就可以在很多方面让数字帮助我们。我举了几个小例子，比如：基于数据进行技术决策、预先设定系统指标，以及发现系统中的问题等等。希望你也可以把数字思维带到你的日常工作中。
博客
为什么说做事之前要先进行推演？
05-15 396
即便已经确定了自己的工作目标，我们依然要在具体动手之前，把实施步骤推演一番，完成一次头脑中的创造，也就是第一次创造或智力上的创造。这种思想在军事上称之为沙盘推演，在很多领域都有广泛地应用。在软件开发过程中，我们就假设软件已经就绪，看就绪之后，要做哪些事情，比如，如何上线、如何推广等等，这样的推演过程会帮我们发现前期准备的不足之处，进一步丰富我们的工作计划。为了不让我们总在“最后一公里”摔跟头，前期的推演是不可或缺的，也是想让团队进入有条不紊状态的前提。在动手做一件事之前，先推演一番。
博客
解决了很多技术问题，为什么你依然在“坑”里？
05-15 339
程序员总喜欢用技术去解决一切问题，但很多令人寝食难安的问题其实根本不是问题。之所以找不出更简单的解决方案，很多时候原因在于程序员被自己的思考局限住了。不同角色工作真正的差异在于上下文的差异。在一个局部上下文难以解决的问题，换到另外一个上下文甚至是可以不解决的。所以说无论单点有多努力也只是局部优化，很难达到最优的效果。想把工作做好，就需要不断扩大自己工作的上下文，多了解一下别人的工作逻辑是什么样的，认识软件开发的全生命周期。
博客
精益创业：产品经理不靠谱，你该怎么办？
05-15 359
你好，我是程序员贵哥。前面谈到验收标准时，我们说的实际上是确定性需求，也就是说，我们已经知道了这个需求要怎么做，就差把它做出来了。而有时候，我们面对的需求却是不确定的，比如，产品经理有了一个新想法，那我们该如何应对呢？今天，我们从 IT 行业一个极为经典的话题开始：程序员如何面对产品经理。我先给你讲一件发生在我身边的事。有一次，我们一大群人在一个大会议室里做一个产品设计评审，来自产品团队和技术团队的很多人都参与到这个评审中。一个产品经理正对着自己的设计稿，给大家讲解一个新的产品特性。
博客
持续集成：集成本身就是写代码的一个环节
05-15 418
在软件开发中，编写代码是很重要的一环，但程序员的交付物并不应该是代码，而是一个可工作的软件。当我们在一个团队中工作的时候，把不同人的代码放在一起，使之成为一个可工作软件的过程就是集成。在很长一段时间内，集成都是软件行业的难题，改动量和集成时间互相影响。幸运的是，不同的人在不同的方向尝试着改变，结果，同时加大改动量和集成时间的人陷入了泥潭，而调小这两个参数的人看到了曙光。每日构建作为早期的一种“最佳实践”被提了出来，但因为它基本上都是原则，没有得到广泛的应用。
博客
接到需求任务，你要先做哪件事？
05-15 558
需求，是软件开发中的一个关键环节，一旦需求理解出现问题，势必会造成大量的浪费。传统的功能列表只是简单罗列了要实现的功能，丢失了大量的上下文，会导致团队成员对于需求“只见树木不见森林”。而在比较大的团队中，更是会将一个功能分拆到多个小团队中，每个人看到的只是功能碎片。于是，后来产生了其他的需求描述方式，比如用例和用户故事。在实际的开发过程中，大量的分歧来自于对“需求完成”的定义。当我们把“以终为始”的原则应用在需求领域中，就会注意到，用户故事有一个非常重要的组成部分是验收标准。
博客
DoD的价值：你完成了工作，为什么他们还不满意？
05-15 713
DoD 这个概念本身并不复杂，它就是告诉我们怎样算是完成了，尽量减少因为理解偏差造成的各种浪费。具体怎么做呢？就是团队在开始工作前，先制定 DoD。以前面的场景为例，团队可以规定：特性开发完成，表示开发人员经过了需求澄清、功能设计、编写代码、单元测试，通过了测试人员的验收，确保代码处于一个可部署的状态，相关文档已经编写完毕。开发完成，表示开发人员编写好功能代码，编写好单元测试代码，编写好集成测试代码，测试可以通过，代码通过了代码风格检查、测试覆盖率检查。
博客
以终为始：如何让你的努力不白费？
05-15 626
你好，我是程序员贵哥。我曾在公司内部做过这样一个练习，我扮演客户，让大家帮我设计一个登录功能。同事们一听就高兴了，登录不就是用户名加密码嘛，我熟啊，我还可以设计出验证码、找回密码、第三方登录等等功能。更有个别动作快的同事，甚至已经开始设计数据库表，考虑用Redis做缓存了。整个过程下来，大家彼此讨论得热火朝天，唯一没人理会的就是我这个“客户”。讨论结束，扮演客户的我告诉大家，作为一个“土豪”，我打算做一个打车软件，用户可以通过手机号接收验证码的方式进行登录。你可以想见，同事们一副“被套路了”的表情。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值