跳到主要內容

發表文章

[野人獻曝] 開個 Stable Diffusion WebUI 的懶人包

前篇提到 Stable Diffusion WebUI, 這次要利用 Google Colab 服務來跑這玩意。 主要流程其實很簡單: 如果還沒有下載模型檔的話, 請先打開主要作業的區塊執行開啟 Google Drive 的權限, 然後再到第三個大區塊中的下載輸入模型檔下載路徑, 下載完成後就可以開始下載 Stable Diffusion WebUI 並準備執行。 如果已經執行過下載模型的話, 可以直接按下主要作業那個大區塊中的執行即可。 當不想玩了以後,請記得按下第二個大區塊的執行。 這個步驟會把該次產生的圖片存回到 Google Drive 內。 網址: https://colab.research.google.com/drive/1irIstg03GHVtXJLVhYLOtNuUy3z7ELz_?usp=sharing
最近的文章

[野人獻曝] 架個 Stable Diffusion WebUI 來生個香香的老婆圖

A.I. 當道後, 什麼以文生文、以文生圖、以文生聲(?)等玩意陸續蹦出來。 別的先不說, 光是以文生圖就有像是 MidJourney 還是 Dall-E 等模型提供相關服務。 而後 NovelAI 自爆自己的以文生圖模型是透過 Danbooru 上收集的圖片所訓練, 外加相關程式碼也不小心外洩後, 你各位紳士們就開始在以文生圖這塊領域中尋找自己的婆了。 不過以上都不是重點, 本文只是想要記錄下 Stable Diffusion WebUI (以下簡稱 SDWebUI)的架設步驟而已。 其實安裝步驟出乎意料的簡單(當然是指在 Google CoLab 上), 只要以下幾個步驟,基本上就能把 SDWebUI 跑起來並且開始生圖: * 確保機器上有 Python 3 以上環境 * 下載 SDWebUI 原始碼,可以直接在 Github 上 clone 下來。 * 下載所需的模型:在產生 ACG 相關圖片的話,目前推薦使用 Anything 或是 Hentai Diffusion 等模型。不過要注意一點:模型檔案越大的話,硬體要求會更高(主要是顯卡的 GPU 和記憶體等級)。如果沒滿足需求的話可能會跑不起來 * 切換到 SDWebUI 目錄,執行以下指令開始跑 SDWebUI 的設定,會在這個步驟安裝其相依的 Python 套件並處理相關設定: COMMANDLINE_ARGS="--exit" REQS_FILE="requirements.txt" python launch.py *  把前面步驟所下載的模型檔案,搬移到 SDWebUI檔案目錄/models,例如 clone 到 /home/user/stable-diffusion-webui 的話,就把模型檔複製到 /home/user/stable-diffusion-webui/models 下。 * 執行以下指令,等待跑完以後,畫面應該會顯示一組 xxx.gradio.xxx 的網址,可以讓自己或朋友連進來玩(網址 72 小時內有效)。如果只是自用的話,也可以用 localhost 的網址開啟服務: COMMANDLINE_ARGS="--share --gradio-debug" REQS_FILE="requirements.

[野人獻曝] Google App Engine ...... 的踩雷

最近因為要把用 Go 寫的一些 API 搬到專用平台跑又不想花錢, 想到 App Engine 有免費方案, 所以看了一下就先搬一兩隻進去跑了一個禮拜後, 昨天好奇瞄了一下帳單後大吃一斤, 發現才跑一個星期就有 16 鎂的帳單! 再仔細翻一下文件發現這其中的奧秘...... App Engine 分成兩種運作環境, 一為標準,另一個則為彈性。 前者有提供免費方案,依照選擇的類型不同,可能會有一天 28 或 9 個的免費時數可用; 後者完全沒有免費方案,一開下去就立刻算錢。 而我用的正是彈性,所以一開下去就馬上燒錢 Orz 話說回來了,到底標準和彈性環境有什麼差別? 標準環境的特色: 使用的程式語言版本基本按照 App Engine 要求。以 Go 為例,他該死的就只支援到 1.16 ,想用 1.17 以上的版本,你只能使用彈性環境。 有免費方案(不是重點 運作系統規格只有籠統的 F1 / B1 這種讓你選,就算想要記憶體多一點你也只能選更高的等級。 AutoScaling 只能設定標準由 App Engine 自行控制 想在運作環境裝一些額外的東西嘛......應該是不行。 彈性環境的特色: 可以自己寫 Dockerfile ,所以要什麼東西用什麼語言環境,你自己決定 沒有免費方案(依然不是重點 運作所需的 CPU 核心和記憶體數量可以自訂,只要符合基本要求即可 AutoScaling 機制可以手動也可以自動控制 可以 SSH 登入,想查什麼東西還蠻方便的說 所以你知道為什麼彈性環境沒有免費方案了吧(眼神死 ====================== 不過根據使用和昨天翻文件下來, 我覺得 App Engine 彈性環境遠比 AWS 的 ECS Fargate 更懶人包。 前者只需要專注在程式撰寫和設定所需運作的環境,基本上沒什麼事要做了; 但後者除了上述的東西外, 還需要自己設定從 VPC / Security Group / Load Balancer 等一狗票東西, 老實說還挺麻煩的。 ====================== 不過地雷還是有, 在寫 App Engine 的 app.yaml (運作環境設定檔)時, 關於 auto_scaling 的相關設定必須要特別注意, 如果沒特別宣告的話, 會讓你的服務可能一開始就開出兩個 instance 運作

[野人獻曝] 關於建立 AWS 服務架構的工具

通常為了要達成 IaC 的目標, 架構師還是 DevOps 工程師都會用很多工具來達成目標。 而比較通用的工具大概會是 Terraform / Ansible 之類的。 不過實際狀況是因為 AWS 服務眾多反而是使用 AWS 自家工具來做還比較方便。 所以用個表格來比較: 比較表 AWS CDK / CDK For Terraform GoFormation 原生 CloudFormation JSON / YAML 優勢 較為高階,有些細節不用特別處理(例如建立 Subnet 不用自己額外寫 RouteTable 那些東西) 跟程式語言結合,使用起來比較可讀好懂 跟 Terraform 結合的話要學的東西相對比較少一點 最接近原生 JSON / YAML 寫法,但又擁有建立每個資源時很快就可以知道要丟什麼東西進去的優勢 跟程式語言結合,可以做一些靈活變化 原生寫法不解釋 如果有新東西的話通常會第一支援 弱勢 因為太高階,比較細項的修改反而變得很麻煩 老實說,我覺得好像沒什麼弱勢!大概只有部分函式不能用還有需要產生檔案比較麻煩一點 很低階,所以在寫的時候要搭配文件才能知道需要丟什麼東西進去 一不小心會寫出上千行的檔案,也會不小心改錯項目出包

[野人獻曝] AWS Certified Solutions Architect 認證考試心得

大概是去年聖誕節前夕, 不知道被什麼打到, 突然想考一張 AWS 認證考試, 所以就很突然地報了 AWS Certified Solutions Architect - Associate 的考試! 為了那場考試我還買了對岸出的翻譯教科書( 原文版 、 簡體版 )讀。 只是......因為我真的很不會讀書, 外加我上班真的超懶, 那本書我只看了前面幾章, 然後隨便做了書內的練習題和 Google 到的考古題, 就直接上場考試了! 雖然是很有驚無險地通過了啦(720 分通過,我考 761 分)..... 然後今年十一月左右也是因為很突然就離職, 所以也是很突然就決定再去報 AWS Certified Solutions Architect - Professional 的考試! 這次考試比之前稍微認真一點, 除了把那本教科書的後面幾章......的練習題重做外, 也開始狂 K 官方的訓練課程, 外加又多冥想了各種考題方向, 也順便自己開了一些不常用的服務練習(估計帳單也......), 大概是花了一個星期時間專心(?)準備! 這次也依然是很驚險地通過(750 分通過,我考 797 分) ====== 以上都是廢話 ===== 其實我去年考的時候還不知道認證架構師是最難的考試, 不過考完架構師考試後, 其實就會理解到 AWS 認證架構師就某種程度是最了解 AWS 架構的人, 如果一間公司全部使用 AWS 服務的話, 這傢伙應該就是部門的 Center ! 只是有沒有必要考到 Professional 等級就因人而異啦, 畢竟 Professional 級的考題很刁鑽, 遠比 Associate 級更為刁鑽, 除了出現一堆你壓根沒聽過的 AWS 服務外(我看到考題才知道有 EFA 這玩意), 還需要你從安全面、成本面、可維護性去思考架構該怎麼設計(其實 Professional 級這幾個面向的考題遠比 Associate 多), 這就很吃使用經驗和你有沒有想過最佳實踐。 如果是半吊子以為只是比 Associate 難一點點就上場去考的話, 保證很容易就會 GG ! 再次聲明:我真的只是好運考過的 QQ ====== 怎麼準備 ===== 其實不是很建議無謀地只讀教科書就去考! 最好是先有一段時間的 AWS 操作經驗, 至少要理解 VPC / SecurityGroup

[野人獻曝] AWS CDK8S 初步使用筆記

說到 K8S 喔,就不得不提到那精美的 YAML , 當你想佈個 Service / Deployment 時, 可能會因為你常打還知道怎麼打出來! 一旦你要用的元件是不常用的時候, 你應該會很幹的去翻 K8S 官網文件查! (就跟我之前為了要寫 AWS Cloudformation 時還要翻那該死的文件一樣) 因此 AWS 推出 CDK8S , 讓你開發時比較不需要花太多時間翻文件! CDK8S 目前支援 TypeScript / Python / Java, 不過這裡直接用 TypeScript 做個說明好了。 安裝 CDK8S 工具 npm install -g cdk8s-cli 建立新專案 mkdir /helloworld cd /helloworld cdk8s init typescript-app 開始開發 打開專案的 main.ts ,那就是開發的起點了! 部署 雖然一般都會直覺想到用 npm run build , 但是實際上這會跑 compile / test / generate yaml 三個動作。 在還沒有寫測試之前,建議直接跑 npm run compile && npm run synth , 這樣就能直接產生 K8S 所需要的 YAML(在 dist/ 目錄內) 接著輸入 kubectl apply -f dist/* 就可以開始部署到你的 K8S Cluster 上。 感想 老實說,這其實是個還蠻方便的玩意, 除了常用的一堆元件外, 也可以針對各種少見但就是會用到的元件寫自己的宣告(?), 下次要寫的時候可以提示哪些參數是必須或是該填些什麼, 能夠省下每次翻文件的時間。

[野人獻曝] AWS Go CDK 初步使用筆記

AWS 之前推出了 Cloud Development Kit (CDK) 工具, 讓以前寫 YAML 透過 CloudFormation 建立資源的麻煩和不便減少許多, 只是彼時只支援 C#、Java、JavaScript / TypeScript 以及 Python。 不過最近開始支援 Go 了, 所以我就來稍微試用一下! 為了要使用 CDK Go, 必須確認開發機器上是否有以下工具: aws-cdk :CDK 工具,可以透過這個工具進行建立新專案 / 部署等動作,最新版本: 1.100.0。 Go :由於 CDK 會使用到 Go 內建的 embed 套件,所以版本必須為 1.16.x 以上 aws-cdk-go :CDK 的 Go 函式庫,目前還在 preview 階段,最新版本是:1.100.0 以上工具安裝完後,即可開始建立新專案。 建立新專案 建立一個目錄後並切換到該目錄, 接著輸入: cdk init --language go  然後就會在該目錄下建立出相關的專案檔 開發 使用你習慣的 IDE,打開以該目錄為檔名的 .go 檔, 你所有需要的程式碼即會集中在這裡。 部署 輸入以下指令即可開始部署作業: cdk deploy 輸入以下指令則可以確認這次修改後會有什麼樣的資源變動 cdk diff 輸入以下指令則可以刪除 cdk destroy 注意事項  CDK 有兩種類型的物件: awscdk.NewCfn* 和 awscdk.New* , 前者是為了仍在使用 YAML 操作重複類型資源的狀況下使用, 只需要帶入模板檔路徑與該模板所需參數即可建立相應資源; 後者則偏向懶人包, 可以在建立資源時一併設定其他相依資源的屬性以便一起建立, 如果未設定的狀況下也會以預設的屬性直接建立。