meta-llama/Meta-Llama-3.1-405B-Instruct-FP8 (ollama link)
不要再嘴什麼AI XX 或者 Gen AI 了 ... 先跑起來，我就信你有心認真要做 AI ~ XD
不要再嘴什麼AI XX 或者 Gen AI 了 ... 先跑起來，我就信你有心認真要做 AI ~ XD
GraphRAG 殺雞焉用牛刀且雲端LLM的token數很可怕，你變不了現；BUT 地端你有 GPU？
9.11和9.9誰大？我們實測15個大模型，超半數翻車 自己順手也測了一下 XD
開始之前，先瞭解一下很常聽到的 XX B 的這個 B，以及要怎樣計算需要多少 GPU VRAM；這裡的「B」表示10億 (Billion)，即10^9。因此，7B表示70億個可訓練參數。現在多數模型參數大多數都是 float32，佔4個位元組 (bytes, 1 bytes = 8 bits)。最好記的算法是每10億個參數，佔用 4GB GPU VRAM，精度每減半如fp16，VRAM也會減半(實際上是 10^9*4/1024/1024/1024=3.725G，方便就先記為4GB)。但這只是模型權重，你可能還需要考慮包含反向傳播的梯度、最佳化器所使用、正向傳播的啟動狀態記憶體。
以 fp32 推理 (單位為 GB)：因為1 GB ≈ 1B字節，模型記憶體= 4 * 參數量 (位元組)，總量約需≈ 1.2×模型記憶體；以 fp32 訓練 (單位為 GB) 至少：模型權重 4 * 參數量 + 優化器 12 * 參數量 + 梯度 4 * 參數量 + 啟動
結論：假設是 Llama 2 70B 以 FP 32 做推論，那至少要 280 GB，低於這數字或者是用了消費型顯卡，那十之八九應該就是用了 int8 或者傳說中的 deepspeed 的 ZeRO-Infinity 之類的，而這種做法，準確度會降，速度也會降的 (多張卡的數據、模型傳輸)，而且你還得考慮 GPU跟 SSD的傳輸速度落差。 (希望不要再有廠商四處亂唬弄人了)
2023/08 公司添購 RTX 6000 Ada 48 GB * 2 和 A 100 80GB * 4
2024/05 公司添購RTX 6000 Ada 48 GB * 8 * 2
Hugging Face 有篇不錯的說明文：Optimizing your LLM in production
- Bloom ≈ 4 * 176 GB = 704 GB記憶體
- Llama-2-70b ≈ 4 * 70 GB = 280 GB記憶體
- Falcon-40b ≈ 4 * 40 GB = 160 GB記憶體
- MPT-30b ≈ 4 * 30 GB = 120 GB記憶體
- bigcode/starcoder ≈ 4 * 15.5 = 62 GB記憶體
這篇內容主要是要記錄一下(踩坑過程)怎樣使用 AutoGen 跟 AutoGen Studio 來建個多代理人 的分工合作交互模式 (ReRanker、Function Call 和 Workflow 等等)，另外也測了AnythingLLM (2024/05/04 更新了 dify、RAGFlow)；發現這其實要拆分為兩種不同的應用需求，然後因為 OpenAI 跟 AOAI 的 API 畢竟也是要費用，所以又弄了 Ollama 還有 xinference 來當做本地端的 LLM 跟模型使用；不多說，先上截圖吧 !
Get up and running with large language models.
curl https://ollama.ai/install.sh | sh (之後想更新也是直接執行這串就可以)
這個工具就是降低你使用大模型的繁瑣設定，且安裝操作也非常簡單，雖然你可能會找到 LM Studio，但可惜它只能在桌面環境操作，一般想開發產品，我想你很少會開個桌面，然後執行吧？這邊補充一下怎樣修改 ollama model 的儲存路徑還有啟動時要不只在 127.0.0.1，這在要跨docker時會很連不到
sudo vi /etc/systemd/system/ollama.serviceEnvironment="OLLAMA_MODELS=/path/to/ollama/models" (在最下方的service加上這行你要的路徑)sudo systemctl daemon-reloadsudo systemctl restart ollama.servicesudo systemctl status ollamaOLLAMA_HOST=0.0.0.0 ollama serve (或者是用變量來做 launchctl setenv OLLAMA_HOST "0.0.0.0")如果是想要用 ngrok 來做服務，那就需要這樣ngrok http 11434 --host-header="localhost:11434"
如上面截圖，嗯 ! 就這樣很容易的跑起了 Yi-34B啦 !
當然，就馬上下載了這幾個大語言模型 LLM (Large Language Model) 來加減跑看看啦，官方網頁當然也列出了支援的模型：https://ollama.com/library?sort=newest
- LLM 模型
- 14 GB：codeqwen:7b-code-v1.5-fp16
- 69 GB：llava:34b-v1.6-fp16
- 73 GB：codellama:70b-code-q8_0
- 74 GB：dolphin-llama3:70b-v2.9-q8_0
- 75 GB：llama3-chatqa:70b-v1.5-q8_0
- 74 GB：llama3:70b-instruct-q8_0
- 115 GB：mixtral:8x22b-instruct-v0.1-q6_K
- 118 GB：qwen:110b-chat-v1.5-q8_0
- 250 GB：deepseek-coder-v2:236b-instruct-q8_0
- 250 GB：deepseek-v2:236b-chat-q8_0
- 141 GB：llama3.1:70b-instruct-fp16
- 231 GB：llama3.1:405b (ollama link)
- 245 GB：mistral-large:123b-instruct-2407-fp16 (ollama link)
- Text Embedding 模型
- bge-reranker-large
- bge-large-zh-v1.5
- mxbai-embed-large:v1
- nomic-embed-text:v1.5
接著也補充一下除了 OLLAMA_HOST跟 OLLAMA_MODELS 還有啥參數可以用吧
- OLLAMA_FLASH_ATTENTION：優化的，計算效率跟記憶體使用率都會比較好
- OLLAMA_ORGINS：用逗號分隔，來當作連線來源限制
- OLLAMA_KEEP_ALIVE：指的是模型能存活多久，有在用的就知道，有時會跑很久，就是因為整個重新 loading，當然如果 GPU 夠的話，其實可以活久一點啦
- OLLAMA_PORT：這個是指定 PORT，很好懂
- OLLAMA_NUM_PARALLEL：這個是同時要啟用幾個模型，如果GPU很夠用，是真的可以多開
- OLLAMA_MAX_QUEUE：默認512，如字面意思，就是可以排多長的隊啦
- OLLAMA_MAX_LOADED_MODELS：如字面意思，會合理分配，默認是1，也就是只會有一個模型在 VRAM 裡
- OLLAMA_DEBUG：輸出DEBUG的log
- 預設上下文視窗大小為2048 tokens，可以透過指令/set parameter num_ctx 4096 將上下文視窗長度調整為4096 token
- ollama ps判斷模型時運行在CPU還是GPU上
本來想補充一下怎樣自己轉出自己想要的模型給 ollama 用
~~~ 但下載好模型後，就忘記了 ~~~
抓別人的 GGUF 模型，用 Ollama 在本機執行！ (就是用 huggingface 函式庫 下載)
from huggingface_hub import snapshot_download
model_id = "google/paligemma-3b-pt-896" # hugginFace's model name
snapshot_download(
repo_id=model_id,
local_dir="paligemma-3b-pt-896",
local_dir_use_symlinks=False,
revision="main",
use_auth_token="<YOUR_HF_ACCESS_TOKEN>")將 HuggingFace 模型轉換為 GGUF 及使用 llama.cpp 進行量化 (接著就是自己設定個 Modelfile )
把放 GGUF 檔目錄，再新增一個檔案 Modelfile，裡面寫 FROM ./模型檔名.gguf
還有要再另外寫上 TEMPLATE 跟 PARAMETER
細節一樣官方文件都有寫：https://github.com/ollama/ollama/blob/main/docs/modelfile.md再來這個是要用 llama.cpp 來轉成 gguf 就是
最後附上個官方說明頁，裡面有像是 ps、list、cp、rm等等相關指令
2024/05/11 更新了 Dify
其實官方網站的文件寫的超清楚 XD 然後又有 docker 可以直接用，好像只能截個圖？最主要的還是在於它已經整合了 RAG、Function Call、Agent、WorkFlow，一整個實在是太強大了
就這樣順手整合了一下單據解析 OCR 跟 RAG 的 Q&A 了
2024/05/04 更新了 RAGFlow
其實官方網站的文件也寫的超清楚 XD 然後又有 docker 可以直接用，好像只能截個圖？
2024/04/12 更新 anythingllm
AnythingLLM是Mintplex Labs Inc. 開發的開源ChatGPT 等效工具，用於在安全的環境中與文件等進行聊天，專為想要使用現有文件進行智慧聊天或建立知識庫的任何人而建立。
(source: AnythingLLM：基於RAG方案構專屬私有知識庫 (開源｜高效｜可自訂))
AnythingLLM 能夠把各種文件、資料或內容轉換成一種格式，讓LLM（如ChatGPT）在聊天時可以引用這些內容。然後你就可以用它來和各種文件、內容、資料聊天，支援多個使用者同時使用，還可以設定誰能看或改哪些內容。 支援多種LLM、嵌入器和向量資料庫。
AnythingLLM 找到了更方便的安裝啟動方法了啊 ! 超快又好用 ! 就是只差下面幾個動作
https://github.com/Mintplex-Labs/anything-llm/blob/master/docker/HOW_TO_USE_DOCKER.md
這裡直接照著做，馬上就啟動了 !
docker pull mintplexlabs/anythingllmexport STORAGE_LOCATION=$HOME/anythingllm && \mkdir -p $STORAGE_LOCATION && \touch "$STORAGE_LOCATION/.env" && \docker run -d -p 3001:3001 \--cap-add SYS_ADMIN \-v ${STORAGE_LOCATION}:/app/server/storage \-v ${STORAGE_LOCATION}/.env:/app/server/.env \-e STORAGE_DIR="/app/server/storage" \mintplexlabs/anythingllm
不過可能會啟動失敗，記得要 chmod -R 777 anythingllm/ 這是因為權限問題
接著用 root 進入 anythingllm 的 docker 的 root 帳號，因為你會很多東西不能裝不能用，連 vi 都沒
docker exec -u 0 -it <容器ID或名称> bash
接著就是把 anythingllm 加到 sudoers 裡，這邊要記得要先用 passwd 幫 anythingllm 這帳號補密碼
vi /etc/sudoers
找到下面這行，接著直街新增下面那一行，這樣你就可以進去裝好 conda 跟 ngrok 等等的東西
# User privilege specification
root ALL=(ALL:ALL) ALL
anythingllm ALL=(ALL) All
不過，本來想要就直接用這個 docker 開始做點自己想做的事，但是它的硬碟看來設得很滿 XD
剩下的用法就都差不多啦 !
這邊可以看到它本身就具備了 API 可以做整合
至於這裡就可以看到它支援了不少 LLM，Gemini 都能直接用有意外到
接著是 Embedding，我就直接用 AOAI，但其實有注意到幾個新的開源 Embedding，可以來研究一下就是；但有查到其實用第一個 " Use the built-in embedding engine for AnythingLLM. Zero setup! " 也是很勘用就是
向量資料庫，目前也沒用到
最後截一下對話範例圖
當然，最想要的快速把 RAG 佈署好的功能也是有的 !
值得玩一下呢 !
其實現在有好多LLM Application Development類似的開源，頓時在想，這樣的 LLM、RAG 還有什麼商業模式嗎 ?
最後，再來個 QAnything、CrewAI、Phidata 一鍵三連，我覺得也是個不錯的開源的
看了一下官網的範例，直覺上跟AnythingLLM功能很像，但是手邊 GPU 都已經在跑，所以就先跳過這個 XD，是說這裡有篇寫得也蠻清楚的啦
QAnything支援任意格式檔案或資料庫的本地知識庫問答系統
上下兩個截圖，別是用來做一些基本技能的示範，找到的幾篇文章也都在上面 (官網其實非常齊全，認真看，好好看啊)，都可以點去參考學習一下 !
sudo apt update
sudo apt install nodejs npm
https://github.com/microsoft/autogen/tree/main/samples/apps/autogen-studio
後來又重裝了一次，倒是只卡在 node 跟 nodejs 還有跑 yarn 時的 node 版本不一樣的問題就裝好了
npm install -g gatsby-cli
npm install --global yarn
cd frontend
yarn install
yarn build
安裝，也有過 npm install -g gatsby-cli 第一行就遇到奇怪問題，對 nodejs、npm 實在不熟 !!!
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! lmdb@2.5.3 install: `node-gyp-build-optional-packages`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the lmdb@2.5.3 install script.
npm ERR! This is probably not a problem with npm.
There is likely additional logging output above.
而這一切都是為了想要手工改動一下 AutoGen 和 AutoGen Studio (至少ui版面想改動一下)
There are two ways to install AutoGen Studio - from PyPi or from source. We recommend installing from PyPi unless you plan to modify the source code.
最後只好乾脆 build 一個它的 docker 來用了
sudo docker build -f .devcontainer/full/Dockerfile -t autogen_full_img https://github.com/microsoft/autogen.git
sudo docker run -it --name autogen -v /opt/data:/opt/data -p 9999:9999 -p 8889:8889 --shm-size=32g autogen_full_img:latest /bin/bash
sudo docker exec -i -t autogen /bin/bash
./Anaconda3-2023.09-0-Linux-x86_64.sh
conda create -n autogen python=3.10
進來第一件事當然就是裝 conda 了，接著就 create 一個專用的 conda
git clone https://github.com/microsoft/autogen.git
cd autogen
pip install -e .cd samples/apps/autogen-studio/
pip install -e .
另外這邊也要同步讓 jupyter 跑起來，不然一直開著 team viewer 也是很麻煩
jupyter notebook --generate-config
(首先就是先生成 config 檔)
vi ~/.jupyter/jupyter_notebook_config.py
(接著去編輯相關設定參數)
# Default: False
c.NotebookApp.allow_remote_access = True
(這是遠端連線用，要拿掉註解的#跟=後面的False改成True)
jupyter notebook password
(這就是遠端連線的登入密碼/token)
Enter password: ****
Verify password: ****
[NotebookPasswordApp] Wrote hashed password to ~/.jupyter/jupyter_notebook_config.json
c.NotebookApp.port = xxxx
(這個就是 port 號)
ipython kernel install --name "deepspeed" --user
(我有個 conda env 叫 deepspeed，這樣就能加到 jupyter)接著就是直接啟動啦jupyter notebook至於 autogen 嘛，啟動指令是這樣
autogenstudio ui --port 9872
最後，如果是要 ngrok 那就看一下這篇吧 XD
2024/05/20 想起了這個也蠻方便的 tunel 的用法 " TryCloudflare "
接著說明一下，AutoGen Studio 就是有個 ui 讓你很好的去設計你想要做到的，不用在 cmd 模式下設計，當然最後要怎樣去整合，就看個人造化了；github 上也有找到有人特地開發 UI
回到 AutoGen Studio，它總共有 Skills (技能：給你寫你想要的工作)
Model (模型：就是你要使用的大語言模型)
Agents (代理人：就是你要設計的不同的專家；一個代理人可以同時有4個技能)；我個人比較不會去特別建 Agent，因為貌似你每次改動設定，都得來重調整，我都直接在 workflow 裡設定 Agent
Workflow (流程，這就是讓你除了把技能整合到代理人以外，你還可以設計不同流程跑不同代理人來解決你想要的問題)
最後就是 Playground了，也就是馬上實驗你剛剛做的相關設計啦
操作至今，真的感覺微軟實在是很佛心的開源了這個神器，雖然中間還是會有點小bug，但對於大家一直喊的無法把 LLM 給落地商業化開發，還是個很棒的開源工具 ! 畢竟可能還是有段路 XD
官網給了說明跟 AutoGen 和 ChatDev 有什麼差異，另外也在網路上找到一段說明，相信認真找找，你應該可以得到你想要的答案 ?
- Autogen: While Autogen excels in creating conversational agents capable of working together, it lacks an inherent concept of process. In Autogen, orchestrating agents' interactions requires additional programming, which can become complex and cumbersome as the scale of tasks grows.
- Autogen 代理只能按照它們被編程的方式進行互動。如果需要代理以不同的方式交互，則需要進行額外的編程。 程式設計複雜：程式設計Autogen 代理程式的互動可能非常複雜，尤其是對於複雜的任務及邏輯。 可擴展性差：Autogen 代理的程式設計方式不利於可擴展性。隨著任務規模的成長，程式設計代理的互動變得更加困難。
總的來說，相對於Autogen 和ChatDev 創建會話代理的工具，CrewAI 的構建以生產為中心，既提供了Autogen 對話代理的靈活性，又採用了ChatDev 的結構化流程方法，但又不失靈活性。 CrewAI 基於動態的流程設計理念，具有很強的適應性，可以無縫地融入開發和生產工作流程，以使得工作流程可以根據需求進行調整和優化，以適應不同的工作場景和業務需求。 - ChatDev: ChatDev introduced the idea of processes into the realm of AI agents, but its implementation is quite rigid. Customizations in ChatDev are limited and not geared towards production environments, which can hinder scalability and flexibility in real-world applications.
- ChatDev 中的自訂是有限的。這意味著ChatDev 可能難以滿足複雜應用程式的需求。 不適合生產環境：ChatDev 不適合生產環境。這意味著ChatDev 可能難以滿足實際應用程式的要求。 可擴展性差：ChatDev 的實作不利於可擴展性。隨著任務規模的成長，ChatDev 可能難以滿足應用程式的需求。
至於要不要再先幫各位去踩坑呢 ? 就看看這篇文章的效果，再來決定要不要再補上最後三個踩坑啦；最後再補個關於用 CPU 做推理加速的踩坑好了
https://github.com/Deep-Learning-101/Natural-Language-Processing-Paper#llm
推理加速 / DeepSpeed介绍 / 微軟DeepSpeed
https://huggingface.co/docs/transformers/main_classes/deepspeed
DeepSpeed之ZeRO系列：將顯存優化進行到底
ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning
https://github.com/intel/intel-extension-for-transformers
raise MissingCUDAException("CUDA_HOME does not exist, unable to compile CUDA op(s)") CUDA_HOME does not exist, unable to compile CUDA op(s)
cannot import name builder from google.protobuf.internal
