高通收購 AI 軟體新創 Modular，打造跨硬體通用推論平台
Qualcomm 官方新聞稿 · 2026-06-24
高通（Qualcomm）於 2026 年 6 月 24 日宣布，已與 AI 軟體基礎架構新創公司 Modular 達成收購協議，交易預計於 2026 年下半年完成，仍需通過監管審查。Modular 以開源程式語言 Mojo 及推論框架 MAX 聞名，其核心主張是讓 AI 模型「一次撰寫，到處執行」，橫跨 CPU、GPU、NPU 及客製化 ASIC 等異質硬體。這項交易標誌著高通正式將軟體能力列為 AI 策略的核心支柱。
原本的問題：AI 軟體碎片化的困境
當前 AI 推論市場面臨嚴重的硬體鎖定（hardware lock-in）問題：開發者為了在不同加速器上執行相同模型，往往必須針對各家廠商的專有 SDK 重新撰寫底層核心（kernel）。NVIDIA 有 CUDA，AMD 有 ROCm，高通自家的 NPU 亦有其對應工具鏈，導致跨平台部署成本極高。
高通執行長 Cristiano Amon 在聲明中指出，產業正朝向「分散式、多供應商架構」演進，這樣的趨勢要求一個更開放、更現代的軟體基礎。邊緣裝置與資料中心之間的工作負載分配日益靈活，若每換一種硬體都需重新最佳化，商業部署速度勢必受阻。
採用的方法：MAX 框架與 Mojo 語言
Modular 的技術核心由兩個元件構成。MAX（Modular Accelerated Xecution）是一個專為生成式 AI 設計的模型服務框架，支援混合專家模型（Mixture-of-Experts, MoE）、開放權重模型等主流架構，並已在 Modular Cloud 上對外提供服務。
Mojo 則是由前 LLVM 及 Swift 語言設計者 Chris Lattner 主導開發的新程式語言，語法相容 Python 生態系，但執行效能接近 C。
- 支援 CPU、GPU、NPU、自定義 ASIC 等多種目標硬體
- 透過統一抽象層消除各廠商 SDK 的底層差異
- 模型權重與推論邏輯分離，升級硬體時無需重新訓練
- 2026 年 6 月 18 日發布的
Modular 26.4已引入 MoE 推論支援，並推進Mojo 1.0開發進程
Lattner 在收購聲明中表示，加入高通能取得「規模與平台觸及範圍」，以加速讓 AI 開發對更廣泛開發者更為可及。高通則計劃將 Modular 的技術整合至其橫跨邊緣與資料中心的 AI 產品線，補強現有 Snapdragon 與 Cloud AI 系列晶片的軟體生態。
實際效果：對產業格局的影響
這項收購的時間點耐人尋味。高通在智慧手機 SoC 市場的 NPU 領導地位雖早已鞏固，但在資料中心 AI 推論市場，其影響力仍遠不及 NVIDIA。取得 Modular 後，高通有機會以軟體作為差異化入口，將自家硬體的吸引力延伸至雲端工作負載。
此外，對 NVIDIA 而言，這是一個潛在的競爭訊號：一旦有工具能讓開發者以極低成本將推論工作負載從 H100 遷移到其他平台，NVIDIA 的護城河便不再只取決於硬體效能，還需仰賴生態系黏性。Modular 已於 2026 年 6 月舉辦開發者大會 ModCon 2026，展示同一套程式碼在 NVIDIA、AMD 及其他硬體上的效能數據，此舉更直接向市場傳遞了「去鎖定」的訊號。
OpenAI 發表首款自研推論晶片「Jalapeño」，與 Broadcom 合作打破 NVIDIA 單一依賴
TechCrunch · 2026-06-24
OpenAI 於 2026 年 6 月 24 日正式揭露首款自研 AI 推論晶片 Jalapeño，該晶片由 OpenAI 與半導體大廠 Broadcom 合作設計，專為推論工作負載（inference）最佳化，目前處於早期測試階段。OpenAI 總裁 Greg Brockman 表示，Jalapeño 在初步測試中展現出「優於現有最先進方案」的每瓦效能（performance-per-watt），預計部署後將大幅降低 ChatGPT 等服務的運算成本。
為何自研晶片？從 NVIDIA 依賴談起
過去數年，OpenAI 幾乎完全倚賴 NVIDIA GPU（尤其是 H100 和 H200 系列）執行模型訓練與推論。GPU 的高採購成本與供應鏈限制成為 OpenAI 擴大服務規模的主要瓶頸，促使公司從 2025 年起積極探索自研矽晶路線。
Brockman 指出，OpenAI 內部識別出「特定工作負載被現有硬體嚴重服務不足」的情形，尤其是即時程式碼生成這類對延遲極為敏感、但計算強度不及大規模訓練的場景。這類工作負載在通用 GPU 上執行時，能耗比並不理想，是自研晶片最具說服力的切入點。
Jalapeño 的設計哲學
Jalapeño 的設計哲學體現在 OpenAI 對「全棧最佳化」的追求：從晶片架構、記憶體系統、網路層到排程系統，全部圍繞特定推論場景協同設計，而非在通用 GPU 之上疊加軟體優化。這與 Google 的 TPU（Tensor Processing Unit）及 Amazon 的 Trainium 策略如出一轍，均試圖透過垂直整合降低 AI 服務的邊際成本。
值得注意的是，OpenAI 的 AI 模型本身也參與了 Jalapeño 的晶片設計流程，用於最佳化電路佈局與核心架構決策——這一點被 OpenAI 刻意強調為「全棧 AI」理念的具體呈現。Broadcom 在此扮演的角色是晶圓廠接口與封裝設計，而非主導架構；核心工程主導權仍在 OpenAI 手中。
| 公司 | 自研晶片 | 主要用途 | 合作夥伴 |
|---|---|---|---|
| OpenAI | Jalapeño | 推論（Inference） | Broadcom |
TPU v5e/v5p | 訓練 + 推論 | 自研 | |
| Amazon | Trainium 2 | 訓練 | 自研 |
| Meta | MTIA | 推論 | 自研 |
訓練仍靠 NVIDIA，推論才是主戰場
OpenAI 明確表示，大規模預訓練（pre-training）工作短期內仍將持續使用 NVIDIA 硬體，因為這類工作負載對絕對算力的需求遠超過能耗最佳化的優先級。Jalapeño 鎖定的是「模型訓練完成後」的推論階段——也就是 ChatGPT、Codex 等產品回應用戶請求時所需的算力。
這個策略有其商業邏輯：推論占 OpenAI 日常運算支出的絕大比例，服務規模越大，每次推論的成本越直接影響獲利能力。以 Jalapeño 替代部分推論 GPU 集群，哪怕只是特定工作負載，都能帶來可觀的成本節省。此外，OpenAI 與 Broadcom 的策略合作協議早於 2025 年 10 月便已公告，此次發布是正式落地成果。
原始來源：TechCrunch 報導
Discord 如何用 Rust 打造資料庫自動化控制平面，將 36 小時手動作業壓縮至 2 小時
Discord Engineering Blog · 2026-05-08
Discord 資料庫基礎架構工程師 Peter French 於 2026 年 5 月 8 日發表文章，詳述該公司如何設計並實作 Scylla Control Plane（SCP），以自動化方式管理數十個 ScyllaDB 叢集及其中數百個節點。在 SCP 上線之前，一次完整的叢集擴容或作業系統升級，往往需要工程師持續投入超過 36 小時的人工操作；如今同樣的工作僅需不到 2 小時，且多數等待時間無需人員值守。
原本的問題：自動化腳本的三大失敗模式
Discord 的 Persistence Infrastructure 團隊並非一開始就沒有自動化工具。他們曾以 Python 和 Bash 腳本拼湊出一套臨時方案，但這些腳本隨著叢集規模成長暴露出三個根本缺陷。
- 執行順序不安全：腳本之間缺乏明確的先決條件聲明，容易在叢集狀態未就緒時就執行後續步驟
- 中途失敗難以恢復：一旦操作在中間環節失敗，缺乏統一的狀態紀錄，難以從斷點安全繼續
- 難以擴充：每新增一種操作類型，都需要具備深厚機構知識的工程師才能正確修改腳本邏輯
這三個問題的共同根源是缺乏一個統一的抽象層，使得各種資料庫運維操作能夠以一致、可重用的方式被定義與執行。SCP 的設計目標正是填補這個空缺。
採用的方法：Task、Workflow、Job 三層架構
SCP 採用三層架構，由下而上分別是 Task、Workflow 與 Job。Task 是最小的工作單元，分為節點層級（node task）與叢集層級（cluster task）兩類，每個 Task 必須實作三個介面：
fn name() -> String
fn preconditions() -> Vec<Condition>
fn execute() -> Result<(), Error>冪等性（idempotency）是 Task 的強制要求——執行一次與執行兩次的結果必須相同。此外，Condition 機制允許 Task 在執行前輪詢叢集狀態，例如等待所有節點完成 compaction 後才繼續，避免在不穩定狀態下貿然操作。
第二層 Workflow 以 YAML 定義 Task 的執行序列，並透過兩個關鍵參數控制並行安全性：
concurrency_unit：定義並行單位（例如以可用區 Availability Zone 為單位），確保不同 AZ 的節點不會同時重啟，避免 quorum 喪失concurrency_limit：限制同一時間最多允許幾個並行單位同時執行
Workflow 亦支援 template variable，讓同一份定義可在執行時帶入不同參數，無需為每個叢集維護獨立的設定檔。第三層 Job 是 Workflow 的執行實例，綁定至特定叢集，狀態持久化於本地 SQLite 資料庫中，確保即使服務中途重啟也能從中斷點繼續。
實際效果：從數十小時到無人值守
SCP 目前已自動化 Discord 資料庫團隊的多種核心運維場景：
- 叢集擴容與新節點加入（node joining）
- Ubuntu 作業系統滾動升級
- 設定變更的滾動重啟（config change rolling restart）
- ScyllaDB 版本升級（透過 shadow cluster 策略）
- Binary cycling 與清理操作
以 OS 升級為例，原本需要工程師全程陪同操作 36 小時以上，現在 SCP 自動按 AZ 分批推進，工程師只需在出現「不可恢復錯誤（unrecoverable error）」時才需介入——SCP 會透過 webhook 主動通知，其餘時間系統完全自主運行。這個設計本身也反映了 SCP 的錯誤分類哲學：可重試的錯誤自動重試，不可恢復的錯誤才升級為人工事件。
技術實作方面，SCP 以 Rust 撰寫，選擇 Rust 除了效能考量外，更重要的是型別系統在編譯期強制錯誤分類的正確性，減少運行期因錯誤處理疏漏導致的叢集故障。SQLite 作為狀態後端則刻意避免了對外部服務的依賴，降低 SCP 本身的運維複雜度。