巨頭不是為 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

從一個念頭,到一套能力 : 一段工程演進,看見企業隱性智慧如何變成資產
從一個念頭,到一套能力 : 一段工程演進,看見企業隱性智慧如何變成資產

PCPiLOT 工程師思路系列 從一個念頭,到一套能力 一段工程演進,看見企業隱性智慧如何變成資產 7月6日,星期日傍晚六點。 我原本只是想解決一個採購效率問題。 沒有規劃十六個版本。沒有想過要做成什麼平台。甚至沒有想過,這件事最後會和企業 AI 轉型產生任何連結。 我只是覺得:「這件事如果能自動化,應該會更好。」 就這樣開始了。 十天後,我回頭看,發現自己走過的這條路,其實不只是寫了一個工具。 而是驗證了一件事: 一個人累積多年的判斷經驗,可以被整理、被保存、被傳承——變成任何人都能使用的能力。 第一天:先讓資料進來 程式第一版做的事情很簡單。 跑完,螢幕印出幾十個型號的價格和現貨數量,整齊排列。 就這樣。 但那個當下,看著原本需要手動搜尋幾十次的事情,變成幾秒鐘自動完成——有一種說不清楚的滿足感。 不是因為做了什麼了不起的東西。 而是因為:一個念頭,開始變成真實。 有用。繼續。 幾天後:資料進來了,但還不夠 數字有了,問題來了。 「這顆值不值得買?」 光看價格和筆數,還是不知道。 於是開始加東西:幾個核心、功耗多少瓦、效能評分、有沒有內建顯示晶片。 資料開始變成資訊。但我知道,資訊還不夠——真正需要的,是判斷。 關鍵轉折:把多年的經驗寫進去 這是整個過程中,讓我最有感觸的一步。 有一顆叫 E5-2678 v3 的處理器。規格表上就是幾個數字,看不出任何特別之處。 但我知道它的故事。 這是中國工廠特供的型號,台灣幾乎沒有新品,卻因為大量企業設備汰換而流入二手市場,用一般消費型主機板就能插,效能是同價位產品的好幾倍。這些資訊,不在任何規格表裡,不在任何評測網站上——它只存在於在這個市場裡打滾過的人的記憶中。 我把它寫進去,就七個字: 「中國特供雙路神U。」 看似簡單的七個字,背後是十多年市場經驗壓縮後留下的判斷。 R3 3300X 四核全在同一個運算模組,記憶體延遲極低,實際表現遠超規格,停產後身價反漲。 i5-11400 這一代意外保留了企業級指令集,卻在下一代被取消,是近年最特殊的消費級 CPU。 每一條,都是曾經讓我在某個場合停下來多想一秒的事情。現在,它們全部在工具裡了。 那個夜晚,我盯著螢幕看了很久。不是因為程式有多複雜,而是因為突然意識到: 我一直以為這些判斷只存在我腦子裡,沒想到它們可以被說清楚,被整理出來,被放進一個任何人都能使用的地方。 第一個真正的考驗:報告全部消失 某天早上,打開報告——空白一片。 所有分析、所有資料、所有花了好幾天整理的內容,全部不見了。 那一刻,有一種熟悉的感覺:這種事,做任何事情的過程中都會遇到。 追查之後,發現問題出在一個非常小的地方——一個格式衝突,導致整份報告無法運作。 修好之後,我做了一件比修復本身更重要的事: 把這次的問題、原因、解法,全部寫下來,變成一條守則。... » 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

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

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

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

按下 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

「當企業開始部署地端 AI,真正困難的其實不是模型」
「當企業開始部署地端 AI,真正困難的其實不是模型」

公司官網部落格版本(WordPress Gutenberg 適用) PCPiLOT 技術觀察 當地端 LLM 開始進入「工作負載工程」: 我們如何重新理解模型、Prompt 與商業效率 這不是一篇單純比較模型分數的 benchmark 報告,而是一場對「本地 AI 系統工程」的重新理解。 最近這段時間,我們在 PCPiLOT 內部進行了一輪相當完整的本地 LLM 壓力測試與工作負載分析。 測試對象包含多種模型架構、多個 Context Window、不同量化設定,以及六種企業常見知識工作場景。我們不只看模型回答「像不像」,而是開始量測: 知識密度 推理穩定性 字數控制能力 tok/s 與 wall time Context 使用效率 不同 workload 下的商業效益 而真正有趣的地方,是測試結果開始顛覆許多人對 LLM 的直覺。 一、大模型,不一定帶來更高商業價值 我們原本預期,27B 等級模型應該會明顯優於 9B 模型。但在實際測試中,結果並非如此。 某些 9B q8 模型,在多數企業知識工作場景下,輸出品質幾乎貼近 27B q4;但延遲更低、推論更快、VRAM 壓力更小。 這代表一件重要的事: 真正影響企業 AI 導入成本的,往往不是模型能力本身,而是整體推論系統效率。 在企業環境裡,真正的成本來自:... » read more

AI 助理一本正經瞎猜,然後被官方文件打臉——<br>一次 OpenCode v1.14.40 + Ollama 的 Windows 排錯完整故事
AI 助理一本正經瞎猜,然後被官方文件打臉——
一次 OpenCode v1.14.40 + Ollama 的 Windows 排錯完整故事

這篇文章有三個主角:一個固執的排錯工程師、一個聽起來很有把握的 AI、以及一份他們都沒去讀的官方文件。 結局是:工程師手動挖對了一半,AI 說中了一半又說錯了一半,官方文件早就把答案寫好了——只是沒人第一步就去查。 一、故事的起點:Qwen 在哪裡? 環境是 Windows 11,Ollama 本地跑著 qwen3.5:9b-q8_0,OpenCode v1.14.40 剛裝好。按理說一切應該順暢——但 OpenCode 每次啟動,都自作主張地選回了一個叫做 minimax-m2.7:cloud 的雲端模型。 ⚠️ 問題明確:你設定好的本地模型,隔一次重啟就消失了。minimax 幽靈般地回來,像是設定根本沒被寫進去。 排錯的直覺是:設定檔的問題。但 哪個 設定檔? XDG 規範遷移的陷阱 OpenCode 在某個版本之後,悄悄從 Windows 慣例路徑遷移到了符合 XDG 規範的新路徑。舊版使用者習慣去改的地方,新版根本不理。 # 舊版慣例(不再生效) %APPDATA%\opencode\opencode.json # 新版 XDG 規範路徑(這才是有效的) %USERPROFILE%\.config\opencode\opencode.json 在這個路徑下,把 model 欄位手動修正為 ollama/qwen3.5:9b-q8_0,重啟,終於有效。Qwen 3.5 開始正常接管工作,而且 tool calling 能力也確認正常——它主動調用 read 工具讀取了本地的 CONSTITUTION.md,完全符合 agentic 工作流的期待。 ✔️ 第一階段結論:路徑找對了,模型確認上線,憲法執行能力驗證通過。... » read more

24GB VRAM 的生存法則:為什麼 26B 模型會讓你的地端 AI 體驗撞牆?
24GB VRAM 的生存法則:為什麼 26B 模型會讓你的地端 AI 體驗撞牆?

前言:效能與品質的拔河 在追求地端大型語言模型(LLM)的過程中,許多企業主與開發者常面臨一個抉擇:在現有的硬體資源(如單片 24GB 顯存環境)下,究竟該追求模型參數的大小,還是追求輸出的穩定性? 最近我在實際操作 PCPiLOT 的核心邏輯時,對 26B / 27B 等級模型進行了深度測試,發現了一個極為現實的技術瓶頸。這篇文章將解析為什麼「模型塞得進去」不代表「真的好用」。 一、 模型變大,不代表生產力提升 以 26B / 27B 等級的模型(如 Qwen 或 Gemma 系列)來說,輸出的邏輯與表達確實非常出色,甚至接近商用等級。 但問題在於:在 24GB VRAM 的環境下,這類模型幾乎把資源吃到極限。這就像一台超載的貨車,雖然還能上路,但已經沒有任何避震空間與加速餘裕。 二、 隱形的效能殺手:KV Cache 與上下文長度 許多人評估硬體時,只看「模型權重大小」,卻忽略了推論過程中的動態變數: 當 VRAM 被模型權重與 KV Cache 噴滿後,系統會被迫將資料外溢到電腦記憶體(RAM)。此時,推論速度會出現「斷崖式下降」,從流暢的每秒十幾字,變成讓人難以忍受的一秒一字。 三、 實戰取捨:為何我目前改採 9B 模型? 為了確保 PCPiLOT 知識中心的運作效率,我目前的工程策略是改用 Qwen 3.5 9B 先撐住。這並非退步,而是基於「可用性」的權衡: 這是一個典型的工程觀念:不追求極致的靜態品質,而是追求「可用性 + 穩定性」的綜合表現。 四、 給地端部署者的三條建議 五、 結語:專業顧問的價值... » read more

<strong>黑盒 白盒 怎麼選? 中小企業 AI 部署邁步走</strong>
黑盒 白盒 怎麼選? 中小企業 AI 部署邁步走

建立地端方案, 第一是要有個目標, 這裡以:針對中小企業在地端部署知識中心的完整建議,考量到要支援:1. 10 類文件、2. 5000 份檔案、3. 1000 張圖表、4. 200 部影片,以及5. 5–10 位同仁同時使用讓 AI 助理 (KIMI) 幫忙擬出專案計畫, 可以分三階段推進.以滿足 新人訓練 以及 客戶服務 的 企業用途.———-這裡立刻展現了一個事實:1. AI 助理很擅長寫企劃,2. 接下來也不難,i. 要有預算,ii. 要有人, 花時間, 盯著企劃一步一步完成.[ 關於 “怎麼執行 ?” 的建議 ]A. 如果企業沒預算, 那就再等等, 等預算湊到再說.B. 如果企業有預算, 沒有執行人才, 那就考慮 市場上的現有方案.C. 如果企業有預算, 也有執行人才, 那就考慮 參考 AI 助理意見,參考市場上的現有方案, 參考雲端服務, 自己花時間推進看看.