From ddf5b3d2711d85012e5eedca610d8871b294d1b7 Mon Sep 17 00:00:00 2001 From: gongjy <2474590974@qq.com> Date: Fri, 6 Sep 2024 10:55:52 +0800 Subject: [PATCH] update readme --- README.md | 39 ++++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/README.md b/README.md index 4f571e2..2266c50 100644 --- a/README.md +++ b/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)下载模型权重文件 ```