巨頭不是為 SMB 而設計,卻意外改變了 SMB 的 AI 部署門檻
巨頭不是為 SMB 而設計,卻意外改變了 SMB 的 AI 部署門檻

巨頭不是為 SMB 而設計,卻意外改變了 SMB 的 AI 部署門檻 工程師思路系列・事出必有因 | Mr. τ/風雲網通系統 如果把近兩年大型模型(Google、Meta、DeepSeek、阿里、Moonshot 等)的演進整理起來,可以發現一件有趣的事: 幾乎沒有任何一項技術,是專門為 SMB 本地部署而設計。 各家模型公司真正追求的,始終是資料中心的吞吐量(Throughput)、降低雲端服務成本、增加併發(Concurrency),以及降低每百萬 Token 的推論成本。 然而,這些為龐大雲端設施打造的底層技術,透過開源與社群的轉譯,最後卻讓只有雙卡 RTX 3060 12GB、甚至 Mac Studio 的 SMB 使用者,意外成了最大的受益者。 要理解這股紅利如何傳導到地端,不能只看單一名詞,而必須用系統工程的三層架構來拆解。更重要的是,這三層並非平行存在,而是嚴格的依賴與傳導鏈: 模型架構(決定天花板) → 推論框架(決定能不能跑) → 部署技術(決定有沒有資格入場) 例如:MLA 再強,如果推論引擎沒有支援,SMB 一樣享受不到;反過來,GGUF 量化格式再成熟,如果模型本身缺乏 GQA 或高效設計,VRAM 還是會被 KV Cache 瞬間撐爆。唯有三者同步成熟,地端的性價比甜蜜點才會出現。 第一層:模型架構層(決定天花板) 一 MLA(Multi-head Latent Attention)— 以 93.3% 壓縮率突破 KV Cache 瓶頸... » read more

工程師思路系列・地端 AI 洞察: 從 HuggingFace 社群硬體統計 看 SMB 地端 AI 的真實生態
工程師思路系列・地端 AI 洞察: 從 HuggingFace 社群硬體統計 看 SMB 地端 AI 的真實生態

從 HuggingFace 社群硬體統計看 SMB 地端 AI 的真實生態 工程師思路系列・地端 AI 洞察 從 HuggingFace 社群硬體統計看 SMB 地端 AI 的真實生態 Mr. τ|風雲網通系統有限公司 PCPiLOT|2026.07 #地端AI #LLM推論 #硬體選型 #SMB決策 #CPU推論 前言:這份數據為什麼值得認真看? HuggingFace 是全球最大的開源 AI 模型社群,超過百萬名開發者與研究者在此下載、部署模型。他們公開了一份「社群硬體統計」,讓用戶自願登記手上跑 AI 的設備——這不是銷售數字,不是市調報告,而是真實在做 AI 推論的人,手上用什麼。對 SMB 決策者的意義在於:它是一面鏡子,照出當全球最前線的 AI 實踐者遇到相同預算與部署限制時,他們做了什麼選擇。 一、大局:四大陣營的勢力版圖 陣營 佔比 核心意涵 NVIDIA GPU 45% 生態成熟,CUDA 壟斷,入門到旗艦齊備 CPU-only 32% 量化技術成熟,無 GPU 也能推論 Apple Silicon 17%... » read more

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

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

工作管理員說 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

從一次 OOM 事件,看見企業地端 AI 的隱藏成本
從一次 OOM 事件,看見企業地端 AI 的隱藏成本

從一次 OOM 事件,看見企業地端 AI 的隱藏成本 Steven Lai(Mr. τ)|風雲網通系統有限公司 PCPiLOT  ·  2026-06-06 最近在開發 PCPiLOT 專案時,我遇到了一個很有意思的現象。 測試環境裡有兩張 RTX 3060 12GB。 照理說,許多人會認為:兩張顯示卡,應該比一張顯示卡更穩、更快、更有餘裕。 然而實際情況卻不是如此。 現場觀察 在模型推理與功能驗證過程中,我發現其中一張顯示卡長時間維持高負載,另一張顯示卡卻幾乎處於待命狀態。隨著上下文(Context)逐漸增加,系統開始出現記憶體不足(OOM)與推理中斷的現象。 短短不到十分鐘,就發生了多次模型重新載入與執行環境重建。結果最花時間的,並不是 AI 在思考問題,而是在等待系統恢復工作狀態。 企業導入 AI,真正的成本不一定是硬體 很多人談 AI 時,第一個想到的是: ✔ 顯示卡夠不夠大? ✔ VRAM 有沒有 24GB? ✔ 要不要再多買一張 GPU? 這些當然重要。但當系統真正進入長時間運行階段後,往往會發現另一個問題: 真正影響效率的,未必是算力本身,而是資源如何被使用。 如果兩張顯示卡的資源無法有效協同運作,即使帳面上擁有更多的 VRAM,也未必能獲得理想中的穩定性。 AI Runtime 的設計取向,決定了資源如何被消耗 目前許多地端 AI 推理框架,都傾向於優先追求低延遲(Low Latency)。這種設計有其合理性——對聊天機器人而言,使用者通常希望輸入問題後,幾秒鐘內就能得到回應。 為了達成這個目標,系統往往會盡量減少顯示卡之間的資料交換。結果就是: ✅ 好處 回應速度較快,使用者體驗流暢,適合短對話場景。 ⚠️... » read more