原來整理 GPU，也是在做裝箱演算
原來整理 GPU，也是在做裝箱演算

原來整理 GPU，也是在做裝箱演算法 最近在研究本地 AI 推理環境時，遇到一個非常有趣的問題。 我的測試主機配置了三張 RTX 3060 12GB 顯示卡。其中兩張透過 PCIe x16 運作，另一張則作為亮機卡使用，只連接 PCIe x4。 乍看之下，總共有 36GB VRAM 可供運用。然而在實際部署大型語言模型時，事情遠比想像中複雜。 有些模型可以獨立運行於單張 GPU；有些模型則需要跨兩張 GPU 分攤權重；還有些模型雖然容量不大，卻需要與其他服務共同分享有限的記憶體空間。 這讓我開始思考一個問題： 如何讓有限的 GPU 資源，發揮最大的模型部署效益？ Bin Packing：經典的裝箱問題 深入研究之後，我發現自己面對的其實是一個經典的電腦科學問題：Bin Packing（裝箱問題）。 所謂裝箱問題，可以用生活中的行李打包來理解。 每張 GPU 就像一個行李箱。 每個 AI 模型就是一件行李。 GPU VRAM 就是行李箱容量。 模型大小則是行李體積。 目標是在不超過容量限制的前提下，把所有行李放進有限的箱子裡，並盡可能提高空間利用率。 這看似簡單，實際上卻是著名的 NP-Hard 問題之一。 真實世界比數學題更複雜 如果只是比較模型大小與 VRAM 容量，問題其實不難。 然而在實際部署環境中，還會出現許多額外限制： 某些模型禁止部署於亮機卡。 某些模型必須跨兩張 GPU 運行。... » read more

0
Read
steven
AI 時代最容易被遺忘的能力：保留替代路徑
AI 時代最容易被遺忘的能力：保留替代路徑

AI 時代最容易被遺忘的能力：保留替代路徑｜PCPiLOT PCPiLOT 技術觀點 AI 時代最容易被遺忘的能力：保留替代路徑 Mr. τ／風雲網通系統　·　2026 昨天找鍵盤滑鼠的 USB 接收器，找了半天，沒找到。工作用電腦沒有輸入裝置可操作，第一個反應很直接：上網下單。火箭速配，Logitech MK275 一組，昨夜按下去，今天到貨。這大概也是現代人最自然的解法——缺什麼，就買什麼。 等貨的空檔，腦子突然轉了一圈。 我家地下室不是有一堆有線鍵盤滑鼠嗎？ 於是下樓翻找。一落整理好的 PS/2 鍵盤，挑了一把看得順眼的；牆上掛鉤還有幾支 USB 有線滑鼠，拿下一支，插上去，電腦重新上線。MK275 還在物流車上，問題已經解決了。 看起來只是件小事。但事後回頭想，真正有意思的地方不在於我找到了鍵盤，而是：我第一時間想到的是購買，而不是盤點現有資源。效率，正在悄悄改變我們解決問題的方式。 公理號的隱喻 《瓦力》（WALL-E）中的公理號（Axiom）是個有趣的隱喻。船上一切都被最佳化了：移動由懸浮椅代勞，資訊由螢幕主動推送，生活由自動化系統全面照顧。人類不需要規劃，不需要修理，不需要尋找替代方案，更不需要處理意外狀況。 這艘船最可怕的地方，其實不是機器人管理人類，而是整個系統已經把「解決問題的能力」從人類身上逐漸抽離。當一切正常運作時，這種設計看起來非常成功。但當系統失效時，人類已經失去了接手的能力。 皮克斯在 2008 年就把這個場景拍出來了。不是預言，是觀察。 企業現場也在發生同樣的事 這讓我想到許多企業資訊系統的現況： 交換器故障了 買新的 NAS 空間不足了 買新的 伺服器效能不夠了 升級硬體 AI 額度不夠了 升級方案 這些決策未必錯誤。但很多時候，問題並非資源不足，而是對既有資源缺乏理解。 許多企業追求極致效率時，最先被犧牲的往往就是那些看似多餘的東西：備品庫存、備援設備、技術文件、知識庫、交接紀錄、替代流程。它們平常不產生營收，看起來佔空間，甚至讓人覺得浪費成本。於是被逐步裁撤。直到某位資深員工離職、某台核心設備故障、某個雲端服務中斷，大家才發現，系統其實沒有第二條路。 那落 PS/2 鍵盤的系統工程意義 回到那批 PS/2 鍵盤。它們平常幾乎沒有存在感，甚至十年都未必會被拿出來一次。但昨天，它們扮演了重要角色。 從系統工程的角度來看，它們其實就是一種 Cold Standby——平時閒置，必要時接手。 關鍵前提 我能翻出那落 PS/2 鍵盤，有一個前提——我當初沒有丟掉它。這不是節儉，也不是囤積癖，而是一個主動的決策：對未來不確定性的預判與準備。... » read more

0
Read
steven
Prototype 能動，不代表 Product 能活
Prototype 能動，不代表 Product 能活

軟體工程 AI 協作 SMB 數位轉型 委外 CKO Prototype 能動，不代表 Product 能活 AI 時代的「原型膨脹幻覺」與複雜度治理，一篇給想動手者、也給評估委外者的清醒文 這兩年，很多人第一次有了「原來我也能做軟體」的感覺。 對著大型語言模型（LLM）下幾段精準的指令，網頁登入畫面會自己長出來，資料庫結構會自己建，API 串接、Docker 容器化、前後端框架——AI 助理都能在幾分鐘內幫你完成初稿。這是一個非常真實的突破。過去阻擋許多企業與領域專家的，是程式語言本身的高門檻。而現在，那道牆正在鬆動。 許多原本因為「缺人缺錢缺時間」而永遠啟動不了的專案，終於第一次有了「從 0 到 1」的可能性。這件事，我們是真心欣喜的。 但也因為進入門檻的全面民主化，市場正在出現一種全新的治理盲區——我們在現場看了二十年，必須把實情說清楚。 📌 什麼是「Prototype Inflation（原型膨脹幻覺）」？ 越來越多團隊第一次成功做出了 Demo，看著畫面上會跑會動的介面，就誤以為自己已經完成了產品。網路上充滿「用 AI 10 分鐘做一個 App」的激情短影音，卻極少有人以「在 Production 生產現場活過二十年」的視角，冷靜地指出後面那個會爆炸的修羅場。 Prototype 能動，不代表 Product 能活。 這句話，是這篇文章最想傳遞的一件事。 先說給「想自己動手」的你聽 LLM 是一個真實的能力放大器。如果你在自己的領域有深厚的知識與經驗，你現在確實是最適合動手嘗試的一群人——因為你知道痛點在哪、知道答案對不對、知道什麼才算「真正能解決商業問題」。 但是，軟體工程是非常現實的事情。Demo 階段的美好，和實際營運階段的考驗，是兩個完全不同的世界。當你的系統脫離實驗室、準備承擔商業責任時，真正的複雜度治理挑戰，才正要開始。 如果試了之後發現自己或內部團隊確實不那麼擅長軟體架構與生命週期管理——請點頭承認，這也是非常正常且理性的經營判斷。交給相熟且具備實戰經驗的 IT 專家處理，是最務實的選擇，不是認輸。 ⏳ 時代的隱形風險：限制消失了，系統在理解複雜度前就已長大 在過去，軟體開發緩慢的步調，某種程度上其實是對企業的一種隱形保護。因為開發慢、成本高，團隊在初期就會被迫面對各種預算、人力與技術限制，這反而促使團隊提早去思考模組劃分、運維流程與權限資安。 但 AI 時代打破了這個保護機制。現在最大的風險，不是做不出系統，而是開發速度太快了——快到團隊還來不及建立系統防禦力，就已經利用 AI 把系統盲目堆大了。這種缺乏地基的補丁式系統，一旦進入市場，隨之而來的工程現實一個也逃不掉。... » read more

0
Read
steven
用 AI 做決策這件事，其實是火箭工程的延續
用 AI 做決策這件事，其實是火箭工程的延續

工程思維 × 知識管理 用 AI 做決策這件事，其實是火箭工程的延續 從挑戰者號到多模型投票機制——容錯從電路搬到了語言層 Mr. τ／風雲網通系統  |  PCPiLOT 知識管理實驗室 最近在收斂一個客戶專案的解決方案規格時，我刻意做了一個設計上的決定： 不再依賴單一 AI 給答案，而是同時讓 3～4 個模型互相審查、主動挑錯、填補盲點，最後才收斂成可以落地的方案。 這件事乍看像是「AI 工具的用法選擇」，但它其實更像一個老到不能再老的工程問題：如何避免關鍵系統在最後一刻因為「大家都同意」而悄悄崩潰。 1986 與 2003：不是技術失誤，是裁決機制失敗 挑戰者號（1986）與哥倫比亞號（2003）的兩場災難，事後復盤都不是單點錯誤，而是暴露出同一種結構性缺陷： ✗ 工程師的警告訊號存在，但在層層彙報中被稀釋 ✗ 邊界條件被逐步「正常化」——這次看起來跟上次一樣，應該沒事 ✗ 最終裁決壓縮成一個二元問題：Go / No-Go，沒有灰度，沒有異議空間 真正的問題不是火箭的材料或設計，而是：錯誤被系統性地放行了。決策系統說服了自己「這次應該也沒事」。 火箭工程早就給過答案：TMR 三模冗餘 阿波羅任務與土星五號時代的導航電腦，採用了一個當時極為硬派的工程解法——TMR（Triple Modular Redundancy，三模冗餘）： 機制 說明 三套獨立系統 同時計算同一個問題，彼此不知道對方的答案 硬體投票裁決 少數服從多數，異常值直接被隔離 無 rollback 設計 太空中沒有重試機會，容錯必須在決策當下完成 這個設計的核心哲學不是「讓系統更聰明」，而是：假設任何單一系統都可能出錯，所以在架構上就不允許它單獨做最終裁決。 現在的 AI，重新打開了同一個問題 單一大型語言模型的問題不在於能力不足，而在於它有幾個結構性弱點： ▸ 幻覺（Hallucination）——以高度自信的語氣輸出不存在的事實 ▸... » read more

0
Read
steven
AI 不再是「大雄的安慰機器人」
AI 不再是「大雄的安慰機器人」

AI 不再是「大雄的安慰機器人」 今天是第二場次的中小企業知識系統推進簡報與交流。 這次主要分享近幾個月大型語言模型（LLM）在企業現場的應用演進， 以及「地端 AI + 雲端 AI 協作」逐漸成熟後，中小企業可以真正落地的實作模式。 很多企業主對 AI 的理解仍停留在：寫文案、摘要、做簡報。 但實際上，架構已經開始往「企業雙層思考系統」演進。 地端 AI × 雲端 AI 的分工開始成形 地端 AI 可以處理企業內部的第一層知識與資料： 內網資料整理與索引 私有文件檢索與分析 NAS / ERP / SOP 系統串接 第一線設備與網路資料監控 雲端 AI 則負責更高階的推理與整合： 策略規劃與決策輔助 跨領域資訊整合 高階文件生成與整理 抽象問題建模 兩者結合之後，其實已經形成一種「企業第二思考層」的雛型。 中小企業反而更有機會 有趣的是，這一波 AI 架構轉變，中小企業不一定落後，甚至可能更有優勢。 因為 SMB 的特性是： 決策距離短、現場經驗集中、問題回饋速度快。 真正的瓶頸往往不是資料不足，而是： 如何把「隱性經驗」轉換成「可累積的知識系統」。 AI 的真正角色，不是安慰，而是放大觀察力 AI 很擅長整理與生成內容，但真正的洞見仍然來自第一線的經驗。 企業主與主管往往已經知道：... » read more

0
Read
steven
2026 Local AI 的典範轉移: 從「硬體軍備競賽」走向「系統工程調校時代
2026 Local AI 的典範轉移: 從「硬體軍備競賽」走向「系統工程調校時代

從「硬體軍備競賽」走向「系統工程調校時代」 風雲網通系統 ｜ 技術深度報告 2026 Local AI 的典範轉移 從「硬體軍備競賽」走向「系統工程調校時代」 LOCAL AI MoE ARCHITECTURE llama.cpp SMB AI 落地 許多中小企業（SMB）在評估地端 AI 落地時，最常聽到一個問題：「我們是不是非得採購動輒數十萬的高階 AI 伺服器，才能跑動夠聰明的大型語言模型？」 在傳統「暴力堆砌硬體（Hardware Brute Force）」的思維下，答案似乎是肯定的。然而，邁入 2026 年，Local AI 的技術底層已悄悄迎來一場革命性的典範轉移。 實測案例 ／ 觸發本文的關鍵數據 技術頻道 Codacus（YouTube）發布實測影片《Running a 35B AI Model on 6GB VRAM, FAST》，以一張 8 年前的 GTX 1060 6GB、搭配 i3 處理器與 24GB DDR4，成功流暢運行 350 億參數（Qwen 3.6 35B... » read more

0
Read
steven
資深 IT 工程師如何用 AI 對話，把二十年現場經驗轉化成可傳承的方法論
資深 IT 工程師如何用 AI 對話，把二十年現場經驗轉化成可傳承的方法論

知識中心 · 方法論 · 2026-05-20 · Mr. τ｜風雲網通系統有限公司 起點很小很具體：只是想做一個 MTU 自動偵測工具，解決 DrayTek 搭配中華電信 PPPoE 時，LINE 電腦版卡在「正在搜尋最佳網路環境」的問題。結果這一聊，就像打開了一個開關。 對話是怎麼一層一層往上走的 和 AI 的對話沒有停在技術細節，而是像螺旋一樣，一層一層往上旋轉。 層級提升的對話過程 v0.8 腳本怎麼寫？PPPoE MTU 1492、MSS 1452、PMTUD Black Hole 成因——純工程師思維。 ↓ v1.0 這份報告要怎麼寫，才不會被客戶資安部門打回票？ ↓ v1.1 這其實應該是一套結構化的現場診斷方法，而不是單一工具。 ↓ v1.2 這套方法如何變成 SI 廠商可重複交付、可培訓傳承的服務閉環？ 真實案例：醫美診所的多年冤案 昨天在一家醫美診所，解決了一個讓多名工程師束手無策、拖了多年的問題。 實戰案例 · 醫美診所 症狀：網路連線極慢、換過多名工程師，問題始終沒有解決。 根因：數據機多個 LAN 埠各自建立獨立 NAT 網段，院長電腦與檔案來源主機被割裂在兩個不互通的孤島。加上檔案來源主機的無線網卡被裝潢遮蔽，訊號嚴重衰減。 解法：在三個重點位置用手機掃描 Wi-Fi 訊號，發現多個不同網段的 SSID。追出院長電腦的網路線，插回正確的... » read more

0
Read
steven
按下 Enter 的那 1.2 秒，世界裡發生了什麼事？
按下 Enter 的那 1.2 秒，世界裡發生了什麼事？

按下 Enter 的那 1.2 秒， 世界裡發生了什麼事？ 你的腦袋要讀 15 分鐘的東西，AI 為什麼幾秒就懂了 #AI科普  #LLM  #雲端運算  #ChatGPT  #Claude  #地端AI 下午三點，你打開一份 PDF——季報、技術文件、或者一份你根本不想讀的會議紀錄。密密麻麻，滑鼠往下捲了三下才到底。 你嘆了口氣，把整份文字框選，貼進 ChatGPT 或 Claude，打了幾個字：「幫我抓重點。」 然後按下 Enter。 你端起咖啡杯。 還沒喝到嘴邊——答案已經出現在螢幕上了。 「等等……這份文件我自己看，要花至少 15 分鐘。 它怎麼可能幾秒就……讀完了？」 這個問題，值得認真回答。 AI 根本沒有在「閱讀」 在解釋「為什麼這麼快」之前，要先打破一個根本性的錯覺： AI 沒有在讀你的文字。 人類閱讀是線性的。你的眼睛從第一行掃到最後一行，大腦一邊解讀、一邊建立理解，遇到難的段落還要回頭重看。這個過程有前後順序，快不起來。 AI 做的事，完全不同。 它把你貼進去的所有文字，瞬間打散成數萬個數字（每個詞、每個標點都變成一串向量），然後用一種叫做「矩陣運算」的方式，讓所有詞語同時互相對照——哪些詞跟哪些詞有關聯、哪裡是重點、哪裡是細節——一次算完。 一個比喻： 人類閱讀，像是一個人拿著手電筒在黑暗中逐行照。 AI 處理，像是整個房間的燈同時打開——所有角落一眼看清。 1000 行的程式碼，對 AI 而言不是「1000 行要逐行理解」，而是「幾萬個數字，做一次大規模的平行矩陣計算」。 按下 Enter 之後，那 1.2 秒裡發生了什麼 跟著一個請求，從你的鍵盤出發，往下走一遍。... » read more

0
Read
steven
為何公司同仁突然拿不到 IP？NAS 與印表機間歇性失聯？
為何公司同仁突然拿不到 IP？NAS 與印表機間歇性失聯？

RFC 9797 與企業 DHCP Pool 危機 為何公司同仁突然拿不到 IP？NAS 與印表機間歇性失聯？ 近年來，企業 IT 現場開始頻繁出現一種「難以定位」的網路異常： 許多管理者第一時間會懷疑： 然而，真正的原因，可能與現代行動裝置導入的 MAC Randomization（隨機 MAC 位址）機制有關。 而此一趨勢，也與 RFC 9797 所代表的裝置隱私方向密切相關。 MAC Randomization 正在改變企業網路環境 現代作業系統為了降低裝置被追蹤的風險，開始大量採用： 目前常見於： 其核心目的在於： 避免使用者透過固定 MAC 位址，被長期識別與追蹤。 從隱私保護角度而言，這是正向發展。 但對企業 DHCP 管理而言，卻帶來新的挑戰。 同一台設備，可能重複取得多組 IP 在企業 Wi-Fi 環境中，行動裝置會頻繁出現： 若裝置使用 Randomized MAC， DHCP Server 可能會視其為： 「新的設備」。 因此： 同一台手機、筆電或平板， 短時間內可能重複取得 2~3 個 IP。 /24 網段其實很快就會耗盡... » read more

0
Read
steven