那些大型語言模型 (Large Language Model, LLM) 要踩的坑:Ollama、Dify、LangFlow、Flowise、RAGFlow、AnythingLLM、CrewAI、AutoGen

這篇 2025/01 略做更新,然後以上面粗體字的為主,特別是 Dify 應用 案例
RAGFlowAnythingLLMCrewAIAutoGen

希望自己永遠不會像很多人只會四處嘴什麼AI XX 或者 Gen AI 還出書或辦講座,一副自己做了好多AI落地應用;但常常可能 GPU 都擠不出來連環境都沒,根本沒心認真要把 AI 落地 !
開始之前,先瞭解一下常聽到的 XX B 的這個「B」(Billion 縮寫,10億,即10^9),以及要怎樣計算需要多少 GPU VRAM;因此,7B表示70億個可訓練參數。現在多數模型參數大多數都是 float32,佔4個位元組 (bytes, 1 bytes = 8 bits)。最好記的算法是每10億(「B」) 個參數,佔用 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
這篇內容主要是要記錄一下(踩坑過程)怎樣使用 AutoGen 跟 AutoGen Studio 來建個多代理人 的分工合作交互模式 (ReRanker、Function Call 和 Workflow 等等),另外也測了AnythingLLM (2024/05 更新了 Dify、RAGFlow,然後再補一下 LagnflowFlowise 好了);發現這其實要拆分為兩種不同的應用需求,然後因為 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.service
Environment="OLLAMA_MODELS=/path/to/ollama/models" (在最下方的service加上這行你要的路徑)
sudo systemctl daemon-reload
sudo systemctl restart ollama.service
sudo systemctl status ollama
OLLAMA_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 模型
    1. 14 GB:codeqwen:7b-code-v1.5-fp16 
    2. 69 GB:llava:34b-v1.6-fp16 
    3. 73 GB:codellama:70b-code-q8_0 
    4. 74 GB:dolphin-llama3:70b-v2.9-q8_0
    5. 75 GB:llama3-chatqa:70b-v1.5-q8_0
    6. 74 GB:llama3:70b-instruct-q8_0
    7. 115 GB:mixtral:8x22b-instruct-v0.1-q6_K
    8. 118 GB:qwen:110b-chat-v1.5-q8_0 
    9. 250 GB:deepseek-coder-v2:236b-instruct-q8_0
    10. 250 GB:deepseek-v2:236b-chat-q8_0
    11. 141 GB:llama3.1:70b-instruct-fp16
    12. 231 GB:llama3.1:405b  (ollama link)
    13. 245 GB:mistral-large:123b-instruct-2407-fp16 (ollama link)
  • Text Embedding 模型 
    1. bge-reranker-large
    2. bge-large-zh-v1.5
    3. mxbai-embed-large:v1 
    4. 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 用,但下載好模型後,就忘記了 
主要是可以考慮一下使用 Xinference (自定義模型點我)
整體來說是個很好用的工具,也相對的比自己再做一個GGUF還簡單多了

抓別人的 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>")
把放 GGUF 檔目錄,再新增一個檔案 Modelfile,裡面寫 FROM ./模型檔名.gguf
還有要再另外寫上 TEMPLATE 跟 PARAMETER
細節一樣官方文件都有寫:https://github.com/ollama/ollama/blob/main/docs/modelfile.md
再來這個是要用 llama.cpp 來轉成 gguf 就是

最後附上個官方說明頁,裡面有像是 ps、list、cp、rm等等相關指令

也因為大型語言模型 (LLM) 快速發展,越來越多希望以更低門檻、更高效率的方式,將 LLM 整合進行業務流程或應用開發。目前市面上已經有幾款「可視化拖拽式」的開源平台,能幫助開發者快速串接各種 LLM、設定對話邏輯與流程節點,進而實現多樣化的應用場景。

2025/01/11 補一下 LangFlow
目前最常用的是 dify,但這個也是個不錯的工具,官方 HuggingFace 的 DEMO 可體驗一下 
  • 重視插件生態與二次開發彈性,允許開發者自行撰寫自訂節點或功能模組。
  • 提供一套基礎向量查詢工具與文檔管理機制,用於多輪對話中的上下文引用。
  • 強化前端可視化介面:提供節點連線預覽、工具提示等,使流程編排更直觀。
  • 支援模型與資料庫分離式部署,方便處理機密資料或大型檔案時更為靈活。
  • 可整合使用不同角色或權限管理,針對專案分工進行細緻控管。
記得確認一下 版本
Python
  >=3.10

安裝整個快速又簡單
python -m pip install langflow -U
Looking in indexes: https://pypi.org/simple, https://pypi.ngc.nvidia.com
Collecting langflow
  Downloading langflow-1.1.1-py3-none-any.whl.metadata (8.5 kB)
Collecting assemblyai<1.0.0,>=0.33.0 (from langflow)
  Downloading assemblyai-0.36.0-py3-none-any.whl.metadata (29 kB)
Collecting astra-assistants~=2.2.6 (from astra-assistants[tools]~=2.2.6->langflow)
  Downloading astra_assistants-2.2.9-py3-none-any.whl.metadata (4.7 kB)


執行上也是
python -m langflow run

2025/01/11 補一下 Flowise
這個的功能跟 LangFlow 非常像,不過目前個人最常用的還是 dify 就是
  • 強調可視化聊天流程設計:支援多階段對話與條件判斷,可配置較為複雜的對話邏輯。 
  • 內建多語種支援及部分翻譯功能,方便在多國際化專案中使用。 
  • 擁有多種資料來源的連接器,輕鬆將 Excel、資料庫、網路 API 等整合供 LLM 使用。 
  • 提供社群支援與插件庫,可快速擴充新功能或套用範例流程。 
  • 從系統層級可監控資源使用情況,並可視需要做水平或垂直擴充。
sudo npm install -g flowise
[sudo] password for twman:
npm WARN ERESOLVE overriding peer dependency
npm WARN ERESOLVE overriding peer dependency
npm WARN While resolving: flowise-react-json-view@1.21.7

npx flowise start
Need to install the following packages:
  flowise@2.2.3
Ok to proceed? (y) y

npx flowise start --FLOWISE_USERNAME=user --FLOWISE_PASSWORD=1234

http://localhost:3000/

2024/05/11 更新了 Dify
  • 提供類似流程圖的任務編排視圖,能直接拖放節點來串聯對話及資料處理邏輯。
  • 內建多種主流 LLM 模型供選擇,並可彈性切換。 
  • 支援使用者管理與登入機制,以及基本的系統監控與日誌功能。 
  • 提供外掛機制 (Plugin) 與向量資料庫整合,可將外部知識庫內容更有效率地植入。 
  • 可與第三方應用整合,並能通過 API 形式將對話功能嵌入至其他系統。
其實官方網站的文件寫的超清楚 XD 然後又有 docker 可以直接用,好像只能截個圖?最主要的還是在於它已經整合了 RAG、Function Call、Agent、WorkFlow,一整個實在是太強大了
就這樣順手整合了一下單據解析 OCR 跟 RAG 的 Q&A 了
上面是上市公司股票資訊的爬取分析;下面則是一個類網路溫度計的Agent
上面是多模態的單據分析,下面是根據工地場景照片,分析可能工地缺失以及抵觸那條法規
下面則是幫忙寫註解跟測試案例的
接這這個就更複雜了,透過內部API來做一些客服的信件回覆
最後來一個很受關注的 RAG 應用





2024/05/04 更新了 RAGFlow


其實官方網站的文件也寫的超清楚 XD 然後又有 docker 可以直接用,好像只能截個圖?

2024/04/12 更新 anythingllm
AnythingLLM是 Mintplex Labs Inc. 開發的開源ChatGPT 等效工具,用於在安全的環境中與文件等進行聊天,專為想要使用現有文件進行智慧聊天或建立知識庫的任何人而建立。 
直接照著做,馬上就啟動了 ! 
docker pull mintplexlabs/anythingllm

export 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

安裝過程略有點小問題要解決,但查到的都是至少要開到5個容器,但目前我用不太到向量資料庫還有LoaclAI等,所以只開了 FastAPI 共兩個
這邊可以看到它本身就具備了 API 可以做整合
至於這裡就可以看到它支援了不少 LLM,最後截一下對話範例圖
當然,最想要的快速把 RAG 佈署好的功能也是有的 !
其實現在有好多LLM Application Development類似的開源,這樣還有什麼商業模式嗎 ?
最後,再來個 QAnything、CrewAI、Phidata 一鍵三連,我覺得也是個不錯的開源的
看了一下官網的範例,直覺上跟AnythingLLM功能很像,但是手邊 GPU 都已經在跑,所以就先跳過這個 XD,是說這裡有篇寫得也蠻清楚的啦
QAnything支援任意格式檔案或資料庫的本地知識庫問答系統
雖然有好朋友贊助機器給我做些開發和測試,但還是希望可以早日再得到老闆贊助

https://microsoft.github.io/autogen/
上下兩個截圖,別是用來做一些基本技能的示範,找到的幾篇文章也都在上面 (官網其實非常齊全,認真看,好好看啊),都可以點去參考學習一下 !

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 做推理加速的踩坑好了