35台NVIDIA超算把歐洲變實驗室

我拆 NVIDIA 歐洲 35 台 AI 超算佈局，順手給你一份可直接套用的 HPC、AI factory、量子-GPU 規劃模板。

我盯 NVIDIA 這類超算新聞一陣子了，老實說，很多時候都像在看簡報煙火：數字很大、名詞很多、照片很亮，但落到實際工作流程，常常還是那套老問題。GPU 買了，機櫃上了，大家拍完照，研究團隊還是在排隊，模型還是在卡，跨團隊整合還是在靠人肉接龍。我以前也以為只要算力夠大，後面自然會順，結果通常不是。真正卡住的，從來不是「有沒有機器」，而是「能不能把研究、訓練、推論、模擬一路串起來」。

這次我讀的是 NVIDIA 這篇歐洲 35 台 AI supercomputers 的 newsroom 文章。它最刺到我的，不是那種老套的「更快、更強」，而是它明明白白在講一個系統：35 個系統、23 個國家、超過 300 萬研究者，還把量子工作、模擬、訓練、推論一起放進同一個敘事裡。這就不是單純買硬體了，這是在搭一個讓人真的能做事的操作模型。

歐洲不是在買超算，是在買時間

"NVIDIA today announced that a record 35 NVIDIA AI HPC supercomputers are in development across Europe — equipping more than 3 million researchers with next-generation infrastructure for continental AI, accelerated science and industrial innovation."

翻譯一下就是：歐洲想縮短研究週期。這句話很樸素，但很要命。你在氣候、醫療、生醫、能源、製造這些領域做事，真正磨人的往往不是模型本身，而是「想法 → 模擬 → 訓練 → 驗證 → 重跑」這一整段循環太慢。慢一天，團隊就少一輪判斷；慢一週，很多專案就只剩會議。

我看到「300 萬研究者」這個數字時，腦袋裡跳出來的不是規模，而是對象。NVIDIA 不是只在賣給少數平台工程師，而是在想辦法讓一大票本來就有科學問題的人，直接碰到算力。這跟「給一組精英團隊一台猛機器」完全不同。前者是公共基礎設施思維，後者只是採購。

我以前幫過一個研究團隊整理混合模擬和 ML 的流程，算力其實不差，但每個步驟都在不同工具鏈裡，交接全靠人工。最後整個系統看起來很高級，實際上只是把慢流程包進排程器裡。大家不在乎 FLOPS 多漂亮，只在乎下一次實驗能不能從三天縮到三小時。

實操上，我會先把問題改寫成「這套平台每年能省多少研究者工時」，而不是「有多少 GPU」。你要量的是 queue time、模型迭代時間、模擬 turnaround、部署延遲。這四個如果沒降，其他都是裝飾。

• 先畫完整 workflow，再看算力缺口。
• 先量排隊時間，再談峰值 FLOPS。
• 研究工作流和 production inference 要分開算，不要混成一鍋粥。

全棧不是口號，是避免你自己補洞補到死

"With NVIDIA Quantum InfiniBand networking, NVIDIA CUDA-X libraries, NVIDIA NIM microservices and NVIDIA AI Enterprise software, NVIDIA provides a full-stack platform for science, spanning model training, simulation, inference and agentic AI."

這段的白話版就是：NVIDIA 賣的不是一堆零件，是一套有意見的系統。老實說，這才合理。你如果只丟 GPU 進去，然後說剩下交給團隊自己整合，最後通常會變成：網路是另一組人管，排程是另一組人管，模型服務又是另一組人管，最後大家都在補洞，沒人真的擁有流程。

我喜歡這段的原因很直接：它承認 GPU 不是價值單位，workflow 才是。CUDA-X、NIM、AI Enterprise、Quantum InfiniBand 這些東西，核心目的都一樣，就是少寫 glue code，少做重複整合，少讓研究者變成半個系統管理員。你要的是把科學問題往前推，不是讓每個人都學會怎麼救網路拓樸。

我之前看過一個平台專案，硬體規格漂亮得要命，但從資料匯入、訓練、推論到部署，中間每一段都要手動接。結果團隊每週都在開「整合會」，沒人真的在做實驗。那種平台很像買了一台超貴的工具箱，裡面每把工具都閃閃發亮，但你還是得自己先學會修水管。

實操寫法很簡單：你評估平台時，不要只看 spec sheet，請廠商直接走一條端到端流程給你看。從資料進來、訓練、驗證、推論、部署，誰負責什麼，哪一步會爆，爆了誰接。再問一次混合模擬和 AI 的場景怎麼處理。如果對方只能講單點能力，不能講流程，那多半還在賣零件，不是在賣系統。

• 要求一條完整 reference workflow。
• 確認網路是為多節點訓練設計，不只是為儲存服務。
• 把推論支援寫進合約或交付範圍，別只口頭說「也可以」。

AI factory 不是新名詞，是共享基礎設施的正名

"Barcelona Supercomputing Center’s AI Factory, the first EuroHPC AI-specific installation"

這句話的意思很明白：歐洲開始把 AI 基礎設施當成一種共享公用層，而不是某個專案臨時拼出來的資源池。它用的是 "AI factory" 這個詞，不是為了好聽，是因為這詞帶有重複性、服務性、可交付性。不是一台一次性的機器，而是一個可以讓很多人持續使用的設施。

這篇裡 Barcelona Supercomputing Center 的 MareNostrum 5 升級是最像樣的例子。它把 GB300 NVL72、GB200 NVL4、Quantum-X800 InfiniBand 都放進來，還講到大概 20 exaflops 的 training 和 33 exaflops 的 inference。你要不要背數字其實其次，重點是方向很清楚：這不是單純追峰值，而是把平台做成能同時服務研究和交付的東西。

我看過這種模式做得好的團隊，通常都有一個共同點：他們把平台當產品，而不是當倉庫。相反地，做壞的團隊都很像在期待平台組「順手把複雜度吃掉」。不會的。你不先定義誰能用、怎麼排隊、資料怎麼管、哪些工作負載能上哪一層，最後就會得到一個超貴的共享資料夾，裡面塞滿半成品 notebook。

實操上，如果你也在做內部 AI factory，我會直接把它寫成產品規格：使用者是誰、支援哪些 workload、有哪些 access tier、SLA 怎麼訂、資料主權怎麼管。不要一開始就談願景，先談規則。願景通常大家都會講，規則才是會吵架的地方。

這裡我會順手看幾個權威來源：Barcelona Supercomputing Center、EuroHPC Joint Undertaking、還有 NVIDIA data center 頁面。因為真正重要的不是新聞稿，而是這些機構怎麼把抽象名詞變成政策和流程。

歐洲真正想要的是把科學和產業放在同一條軌上

"These systems will support research across climate science, healthcare, clean-energy decarbonization, quantum computing and fundamental science."

白話講，這批系統要同時服務公共研究和產業場景。這很難，因為兩邊的需求根本不一樣：研究要自由，產業要穩定；研究可以試錯，產業不能亂來；研究愛跑長實驗，產業在意 SLA。可是一旦設計得好，回報也很實際，因為同一套底層可以少掉很多重複建設。

這篇裡點名的專案像 BavariaAI 的 Blue Swan、IT4LIA、HLRS 的 HammerHAI、NAISS 的 Mimer AI Factory，方向都很一致：共享底層，保留地方需求，不要每個機構都自己長出一套互不相容的堆疊。這種事講起來很簡單，做起來很煩，但它確實比各自為政好太多。

我自己碰過一個很像的情境：同一個 engineering 組織想同時支援研究實驗和面向客戶的 inference。研究團隊要自由，產品團隊要可預測。最後我們的做法是切成 shared backbone、separate execution lanes。共享身分、監控、政策，但把實驗、批次模擬、低延遲推論隔開。這樣至少不會讓 production 被實驗拖下水。

實操寫法：把 control plane 和 workload lanes 分開。身份驗證、觀測、治理可以共享，但研究 job、batch simulation、production inference 要分流。你如果用 Kubernetes、Slurm，甚至兩個一起用，都要明確寫出哪一層管什麼，不然最後就是所有人都說自己有治理，實際上沒人能擋住亂流。

工業面也很有意思，NVIDIA 把 Siemens Energy 和氫能渦輪這類案子拉進來，重點其實不是 AI 多神，而是模擬迭代被壓縮了。這種場景最能看出算力是不是有用，因為它直接反映到設計週期。

量子-GPU 這條線，終於比較不像簡報童話

"NVIDIA is enabling European supercomputing centers and institutions to develop and run useful hybrid quantum-classical applications using NVIDIA CUDA-Q, an open, qubit-agnostic platform for hybrid computing"

這段我看了是有點爽的，因為量子計算終於比較像在講工作流，不像以前那種只會拿幾張圖騙人。過去很多 quantum demo 看起來很炫，結果你一問：排程怎麼接？資料怎麼進？模擬怎麼做？硬體怎麼切？整個就開始飄。現在至少開始往實際環境靠了。

文章裡列了幾個具體動作：CINECA 和 EuroHPC 跟 Pasqal 合作、Fraunhofer FOKUS 把 CUDA-Q 跟 Eclipse Qrisp 整合、Barcelona Supercomputing Center 部署 Qilimanjaro 的 analog QPU、Jülich 在 JUPITER 上模擬一個 universal 50-qubit quantum computer。尤其最後那個很有意思，因為它講的是模擬規模，不只是硬體口號。

CUDA-Q 的價值在於它是 qubit-agnostic。這種詞聽起來很工程，但其實很重要，因為它代表你不用每換一種量子硬體就整套重寫。這種「少綁死」的設計，才是平台能不能活下去的關鍵。不是每個人都需要量子，但如果要做，至少別把自己鎖死在單一硬體上。

實操上，如果你在摸 quantum-plus-HPC，我會先看三件事：能不能直接接現有排程、能不能先用模擬開發、能不能跟既有觀測和資料管線共用。只要這三件事有一個斷掉，整條路就會很難走。量子不是不能做，是不要一開始就把自己做成孤島。

• 先用模擬當預設開發路徑。
• 量子 job 提交流程要盡量對齊現有 scheduler。
• 工具選型先看能不能減少硬體綁定。

真正值錢的地方，是把昂貴模擬縮短

"This cuts simulation times by up to 77% to advance hydrogen-capable, low-carbon gas turbines."

這句最務實。翻譯一下就是：算力不是拿來炫，是拿來縮短工程迭代。對這種物理問題很重的領域來說，實體測試又貴又慢，能把模擬時間砍掉，等於直接改變團隊怎麼做決策。這比很多 AI 口號都實在。

Siemens Energy 這個例子很適合拿來當教材，因為它把設計、CFD 模擬、製造跟 NVIDIA Omniverse libraries、CUDA-X、AI infrastructure 串在一起。這不是 demo，是流程。你如果真的能把 simulation time 壓下來，工程團隊就能多做幾輪設計比較，不用每次都賭一把。

我喜歡這種案例，因為它不裝神。沒有人在說 AI 會自己發明更好的渦輪。它只是讓驗證更快、迭代更快、死路更少。這才是基礎設施該有的樣子：不是替你思考，而是讓你少浪費時間在等待上。

實操寫法：先挑你組織裡一條最貴的模擬流程，做 before/after。量 runtime、工程師 review 時間、每週能跑幾輪設計。然後只把 AI 放進最卡的那一小段，不要一開始就搞什麼 agentic 大戲。先解 bottleneck，再談漂亮架構。

如果你要查工具，CUDA-X 和 NIM 這兩頁值得一起看。至少你會比較清楚這套堆疊到底想怎麼把軟體層補齊。

可抄的模板

# AI supercomputing rollout template for research + industry + optional quantum workloads

## 1. 我們要解的問題
我們不是在買 GPU。
我們是在建立一個共享 AI/HPC 平台，讓研究、模擬、推論、部署可以在同一個治理框架下運作。

## 2. 使用者分層
- Research users：需要訓練、模擬、批次推理
- Engineering users：需要快速設計迭代、驗證、分析
- Production users：需要低延遲 inference、穩定 SLA
- Optional quantum users：需要 hybrid quantum-classical workflow

## 3. 平台分層
### Compute
- GPU nodes for training and inference
- CPU nodes for orchestration, preprocessing, ETL
- Optional quantum access layer or simulator tier

### Networking
- High-bandwidth interconnect for multi-node jobs
- Separate storage traffic from training traffic
- Define latency-sensitive lane for inference

### Software
- Scheduler: Slurm / Kubernetes / hybrid
- Container runtime: OCI-compatible
- Model serving: NIM / vLLM / equivalent
- Workflow tools: notebooks, pipelines, CI/CD
- Quantum workflow: CUDA-Q / simulator / vendor SDK

### Governance
- Identity and access control
- Data classification and residency rules
- Queue priority by workload type
- Approval flow for production workloads

### Observability
- Queue time
- GPU utilization
- Training throughput
- Simulation runtime
- Inference latency
- Cost per experiment
- Failure rate by workload type

## 4. Operating model
- Shared control plane
- Separate execution lanes for research, batch simulation, and production inference
- Default to simulation before hardware access for experimental workloads
- Publish service levels for queue time and uptime
- Define who owns incidents at 2 a.m.

## 5. Launch checklist
- Who can submit jobs?
- Which workloads are allowed?
- What data can move between systems?
- What happens when research traffic conflicts with production traffic?
- Which team owns support, patching, and cost controls?

## 6. First 90 days
### Days 1-14
- Map current workflows and bottlenecks
- Identify the top 3 expensive queues
- Define user groups and access tiers

### Days 15-30
- Pick one pilot workload end to end
- Set success metrics: queue time, runtime, iteration speed
- Decide the minimum governance model

### Days 31-60
- Connect training, simulation, and serving paths
- Add monitoring and cost attribution
- Document fallback paths when a lane is congested

### Days 61-90
- Review usage by workload type
- Tune queue priorities
- Publish the first internal platform SLA

## 7. Copyable prompt for platform planning
You are helping me design a shared AI and HPC platform for research, simulation, inference, and optional quantum workflows.
Give me:
- a workload split
- a governance model
- a scheduler and serving stack recommendation
- a minimal observability checklist
- a 90-day rollout plan
Keep it specific and assume multiple teams will share the system.

## 8. Decision rule
If a proposal does not reduce queue time, iteration time, or integration work, do not approve it.

我會直接拿這份模板去比對這次歐洲的幾個站點：Barcelona、BavariaAI、IT4LIA、HammerHAI、Mimer。每一站都問同一組問題，看誰是真的在產品化 access，誰只是把容量做大。這樣比看新聞稿有用多了。

這篇的原始來源是 NVIDIA newsroom：https://nvidianews.nvidia.com/news/europe-unveils-a-record-35-new-nvidia-ai-supercomputers。我上面拆的觀點和模板是我自己的整理，裡面的事實、引述和專案名則來自原文與文中連結的官方頁面。