雜談：總算把架設了Stable Diffusion WebUI Forge / TALK: Finally Set Up Stable Diffusion WebUI Forge
由於之前硬碟毀損，導致我用來做AI繪圖的Stable Diffusion環境全部消失。這次乾脆全部重來，用Stable Diffusion WebUI Forge重建整個繪圖環境吧。
Stable Diffusion環境與Docker / Stable Diffusion Environment and Docker
大家會把Stable Diffusion的環境架設在哪裡呢？
網路上大部分的教學都是基於Windows的環境。一方面是因為使用者眾多、為Windows環境開發的懶人工具也很多；二來是Windows環境也相對單純，WSL2穩定的表現讓人印象深刻。不過這些都跟我這個Linux使用者沒有關係。
Linux使用者常常會受到發佈版和套件相依之苦，安裝系統和轉換的時候往往會遭遇很多困難。現在有許多方案都在嘗試解決跨平臺(Linux自己的平臺)的各種問題，有針對套件管理的AppImage、snap、Flatpak、有針對運作環境的distrobox、也有強調Windows相容的PlayOnLinux、Bottles。
不過在伺服器的情境下，Docker應該還是目前最多人選擇的虛擬化方案。在使用Linux電腦的這三年之間，我認知到這電腦就是註定常常損壞的設備。因此我所建立的系統環境首要目的就是容易管理、容易遷移，而這也是我選擇Docker的原因。
https://github.com/AbdBarho/stable-diffusion-webui-docker/blob/master/README.md
因此，一開始我的Stable Diffusion環境是基於AdbBarho所建立的stable-diffusion-webui-docker來架設。當時AdbBarho很用心地將Stable Diffusion主流的創作環境AUTOMATIC1111、ComfyUI、Sygil-webui、InvokeAI都整合了進來。我們在啟動Docker的時候可以自由切換需要的環境。而各個環境背後使用的模型，則在Docker巧妙的設定中能夠共享。
這些不同的環境在瞭解探索Stable Diffusion的初期讓我覺得非常有趣，不過使用到最後，其實主要還是用AUTOMATIC1111搭配強大的擴充功能、以及ComfyUI能結合Kirta繪圖而已 (題外話，網路上搜尋個相關介紹，怎麼一直跑出來Ivon的部落格，你也太會寫了吧！！)。另一方面，AdbBarho雖然也有持續更新專案，但他也沒有結合後來許多基於AUTOMATIC1111擴充版本，例如Forge。而且由於AdbBarho複雜的檔案架構，使得我也很難去修改或升級專案，只能這樣繼續用下去。
Stable Diffusion的效能頻頸 / Stable Diffusion Performance Bottlenecks
https://www.razer.com/tw-zh/gaming-egpus/razer-core-x
雖然使用Docker架設Stable Diffusion的運作環境是可行的，但這不代表Stable Diffusion就能夠順利運作。整體來說，Stable Diffusion的效能頻頸會卡在兩個地方：顯示卡、儲存空間。
Stable Diffusion的運作極度仰賴GPU的運算能力，也就是顯示卡。雖然目前也有用CPU運作Stable Diffusion的做法，但效率低到不具使用價值。你看看Ivon的抱怨就知道了。而我選擇的是用Razer Core X透過Thunderbolt 3外接GPU的方案，用USB Type-C外形的Thunderbolt 3連接線，接上Lenovo L13 Yoga筆電來運作。對了，順便說一下，由於Stable Diffusion在AMD顯示卡的運作環境還不太穩定，而且大部分仰賴CUDA的人工智慧運算都是仰賴NVidia顯示卡，所以目前我並不考慮NVidia顯示卡之外的選擇。
如果你的作業系統是Windows，那外接顯示卡方案運作起來通常很穩定。但如果是在Linux環境裡，這種eGPU方案可以用，但配置過程非常辛苦，而且還常常出錯。例如我在之前就寫過「Linux開機卡在「Started Load/Save RF Kill Switch Status」」的問題，真的是非常困擾。
這個問題可能出自於NVIDIA驅動程式在Linux環境中不夠穩定，Linux系統的軟硬體變更都很容易導致NVIDIA驅動程式的崩壞。但我認為最大的問題應該還是出自於「外接」硬體本身就很不穩定，再加上我的筆電也是會到處移動、線路拔拔插插，這些問題就常常在拔插USB線路的時候發生。
唉，本來是期望移動的便利性所以選擇了外接方案，反而帶來了更嚴重的不穩定問題啊。
Stable Diffusion另一個問題也跟外接方案有關。我在筆電上運作Stable Diffusion，然而Stable Diffusion所需要的模型，隨隨便便就動輒5GB以上。記得當時光是嘗試各種模型的組合，硬碟空間就用掉了200GB多。對內建空間只有512GB的筆電來說可真的是房間裡面的大象了。
為此我準備了外接的SSD硬碟外接盒，搭配SSD硬碟跟高速USB連接線，將Stable Diffusion運作所需的檔案和模型放在裡面。一開始的確是可以運作，但用著用著才發現不太對勁，整個系統卡到不行。仔細檢查後我才發現原來另一個瓶頸是這個SSD外接盒，不是SSD本身的速度慢，而是USB在外接的過程中受到速度的限制，而使得整個系統跟著被拖慢。
一般人可能很難理解什麼叫做被USB的速度拖慢。如果你使用USB的情況是傳輸10MB以下的文件檔案，那大概不太會有什麼感覺。但是Stable Diffusion的Checkpoint基礎大模型就是5GB以上，而搭配使用的數個LoRA也大概都有500MB以上的大小。也就是說，在開始使用Stable Diffusion之前，我們必須傳輸約7GB的資訊量給顯示卡，接著才能開始運作，然後畫出上面那張圖。
顯然的，這對一臺筆電跟一堆外接設備來說，這個架構太過苛刻了。所以後來我決定另外找一臺電腦來負擔此任務。
在Proxmox VE上架設Stable Diffusion / Setting Up Stable Diffusion on Proxmox VE
由於常常要搬家的考量，再加上我也不想捨棄外接顯示卡的硬體，我這次也是沒有買普通的臺式電腦，而是將目光移動到小型電腦上。摩方Morefine是中國常常推出小型電腦的廠商，這臺M600另一個特點是支援Thunderbolt 4外接顯示卡方案，而且可以直接在電腦裡面安裝SSD硬碟，解決了我上述的外接SSD硬碟和帶來的速度瓶頸。
我在M600上安裝了Proxmox VE 8，然後在裡面安裝能夠運作Docker的虛擬機器環境，這樣就能把我裝在Docker裡面的Stable Diffusion遷移過去。這裡面我用了PCI硬體直通(PCI Passthrogh)的方式，讓虛擬機器能夠抓到外接顯示卡跟SSD硬碟。
這裡的虛擬機器使用的是KVM的VM方案。原本我比較想用LXC的CT方案，並參考LXC 直通顯示卡 - PVE 7的做法來設定看看。但Proxmox VE 7跟Proxmox VE 8的核心套件有些不同，導致最後一直沒辦法在Proxmox VE 8設定NVIDIA Driver。只好退而求其次，使用KVM的直通方案。
值得注意的是直通SSD硬碟的問題。目前Proxmox VE並不能讓人在網頁介面新增硬碟的PCI設備，只能在命令端靠指令去設定。而且這種直通SSD硬碟的設定會導致備份、復原的過程出錯。我們必須先移除SSD硬碟的直通、備份，然後在開機之前把SSD硬碟的直通設定新增回去。手續複雜很多。
多虧當初用Docker封裝了Stable Diffusion的運作環境，其實我主要只是透過PCI直通讓虛擬機器抓到SSD硬碟裡面的檔案，以及連上外接顯示卡，這樣Stable Diffusion的環境就可以運作了。
儘管運作起來速度並沒有想象中的快，但反而是在另一臺電腦上慢慢跑，我的筆電只是用瀏覽器遠端控制Stable Diffusion WebUI產生圖片，不會拖慢我本來筆電的速度。我也就用這樣的架構，繼續使用Stable Diffusion畫圖。
SSD硬碟毀損 / SSD Drive Is Unusable
然後過了半年，SSD硬碟就壞了。
在我幾次將Proxmox VE開關機的過程中，赫然發現跑Stable Diffusion的虛擬機器一直無法啟動。仔細檢查，赫然發現是因為虛擬機器無法用PCI直通連上SSD硬碟。我將SSD硬碟拆下來，用外接硬碟盒讀取看看，結果也是無法正常讀取裡面的檔案。
沒辦法，只好趁保固內送去Kingston換一條了。還好Kingston的售後服務做的很好，表單填一填，等待受理審查完成、取得維修單號，就可以把壞掉的SSD硬碟寄回去。而過了不到一週，Kingston就送了另一條全新的SSD硬碟回來，真的很感謝他們的幫忙。
不過，原本我在SSD硬碟裡面保存的資料，也都回不來了。SSD硬碟上不僅僅只是我用Stable Diffusion畫出的圖片，還有繪製該圖片所需要的模型檔案，全部都要重新找尋。儘管當初我用Docker封裝了Stable Diffusion的運作環境，但因為模型檔案太大，而且時常需要變動，我就只是把模型檔案擺在SSD硬碟裡面，沒跟Docker放在一起管理。沒想到最後會因為SSD硬碟毀損，導致模型檔案也一起跟著消失啊。
這件事情告訴我們，也許真的不要在Proxmox VE的PCI直通掛載硬碟吧。好像真的很不穩啊...
架設Stable Diffusion WebUI Forge / Setting up Stable Diffusion WebUI Forge
https://www.youtube.com/watch?v=zqgKj9yexMY
好吧，過去的事情也救不回來，不如趁這個機會，嘗試看看新的做法吧。這次我的目標是架設近年來為人稱道的Stable Diffusion WebUI Forge，並且重新規劃模型檔案跟產圖結果的資料位置，最後還要能跟Dify整合。
https://github.com/ai-dock/stable-diffusion-webui-forge/blob/main/README.md
老樣子，我一開始也是先看看有沒有用Docker封裝的Stable Diffusion WebUI Forge方案。我先是看上了ai-dock整理的結果，然後試著裝裝看。但整個過程非常不順利，ai-dock包裹了很多我不太確定是用來作什麼的套件，但唯獨最後Stable Diffusion WebUI一直無法順利啟動。
找來找去，一直沒能找到看起來比較合適的Docker方案。於是我轉念一想，其實Forge在Ubuntu裡面看起來也不是這麼難啟動，我何不要直接用Docker自己配置好環境跟資料夾，然後自己寫腳本來啟動Forge就好了呢？
以自己設定Docker的念頭來配置Stable Diffusion WebUI Forge，反而很快就把Stable Diffusion WebUI Forge架設起來。過程中比較麻煩的是PyTroch、xformers等運算套件體積非常大，調整配置後重新安裝時很花時間。除此之外整體配置大致上都能夠符合我的預期，Stable Diffusion WebUI Forge的全套內建擴充功能一下子就蹦出在網頁上了。
而且因為是自己瞭解的資料夾配置方式，我也把模型、輸出資料夾檔案掛載到NAS上，虛擬機器本身依然只有Docker跟Stable Diffusion的運作環境。我本來以為走Samba掛載NAS的方式讀取模型的速度會很慢，但實際上Gigabit等級的網路速度竟然讓我覺得沒有差太多，真是意外。不過也許會在大量使用Stable Diffusion之後才會實際感覺到問題吧。
最後是在Dify裡面介接Stable Diffusion。只要在webui.sh啟動指令加上參數「--api」，我們就能在Dify連結Stable Diffusion。讓我驚訝的是，我們不僅僅能在Dify的Stable Diffusion WebUI節點裡設定PROMPT，還能設定LORA、STEPS、WIDTH、HEIGHT、NEGATIVE PROMPT、SAMPLING METHOD這些常用的參數。儘管這跟ComfyUI相比遜色不少，但也保留了一定的可自訂範圍，讓我們能將Dify的工作流與Stable Diffusion整合。
小結 / In Closing
到目前為止，我雖然將Stable Diffusion WebUI Forge架設起來，能夠開始使用Stable Diffusion繪圖，但若要繪製希希助教這樣的形象，還是有一段很長的距離要走。我得要重新檢查之前繪圖時使用的模型檔案，一一把相關的Checkpoint、LoRA、embedding都找回來，才有可能再度讓希希助教出場。
除此之外，我也想用Stable Diffusion繪製我在其他地方需要使用的圖示或背景。之前我會用Bing Image Creator跟ChatGPT繪圖，但儘管控制了提示詞的結構，它們產生的圖片還是會跟我的預期有所落差。希望擁有複雜功能的Stable Diffusion WebUI Forge能夠如我預期地順利運作。而且如果要更有系統地產生出穩定品質的圖片，ComfyUI的架設就會是必須面臨的挑戰。
總而言之，Stable Diffusion的繪圖之路依然漫長。我不奢求要畫出什麼藝術比賽得獎作品，也不需要以假亂真的電影片段，只要在我工作需要插圖的地方，好好產生合適的圖片即可，這樣我就滿足了。
