SUSE 和 Openchip 把 RISC-V 變成 EU stack

我拆解 SUSE 和 Openchip 怎麼把 RISC-V 從晶片話題，拉成歐盟可落地的軟硬體 sovereign stack。

我盯歐洲這種「主權雲」「自主可控」的說法很久了，老實講，大多數都像採購簡報。嘴上講得很硬，底下還是別人的晶片、別人的韌體、別人的控制平面，最後只是把 logo 換掉。我本來也以為 SUSE 跟 Openchip 這種合作差不多，直到我把它的脈絡拆開看，才發現它不是在喊口號，而是在補一條很麻煩、但真的重要的路：ISA、Linux、AI inference、客戶試點，全部一起拉齊。

我真正覺得不對勁的，是歐洲談 sovereignty 時，常常只停在政策詞彙，沒碰部署現實。布魯塞爾可以講戰略自主講到天亮，但如果你的 enterprise Linux、cloud-native 工具、AI stack 還是預設 Nvidia-first，那你只是把依賴往下一層藏而已。這次 SUSE 和 Openchip 的方向，至少第一次讓我覺得像工程，不像品牌話術。

我這次的拆解主要參考 Noah Bovenizer 在 The Stack 的文章，裡面提到 SUSE 和 Openchip 的合作備忘錄，時間是 2026 年 6 月 25 日。文中也連到 SUSE、Openchip、European Commission 的 Chips Act，以及 RISC-V。來源沒有提供觀看數、星數或書籤數，所以我不亂掰。

這不是在談晶片，是在搶預設值

"By optimising the hardware and software layers in tandem, the collaboration unlocks maximum performance for intensive AI and high-performance computing (HPC) workloads, especially leveraging native integrations such as the RVA23 profile and RVV vector instructions."

翻譯一下就是：SUSE 和 Openchip 想把軟體假設跟硬體現實對齊。這句話很無聊，但很要命。你如果真的 port 過 OS、runtime 或容器平台到新架構，就知道最煩的不是能不能 compile，而是 compile 完之後一堆細節開始爆：效能掉、套件壞、driver 不合、support matrix 一塌糊塗。

我以前幫團隊看過 ARM migration，大家一開始都以為難點是「先讓它跑起來」。錯。真正難的是讓它夠 boring，boring 到 ops 願意接、security 願意簽、產品團隊願意上，不用每次都開 exception。這次的重點也一樣。RISC-V 是 ISA 沒錯，但真正值錢的是預設值：OS 怎麼預期、AI stack 怎麼假設、哪種硬體 profile 會變成正常選項。

實操上，我會先把「硬體架構」當成 platform engineering 的一部分，而不是另一條平行線。你如果在做 sovereignty、成本控管、供應鏈風險管理，先把 stack 的假設攤開來看：

• 哪些 binary 是 architecture-specific。
• 哪些 kernel、driver、accelerator 其實綁死單一 vendor。
• 哪些 CI 只測 x86，根本沒真的支援多架構。
• 哪些地方只是「能跑」，不是「能交付」。

我最喜歡這組合作的一點，是它把問題從「歐洲能不能做晶片」改成「歐洲能不能做出一個讓晶片真的可用的 stack」。這題才對。沒有軟體支援的晶片，通常只是昂貴的樂觀。

RISC-V 是逃生門，但前提是你願意做髒活

文章把合作重心放在 RISC-V，這個 open instruction set architecture 之所以常被拿來談 sovereignty，不是沒原因。它不像 x86 或 ARM 那樣被單一生態徹底綁住。聽起來很爽，像終於有出口了；但工程現實很冷血，出口是有代價的。

也就是說，RISC-V 只能幫你降低政治依賴，不能自動消滅工程債。你還是得補 compiler、kernel、toolchain、測試、observability、packaging，還要有客戶故事。這些東西沒對齊，open ISA 只會變成「很適合 demo 的研究題目」。

我自己踩過類似的坑。以前幫一個 edge device 團隊評估架構切換，大家都很興奮，因為故事很好聽。結果沒人想接 build pipeline、container base image、runtime regression 這些硬活。最後我們做出一個 demo，沒做出一個 platform。這差別很大。demo 是給簡報看的，platform 是給客戶和 SRE 活著用的。

SUSE 這裡的角色很關鍵，因為 enterprise Linux 就是架構夢想要嘛變正常、要嘛安靜死掉的地方。如果 SUSE 能把 RISC-V 上的系統行為做得穩、做得可預期，這玩意就不再像實驗室玩具，而是 procurement 可以認真看的選項。

實操寫法很簡單：你如果要評估新架構，先把 operational criteria 寫死，不要只講 vibe。像這些問題就該先問：

• 能不能照你自己的節奏 patch。
• 能不能掃漏洞、做合規檢查。
• 能不能從 source 重建。
• 能不能在不特殊處理的情況下接進 CI/CD 和 observability。

如果答案不是清楚的 yes，你沒有 portability，你只有 pilot。這句我講得很直，因為我看太多人把 pilot 當成已經成功，最後只是把風險延後而已。

AI Factory 這條線，才是歐洲 sovereignty 的真面目

The Stack 提到，兩家公司還會一起碰一個「sovereign」的歐洲 AI inference stack，基礎是 SUSE 的 AI Factory。文章也直接點出，這套東西目前還是 Nvidia-centric。這段我看得很清楚，因為它把歐洲 sovereignty 的矛盾整個掀開：你不能一邊講 sovereign，一邊在最熱的工作負載類別上，仍然高度依賴單一加速器生態。

翻成白話，這不是叫你明天就把 Nvidia 踢出去。那太幼稚了。真正該做的是先做出一條可走的退路。Inference 比 training 更適合先切，因為它比較容易標準化、比較容易分發，也比較容易跟企業真實需求接上。如果歐洲能證明一套 sovereign stack 可以把 inference 跑得夠穩、夠快、夠可支援，這比再寫十份白皮書都更有說服力。

我喜歡這種 sequencing，因為它誠實。你不會先挑最難的工作負載，然後假裝其他問題會自己消失。你先從客戶真的會買單的場景開始，再慢慢把平台擴大。基礎設施就是這樣長出來的，一個又一個 boring、但會收錢的 use case。

實操上，如果你在做 AI platform，我會把問題拆成四塊：training、inference、orchestration、governance。這四個不是同一場仗。

• Inference 最適合先試硬體或軟體替換。
• Training 最容易被 vendor lock-in 卡死。
• Orchestration 看的是平台整合能力。
• Governance 看的是你能不能說清楚資料、模型、部署責任。

還有一件事要講白：你組織裡如果在講 sovereign，先定義清楚。是 data residency 就算？還是 source code control、supply-chain control、hardware independence 都要？我看過太多團隊拿這個詞當遮羞布，嘴上很大聲，實際上還是完全綁在單一 vendor 的 roadmap 上。

歐洲的 sovereignty 問題，本質上是供應鏈問題

文章把這次合作連到 European Commission 對 semiconductor 的說法，重點是歐洲的 technology sovereignty 很急，而且供應鏈依賴有被 weaponised 的風險。這種官話很硬，但意思其實很簡單：你只要被一個外部供應商卡住，就能整條 roadmap 被悄悄掐死。

也就是說，歐洲想做的不是「完全不依賴任何人」，那種想法太天真。真正目標是減少那些可以單方面 veto 你計畫的地方。晶片、firmware、作業系統、accelerator、工具鏈，只要其中一層鎖死，整個 sovereign 故事就會開始漏風。

我自己也看過企業版的同款劇情。平台團隊先標準化一套 stack，結果 vendor 改 licensing、改產品方向、改 support policy，原本的「標準」瞬間變成包袱。把這件事放大到國家和區域層級，名字就叫 sovereignty。說穿了，還是 exit cost 的問題。

所以實操寫法不是去追求零依賴，而是把每個依賴變成「可替換」。你要的不是自由幻想，是可退出性。

• 列出會卡住 roadmap 的前三大供應商。
• 替每一個依賴標出替換難度和替換時間。
• 先做一條替代路徑，哪怕很醜也行。
• 盡量用 open standards，但要在 production 裡驗證過。

這也是我覺得 SUSE / Openchip 這個組合有意思的地方。它不是把「open」當終點，而是把它當起點。開源很好，但開源本身不會幫你完成整合、認證、支援，更不會自己跳出來把最髒的中段工作做完。

真正的考驗，是客戶能不能不用研究補助就買單

Openchip 那句話我覺得很實在，提到接下來要做的是 certification、roadmap alignment、joint customer pilots。這些詞一點都不酷，但我反而信它。因為很多 infrastructure 計畫死就死在這裡：有政策、有 demo、有新聞稿，就是沒有辦法變成客戶真的能評估、能導入、能負責的東西。

翻譯一下就是，這組合作不是只想被看見，它想變成可以被採購。這很重要。因為 sovereign stack 如果只活在公部門補助案或內部 R&D 裡，其實沒什麼用。它必須撐得過 procurement、security review、support contract，還有第一次 production 出事時的現場。

我坐過那些會議，問題都很土，但也最狠：誰 patch、誰備份、誰被叫起床、kernel issue 誰負責、driver 壞掉怎麼辦、accelerator 晚到六個月怎麼辦。你回答不出來，就不是 platform，只是 presentation。

實操上，我會把 roadmap 直接設計成 customer proof，不要只看內部里程碑。好 pilot 應該至少回答三件事：

• 它能不能跑真實 workload。
• 它能不能融進既有企業流程。
• 它能不能被支援到夠久，久到有商業意義。

如果這三題你答不全，就別硬講大詞。尤其是你在歐洲做技術，別拿 sovereignty 當遮羞布。你得說清楚它到底改了什麼：供應商組合？支援模式？合規姿態？部署架構？如果都沒有改，那它只是貼國旗的 slogan。

我會盯的不是大詞，是四個很無聊的指標

如果我接下來幾季要追這個合作，我不會先看誰講得最大聲。我會盯四件很無聊、但很誠實的事：第一，SUSE 會不會真的把 RISC-V support 做到超過 announcement 層級；第二，Openchip 能不能拿出可取得、可文件化、可支援的硬體；第三，joint AI inference story 會不會從 architecture 變成 reference deployment；第四，有沒有客戶試點真的變成公開可說的 win。

也就是說，成不成功其實看 plumbing。真的有料，你會看到 package support、tooling compatibility、performance notes、customer-facing docs。沒料，你會看到更多政策字眼，和更少 artifact。

實操到你自己的組織也一樣。你在評估任何「sovereign」或「open」平台時，就直接要這些東西：

• support matrix。
• build instructions。
• security posture。
• migration path。
• pilot 轉 contract 的證據。

這就是我喜歡這則故事的原因。它沒假裝難的部分是新聞稿。難的部分是把 stack 做到夠 boring，boring 到你真的敢把它放進 production。這比喊願景實際太多了。

可抄的模板

# Sovereign stack evaluation template（可直接改成你公司的版本）

## 1) 我們到底在解什麼問題？
- 要降低的依賴： [vendor / architecture / region]
- 目標 workload： [inference / HPC / edge / core enterprise]
- 成功定義： [supportability / portability / cost / compliance]

## 2) 架構假設
- ISA： [x86 / ARM / RISC-V / other]
- OS support： [kernel versions, distro, lifecycle]
- Toolchain： [compiler, runtime, packaging]
- Acceleration： [GPU / NPU / custom silicon / none]

## 3) 依賴盤點
| Layer | Current dependency | Replacement difficulty | Exit time | Owner |
|------|--------------------|------------------------|----------|-------|
| Firmware | [name] | [low/med/high] | [weeks/months] | [team] |
| OS | [name] | [low/med/high] | [weeks/months] | [team] |
| AI runtime | [name] | [low/med/high] | [weeks/months] | [team] |
| Hardware | [name] | [low/med/high] | [weeks/months] | [team] |

## 4) Pilot 設計
- Workload: [real customer workload]
- Environment: [lab / staging / production-like]
- KPI 1: [performance]
- KPI 2: [operational fit]
- KPI 3: [support readiness]
- Fallback plan: [what happens if it fails]

## 5) 證據清單
- [ ] Build instructions are reproducible
- [ ] Security scanning works on the target stack
- [ ] Monitoring and logging are supported
- [ ] Upgrade path is documented
- [ ] Support contract exists
- [ ] Customer pilot has a named owner

## 6) 決策規則
只有在以下三件事都成立時才往下走：
- platform 能跑真實 workload
- operational model 可支援
- current dependency 的 exit cost 有下降

## 7) 給管理層的 30 秒版本
我們不是在買 sovereignty 這個口號。
我們是在買 optionality、supportability，還有一條更低風險的 vendor lock-in 退出路徑。

這段我真的建議你直接拿去改。因為它逼你把討論從意識形態拉回工程，這才是有用的地方。

原始來源是 Noah Bovenizer 的 The Stack 文章，以及文中連到的 SUSE、Openchip、European Commission Chips Act、RISC-V。我上面加的判讀、拆解和模板是我自己整理出來的，原文新聞點和引述則來自這些來源。