馬克的技術旅程

繼先前在 RTX 5060 Ti 16GB 上折騰完 MiniMax H3 音視訊生成 與 Qwen 3.8 27B 地端部署 後，阿里雲 Qwen 團隊剛發布了開源多模態生圖旗艦模型 Qwen Image 2.1。這款模型號稱具備原生 2K 輸出、支援多圖一致性與強悍的多模態視覺理解。社群最關心的莫過於：16GB 顯存的甜品卡到底扛不扛得住 7B DiT 加上 8B Qwen3-VL 文本編碼器的雙重壓力？會不會一按生成就直接 CUDA OOM 爆顯存？ 我第一時間拉下官方權重，透過 ComfyUI 搭配 INT8 ConvRot 量化展開極限壓測。本文將完整記錄這套環境的部署配置、4.2 MP 原生 2K 解析度實測、ComfyUI 雙工作流（T2I 文生圖與多圖虛擬換裝），以及橫跨東方神話、史詩魔幻全景到 9:16 商業海報的真實 Prompt 調校與渲染表現。 1. 測試環境與模型選型：16GB 顯存的生存平衡術在消費級顯示卡上部署視覺大模型，最棘手的就是顯存開銷。Qwen Image 2.1 採用 7B 參數的單流擴散 Transformer（Single-St...

要在 16GB 顯存的消費級顯示卡（如 RTX 5060 Ti）上部署 27B 至 35B 規模的大語言模型，記憶體配置與參數調校是影響實用性的關鍵。先前因為測試 MiniMax H3 音視訊生成，後台的 ComfyUI 常駐佔用了約 12.9GB VRAM，因此在進行 LLM 評測時，必須先停止 ComfyUI 服務以釋放完整顯存。 在將 16GB VRAM 完整留給 LLM 後，我針對 Qwen 3.8 27B 的多個量化版本以及 Ornith 35B MoE 進行了一週的壓力測試。本文紀錄實測數據、Gated DeltaNet 架構在 CPU Offload 下的效能折損、MTP 投機解碼的記憶體開銷，以及生產環境的啟動配置。 1. 測試環境與軟硬體規格評測使用的本地硬體與軟體環境配置如下： CPU：Intel Core i7-13700（llama.cpp 設定 6~8 threads） RAM：23GB DDR5（加上 /data 磁碟 32GB Swap） GPU：NVIDIA GeForce RTX 5060 Ti 16GB（實際可用 VRAM 約 16,...

MiniMax H3 作為新一代支持音視訊同步生成的原生大模型，其畫面細節與音效對齊能力令人驚艷。然而，動輒雙位數 B 參數量與高解析度 Latent 計算，讓配備 16GB VRAM 的顯示卡（如 RTX 5060 / RTX 4080）在本地部署時面臨嚴峻的顯存極限挑戰。直接使用預設模型與工作流，往往在點擊 Generate 的瞬間就會傳來 CUDA Out of Memory (OOM) 的噩耗。 本文將分享我如何透過 INT8 模型剪枝量化、SageAttention 顯存補丁、Dual-Clock 雙時鐘採樣器 以及 Turbo LoRA，在 RTX 5060 (16GB VRAM) 上成功以 1.0MP (1344x768) 解析度、6 步快速渲染流暢輸出 10 秒音畫同步影片的完整 ComfyUI 實戰與壓測調校經驗，並附上提示詞寫法與硬體選購指南。 1. 成果展示：10秒音畫同步實際生成效果光看數據不夠直觀，以下是使用本文介紹的 1.0MP 6 步工作流，在 RTX 5060 上實際生成的 10 秒長鏡頭短劇畫面（包含自動生成的同步現場音效）： ...

之前執行了一個系統重構的案子，主要的任務是將原本的資料庫從 SQL Server 全面搬遷到開源的 PostgreSQL。原本以為大換血的過程已經平安落幕，沒想到轉換資料庫穩定運行一段時間後，系統卻無預警發生應用程式連不上資料庫的狀況！當下只能先緊急重啟資料庫恢復服務，但這治標不治本。這篇文章就來分享，我如何追查出連線數耗盡的真兇，並透過在 CapRover 部署 PgBouncer 徹底解決問題，最後分享一套我自寫的 PostgreSQL 自動備份到 S3 的實用工具。 1. 遭遇痛點：資料庫連線數耗盡危機連不上資料庫的驚魂夜系統轉移到 PostgreSQL 並部署在 CapRover 上穩定運行了一段時間後，客服突然回報系統發生異常。我一查 API 的 Log，赫然發現滿滿的都是 SqlSugar.SqlSugarException，具體錯誤訊息寫著： The connection pool has been exhausted, either raise MaxPoolSize (currently 100) or Timeout (currently 15 sec...

專案聲明：本專案為個人學習 Web3 與 DApp 的練習專案，大部分程式碼是由 AI 程式助手（如 Codex）協作產生，非生產級別的專業代碼，如有疏漏或錯誤請多包涵，非常歡迎交流指教！ 開源原始碼：markx2008/bsc-gamefi-bot 線上 Demo 站：gamefi.zeabur.app 最近我利用閒暇時間開發了一個 DApp 練習專案 bsc-gamefi-bot。這個專案的遊戲規格，主要是參考了 Telegram 上常見的熱門小遊戲。為打造一個完整的微型經濟體，核心玩法不僅包含三款滿足不同風險偏好的遊戲，更加入了吸引玩家留存的鎖倉理財機制： 硬幣比大小（Coin Flip）：低波動、高頻次。平台設定了 3% 的莊家優勢（House Edge），這意味著長期下來，玩家每下注 100 元，平台就能穩定賺取 3 元，作為基礎利潤。 骰子比大（Dice）：中波動，滿足喜歡調整勝率與賠率的策略型玩家。 幸運轉盤（Lucky Spin）：高波動，包含大獎（Jackpot）機制。為了避免玩家連中大獎瞬間掏空平台的「遊戲金庫 (Game Vault)」...

前幾天接到一個有趣的委託，某個店家希望能做一套「匯率展示系統」，可以直接掛在店內或飯店大廳當作廣告看板。需求聽起來很直白：系統要定時去抓台灣銀行的外幣匯率，然後在畫面上顯示加上「店家利潤」過後的匯率。 說白了，這就是要一台能夠自動更新、自動算好加扣點數的數位看板。 在真的跳下去寫 code 之前，最重要的永遠是先確認「這東西真的能解決問題嗎？」、「店家真的願意為了這個付月費嗎？」。這篇文章我就來分享一下，如何用最低成本、最少開發時間，規劃出一個足以用來驗證市場意願的 MVP（Minimum Viable Product）架構。 1. 核心問題：把力氣花在刀口上開發完整產品很花時間，為了在初期以最低成本驗證買家意願，我們只專注在一件事：真實的銀樓或旅店負責人，看到這個東西，會不會買單？ 所以這個「MVP Lite」版本，我們只做「能讓店家看到效果、能開口談月費」的最少功能，把那些對驗證沒有直接幫助的功能通通砍掉。 那些被我砍掉的功能在規劃初期，我們必須很果斷地捨棄一些過度工程： App 開發（Flutter / Android / Windows）：開發...

隨著專案越長越大，基礎架構的維運成本總是個令人頭痛的問題。最近我將一些服務的部署流程進行了大換血，從原本熟悉的 CapRover 體系，轉移到了最近相當火紅的 Zeabur 平台上。 說白了，這次的轉換不僅讓部署流程變得超級簡潔，還讓我意外發現了 Zeabur 的「神奇網路工具（Wonder Mesh）」，直接把我角落那台生灰塵的閒置電腦變成了雲端部署節點。這篇文章就來跟各位聊聊這次的架構轉換心得，以及如何榨乾閒置硬體的剩餘價值。 什麼是 Zeabur？對於還沒接觸過的朋友，Zeabur 是一個主打「為開發者打造的無痛部署平台」。簡單來說，你只需要把程式碼推送到 GitHub，剩下的建置、部署、網域綁定，它都幫你處理得服服貼貼。 以往我們在建立自己的 PaaS 服務時，可能要搞定伺服器、裝好 Docker、設定反向代理，現在這些繁瑣的基礎建設工作，Zeabur 幾乎都幫你包辦了。它支援各種主流框架（Node.js, Python, Go, Java 等），甚至連資料庫（PostgreSQL, Redis 等）也能一鍵拉起來。 輕量級部署首選：超高 CP 值的主機方案在 Zeab...

在 SaaS 產品開發的路上，收費模式與金流串接絕對是開發者會遇到的魔王關卡。最近在重構點餐系統的店家後台升級方案流程時，為了滿足不同的商業需求，我們同時導入了「PAYUNi 統一金流」與「Creem 訂閱金流」。這篇文章會帶大家看看，我們如何優雅地將這兩種截然不同的金流模式，整合進同一個系統架構中。 為什麼需要兩家金流商？如果你也有做過 SaaS，可能會想：為什麼不選一家搞定就好？說白了，因為不同的商業場景需要不同的武器。 PAYUNi 統一金流：這是深耕台灣本土市場的強大金流，支援信用卡、ATM 虛擬帳號與超商代碼繳費。在我們的系統中，它主要負責「一次性付款」模式，幣別為台幣（TWD）。當我們需要搭配本地的優惠碼活動，或是計算舊方案剩餘天數折抵時，PAYUNi 是非常靈活的選擇。它的運作模式是經典的 Form POST，由前端帶著加密表單導向付款頁面。 Creem 訂閱金流：相較於傳統金流，Creem 是專為 SaaS 訂閱制打造的現代化服務。它以美元（USD）計價，採用純訂閱 Checkout 模式。前端只需一個 URL 就能重新導向到付款頁面，後續的續扣、暫停或取消，...

最近因為專案需求，我深入研究了 Superpowers 這套專案，順手整理了一下它的開發流程與實務心得。原本只是好奇「這東西到底能解決什麼痛點」，結果仔細跑過幾次工作流之後發現，它根本就是一套專為 AI Agent 量身打造的工程紀律框架，早就超越了單純 AI coding 小工具的範疇。 現在很多人把大語言模型（LLM）投入日常開發，最大的痛點往往來自於它太會寫、寫太快，卻完全缺乏架構意識，反而讓人忽略了它到底會不會寫程式這個基本問題。你一句話丟下去，它馬上幫你改檔案、加功能、修 bug，初期看起來極度有效率。但過不了多久，你可能就會面臨以下技術債： 它其實沒有真正理解核心需求，只解決了表面症狀。 測試覆蓋率極低，總是最後才想到要補 Unit Test。 改動範圍如同滾雪球般越來越大，破壞了原本的架構設計。 發 PR 的時候看起來很忙，但不知道到底解決了什麼根本性問題。 最終，身為資深工程師的你，還是得自己回頭「下足重本」去收拾殘局。 Superpowers 想解決的，正是這個業界痛點：讓 Agent 擺脫「盲目寫碼機器」的標籤，強制它遵循一套可靠、具備可驗證性的開發流程...

AI 工具發展的速度有時候真的讓人覺得「才剛摸熟這個，怎麼隔壁又出新招了？」。與其每天盲目追逐新潮的玩具，不如停下腳步，把現有能實質提升效率的工具組合起來，打造一套真正能落地的工作流。這篇文章單純紀錄一下我目前每天都在實戰中使用的開發神器，以及整套從 0 到 1 的 AI 輔助開發流程。 核心工具介紹opencode：更彈性的開源 AI 寫碼助手這款工具號稱是開源版的 Claude Code，實際用起來體驗確實非常接近。但它最大的優勢在於模型選擇的自由度，你可以完全主導要串接哪家 AI 模型。像是我之前介紹過的 opencode Go 方案，就支援多種大陸模型；當然，如果你想接入 Gemini 或最新的 GPT 模型，也都能無痛搞定。說白了就是不受單一生態系綁架，這點在面對各家大廠模型大亂鬥的現在尤為重要。 CLIProxyAPI：統一 API 格式的幕後功臣在使用多種 AI 模型的過程中，最讓人頭痛的莫過於每家的 API 格式跟驗證機制都不太一樣。CLIProxyAPI 完美解決了這個痛點，它允許我們透過 OAuth 方式登入各家的模型服務，並在底層自動將其轉換為統一的 ...