建立自用的 Docker Hub 代理
1 | server { |
/etc/docker/daemon.json
1 | { |
1 | systemctl daemon-reload |
1 | server { |
/etc/docker/daemon.json
1 | { |
1 | systemctl daemon-reload |
咱们这次使用 书生·浦语大模型挑战赛(春季赛)Top12,创意应用奖
的数据集,使用LLaMA3-8B大模型微调
Conda 虚拟环境
1 | cd llama3-ft |
1 | pip install -r requirements.txt |
你可以直接使用 dataset/huanhuan.json
数据集(该数据集来源于 https://github.com/KMnO4-zx ),也可以自己准备数据集 ,比如你的客服对话(FAQ)
数据集,这样就可以微调一个更适合你的智能客服的模型,客服回答更准确。
数据集的格式也比较简单,示例如下:instruction
是问题,output
是回答
1 | [ |
train.py
文件里面的 model_id
变量即可。HuggingFace
比较困难,因此使用 ModelScope
提供的模型。1 | # 需要微调的基座模型 |
1 | python train.py |
微调完成后,你可以执行以下命令启动一个 ChatBot 进行对话测试。
1 | streamlit run chat.py |
该命令执行后,会自动打开浏览器对话页面
微调的时间会根据你的数据集大小和模型大小而定。
我由于没有 GPU,因此耗时2个小时,如果你有 GPU,大概需要 30 分钟。
代码会自动下载模型,然后开始微调
微调完成后,所有的文件会保存在 models 文件夹下面,结构如下:
1 | ├── models |
Cannot copy out of meta tensor; no data
报错
1 | `NotImplementedError:Cannot copy out of meta tensor; no data! Please use torch.nn.Module.to_empty() instead of torch.nn.Module.to() when moving module from meta to a different device.` |
解决:强制设置 device = “mps”
1 | # 检查CUDA是否可用,然后检查MPS是否可用,最后回退到CPU |
在特定的情况下,要保证信息安全的同时还能享受到AIGC大模型带来的乐趣和功能,那么,私有化部署就能帮助到你,最起码,它是一个真正可用的方案。私有化部署指的是将AI应用部署在企业内部的服务器上,而非云端。这种部署方式可以在保证数据安全的同时,提高企业对于自身数据资产的控制权。
简单描述下本地电脑的配置:
本次只是初步评估ChatGLM3-6B的效果,尽可能在已有本地设备的情况下进行低成本本地模型部署,如果要更好的效果,还是上专业的硬件设备。
ChatGLM3 下载
1 | git clone https://github.com/THUDM/ChatGLM3 |
但是,默认里面是没有模型的,只有自带的简单的聊天项目以及相关的接口示例项目,还得继续下载模型。
ChatGLM3-6B 模型下载
当然,如果你自己不下载这些模型,这些模型就会在运行的时候自动下载(网络不好的话会影响使用体验,所以,建议提前下载)
1 | git lfs install |
项目配置和部署
把下载的服务直接放到需要运行的地方,然后执行python环境管理
1 | conda create --name chatglm3 python=3.10 |
然后,进入到主项目中,开始配置一些环境
1 | cd ChatGLM3 |
可以看到,实际上我们可以运行7种案例。
目前,只有第二个的综合例子,是比较有趣的,就以它为案例进行配置修改。
composite_demo例子
看到,这个demo下还有requirements.txt
文件,我们把他给安装了
1 | pip install -r requirements.txt -i https://mirror.sjtu.edu.cn/pypi/web/simple |
演示中使用 Code Interpreter
还需要安装 Jupyter
内核:
1 | pip install ipykernel -i https://mirror.sjtu.edu.cn/pypi/web/simple |
接着修改client.py里面的配置信息
1 | // 修改 MODEL_PATH , chatglm3-6b 绝对路径 |
对于搭载了Apple Silicon
或者AMD GPU
的 Mac,可以使用MPS后端来在GPU上运行ChatGLM3-6B
。需要参考Apple的官方说明 安装 PyTorch-Nightly
(正确的版本号应该是2.x.x.dev2023xxxx,而不是 2.x.x)。
1 | pip uninstall torch torchvision torchaudio |
使用命令
1 | pip list | grep torch |
看到类似这样的带dev的就可以下一步了
1 | torch 2.3.0.dev20231224 |
将client.py
中device_map = "auto"
改为device_map = "mps"
136-140行
1 | self.model = AutoModel.from_pretrained( |
150行
1 | self.model = AutoModel.from_pretrained(MODEL_PATH, trust_remote_code=True, device_map="mps").eval() |
然后,执行以下命令启动服务
1 | streamlit run main.py |
这回答速度真绝,非常的快。
对话模式
输入你是谁,它就输自动的输出信息,速度还挺快。而控制台也会显示你输入的信息以及返回的信息。
工具模式
工具模式,需要自己先定义工具,我这边没有定义,有兴趣的可以整一下。
以下是自带的工具进行的演示:我调用了一个查询天气的工具(tool_registry.py) 文件可以看到 get_weather的代码
代码解释器模式
一开始的时候,没有按照Apple的官方说明安装PyTorch-Nightly
,并配置MPS
,结果效果喜人,一直在推理。后来配置后,感觉速度不亚于chatgpt3.5,答复效果也非常好。下一步开始使用chatGLM搭建私有知识库。
DataX 是一个异构数据源离线同步工具,本次需求是定时调度数据库,
原则是要配合海豚调度DolphinScheduler,但是DolphinScheduler目前看有点重,晚点评估。
mysql同步StarRocks
1 | { |
mongodb同步es
1 | { |
1 | $ cd {YOUR_DATAX_HOME}/bin |
开始统一数仓,seatunnel评估一轮
mongodb-cdc实时同步mysql
1 | env { |
mongodb-cdc实时同步starrocks
1 | env { |
mongodb-cdc 实时同步es
1 | env { |
1 | -- 启用CDC功能 |
1 | 开始 |
内网k8s集群需求:StarRocks的9030端口或mysql的3306端口需要暴露出去,而他们TCP协议,是L4层服务,而ingress是http协议,是L7层服务,不能使用ingress暴露出去
starrocks/starrockscluster-fe-service
deployment: ingress-nginx-controller配置
hostNetwork: true
,pod中运行的应用程序可以直接看到宿主主机的网络接口,宿主机所在的局域网上所有网络接口都可以访问到该应用程序及端口- '--tcp-services-configmap=$(POD_NAMESPACE)/tcp-services'
1 | spec: |
编写TCP/UDP端口转发规则实现L4层服务暴露kubectl create -f tcp-services-configmap.yaml -n ingress-nginx
1 | kind: ConfigMap |
验证TCP 端口的L4服务暴露,查看pod nginx-ingress-controller的ip
1 | > kubectl get pod -n ingress-nginx -owide |
navicat连接
为了让mongodb能使用标准化的sql语句查询,我们使用官方的mongo-bi做一层转换,这一步是统一数仓的关键。
目前该方案不具可行性,原因:
- bi-connect连接mongodb数据源必须开启ssl,这就导致外部客户端连接bi-connect必须useSSL=true,而StarRocks的catalogs未支持SSL
- 不稳定,从BI的外连接看,经常报错
bi-connector支持不同平台安装部署,这里针对Linux环境安装部署配置进行记录。
通过官网下载:https://www.mongodb.com/try/download/bi-connector
我这里下载的文件版本为mongodb-bi-linux-x86_64-rhel70-v2.14.12.tgz
下载后解压到/opt/mongodb-bi目录
当MongoDB启用认证时,bi-connector必须要配置使用证书,才能通过bi-connector连接mongodb
这里先创建证书
1 | #执行创建 SSL 证书 |
1 | sudo install -m755 bin/mongo* /usr/bin/ |
1 | mkdir -p /opt/mongodb-bi/conf/ |
1 | net: |
1 | mongosqld install --config /opt/mongodb-bi/conf/mongosqld-config.yml |
1 | #执行生成 schema |
mysql cil,注意用户名密码是mongodb的用户名密码
1 | mysql --enable-cleartext-plugin --user='root?source=admin&mechanism=SCRAM-SHA-1' --host=192.168.103.153 --protocol=tcp --port=3307 -p |
navicat,需要勾选使用ssl
jdbc连接需要添加额外的JDBC连接字符串characterEncoding=UTF-8&connectTimeout=5000&useSSL=true&allowPublicKeyRetrieval=true&verifyServerCertificate=false
1 | systemctl start mongosql.service |
k8s-1.25.4部署笔记(containerd)
k8s使用nfs作为动态storageClass存储
1 | kubectl apply -f https://raw.githubusercontent.com/StarRocks/starrocks-kubernetes-operator/main/deploy/starrocks.com_starrocksclusters.yaml |
1 | kubectl apply -f https://raw.githubusercontent.com/StarRocks/starrocks-kubernetes-operator/main/deploy/operator.yaml |
我这里配置一个使用腾讯云COS做存算分离+storageClass做FE元数据持久化
shared_data_mode.yaml
1 | apiVersion: starrocks.com/v1 |
1 | kubectl apply -f shared_data_mode.yaml |
验证一轮查询外部数据湖
JDBC ✅已验证
1 | CREATE EXTERNAL CATALOG jdbc1 |
es
存在问题,当使用腾讯云默认索引开了动态模板,starrocks解析mapping有bug,会导致show tables出不来
1 | CREATE EXTERNAL CATALOG es_test |
1 | CREATE EXTERNAL TABLE user_behavior_fet |
在现代数据库中,很多数据库都支持分区(Partition)或分桶(Tablet,分桶有时候又叫分片),它的主要目的是提高查询性能。
StarRocks 使用先分区后分桶的方式,可灵活地支持两种分布方式:
分区的主要作⽤是将⼀张表按照分区键拆分成不同的管理单元,针对每⼀个管理单元选择相应的存储策略,⽐如副本数、冷热策略和存储介质等等。对于访问频率高的分区,可以使用SSD存储;对于访问频率低的分区,可以使用STAT存储。选择合理的分区键可以有效的裁剪扫描的数据量,一般选择日期或者区域作为分区键
分桶的目的就是将数据打散为一个个逻辑分片(Tablet),以Tablet作为数据均衡的最小单位,使数据尽量均匀的分布在集群的各个BE节点上,以便在查询时充分发挥集群多机多核的优势。
StarRocks中的副本数就是同一个Tablet保存的份数,在建表时通过replication_num参数指定,也可以后面修改。默认不指定时,StarRocks使用三副本建表,也即每个Tablet会在不同节点存储三份(StarRocks的副本策略会将某个tablet的副本存储在与其不同IP的节点)。
为方便理解,我们假设当前有一个3BE节点的集群,有表Table A和Table B,表A和表B建表时都未设置分区(视为一个大分区),分桶数为3,副本数replication_num为2,则表A和表B在集群中数据分布的一种可能如下图:
如下:StarRocks 的数据划分以及 Tablet 多副本机制
表按照日期划分为4个分区,第一个分区切分成4个Tablet。每个Tablet使用3副本进行备份,分布在3个不同的BE节点上。
由于一张表被切分成了多个Tablet,StarRocks在执行SQL语句时,可以对所有Tablet实现并发处理,从而充分的利用多机、多核提供的计算能力。
用户也可以利用StarRocks数据的切分方式,将高并发请求压力分摊到多个物理节点,从而可以通过增加物理节点的方式来扩展系统支持高并发的能力。
在StarRocks中,Partition是数据导入和备份恢复的最小逻辑单位,Tablet是数据复制和均衡的最小物理单位。表(Table)、分区(Partition)、逻辑分片(Tablet)的关系如下图:
分区是针对表的,是对表的数据取段。分桶是针对每个分区的,会将分区后的每段数据打散为逻辑分片Tablet。副本数是针对Tablet的,是指Tablet保存的份数。那么我们不难发现,对某一个数据表,若每个分区的分桶数一致,其总Tablet数:总Tablet数=分区数分桶数副本数
以table01为例,我们为其设置了3个分区,为每个分区设置了20个分桶,又对分桶后的tablet设置了1副本,则table01的总tablet数= 3 * 20 * 1 = 60 个。查看table01的tablet信息,发现确实共有60个tablet:
1 | show tablet from table01; |