【CSDN 編者按】一部售價近萬元的iPhone，卻在最基礎(chǔ)的數(shù)學(xué)推理上“翻了車”。本文作者原本只是想做一個輕量級的記賬 App，卻在調(diào)試 MLX 與本地大模型的過程中，意外撞上了一起極其隱蔽、也極具代表性的硬件級 Bug：同樣的模型、同樣的代碼，在 iPhone 15 和 Mac 上一切正常，唯獨 iPhone 16 Pro Max 輸出徹底失真。三天的自我懷疑、無數(shù)次對代碼和框架的反復(fù)檢查，最終指向的不是軟件，而是 Neural Engine 相關(guān)的硬件缺陷。

原文鏈接：https://journal.rafaelcosta.me/my-thousand-dollar-iphone-cant-do-math/

作者 | Rafael Costa 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

過去幾個月，我一直在做一個 Clawdbot / Moltbot 的克隆項目，我給這個復(fù)刻版取名 Schmidt。它的核心功能和原版差不多，但我做的是一個自定義聊天 UI，而不是依賴 Telegram、WhatsApp 這類“我真的很怕哪天被封號”的平臺。

這個項目占據(jù)了我大量的清晨和深夜時間，于是為了緩解一下，我決定搞點簡單點的東西。剛好我最近訂閱了 MiniMax M2.1 大模型，就想著跟風(fēng)做個簡易的記賬 APP，順便測試下這個模型的能力。

這個 APP 的核心功能很簡單：

● 每筆消費完成后，自動記錄到 APP 中；

● 在 Apple Watch 表盤組件中顯示：本月預(yù)算已用百分比；

● 對消費進(jìn)行分類，方便后續(xù)分析。

做這個 APP 的初衷，還是因為 Nubank 原本超好用的原生 APP “擺爛” 了——現(xiàn)在它被替換成了功能大打折扣的 Flutter 版本。

和快捷指令（Shortcuts）的集成過程雖然需要手動操作，但勝在穩(wěn)定。短短 15 分鐘，我就做出了能記錄消費的初版 APP，而我最想要的 Apple Watch 表盤功能可以后續(xù)再完善。

我本以為，消費分類這個功能做起來會很輕松，就想著先把它搞定。

先試 Apple Intelligence：下載卡殼，全網(wǎng)用戶都踩坑

在這個 LLM 百花齊放的時代，Apple 自然也推出了自家的 Apple Intelligence API，供像我這樣的開發(fā)者使用。翻看官方文檔后發(fā)現(xiàn)，使用這個功能的流程很簡單：先檢測功能是否可用，再調(diào)用模型響應(yīng)文本查詢即可，而我的需求只是讓模型做消費分類。

MiniMax 很快就幫我寫完了 Prompt，接著我把代碼部署到了 iPhone 上測試。第一筆消費是在一家叫 Kasai Kitchin 的店產(chǎn)生的，結(jié)果模型給出的分類是…… 未知。

太奇怪了。

查看日志后我發(fā)現(xiàn)了問題：模型支持包還在下載中，功能根本沒啟用。這就更離譜了，我明明已經(jīng)開啟了這個功能。沒辦法，我只能去設(shè)置里反復(fù)開關(guān)這個功能——講真，蘋果的服務(wù)出現(xiàn)這種問題，早就見怪不怪了，說不定是設(shè)置 APP 卡死了。

然后我就等著支持包下載完成——結(jié)果等了 4 個小時，下載進(jìn)度紋絲不動。上網(wǎng)一查才發(fā)現(xiàn)，不少用戶都遇到了這個問題（相關(guān)的討論帖已經(jīng)有 12 頁，全是吐槽的用戶）。只能說，這陣子蘋果的服務(wù)拉胯，已經(jīng)是常態(tài)了。

行吧，Apple Intelligence 這條路走不通，那就換個方案。

再試 MLX LLM：CPU 跑滿，輸出全是亂碼

顯然，蘋果不只有 iOS 框架工程師會用 Swift 開發(fā)機(jī)器學(xué)習(xí) API，他們還提供了另一種完全不同的方案——將模型直接下載到 APP 本地運行。

這種方式對用戶的存儲空間不友好，但對我這個開發(fā)者來說簡直太香了！

還是先在 MiniMax 上做測試，結(jié)合官方文檔和幾篇 Medium 文章，我很快就搞定了代碼。本以為這次在 iPhone 上運行會順順利利，結(jié)果輸出的全是無意義的亂碼。

不僅如此，手機(jī)的 CPU 直接拉滿，模型開始無休無止地生成內(nèi)容，而且完全不會觸發(fā)停止符，就這樣一直跑下去。比如問一句“2+2 等于幾？”，我的 iPhone 16 Pro Max 給出的答案居然是“Applied.....*_dAK [...]”這類莫名其妙的字符。

當(dāng)時我第一反應(yīng)是：我是不是太菜了？連現(xiàn)成的框架都用不明白？或者，問題出在 MiniMax 上？——畢竟，把工作甩給大模型的好處就是，出了問題可以甩鍋給它。但吐槽歸吐槽，我還是得自己動手寫代碼解決。

自研 MLX 實現(xiàn)：代碼沒問題，自我懷疑拉滿

于是，我重新翻了官方文檔和 Medium 的教程，結(jié)果讓我大跌眼鏡：MiniMax 的實現(xiàn)完全是照著文檔來的。我甚至還嘗試了一些已經(jīng)廢棄的生成方法，結(jié)果還是輸出亂碼——這下好了，沒人能甩鍋，只能怪自己。

那陣子我每天上班都被這個問題折磨，折騰了 3 天，我?guī)缀醵家艞壛恕?/p>

直到某個周二早上7點，我突然想到一個辦法：要不試試在我的舊機(jī) iPhone 15 Pro 上運行？在此之前，我一直用主力機(jī) iPhone 16 Pro Max 測試——這部手機(jī)還是之前不小心摔報廢后，蘋果售后 Apple Care 給換的新機(jī)。

我趕在上班前火速做好所有準(zhǔn)備，運行代碼的那一刻：成了！Gemma、Qwen 等所有模型都能生成邏輯通順的回答！

我當(dāng)時還在想：這總不可能是硬件問題吧？肯定不是，iPhone 15 Pro 裝的還是 iOS 18，而 iPhone 16 Pro Max 是 iOS 26，問題一定出在系統(tǒng)上。好奇心戰(zhàn)勝了一切，我索性翹了早會，給舊機(jī)更了 iOS 26。等了好一會兒，更新完成后再測試：結(jié)果和 iPhone 15 Pro 未更新時一樣，依舊能正常運行。

事情的走向，越來越撲朔迷離了……

找到實錘：在 Gemma 的 MLX 實現(xiàn)中加斷點調(diào)試

那天上班，我和同事們吃午飯、喝咖啡時，一直聊這個問題的可能原因。下班回家后，我立刻開始著手調(diào)試 MLX 的運行過程，具體的調(diào)試思路如下：

（1）選用一個驗證過的、能塞進(jìn)內(nèi)存的可靠模型（我選了量化版的 Gemma）；

（2）用最簡單的提示詞測試，比如“2+2 等于幾？”；

（3）為了極致嚴(yán)謹(jǐn)，把提示詞標(biāo)準(zhǔn)化為： user\nWhat is 2+2? \n model；

（4）將生成溫度設(shè)為 0.0，盡可能排除隨機(jī)因素的影響；

（5）找到模型的實現(xiàn)代碼；

（6）定位到模型遍歷各層網(wǎng)絡(luò)的代碼位置；

（7）輸入數(shù)據(jù)經(jīng)過每一層時，打印出 MLXArray / 張量的具體數(shù)值。

沒過多久，我就找到了需要調(diào)試的位置，手動加上斷點、埋好日志，開始測試。

我先在 iPhone 16 Pro Max 上運行，模型成功加載，提示詞“2+2 等于幾？” 也正常輸入，張量數(shù)值開始一行行打印出來。這一次，日志終于不是亂碼了——全是數(shù)字，這些浮點數(shù)代表了模型處理輸入時的內(nèi)部狀態(tài)。

然后我把輸出結(jié)果保存到文件，又在 iPhone 15 Pro 上做了一遍相同的操作，模型、提示詞、代碼完全一致，接下來就是對比兩份結(jié)果。

看到對比結(jié)果的那一刻，我知道這已經(jīng)超出我的專業(yè)知識范圍了。

我篩選了一個本應(yīng)完全一致的特征值——日志第 58 行的數(shù)組，這個位置剛好在數(shù)值歸一化 / 軟最大化處理之前。我覺得，在能正常運行的設(shè)備上，這個數(shù)值應(yīng)該是完全固定的。

iPhone 15 Pro 的輸出：

3: "[[[[53.875, 62.5625, -187.75, ..., 42.625, 6.25, -21.5625]]]]"

iPhone 16 Pro Max 的輸出：

3: "[[[[191.5, 23.625, 173.75, ..., 1298, -147.25, -162.5]]]]"

顯然不一樣，完全沒有任何相似性，數(shù)值偏差直接到了一個數(shù)量級。

而更詭異的是：最開始的輸入張量，兩臺手機(jī)明明是一模一樣的——這說明問題不是輸入，而是中間某個計算環(huán)節(jié)出了大問題。

為了徹底確認(rèn)，我在 MacBook Pro 上跑了一遍同樣的代碼（iPad 兼容模式）：結(jié)果和 iPhone 15 Pro 完全一致。這樣一來，結(jié)論就很明確了：

模型沒問題，代碼沒問題，我也沒問題——就是我的手機(jī)壞了。

我的推測

結(jié)合整個調(diào)試過程，我來說說自己的判斷吧：

iPhone 16 Pro Max 使用的是 A18 芯片，內(nèi)置 Neural Engine，專門用于 ML 加速，而MLX 通過 Metal 把張量運算編譯到這些硬件單元上——問題就出在這個硬件 - 框架的調(diào)用棧中，導(dǎo)致運算結(jié)果出現(xiàn)嚴(yán)重錯誤。

這可能不是普遍問題，但很不幸，我手上這部從 Apple Care 換來的準(zhǔn)新機(jī)，中獎了。

更扎心的是：如果我之前遇到的 Apple Intelligence 無法正常下載 / 運行的問題與此相關(guān)，那那 12 頁帖子里的用戶，恐怕有不少都和我遇到了同樣的問題，只是他們沒有辦法像我這樣做底層調(diào)試而已。

最后的教訓(xùn)

我花了 3 天時間懷疑自己能力不行，先是甩鍋給 MiniMax，最后又自我否定。結(jié)果從頭到尾，問題都是這部價值 1400 美元（國內(nèi)官方起售價為9999元）的手機(jī)，硬件本身就有缺陷。

當(dāng)然，我可以繼續(xù)花時間去深究具體是哪個硬件模塊出了問題，但這完全不值得。

不過這次經(jīng)歷也給了我一個重要的調(diào)試教訓(xùn)：排查問題時，一定要考慮物理硬件層的可能性。我這三天一直想當(dāng)然地認(rèn)為是軟件問題——我的代碼、第三方庫、框架，甚至是自己的開發(fā)能力。

而這次問題的突破口，恰恰就是那個簡單的想法：“萬一不是我菜，也不是代碼的問題呢？”

故事的最后，我用這部 iPhone 16 Pro Max以舊換新了一部 iPhone 17 Pro Max，并做了全量測試——所有功能都能正常運行，和預(yù)期完全一致。所以可以確定，我之前那部 iPhone 16 Pro Max，就是個硬件存在缺陷的殘次品。

未來沒有前后端，只有 AI Agent 工程師。

這場十倍速的變革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 與奇點智能研究院聯(lián)合主辦「2026 奇點智能技術(shù)大會」將在上海隆重召開，大會聚焦 Agent 系統(tǒng)、世界模型、AI 原生研發(fā)等 12 大前沿專題，為你繪制通往未來的認(rèn)知地圖。

成為時代的見證者，更要成為時代的先行者。

奇點智能技術(shù)大會上海站，我們不見不散！