SingNova-H Studio把本機AI變成PC

我拆 SingNova-H Studio 怎麼把 200 TOPS、本機推理和 RISC-V dataflow 組成可用的 local AI PC，最後附可直接套用的評估模板。

我最近看一堆「AI PC」發表，老實說很膩。不是貼個 NPU 標籤就想算數，就是把雲端能力硬塞進本機，講得像使用者終於被照顧了，結果一用還是要登入、要連線、要交資料。我真正在意的不是行銷詞，是這台機器能不能把模型留在身邊跑，別再把本機推理講成附加功能。

所以我看到 Nanyang Singtech 發表 SingNova-H Studio 時，注意力直接被兩個字抓住：RISC-V dataflow，再加上 200 TOPS。這不是單純換殼的筆電規格，而是想把 local large models 這件事做成一台真的能用的 PC。我先不信廣告，先拆它的方法論。

Nanyang Singtech 說自己是由 Nanyang Technological University 孵化，並在 ATxSG 首次亮相。這種資料通常很愛把技術講得很滿，但工程細節又藏得很深。我反而覺得這種時候最適合拆：到底是架構真的有料，還是只是把「AI PC」三個字包裝得比較像樣。

別再把 AI PC 當貼紙看

“...first RISC-V dataflow architecture AI PC with 200 TOPS for local large models.”

翻譯一下就是：它想賣的不是一台「有 AI 功能的電腦」，而是一台把本機模型運算放在核心位置的機器。這差很多。前者是功能表上的一格，後者是整台機器的設計起點。你如果真的在做推理、RAG、embedding、code assistant，差別會很快浮現。

我之前幫團隊整理本機推理環境時，最煩的就是這種名詞遊戲。廠商都說支援 local AI，但一問就露餡：沒有離線能力、沒有穩定 runtime、沒有持續負載下的數字。講白了，能 demo 不等於能工作。

實操上，我現在都先問三件事：第一，離線能不能跑；第二，持續 30 分鐘後會不會掉速；第三，runtime 是不是你能真的拿來接工作流，不是只能看展示影片。這三題過不了，AI PC 這個名詞我就先打折。

如果你也在看這類產品，我建議先把 RISC-V International 的基本資料看過，再把 TOPS 當成粗略指標，不要當聖經。TOPS 能告訴你大概有多少吞吐，但不能告訴你這台機器在真實工作負載下到底順不順。

RISC-V 的重點不是潮，是可改

“...RISC-V dataflow architecture...”

這句話的白話版是：這台機器不是只靠一顆通用 CPU 硬扛，而是想用更可客製的架構去處理模型運算。RISC-V 本身的價值，不在於它比較帥，而在於它讓硬體團隊比較能自己調整路徑，不必完全卡在單一大廠的節奏裡。

我會特別注意 dataflow，因為 local AI 真正麻煩的地方，常常不是算力不夠，而是資料怎麼流、怎麼搬、怎麼餵進去。模型推理很多時候就是大量矩陣運算、token 流動、記憶體搬移。如果架構是為這種模式設計的，熱、耗電、延遲就比較有機會壓下來。

我看過太多「加速」其實只是把 CPU 包裝一下，名字換得很玄，體感還是一樣卡。dataflow 這件事比較像正經路線，因為它關心的是資料路徑本身，不是只看峰值跑分。這種設計如果做得好，最直接的好處就是少一些無謂等待。

實操寫法很簡單：你在看硬體時，不要只問「支援什麼模型」，要問「這顆晶片是為什麼工作型態設計的」。再來是 memory bandwidth、precision、scheduler 在持續負載下怎麼表現。這些細節通常比任何「AI-ready」標章更有用。

• 先看它是不是為持續推理設計，不是只看 burst 數字。
• 問清楚記憶體路徑，因為很多 local model 都死在這裡。
• 確認是不是有針對 workload 的加速，而不是泛用算力口號。

200 TOPS 很大聲，但不等於很好用

“...with 200 TOPS for local large models...”

這句話的意思是：它想讓你相信本機跑大模型是可行的。這我不反對，但我會先把 200 TOPS 當成門票，不當成答案。因為峰值吞吐跟真實工作體感，常常是兩回事。跑 benchmark 很漂亮，接上你自己的 prompt chain 就開始喘，這種戲碼我看太多了。

「local large models」這幾個字其實比 TOPS 更重要。它代表目標不是只做小型 edge inference，而是希望你真的把模型留在本機，少碰雲端。這對隱私、延遲、離線使用、還有避免月租帳單，都是實打實的好處。

我之前做過一個內部 code-assist flow，模型單獨跑還行，一加上 retrieval、長上下文和幾個並發請求，硬體就開始露出原形。那次我學到一個很不爽但很有用的事：峰值算力不是可用吞吐，尤其不是你每天要面對的吞吐。

實操上，我會把 200 TOPS 當起點，然後追問 sustained throughput、token latency、記憶體大小、量化支援、還有 30 分鐘後的熱穩定性。比較時不要只拿規格表對規格表，直接拿一個真實工作流測：一段 prompt、一個 retrieval、一段 generation。這樣比較不會被數字騙。

如果你想看主流市場怎麼講 local AI，我會順手看 Intel Core Ultra 跟 AMD Ryzen AI。不是因為它們一定更強，而是因為它們代表主流敘事。你先知道大廠怎麼定義「本機 AI」，才看得出新產品到底是補位，還是真的不一樣。

真正的產品是 local large models，不是那台機殼

“...for local large models...”

這句話我會直接翻成：它不是賣一台普通 PC 再附送 AI，而是把「本機跑模型」當成主要用途。這個差別很大。因為只要你開始跑 embeddings、reranking、code generation、甚至多模態流程，硬體就不再是背景板，而是整個工作流的地基。

我喜歡 local large models，是因為控制權回來了。你決定資料在哪裡跑、模型怎麼換、更新怎麼控，不用每次都看雲端 API 臉色。這點很現實。尤其是你做產品或內部工具時，最煩的就是外部服務一改版，你的流程就跟著壞，還得跟團隊解釋「不是我寫爛，是對方偷偷改了」。

實操寫法是先畫需求表，不要先看硬體。列出你要跑的模型大小、context 長度、是否需要 embedding、是否要同時做 generation、並發數多少。再回頭看機器能不能 cover。這樣你比較不會被「可跑某某模型」這種話術牽著走。

還有一個常被忽略的點是 runtime。硬體再漂亮，runtime 不順就是廢。你要看有沒有標準工具、有沒有文件、有沒有 API，至少不要把自己鎖進一個只能看 demo 的黑盒子。能接工作流，才叫產品。

• 先定義你要跑的模型，再買硬體。
• 不要只看吞吐，要看延遲和穩定性。
• 確認 runtime 能不能離開 vendor demo 獨立使用。

NTU 孵化代表它不是純嘴砲，但也別先高潮

“...a deep-tech company incubated by Nanyang Technological University (NTU)...”

這句話的白話版是：它背後大概率有研究底子，不是完全空手喊口號。這對我來說是加分，但不是蓋章通過。學術孵化通常意味著團隊真的碰過架構問題、效率問題、硬體限制，不是只會做簡報。

不過我也踩過這種坑：研究型團隊很會做 prototype，不代表很會做產品。從實驗室走到能給開發者用，中間差的是文件、SDK、支援、供應鏈，還有一堆很無聊但很致命的細節。這些東西不性感，可是少一個都會卡。

實操上，我會去看研究和落地中間那條橋。它有沒有 developer page？有沒有 SDK？有沒有範例？有沒有明確的 workload 定位？如果答案都很空，那你看到的可能只是研究成果的包裝版，不是能進工作流的東西。

NTU 本身是可信的錨點，這沒問題。問題是，可信不等於可買。硬體世界最常見的教訓就是：第一版發表通常只是開始，真正決定它是不是有用的，是後面能不能讓開發者直接上手。

ATxSG 這種場子，最會把半成品照得很漂亮

“At this year’s ATxSG technology exhibition...”

這句話的意思是：它是在一個很懂基礎建設、連線、邊緣部署的場子亮相。這其實選得不錯，因為 local AI PC 本來就不是純消費電子，它牽涉的是延遲、資料流、部署成本、還有本機算力怎麼跟現場需求對接。

但展會也很會騙人。燈打亮、demo 跑順、講者語氣很穩，很多看起來很厲害的東西，一離開 booth 就沒了。我對這種發表一向都只給「有意圖」分數，不直接給「可用」分數。因為那中間差很遠。

實操寫法是：你看到展會發表，不要只問它多新，要問它離開展場後還剩什麼。文件在哪？SDK 在哪？定價在哪？支援窗口在哪？如果這些都沒有，那就是表演。如果有，才值得進一步測。

我也會建議去看 ATxSG 官方網站，先理解這個場子到底在對誰說話。你會更容易判斷這台機器是給開發者、企業採購，還是只給媒體標題用的。

可抄的模板

# local AI PC 評估模板

用在任何宣稱能跑本機大模型的機器上。

## 1) 廠商怎麼說
- 產品名稱：
- 架構：
- 宣稱 TOPS：
- 記憶體配置：
- 支援的模型類型：
- runtime / 軟體堆疊：

## 2) 我一定要驗證的事
- 能不能完全離線跑一個有用的模型？
- 持續 30 分鐘後延遲有沒有飄？
- 多請求並發時會不會崩？
- 記憶體壓力上來後表現如何？
- runtime 能不能離開 demo 獨立使用？
- docs、SDK、API 是否真的存在？

## 3) 我的測試工作流
- 模型：
- context 長度：
- prompt 類型：
- retrieval 步驟：
- 輸出長度：
- 並發數：
- 功耗 / 散熱限制：

## 4) pass / fail
- 峰值吞吐：
- 持續吞吐：
- token latency：
- 散熱表現：
- 離線可靠度：
- 開發者體驗：

## 5) 最後決定
- 買 / 再測 / 不買
- 原因：
- 什麼會讓我改變判斷：

## 6) 丟給廠商的短問題
1. 這台機器最適合什麼 workload？
2. 持續性能是多少，不是峰值。
3. 本機實際能跑多大的模型？
4. 開發者第一天拿得到什麼工具？
5. runtime 壞掉時怎麼支援？

這段是我把原始發表拆完之後，整理成能直接拿去問廠商、做 PoC、做採購比對的版本。原始來源是 The Manila Times / Globe Newswire 這篇；前面那些判讀和模板是我自己的整理，不是原文照抄。