市場預測WWDC將推ARM版MacBook?蘋果面臨的問題還有一大堆
市場預測WWDC將推ARM版MacBook?蘋果面臨的問題還有一大堆

6月23日週二凌晨,蘋果即將召開第一次線上開發者大會活動——WWDC 2020。

按照慣例,這是一個屬於開發者的盛宴,人人都在期待新的iOS 14,期待新的macOS、iPadOS、watchOS、tvOS等等。因為大家都知道硬體更新一般都要等到秋季和春季。

WWDC
圖/ 愛范兒

但今年的WWDC上可能會有一些對硬體事關重大的變化措施。

就在最近,傳出了蘋果要轉換平台的消息。準確點說,是蘋果準備推出ARM版本的MacBook產品,而最近幾年和在售的筆電與桌面產品,蘋果一直使用的是英特爾平台。

從英特爾到ARM,是整個軟硬體生態的遷移

其實平台轉換這事蘋果並不是第一次幹,早在十五年前蘋果就經歷過一次從IBM的PowerPC平台轉換到英特爾平台。但今天和2005年不一樣,當年蘋果的平台轉換需求是十分迫切的,因為IBM本身設計能力跟不上,PowerPC G5的功耗和發熱都很高,根本不適合筆記型電腦這樣的行動平台。

根據知乎用戶@蓬岸Dr.Quest在相關問題下的答案,我引用了一部分蘋果從PowerPC轉向英特爾幾個比較重要的時間節點:

2005年7月6日,蘋果宣布進行平台轉換,並向部分開發者提供開發者轉換工具(Developer Transition Kit),同期發布的Xcode 2.1支援生成通用二進制(universal binaries)格式的應用程式。

2006年1月,蘋果發布15寸Macbook Pro和英特爾處理器的iMac。

2006年8月,蘋果發布英特爾處理器Xserve,完成產品線的轉換。QuarkXPress 7.0以通用二進制形式發布。

2007年10月,Mac OS X 10.5發布。這是最後一代可以安裝在Power PC處理器上的Mac OS X。同期發布的Xcode 3.0增強了對64位處理器的支援。

2009年8月,Mac OS X 10.6發布。10.6以及更新版本的Mac OS X無法安裝在Power PC處理器的蘋果電腦上,但仍然提供Rosetta轉譯器使用戶可以繼續使用為Power PC處理器編譯的軟體。

2011年3月,Xcode 4.0放棄了對PowerPC處理器的支援。

2013年8月,蘋果結束對PowerMac G5的支援。

蘋果當時能夠轉換成功有很多現實原因,比如當時體量比現在更加小眾,英特爾在行動處理器方面足夠強勢等等。而如今iPhone的爆紅和蘋果生態黏性的逐漸加大,在Mac平台上促生了大量的iOS開發者。

行動平台的壯大成熟,也反哺了桌面平台,現在很多開發者都是先從iOS起步,之後再轉向OS X(macOS)開發,從軟體生態上就能看出來,先有的iOS版之後才有的Mac版的情況並不少見。

而在iOS時代之前,Mac的生態其實處於比較小眾的狀態,甚至說難聽點就是蠻荒時代,和今天完全無法相提並論,自然也是沒有歷史包袱。

蘋果
圖/ 愛范兒

根據IDC的統計,2005年蘋果電腦的出貨量為217萬台,而在2019年這個數字達到了1,768萬台。這其中固然有筆記型電腦市場整個市場的擴大,但Mac的市份額仍然提升到了之前的兩倍。

而從絕對數量上說,如今使用Mac電腦的人數,可能是十幾年前的十倍。今天蘋果是這個世界市值最高的公司,要撬動這個龐然大物的生態,即便是蘋果自己來做也著實不容易。

從英特爾切換到ARM,所面臨的最大問題可能是整個軟體生態的顛覆。

英特爾
圖/ shutterstock

如果把這些眼花繚亂的軟體追根溯源,我們可以回到處理器和軟體運行最原始的一種關係——指令集。

簡單說,指令集就是處理器運行的「指導思想」,是一套讓處理器能理解程式的行為規範。如果「指導思想」不同,那肯定就沒有互相理解的基礎,而基於這一整套架構開發出來的下游軟體就像由此衍生的各國文化,但亞洲不懂非洲的文化,非洲也不懂南美的文化。

如今的macOS其軟體生態構建在多年來使用的英特爾處理器上,而英特爾使用的是X86架構,現在整個macOS軟體生態都遷移到了64位,也可以說是X86-64或者X64架構。

像iPhone等行動產品使用的晶片則用的是ARM的ARMv8指令集,你別看現在蘋果已經使用自研的架構多年,但在指令集部分依然是基於ARMv8的,不過傳聞說蘋果也準備對指令集這部分動手了。

也就是說,桌面裝置和行動裝置在指令集的層面就是不一樣的,所以換到ARM平台後,軟體是並不能通用的。

有人可能想說,那個誰,微軟不是早前一點也發布了使用ARM晶片的Surface產品嗎,就那個Surface Pro X,它不是也能直接運行Windows 10的程式嗎?

Microsoft
圖/ 愛范兒

沒錯,Surface Pro X使用的Microsoft SQ1的確是微軟找高通定制的ARM處理器,同時運行的也是完整的Windows 10而非先前Windows RT那樣的「殘疾版」系統,同時也能運行Windows 10的應用。

但Surface Pro X的問題依然很多,比如它只能運行UWP應用和32位的Windows應用,基於64位開發的軟體就無法支援。另外透過翻譯架構的方式兼容win32應用導致性能出現大幅損失,效率大概只有原生應用的30%-40%,更別說閃退、軟體重啟等各種各樣不穩定的小毛病。

微軟Surface Pro X.
微軟Surface Pro X.
圖/ 愛范兒

而對於蘋果來說,連透過翻譯架構兼容32位的程式也無法實現,因為蘋果已經透過自己對生態的控制力將全部的應用遷移到了64位。而面對大批不能直接運行的軟體,這個陣痛期一定會比想像中的更痛。

蘋果能做的,就是透過自己的控制力,去要求開發者將已有的軟體在一定的時間內編譯成ARM平台可以運行的版本,只是這並不是一件容易的事,畢竟各個軟體的情況複雜,某些軟體要想遷移到ARM可不是重新編譯一下那麼簡單。

Dell XPS 13 2020
Dell XPS 13 2020
圖/ 愛范兒

在軟體之外,如今的ARM在性能和功耗上可能也佔不到什麼優勢了。無風扇的被動散熱,接近20小時的續航,如今已經陸陸續續被非ARM的筆電完成,比如最新的戴爾XPS13 2020就號稱有最長19小時續航。

而且對於桌面環境來說,蘋果目前基於ARM的A系列晶片性能仍然是不夠的,比如頻率已經處於「灰燼」狀態,再往上就撞到了功耗牆,也就是沒有超頻或者說像英特爾處理器類似的睿頻空間。

更別說十幾二十個核心的高性能服務器版本,還處於路途漫長、要不可及的狀態。

如果今天MacBook還在被說散熱不佳和續航普通,那蘋果可能應該更多在自己身上找找原因,比如WWDC 2020都快來了但還是Bug一身的macOS 10.15 Catalina?

選擇ARM對蘋果來說可能還有一個預料之外的打擊——這些蘋果電腦將不再能用Windows系統。

眾所周知,購買MacBook並不一定等於加入蘋果生態,選擇裝Windows系統使用的用戶也大有人在,因為本身蘋果早就敏銳的察覺到了這件事,並推出了Bootcamp工具讓用戶能夠選擇雙系統運行,但如果推出ARM版,那肯定無法使用了。

ARM版MacBook的對手還有iPad Pro

比起生態遷移和兼容帶來的不確定,ARM版MacBook其實並沒有什麼外敵,Surface Pro X肯定不算,這個產品在微軟這裡只是一款實驗性產品,而真正會對ARM版MacBook造成威脅的,其實是內患。

筆電
圖/ 愛范兒

當「你的下一台電腦何必是電腦」的廣告語從今年iPad Pro宣傳片中蹦出來的時候,就意味著iPad和MacBook這兩條原先還算平行的線路終於「火星撞地球」一樣,正式短兵相接了。

如果對比一下這兩條線,可與看到ARM版MacBook其實處於一個很尷尬的位置。

iPad Pro,採用ARM處理器,使用精簡指令集,iPadOS系統脫胎於行動裝置iOS,在巧控鍵盤的加持下從行動走向桌面。

MacBook,英特爾處理器,使用複雜指令集,立足於macOS桌面作業系統和生態。

ARM版MacBook,採用ARM處理器和精簡指令集,繼續使用macOS的話原先的桌面生態會丟失,只能透過部分移植應用或者zh虛擬機的方式運行之前的桌面軟體,效率大打折扣。

MacBook
圖/ 愛范兒

其實到這裡我依舊沒有想通,蘋果出一個ARM處理器版MacBook,失去了桌面生態最大的優勢,然後去和iPad Pro打架,這究竟是一個什麼樣的邏輯,或者說其巨大的內在驅動力到底在哪。

當然,倒也並非找不出蘋果想要這樣做的理由,比如說想要對自己的產品和生態有更多的控制力,就像iPhone上使用的自家A系列晶片,早期的時候CPU用的是三星的,GPU用的PVR,到了後面全部變成自研架構之後,A系列晶片的性能才算在手機和平板中一騎絕塵。

而現在iPhone、iPad、乃至Apple Watch這些產品的生態與核心硬體已經被蘋果攥在了手裡,幾乎就唯獨筆電和桌面系列還要看英特爾的臉色,像英特爾過去幾年那種「擠牙膏」以及打磨14nm的行為,對於MacBook系列來說其實是挺大的一個掣肘。

但最後我還是覺得這樣的理由不足以說服我,至少我不覺得英特爾沒有餘力。

因為英特爾過去幾年的「擠牙膏」,很大程度上是因為AMD在K10架構的錯誤方向之後一直沒有緩過勁來,直到Zen和Zen2架構的奮起直追,終於讓很多人喊出了「AMD Yes!」。

面對AMD的窮追猛趕,英特爾確實在製程上遇到了一些困難,導致新的工藝節點一直在延後,但在這幾年中並非只是放羊摸魚而沒有技術積累,新品Tiger Lake(Willow Cove架構)性能提昇明顯,終於牙膏管擠出了一截。

而從英特爾轉向ARM也非朝夕之功,顯然還有好幾年的路要走,甚至可能要付出移山挖河般的時間和財力才能逐漸追上,而那個時候,可能已經是2025年甚至更久之後了。

責任編輯:林芳如、蕭閔云

本文授權轉載自:愛范兒

往下滑看下一篇文章
從台灣走進北美千家速食門市!Berry AI 如何攜手博弘雲端,讓 AI 規模化落地?
從台灣走進北美千家速食門市!Berry AI 如何攜手博弘雲端,讓 AI 規模化落地?

一家來自台灣的 AI 新創,如何讓美國上千家速食餐廳,都用它的 AI「看」得來速車道?

這家公司就是專注於 AI 影像辨識技術的 Berry AI (華捷智能),透過攝影機蒐集匿名數據並轉化為多項營運指標,協助速食品牌找出流程瓶頸、提升現場營運效率與整體顧客滿意度。以美國連鎖炸雞品牌 Zaxby’s 為例,在全面導入 Berry AI 解決方案後,服務速度提升 13%-20%,業績表現最好與最差的門市,每週營收差距從 2.4 萬美元縮小至約 9,000 美元。另一家連鎖速食品牌 Culver’s 在導入後,得來速車道的服務時間也立刻改善,進而提升整體吞吐量。

然而,支撐 Berry AI 解決方案的,不只有前端看得見的攝影機與影像辨識技術,還有後端穩定且具彈性的雲端平台。Berry AI 結合 Amazon Web Services (AWS) 全球雲端資源及博弘雲端顧問服務,打造兼顧即時性、穩定性與成本效益的雲地混合架構,成為推動 Berry AI 持續擴大北美市場版圖的重要關鍵。

從台灣 PoC 走向北美千店規模,Berry AI 面臨架構升級新挑戰

Berry AI 執行長林逸中表示,團隊成立初期投入近2年半的時間,探索最適合影像辨識技術的應用場景,最終將目光鎖定高度標準化的速食餐飲業(Quick Service Restaurant;QSR),推出得來速計時器、餐廳計數器等解決方案,運用 AI 影像分析技術,辨識顧客進入得來速車道或餐廳後的狀態,例如:排隊、點餐、候餐等。

同時,Berry AI 也進一步將現場蒐集到的數據轉化為可量化的營運指標,例如:不同門市、日期或時段的顧客等候時間,協助管理者從數據中找出流程瓶頸與可以優化的環節,進而提升服務效率及顧客滿意度。

在確立發展方向並於台灣完成 PoC (概念驗證)後,Berry AI 決定前進全球最大、也是 QSR 最核心的北美市場。然而,隨著合作客戶與部署門市持續增加,資料量快速攀升,加上服務範圍橫跨不同區域,既有以地端為主的架構開始面臨規模化挑戰。

林逸中補充指出,尤其 QSR 業者在選擇 AI 解決方案時,格外重視技術效能與穩定性,包括 AI 辨識精準度、能否因應突發狀況、系統能否穩定運作,以及網路發生問題時能否維持服務等。在這樣的要求下,若將所有運算與資料都留在地端,不僅難以因應日益增加的部署門市與資料量體,設備建置與維運成本也會隨之增加。

BerryAI 攜手博弘雲端 打造高可用性 AWS 雲地混合架構,突破北美規模化部署挑戰

如何確保系統的即時性、穩定性與成本效益,成為 Berry AI 進軍北美後必須解決的新課題。為此,Berry AI 選擇與博弘雲端合作,取得穩定且高可用的 AWS 運算與資料庫服務架構,將即時運算留在地端,同時在雲端環境整合資料庫處理大量資料與後續分析工作,形成兼顧地端即時運算與雲端彈性擴充的雲地混合架構。

Berry AI研發同仁汪楚剛說明,包括車輛偵測、追蹤與狀態辨識等需要即時反應的工作,會先在地端完成;再將辨識結果傳送至 AWS 雲端,計算各項營運指標,提供後續分析與決策使用。透過這套架構,Berry AI 至今已處理超過 2 億筆車輛狀態資料。

此外,AWS 也是 Berry AI 持續優化 AI 模型的重要基礎。Berry AI 將整套資料蒐集流程建構於 AWS 上,透過完整且多樣化的資料,持續訓練與優化模型,進一步提升地端影像辨識的準確度。

博弘雲端
Berry AI 鎖定高度標準化的速食餐飲業(Quick Service Restaurant;QSR),推出得來速計時器、餐廳計數器等解決方案,運用 AI 影像分析技術,辨識顧客進入得來速車道或餐廳後的狀態,例如:排隊、點餐、候餐等,協助管理者從數據中找出流程瓶頸與可以優化的環節,進而提升服務效率及顧客滿意度。
圖/ Berry AI網站圖

成為企業技術團隊的延伸,博弘雲端助 BerryAI 把 AWS 用得更好、更省

隨著北美業務持續成長,Berry AI 也迎來新的課題:如何把雲端資源用得更有效率、更省成本,這也成為 Berry AI 與博弘雲端合作的重要契機。

對此,可能有很多人好奇,像 Berry AI 這類技術能力成熟、具備自行建置架構能力的企業,為什麼還需要與博弘雲端合作?「關鍵在於,博弘雲端長期深耕 AWS,對相關服務與技術架構更加熟悉,可以成為企業內部技術團隊的延伸。」博弘雲端技術長宋青雲說。

當 Berry AI 遇到特定 AWS 服務或技術問題時,可以直接尋求博弘雲端協助;若需要進一步與 AWS 原廠確認,博弘雲端也能協助溝通與處理,減少 Berry AI 自行研究與排除問題所需投入的時間,讓內部研發團隊可以將更多心力和資源集中在核心產品開發。

更重要的是,博弘雲端不只提供技術支援,還能從 Berry AI 實際用量與成長需求出發,客製化設計最適合的節費方案,這對 Berry AI 降低營運成本有很大的幫助。宋青雲說明,博弘雲端根據 Berry AI 既有的 AWS 用量,推估未來 1-3 年內的使用需求,並以此為基礎規劃合適的長期雲端資源用量;同時考量 Berry AI 所屬飛捷集團旗下還有 3 家子公司同樣使用 AWS,進一步整合集團需求進行評估,放大整體採購規模,爭取更大的節費空間。

宋青雲強調,雲端採取隨需即付的計價模式,雖然具備彈性優勢,但若缺乏持續管理,仍可能出現資源配置不符商務規劃,或費用超出預期等情況。而博弘雲端不只能從使用現況出發、建議適合的節費方案,也會從效能、資安與成本等面向進行架構健檢,提出相應的優化建議;同時還會提供相關管理介面,讓企業隨時查看帳戶使用狀況、預估未來用量,在業務規模持續成長的同時,也能兼顧雲端架構的效能、安全與成本效益。

而架構健檢與成本優化,只是博弘雲端服務的一環。從企業準備上雲開始,博弘雲端便能協助將應用程式與資料從地端搬遷至雲端,或直接在雲端完成部署;進一步還能協助建置數據平台、數據中台,進行資料分析及導入 AI 應用,讓企業資料發揮更大價值。當服務正式上線後,博弘雲端也能接續提供維運服務。換言之,從前期 PoC、雲端建置到後續維運,博弘雲端都能依據企業需求,提供相應的服務與支援。

對 Berry AI 來說,藉由與博弘雲端合作,深化 AWS 雲端資源使用,不只是突破規模化挑戰,更重要的是能把有限的資源集中在核心業務,持續優化解決方案、開發更多貼近餐飲營運需求的應用,進一步爭取更多品牌合作,擴大北美市場版圖。目前,Berry AI 正全力拓展北美市場,也持續尋找對 AI 技術與餐飲產業應用充滿好奇心、重視團隊協作的人才加入。徵才方向涵蓋機器學習與電腦視覺、Platform & System(DevOps、Infrastructure),以及 Full Stack 軟體開發。從門市邊緣裝置上運行的 AI 模型、串連雲端與數千家門市的系統平台,到協助餐飲品牌提升營運效率的分析產品,每個環節都還有發揮的空間。 期待匯聚更多優秀夥伴,一起用 AI 解決真實的營運問題,讓來自台灣的技術走進更多全球 QSR 門市。

職缺詳情:https://www.cake.me/companies/berryai/jobs

登入數位時代會員

開啟專屬自己的主題內容,

每日推播重點文章

閱讀會員專屬文章

請先登入數位時代會員

看更多獨享內容

請先登入數位時代會員

開啟收藏文章功能,

請先登入數位時代會員

開啟訂閱文章分類功能,

請先登入數位時代會員

我還不是會員, 註冊去!
追蹤我們
一次搞懂工業AI
© 2026 Business Next Media Corp. All Rights Reserved. 本網站內容未經允許,不得轉載。
106 台北市大安區光復南路102號9樓