update readme
This commit is contained in:
gongjy
parent
288ab3ccb8
commit
ddf5b3d271
39
README.md
39
README.md
@ -213,14 +213,14 @@ streamlit run fast_inference.py
|
||||
因为LLM体积非常小，为了避免模型头重脚轻（词嵌入embedding层参数占整个LLM比太高），所以词表长度需要选择比较小。
|
||||
强大的开源模型例如01万物、千问、chatglm、mistral、Llama3等，它们的tokenizer词表长度如下：
|
||||
|
||||
| Tokenizer 模型 | 词表大小 | 来源 |
|
||||
|--------------------|---------|------------|
|
||||
| yi tokenizer | 64,000 | 01万物（中国） |
|
||||
| qwen2 tokenizer | 151,643 | 阿里云（中国） |
|
||||
| glm tokenizer | 151,329 | 智谱AI（中国） |
|
||||
| mistral tokenizer | 32,000 | Mistral AI（法国） |
|
||||
| llama3 tokenizer | 128,000 | Meta（美国） |
|
||||
| minimind tokenizer | 6400 | 自定义 |
|
||||
| Tokenizer 模型 | 词表大小 | 来源 |
|
||||
|------------------------|---------------|------------|
|
||||
| yi tokenizer | 64,000 | 01万物（中国） |
|
||||
| qwen2 tokenizer | 151,643 | 阿里云（中国） |
|
||||
| glm tokenizer | 151,329 | 智谱AI（中国） |
|
||||
| mistral tokenizer | 32,000 | Mistral AI（法国） |
|
||||
| llama3 tokenizer | 128,000 | Meta（美国） |
|
||||
| minimind tokenizer | 6400 | 自定义 |
|
||||
|
||||
> 尽管Mistral中文词语占比很少，编解码效率弱于qwen2、glm等中文友好型分词器。
|
||||
但MiniMind这里选择了mistral tokenizer作为分词器以保持整体参数轻量，避免头重脚轻，因为mistral的词表大小只有32,000。
|
||||
@ -230,11 +230,10 @@ streamlit run fast_inference.py
|
||||
|
||||
---
|
||||
|
||||
-
|
||||
📙【Pretrain数据】：[seq-monkey通用文本数据集](https://github.com/mobvoi/seq-monkey-data/blob/main/docs/pretrain_open_corpus.md)
|
||||
是由多种公开来源的数据（如网页、百科、博客、开源代码、书籍等）汇总清洗而成。
|
||||
整理成统一的JSONL格式，并经过了严格的筛选和去重，确保数据的全面性、规模、可信性和高质量。
|
||||
总量大约在10B token，适合中文大语言模型的预训练。
|
||||
- 📙【Pretrain数据】：
|
||||
[seq-monkey通用文本数据集](https://github.com/mobvoi/seq-monkey-data/blob/main/docs/pretrain_open_corpus.md)
|
||||
是由多种公开来源的数据（如网页、百科、博客、开源代码、书籍等）汇总清洗而成。整理成统一的JSONL格式，并经过了严格的筛选和去重，确保数据的全面性、规模、可信性和高质量。总量大约在10B
|
||||
token，适合中文大语言模型的预训练。
|
||||
|
||||
---
|
||||
|
||||
@ -555,8 +554,10 @@ MobileLLM提出架构的深度比宽度更重要，「深而窄」的「瘦长
|
||||
* minimind-MoE(0.16B)表现很差，甚至不如它同配置的dense模型minimind(0.05B)
|
||||
，其实这并非MoE的锅。同样是因为偷懒提前kill腾出资源给小模型，但是MoE模型多专家模式需要的训练轮次本来就需要酌情更高，在epochs设置为2时训练的极其不充分。minimind不久前实验阶段在Yi
|
||||
tokenizer上试验过MoE的充分训练版本，可以做到比dense表现肉眼可见的好。现在先这样了hh，日后腾出服务器再训练更新v2 v3版本。
|
||||
*
|
||||
F模型的回答看起来是这里最完美的，尽管存在些许幻觉瞎编的情况。但GPT-4o和kimi的评分都一致认为它“信息过度冗长，且有重复内容，存在幻觉”。其实这种评价太严格了，100个字中有10个字是幻觉，就很容易把它归到0分。由于F模型训练文本默认长度更长，数据集大得多，所以回答的看起来很完备，在体积近似的情况下，数据比模型更重要得多。
|
||||
|
||||
|
||||
* F模型的回答看起来是这里最完美的，尽管存在些许幻觉瞎编的情况。但GPT-4o和kimi的评分都一致认为它“信息过度冗长，且有重复内容，存在幻觉”。
|
||||
其实这种评价太严格了，100个字中有10个字是幻觉，就很容易把它归到0分。由于F模型训练文本默认长度更长，数据集大得多，所以回答的看起来很完备，在体积近似的情况下，数据比模型更重要得多。
|
||||
|
||||
> 🙋♂️个人主观评价：F>D>A≈B>C>E
|
||||
|
||||
@ -675,15 +676,15 @@ minimind模型本身没有使用较大的数据集训练，也没有针对回答
|
||||
|
||||
* [./export_model.py](./export_model.py)可以导出模型到transformers格式，推送到huggingface
|
||||
|
||||
*
|
||||
MiniMind的huggingface集合地址：[MiniMind](https://huggingface.co/collections/jingyaogong/minimind-66caf8d999f5c7fa64f399e5)
|
||||
* MiniMind的huggingface集合地址：
|
||||
[MiniMind](https://huggingface.co/collections/jingyaogong/minimind-66caf8d999f5c7fa64f399e5)
|
||||
|
||||
---
|
||||
|
||||
### API推理
|
||||
|
||||
[./my_openai_api.py](./my_openai_api.py)完成了openai_api的聊天接口，方便将自己的模型接入第三方UI
|
||||
例如fastgpt、OpenWebUI等
|
||||
* [my_openai_api.py](./my_openai_api.py)完成了openai_api的聊天接口，方便将自己的模型接入第三方UI
|
||||
例如fastgpt、OpenWebUI等
|
||||
|
||||
* 从[Huggingface](https://huggingface.co/collections/jingyaogong/minimind-66caf8d999f5c7fa64f399e5)下载模型权重文件
|
||||
```
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user