LLM Deploy - ChatGLM3-6B
LLM 选择
核心玩家
厂家很多,但没多少真正在研究技术 - 成本 - 不少厂商是基于 LLaMA 套壳
ChatGLM-6B
- ChatGLM-6B 和 LLaMA2 是比较热门的开源项目,国产 LLM 是首选
- 企业布局 LLM
- 选择 MaaS 服务,调用大厂 LLM API,但会面临数据安全问题
- 选择开源 LLM,自己微调、部署、为上层应用提供服务
- 企业一般会选择私有化部署 + 公有云 MaaS 的混合架构
- 在国产厂商中,从技术角度来看,智谱 AI 是国内 LLM 研发水平最高的厂商
- 6B 的参数规模为 62 亿,单张 3090 显卡就可以进行微调和推理
- 企业预算充足(百万以上,GPU 费用 + 商业授权)
- 可以尝试 GLM-130B,千亿参数规模,推理能力更强
- GLM-130B 轻量化后,可以在 3090 × 4 上进行推理
- 训练 GLM-130B 大概需要 96 台 A100(320G),历时两个多月
计算资源
- 适合 CPU 计算的 LLM 不多
- 有些 LLM 可以在 CPU 上进行推理,但需要使用低精度轻量化的 LLM
- 但在低精度下,LLM 会失真,效果较差
- 要真正体验并应用到实际项目,需要 GPU
ChatGLM3-6B
简介
- ChatGLM-6B 目前已经发展到第 3 代 ChatGLM3-6B - 中英文推理 + 数学 + 代码等推理能力
- 在语义、数学、推理、代码、知识等不同角度的数据集上测评
- ChatGLM3-6B-Base 在 10B 以下的基础模型中是性能最强的
- 除此之外,还具有 8K、32K、128K 等多个长文本理解能力版本
环境
Key | Value |
---|---|
OS | Ubuntu / CentOS |
Python | 3.10~3.11 |
Transformers | 4.36.2 |
Torch | ≥ 2.0 - 最佳的推理性能 |
算力
Key | Value |
---|---|
CPU 运行 | 内存 ≥ 32GB - 很慢,不推荐 |
低精度运行 | 内存 ≥ 8GB 显存 ≥ 5GB |
高精度运行 | 内存 ≥ 16GB 显存 ≥ 13GB |
代码
1 | $ git clone https://github.com/THUDM/ChatGLM3 |
依赖
1 | $ cd ChatGLM3 |
Git
Git Large File Storage
1 | $ sudo apt-get install git-lfs |
模型
1 | $ git clone https://huggingface.co/THUDM/chatglm3-6b |
启动
命令行
修改 basic_demo/cli_demo.py
1 | MODEL_PATH = os.environ.get('MODEL_PATH', '../chatglm3-6b') |
1 | $ cd basic_demo/ |
Web Console
修改 basic_demo/web_demo_gradio.py
1 | MODEL_PATH = os.environ.get('MODEL_PATH', '../chatglm3-6b') |
python3 web_demo_gradio.py
Composite
支持 Chat、Tool、Code Interpreter
1 | $ cd composite_demo |
精度
- 默认情况下,模型以 FP16 精度加载,大概需要 13GB 显存
- 也可以通过 CPU 启动,大概需要 32GB 内存
- 如果显存不足,可以在 4-bit 量化下运行,大概需要 6GB 显存
超参数
- 超参数用来控制模型的推理准确度
- LLM 推理每次给的回答可能都不一样,因此 LLM 不能用于处理精确度要求很高的任务
ChatGLM3-6B
Parameter | Value |
---|---|
max_length | 模型的总 Token 限制 - 输入和输出 |
temperature | 模型的温度 - 调整单词的概率分布 在较低温度下,模型更具有确定性 - 数字越小,给出的答案越精确 |
top_p | 模型采样策略参数 每一步只从累计概率超过某个阈值 p 的最小单词集合中进行随机采样 不考虑其它低概率的词,只关注分布的核心部分,忽略尾部 |
Prompt
在对话场景中,有且仅有三种角色
Role | Desc |
---|---|
system | 系统信息,出现在消息的最前面,可以指定回答问题的角色 |
user | 我们提出的问题 |
assistant | LLM 给出的回复 |
在代码场景中,有且仅有 user、assistant、system、observation 四种角色
- observation 是外部返回的结果 - 调用外部 API、代码执行逻辑等返回结果
- observation 必须放在 assistant 之后
1 | <|system|> |
- 当前阶段的 LLM 经过训练后,都可以遵循系统消息
- 系统消息不算用户对话的一部分,与用户隔离
- 系统消息可以控制 LLM 与用户的交互范围
- 在 system 角色指定模型充当 Java 技术专家
- 则可以指导 LLM 的输出偏向于 Java 技术范围
- 可以防止用户进行输入注入攻击
- 在进行多轮对话时,每次新的对话都会把历史对话带进去
- 如果在前面的对话中,告诉 LLM 错误的提示
- 那么这些错误的提示会在后续的对话中被当成正确的上下文带进去
- 基于自回归的模型,会根据上下文进行内容推理,因此可能会生成错误内容
- 角色可以使内容更加容易区分,增加注入攻击的复杂度
- 只能尽量减少,无法完全避免
All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.