風雲網通系統

強化您的企業 IT 戰力

AI 應用實戰AI 時代工作法AI 與知識工程NAS 與儲存企業 IT 管理伺服器地端 AI 部署基礎架構工具評測與踩坑工程實戰工程實戰筆記技術科普未分類硬體與算力資訊安全電力

antiX 26 × fcitx5 × 新酷音：從懷疑人生到徹底搞懂
antiX 26 × fcitx5 × 新酷音：從懷疑人生到徹底搞懂

工程師思路系列 事出必有因 現場實錄 一個 Ctrl+Space，卡了一整晚 antiX 26 × fcitx5 × 新酷音：從懷疑人生到徹底搞懂 我有一台 Acer Aspire 4745G，第一代 i5，4GB RAM，說老不老，說新不新。 它的任務是跟我跑現場——去客戶公司做網路勘查，掃設備、抓封包、出報告。 為了讓這台老筆電跑得動勘查工具，我裝了 antiX 26——一個極度輕量的 Linux 發行版。 裝完之後一切都好，只剩一件事：打不了中文。 「這有什麼難的？」——我當時這樣想 在 Windows 上裝中文輸入法是五分鐘的事。Linux 嘛，查一下文件，跑幾行指令，應該也差不多吧。 結果我低估了這件事。 先裝 fcitx5，按照網路教學一步一步來，裝完重開機——Ctrl+Space，沒反應。 換 fcitx4，一樣。換 ibus，還是一樣。 三套輸入法框架，全部裝了又刪，刪了又裝，環境變數在系統裡留下一堆殘骸互相打架。 讓 Google Search AI 幫我試了四種不同版本，全都失敗。 「是不是 antiX 根本就不支援中文輸入？」 「還是我哪個步驟做錯了？」 「還是這台機器有什麼特殊問題？」 這種時候最消耗心力——不是累，是不知道問題出在哪裡，所以不知道從哪裡修。 換個工具，換個思路 後來我換了方法：不再自己亂試，而是讓 Claude Fable 5 協助我做系統性的診斷。 做法很直接——先寫一支診斷腳本，把系統狀態全部挖出來： 目前裝了哪些輸入法套件、環境變數是什麼值、Display... » read more

0
Read
steven
一次 CDN 與防火牆互動造成誤判的排查案例
一次 CDN 與防火牆互動造成誤判的排查案例

CPU 很閒，卻幾乎連不上？ 一次 CDN 與防火牆互動造成誤判的排查案例 ／ Mr. τ・風雲網通系統 工程師最怕的，不一定是 CPU 100%。 有時候，CPU 很閒、RAM 很閒、SSD 很閒，但外面就是幾乎連不上。 這種情況，通常代表真正的問題，根本不在主機裡面。 🗓 事情是這樣開始的 這次的案例，並不是監控報警發現的。 是因為我自己要去官網新增一篇部落格文章，打開編輯器之後，發現反應比平常異常地慢——才開始往下查。 這種情況其實很常見。很多問題不是被監控抓到的，而是「剛好要用」的時候才現形。 🔄 推翻假設的過程 第一直覺當然是先看主機硬體資源——CPU、RAM、磁碟，全部正常。 接著看外網流量，也沒有異狀。 切換到防火牆日誌，才看到大量 SYN Flood 告警。 第一反應：被攻擊了？來源 IP 一看——幾乎清一色是 Cloudflare 的全球節點。 原本以為是來自任意來源的攻擊，查詢後才發現，大多是來自 Cloudflare 全球各地的節點。 那問題真的是 Cloudflare 造成的嗎？ 不是。 💡 根本原因 根本原因不是 Cloudflare 出問題，而是它改變了流量型態，而防火牆不知道。 Cloudflare 的代理機制，會把大量真實用戶的連線，集中由少數 Edge IP 節點轉送進來。如果防火牆的 SYN Flood 偵測門檻，沒有配合 CDN... » read more

0
Read
steven
一個 CMOS 斷電事件，如何引爆 BIOS 預設值、舊顯卡驅動、Linux 相容性的三重連鎖崩潰
一個 CMOS 斷電事件，如何引爆 BIOS 預設值、舊顯卡驅動、Linux 相容性的三重連鎖崩潰

工程師思路系列・事出必有因 那顆 16 年沒換的小電池， 讓一台筆電同時得了三種病 一個 CMOS 斷電事件，如何引爆 BIOS 預設值、舊顯卡驅動、Linux 相容性的三重連鎖崩潰 硬體診斷 Linux 老舊設備維護 BIOS 一台「前陣子還好好的」筆電，今天開機全壞了 前陣子才剛在一台 2010 年出廠的 Acer Aspire 4745G 上裝好 antiX Linux，視窗介面正常、自動登入正常，一切運作順暢。 今天把它拿出來，按下電源鍵，螢幕——沒有畫面。 接上外接螢幕之後，終於看到了一個文字終端機介面，靜靜地等著輸入帳號密碼。問題來了：帳密早就忘光了。 好不容易進入救援模式改了密碼，回到系統輸入 startx——失敗。 📋 本次故障症狀清單 ✔內建螢幕無畫面（外接螢幕正常） ✔開機停在文字模式 TTY，要求輸入帳號密碼 ✔原本的圖形介面自動登入功能消失 ✔手動執行 startx 失敗，無法進入視窗環境 四個症狀，看起來像四個問題。但工程師的直覺告訴我：一定有一個共同的根源。 第一直覺：「電池沒電，老電腦嘛，正常的」 這台 i5-460M 的機器距今快 16 年了，電池早就蓄不了電，是人之常情。 但仔細想一想：鋰電池耗盡，頂多就是筆電不能離開變壓器使用。它不會讓作業系統崩潰，不會讓螢幕沒畫面，更不會讓 X Window 開不起來。 所以，真正的問題不在那顆大電池。 真兇，是另一顆沒人記得的小電池。 主角登場：那顆 16 年從沒被換過的 CMOS... » read more

0
Read
steven
AI 工廠與金字塔的文明結構:當「老師傅」遇上自動化神話
AI 工廠與金字塔的文明結構:當「老師傅」遇上自動化神話

PCPILOT 知識中心 ── 產業觀察 AI 工廠與金字塔的文明結構:當「老師傅」遇上自動化神話 從黃仁勳的水電工論,到外送與 Costco 的悖論,看懂自動化神話背後的人力本質 引言:沙漠中的金字塔 輝達執行長黃仁勳曾說過一句話,讓我反覆思考了好一陣子: AI 時代最搶手的,不是程式設計師,而是水電工;因隨著資料中心的快速增長,未來將需要數十萬名水電工和水管工。 第一次讀到這句話時,我腦中浮現的畫面,竟不是矽谷的伺服器機房,而是法老王金字塔的施工現場。 這個聯想其實一點也不荒謬。金字塔是古埃及人為永生信仰打造的終極硬體基礎設施,而今天的 AI 資料中心,則是現代人為「人工智慧」這個新神打造的終極硬體基礎設施。兩者的共同之處,在於人類把大量資源砸進一場「看不見的崇拜」——你看不到神,但看得到金字塔;你看不到 AI 的「智慧」本身,但看得到一座座吞噬電力與冷卻水的鋼鐵巨獸。 我們總以為 AI 時代是一個「去體力化、腦力至上」的時代,結果繞了一大圈才發現,真正稀缺的,反而是最古老的藍領技能。程式設計師寫完模型之後,要讓 AI 真正跑起來,靠的是電力、冷卻、管線、變電站、備援電源——這些最原始、最物理的東西。就像金字塔再怎麼神聖,最後還是得靠成千上萬人推石頭、拉繩子、抬木槓。只是石塊換成了伺服器機櫃,法老換成了黃仁勳,奴工換成了年薪可能比工程師還高的水電工。 核心對比:外送與 Costco 的悖論 這個「人力填補系統缺口」的觀察,讓我想起兩個生活中再尋常不過的例子。 案例一 外送經濟 年輕力壯的外送員,靠的是迅速響應的服務速率。這套系統把「時間」與「體力」拆解出來販售:付服務費,買的是別人的「執行速率」;選擇自取,則用自身體力與時間置換了溢價。 案例二 Costco 會員制 繳了會員費,再自己開車前往、自己揀貨、自己扛上車。零售業原本該承擔的物流成本,被悄悄轉嫁給消費者,而消費者卻心甘情願,甚至覺得划算。 外送悖論與 Costco 悖論,本質上是同一件事的兩種面貌:系統把效率包裝成自動化的神話,但底層始終靠人力填補設計留下的缺口。 範例 ── 外送服務 系統設計誘因:付費換取「時間壓縮」 人力參與形式:外送員成為即時物流節點 隱含的荒謬感:快速響應成為新階級象徵 範例 ── Costco 系統設計誘因:付費換取「低價與大份量」 人力參與形式:消費者自願成為運輸鏈一環 隱含的荒謬感:自己付錢、自己運貨、自己加油 範例 ── AI 工廠 系統設計誘因:投資換取「智慧與自動化」... » read more

0
Read
steven
Windows 11 更新，有時，不是越新越好
Windows 11 更新，有時，不是越新越好

PCPiLOT FIELD NOTES ✦ 工程現場實錄 Windows 11 更新，有時，不是越新越好 一台 Q470 主機板，三層電源管理的通關紀錄 2026-06 ✦ Mr. τ／風雲網通系統 這篇文章不需要你懂 BIOS 或 Windows 更新機制。 它講的是一件很多人用過幾年的電腦都可能碰到的事：Windows 11 更新越裝越新，機器卻開始出現各種說不清楚的怪現象。睡眠有問題、關機有問題、更新裝不進去——每一個問題看起來都不一樣，但追到最後，指向的是同一個方向。 這是一次真實的維修通關紀錄，也是我交機時跟客戶說的那段話。 起點：以為只是換一顆 SSD 鄰居送來一台 ASUS 商用機（Q470 晶片組），SSD 故障。好消息是還在保固內；壞消息是原廠更換要等兩週。最近 SSD 漲價四到六倍，客戶很冷靜：「等就等。」 於是我用工程部備用的 SATA SSD，做了一次乾淨的 Windows 11 24H2 安裝，讓機器先恢復正常使用。等原廠 SSD 修返，再用系統複製工具把整個環境搬過去。補完主機板驅動，讓 Windows Update 慢慢跑。一切看起來只是例行維修——直到更新開始跑。 ⚠️ 關卡一：DISM 都過了，更新還是卡在 98% KB5095093（選用預覽更新）安裝 → 重新開機 → 更新到 98%... » read more

0
Read
steven
我們不是花八小時修 bug，是花八小時才發現沒有 bug
我們不是花八小時修 bug，是花八小時才發現沒有 bug

PCPiLOT FIELD NOTES ✦ 數位工具開發實錄 我們不是花八小時修 bug，是花八小時才發現沒有 bug 一次 App 開發的真實除錯紀錄，以及它告訴我們關於 AI 協作、資訊可視化與決策品質的事 2026-06-25 ✦ Mr. τ／風雲網通系統 這篇文章不需要你懂程式。 它講的是一個管理者和決策者都熟悉的問題：當你的團隊花了很長時間解決一個問題，最後發現問題根本不在他們找的地方——那段時間，是怎麼浪費掉的？ 我最近第一次開發 Android 手機 App，親身經歷了這件事。過程很痛苦，但教訓很值得分享。 起點：一個真實的市場需求 台灣有超過五百萬慢性病患，他們每天面對一個沒有人幫他們解決的問題： 「站在超商貨架前，拿起一包零食，我能吃嗎？吃多少？今天已經吃太多了嗎？」 我開發的「好口福」App，就是要回答這個問題。使用者輸入身高體重和慢性病狀況，App 掃描食品標示後，給出一個簡單的顏色燈號： 🟢 安心買 🟡 注意量 🔴 地雷區 ⚫ 今日已爆 問題：一個小圖示消失了 App 的主要功能都做好了。最後一個待辦很小：在每個營養素旁邊加一個「ⓘ」圖示，讓使用者點擊後看到健康說明。 程式碼寫好了。系統檢查通過。部署完成。 但手機上，那個圖示完全不見了。 接下來的八小時 我和 AI 協作工具花了將近八小時排查這個問題。每一個假設都被否定： 假設一 程式碼沒有寫對 逐行核查後確認程式碼正確。❌ 不是這個。 假設二 手機作業系統的顯示 bug 查到真實存在的 bug 並修正，還是看不到。❌... » read more

0
Read
steven
一台印表機故障，如何長出一套診斷工具
一台印表機故障，如何長出一套診斷工具

從一次客戶故障，到一套診斷工具的誕生 工程師思路系列：好心辦壞事 —— 一台印表機故障，如何長出一套診斷工具 有些問題，看起來像設備故障。 有些問題，看起來像驅動程式損壞。 但真正深入追查後才發現， 問題其實來自一個原本出於善意的設計。 這次的個案，就是如此。 問題出現 家中有一台 HP Smart Tank 510 無線印表機。 多台 Windows 11 電腦長期正常使用。 但其中一台電腦，某天開始突然無法列印。 更奇怪的是： 測試頁正常 印表機狀態頁正常 Ping 正常 印表機顯示 Online 唯獨 PDF 與 Word 文件送出後， 印表機只動一下就停住。 彷彿設備正常， 卻又無法真正工作。 第一輪排查 遇到這種問題時，最重要的不是急著修復， 而是先排除錯誤假設。 於是開始逐項驗證： 重新安裝 HP 官方完整驅動 確認 Wi-Fi 連線正常 確認其他電腦可正常列印 確認印表機韌體正常 確認網路可正常 Ping 通 結果全部通過。 問題依然存在。 此時可以確定： 印表機本身並沒有壞。... » read more

0
Read
steven
三個不同案例，相同的處理態度與思路
三個不同案例，相同的處理態度與思路

三個不同案例，相同的處理態度與思路 —— 事出必有因系列：不放棄，往問題核心一層層剝去 今天處理了三個 SMB 客戶的現場案件。 網站與信箱突然全部中斷、NAS 權限設定怎麼改都沒用、診所印表機突然不能列印。 三件事看起來毫無關聯，但處理完之後，我發現它們其實在說同一件事： 每一個「突然壞掉」，都只是入口。真正的工作，是從入口走進去，一層一層，直到找到那個改變的點。 案例一｜公司網站與信箱同時消失 客戶早上傳訊息過來：「官網打不開，寄出去的信全部退回。」 第一反應不是叫他去問主機商。 因為網站無法存取，不一定是主機壞了。第一順位的懷疑，是 DNS。 查了 WHOIS，果然——域名出現了 clientHold 狀態。 這個狀態代表：域名在註冊商端被暫時凍結，整個 DNS 解析鏈中斷，網站、信箱、所有對外服務，全部同時消失。 問題是，這個案件牽涉四個環節： 環節 負責方 域名註冊 國外供應商 Tucows，台灣由遠振代理 網站架設 另一家廠商維護 郵件服務 Google 代管 現場 IT 客戶自行處理 四個環節，沒有一個有完整的第一手資訊。能做的，是透過即時聊天持續與客戶確認現象，同時用 DNS 查詢工具監測狀態，逐層排查。 大約三、四個小時後，clientHold 自動解除，服務恢復正常。 原因？到現在還沒有明確答案。 這就是某些案件的現實——你找到了問題在哪裡，但「為什麼發生」這個問題，有時候沒辦法有完美的結論。 📌 企業主應該知道的事 域名是你公司數位資產的地基。地基出問題，上面所有東西同時消失——網站、信箱、一切對外的數位服務。 它不在你的主機上，不在你的 IT 人員手裡，它在域名註冊商那裡。 幾個值得確認的問題：你的域名在哪家註冊商？續費通知寄到哪個信箱？負責人離職後，這些資訊還在公司手裡嗎？ 案例二｜NAS 權限設定怎麼改都不生效 建築師事務所，Synology NAS。 管理員反映說有兩個資料夾的存取權限怎麼設都沒用——帳號正常，操作步驟也對，就是不生效。... » read more

0
Read
steven
收斂的委員會：Decision Convergence Engineering 的一次實踐
收斂的委員會：Decision Convergence Engineering 的一次實踐

個案經驗分享 · AI 應用實戰 · 決策工程 收斂的委員會 Decision Convergence Engineering 的一次實踐 人越多，越難收斂——這是多數人對開會的印象。但我的經驗剛好相反：當與會者全是 AI，收斂速度反而比任何真人委員會都快。 Mr. τ ／ 風雲網通系統　·　2026 🤔 一個違反直覺的觀察 很多人對開會的直覺是：人越多，立場越多，越難有結論。 這個直覺在真人世界裡完全正確。但當與會成員換成 AI 助理，這個規律就失效了。 我長期使用多模型合議來輔助重大決策，觀察到一件事：AI 委員會的發散速度很快，收斂速度也很快。 而且幾乎不需要主席強行裁決——觀點的碰撞本身就會自然篩選出值得保留的東西。 ⚖️ 真人委員會 vs AI 委員會 真人委員會難以收斂，不是因為人不夠聰明，而是因為人帶著太多與問題本身無關的東西進入討論： 真人委員會的阻力 AI 委員會的特性 權力鬥爭與派系利益 ✔ 無組織政治 面子問題、不願認錯 ✔ 無自我防衛 情緒反應與歷史包袱 ✔ 每次對話都是新的起點 部門本位、各守地盤 ✔ 只針對問題本身給出立場 開會時間有限、精力有限 ✔ 幾分鐘內給出有結構的完整立場 AI 之間觀點不同，但沒有任何一個模型有「贏過其他模型」的動機。它們只是在回應問題本身。這讓討論的訊噪比大幅提高。 🧭 實際流程是這樣跑的 我的主導... » read more

0
Read
steven
41 個專案之後，我才搞懂什麼叫做「知識資產」
41 個專案之後，我才搞懂什麼叫做「知識資產」

41 個專案之後，我才搞懂什麼叫做「知識資產」 AI 讓開發速度提升十倍之後，最大的敵人不再是寫程式，而是遺忘。 作者：Mr. τ／風雲網通系統  |  標籤：知識工程 PCPiLOT SMB AI 「你有沒有一個機制，讓 AI 幫你掃描、萃取、歸檔過去寫過的好東西？」 我問過很多工程師。沒有人說有。 事件：29 次掃描，0 次成功 AI 助理出現之後，有一件事悄悄發生了。 開發速度變快了。快很多。以前一年做三個專案，後來一個月可以做三個。SPA、Python 串接、API 模組、診斷小工具……專案數量在我幾乎沒有意識到的情況下，突破了四十個。 然後，遺忘開始追上來。 「哪個專案有 OAuth 模組？」「上次那個 Ollama 串接，是在哪裡寫的？」「GPU 監控的邏輯，我記得優化過，但是在哪一個專案？」——這些問題開始頻繁出現。最大的敵人，不再是開發速度，而是自己累積的東西太多、太快、太散。 我試過用程式自動比對這 41 個專案的相似度，希望找出可以重用的部分。跑了 29 次，設計了各種比對邏輯，結果全部失敗。不是技術問題，是方向錯了——我一直在找「哪裡一樣」，而不是在想「什麼值得留下來」。 發現：掃描工具的方向，一直對齊錯誤的問題 工程師寫工具，有一個慣性：從「發現問題」出發。程式碼有沒有重複？有沒有 bug？有沒有技術債？ 但知識萃取需要的不是這個。開一個新案子的第一個問題，從來不是「我之前有沒有寫過類似的 bug」——而是「我之前有沒有解決過類似的需求」。 這是 PCPiLOT 工程日誌裡記下的一條教訓： 掃描工具應該對齊「開案時的需求」，而不是對齊「發現問題」。這兩個方向，工具架構完全不同。 說穿了就是：你需要的不是程式碼比對器，你需要的是架構解剖台。 抽象：三個步驟，把 41 個專案變成一座知識素材庫 我重新設計了 PCPiLOT 的專案解剖流程，分三個階段： 1 專案群組化 自動掃描目錄，排除實驗性的零散檔案，以「專案」為單位識別核心模組。不是每一個 .py... » read more

0
Read
steven
AI 時代工作法企業 AI 治理知識工程
AI 時代工作法企業 AI 治理知識工程

AI 時代工作法 企業 AI 治理 知識工程 你不需要懂 AI， 但你需要當市長 從三個真實事故，長出來的企業 AI 治理架構 Mr. τ／風雲網通系統有限公司  ·  2026 有一次，我交代一個任務給 AI 助理。 它沒有問我任何問題，直接開始工作。 三十分鐘後，它回報完成了。 但它做的，不是我要的那件事。 它自己判斷了工作範圍，自己決定了方向，然後非常認真地，走錯了路。成本，照單全收。 這不是特例。這件事在不同形式下，我遇到了很多次。 每次我都在想同一個問題： 如果 AI 不知道邊界在哪裡，它會自己畫一條。 而那條線，不一定是你要的那條。 這個問題，帶過人的主管都遇過。新進員工摸不清楚狀況，做了一堆不在範圍內的事；外包廠商沒有接到明確指令，就按照自己的習慣走。AI 也是一樣——只是它做事的速度快很多，所以走錯的代價也大很多。 後來我把這些事故整理了一遍，發現它們都指向同一個根本原因： 不是 AI 不夠聰明。而是沒有人在治理它。 這也是我後來畫出這張圖的原因。 ［ 五層市政廳架構圖 ］ 人類治理 → AI 協作 → 文件系統 → 知識中心 → CSP 基礎設施 這張圖把企業 AI 協作拆成五層。每一層，我都曾經在真實事故裡感受過「缺了它會怎樣」。 以下，我用三個事故來解釋這張圖。 事故一：它很認真，但沒有人告訴它邊界在哪裡... » read more

0
Read
steven
個案經驗分享：軟體專案開發歷程與 AI 可靠性交接設計
個案經驗分享：軟體專案開發歷程與 AI 可靠性交接設計

個案經驗分享：軟體專案開發歷程與 AI 可靠性交接設計 從工程流程、技術債，到多 AI 協作下的信任與交接管理 一、專案的真實推進歷程 一個專案的起點，通常只是一個模糊的初步想法。沒有完整規格書，沒有詳細設計，就這樣開始了。 從那個模糊的起點，工程推進的節奏大致是這樣走的： 1 先產出基本功能模組，讓系統能動起來就好 2 在使用過程中，整體框架慢慢成形，初期的功能設計與使用者介面跟著調整 3 逐項補完自認為不足的功能，同時持續除錯 4 調整操作動線，修正功能畫面，讓使用流程更順 5 引進多家 AI 助理提供評析意見，開始收斂專案結構 6 陸續償還開發期間累積的技術債 整個過程需要大量的持續觀察、監工、推進，以及心力投入。這不是寫完就結束的工作，是一直在跑的系統——你不看，它就會悄悄跑偏。 中間會遇到很多分岔點，特別是大型程式碼變動或重構的時候，這種時刻很容易因為趕進度而跳過一個關鍵動作： 遇到有疑問的分岔點，別忘記趕緊進行 git 版本保存。 很多決策是不可逆的，事後才後悔已經來不及了。 關鍵抉擇之前，也需要凝聚多家 AI 助理的經驗與意見，交互詰問，讓不同視角的問題都浮出來。這個動作看起來慢，實際上可以避開很多後期才爆炸的問題。 能做到這樣，才能真正啟動 40 倍槓桿的效益——讓沒有專業程式設計背景的人，也能完成多項功能的模組化程式串接任務。這不是誇張，是我們實際跑過的個案數字。 二、文件才是資產，不是記憶 開發過程中，有一件事非常重要，但很多人（包括 AI 助理）都會忽略： 最重要的資產是文件，不是個人的記憶，也不是 AI 助理的記憶。 程式碼是一翻兩瞪眼的事情。你說「我記得某個功能是這樣設計的」，那沒有用。把那個功能模組調出來，看哪一行寫了什麼，那才是真正的內容。 這個原則同樣適用於 AI 助理。AI 助理很容易煞有其事地亂掰一通，聽起來很有道理，但查了原始碼才發現根本不是那回事。它們也容易偷懶，把輸出內容簡化，把細節省略掉，讓你以為問題已經處理好了。 人類架構師覺得有疑問，就是要進行確認，不要跟著 AI 助理以為可以安逸。 不要放任 AI 助理胡亂地承諾與答應，然後你就真的信了。 這種工作態度的底線很簡單：有疑問就查，查了才算數。 三、多... » read more

0
Read
steven
工程師思路系列 之 事出必有因
工程師思路系列 之 事出必有因

工程師思路系列｜PCPiLOT 開發日誌 事出必有因 AI Agent 的執行成本，誰來負責？ Mr. τ／風雲網通系統 與 AI 協作，本質上是一種資源管理問題。 最近使用 Claude Code 的時候，忽然發現五小時的使用額度直接前進了 18%。回頭看工作紀錄，完全找不到對應的大型功能產出。 我把 console log 貼給 Claude 分析。 真正發生的事情 分析結果出來：Claude Code 因為找不到目標檔案，直接啟動了全硬碟搜尋。 它執行了 recursive directory scan、數次 PowerShell 呼叫、嘗試多組路徑，最後甚至準備啟動 llama-server 做測試驗證。 問題是，這件事只需要問我一句「檔案在哪裡？」就能解決。十秒鐘。但它沒問。 然後同樣的事情又發生了一次。額度直接燒到 37%。 Claude Code 事後的自我分析是： 使用者的輸入被解讀成「繼續調查」，而不是「停止確認」。 事實上，真正的問題早就結案了：rope.dimension_sections = 3 vs 4。後面所有的行動，全部是多餘的成本。 AI 與人類的成本模型不同 這個問題的核心，不是 AI 太積極，而是： 👉 AI 不知道「執行成本」是什麼。 對... » read more

0
Read
steven
AI 沒有猜錯，但我還是不知道自己在看哪一張 RTX 3060
AI 沒有猜錯，但我還是不知道自己在看哪一張 RTX 3060

AI 沒有猜錯，但我還是不知道自己在看哪一張 RTX 3060 從 GPU Name、Index、Bus ID 到 VBIOS Version，一場關於「可信觀測點」的除錯旅程 最近在研究 Ollama 與 llama.cpp 的 GPU 排程行為。一開始只是想搞清楚幾個小問題：為什麼 Windows 工作管理員看到的數字，跟 nvidia-smi 看到的不太一樣？為什麼有些模型看起來應該跑在某張卡上，行為卻又不像？ 查著查著，我突然發現一個更根本的問題： 我根本不知道自己正在看哪一張 RTX 3060。 我的機殼裡插著三張長得一模一樣的 RTX 3060：同晶片、同 12GB 容量、外觀幾乎沒有差別。當兵時學過「四清、兩點、五查、三找」，裝備識別一個都不能少。沒想到二十年後在自己家裡，我被三張顯示卡逼著把這套紀律重新拿出來用——而且用得比當兵時還狼狽。 GPU 識別其實不是問題本身。它是為了驗證推論系統行為，不得不先解決的前置問題。觀測點如果不可信，後面所有的推論都會跟著錯。以下是這趟除錯的完整過程，包含 AI 助理陪我一起猜錯的每一層。 四層誤判 1第一層誤判：GPU Name 三張卡通通顯示 NVIDIA GeForce RTX 3060。完全沒用，毫無區別。 2第二層誤判：nvidia-smi 的 Index（GPU 0 / 1 / 2） 很多人第一反應是看 Index。但這台機器一路從 GTX 750... » read more

0
Read
steven
36GB VRAM 的幻覺：我讓三家 AI 預測 RTX 3060 ×3 的推論效能，結果全部輸給實測數據
36GB VRAM 的幻覺：我讓三家 AI 預測 RTX 3060 ×3 的推論效能，結果全部輸給實測數據

36GB VRAM 的幻覺：我讓三家 AI 預測 RTX 3060 ×3 的推論效能，結果全部被數據打臉 Mr. τ／風雲網通系統 · 2026-06-10 · 地端 AI 基礎設施 一、心動的開始 前幾天，社群裡流傳一篇文章。 有人用 RTX 5090 在本地跑 Gemma 4 12B，透過一個參數調整，TPS 從 27 直接飆到 103。將近四倍。 看完之後，我盯著螢幕想了很久。 「我手上有三張 RTX 3060 12GB，加起來 36GB VRAM。應該也能跑得很猛吧？」 其實買第三張卡的初衷很務實。不是為了炫耀規格，而是有實際需求： 兩張卡跑大一點的模型，偶爾會 OOM（顯存不足），動不動就崩 想測試 26B、27B 等級的模型，需要更寬裕的 VRAM 緩衝 不希望因為顯存限制，就把好不容易找到的優質模型放棄 帶著這個期待，我做了一件很多人都會做的事：先去問 AI。 💡 小科普：什麼是 TPS？ TPS = Tokens Per... » read more

0
Read
steven
看懂 Qwen3-30B-A3B-QAT-Instruct-Q4_K_M-MTP-NSFW：2026 地端 AI 模型命名學完全指南
看懂 Qwen3-30B-A3B-QAT-Instruct-Q4_K_M-MTP-NSFW：2026 地端 AI 模型命名學完全指南

看懂 Qwen3-30B-A3B-QAT-Instruct-Q4_K_M-MTP-NSFW：2026 地端 AI 模型命名學完全指南 從模型名稱看懂參數規模、MoE 架構、量化格式與推理優化 當你開始接觸地端 AI（Local AI）之後，很快就會發現一件事： 最大的障礙不一定是顯示卡，也不一定是 Linux。 而是模型名稱。 第一次看到： Qwen3-30B-A3B-QAT-Instruct-Q4_K_M-MTP-NSFW 很多人的反應通常都是： 「這到底是模型名稱，還是 Wi-Fi 密碼？」 事實上，這串名稱並不是亂命名。 它其實是在用最短的字數，描述模型的架構、規模、量化方式、推理特性與用途。 如果能看懂這些縮寫，你幾乎可以在下載前就判斷： 需要多少記憶體？ 跑起來快不快？ 適合聊天還是寫程式？ 是否支援特殊優化？ 是否有安全限制？ 一、30B 是什麼？ 30B 指的是： 30 Billion Parameters 也就是 300 億參數。 參數可以理解成模型在訓練過程中學到的知識權重。 模型規模 常見用途 3B 輕量聊天助手 7B 個人 AI 助理 14B 進階推理 30B 高品質通用模型 70B+ 接近大型商業模型能力 通常參數越大，能力越強，但所需記憶體也越高。 二、A3B 是什麼？... » read more

0
Read
steven
工作管理員說 llama-server 吃了 17GB RAM 我把整個過程錄下來了
工作管理員說 llama-server 吃了 17GB RAM 我把整個過程錄下來了

本地 AI 推論 · 記憶體診斷 工程筆記 · 實測紀錄 Mr. τ／風雲網通系統  ·  2026-06-09 我有一台 64GB RAM 的地端 AI 主機，平常系統總用量很少超過 16GB。那天睡眠喚醒後，瞄到用量靠近 32GB，直覺就覺得不對。打開工作管理員，最顯眼的那行是 llama-server.exe，排在所有程式最上面，佔了 17GB。 第一個念頭：GPU offload 掛了，Qwen3.6 27B 整個跑回 CPU 了？ 但 nvidia-smi 一查，GPU1 8153MB、GPU2 8701MB，紋絲不動。推論速度 18.6 tok/s，也沒事。 GPU 好好的，模型在跑，但 RAM 突然多了將近一倍的用量。 那個 17GB 到底是什麼？ 我沒有重開機。我寫了一個監控程式，把整個過程錄下來。 實測數據：163 筆，每 2 秒一筆 程式從喚醒前就跑著，Sleep/Resume 全程自動記錄。以下是這次事件的完整時間軸。 19:31:52 ── 基準線 llama-server Working... » read more

0
Read
steven
原來整理 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