聯發科於 2025 年初釋出他們調整過的 Llama 3.2 模型,上傳至 huggingface。MediaTek 提供部分必要的檔案,.pte
跟 tokenizer.bin
檔案。
Meta 的 llama 提供更多檔案,例如 safetensor,並且 MLX-Example 已經提供 llama 轉換格式的程式碼、MLX-Swift-Example 移植到 iOS 平台上,可以使用 mlx-swift-example repository,搭配 Apple Silcon 一次支援 M1 與 iOS 系統。
pte
檔案可以使用 Executorch 跟它提供的專案,移植到 iOS 上使用。
這裡參考聯發科使用的 Executorch,Executorch 是專門移植到手機與邊緣裝置使用的框架。目前有穩定的版本(stable 0.5 分支),但是如果要移植到 iOS 與 Android 等裝置,需要使用最新的分支(main 0.6 分支)。
文件內容等等都蠻混亂的,很多重複的步驟散亂在個文件中,從 Google 搜尋會給你 main 分支上的文件,其中幾個 iOS App 連結已經被移除,只在 stable 分支才有。
這裡使用的操作電腦為 Macbook Air M1 16GB,並以 main 分支連結。
*.pte
與 tokenizer.bin
或 tokenizer.model
。因為很混亂所以這裡提供過程:
我自己電腦的聯發科 Llama 輸出:
我自己電腦的 meta Llama 輸出:
恩…說實話看不出來差在哪裡,輸出文字有夠短的,我記得有說有改成繁體中文與台灣用詞的東西。
iOS 專案底下的 LLaMARunner,會連結到部分 gitsubmodule,只按照 iOS 文件的步驟很容易會漏掉。前面的 llama 工具執行過程會產生 iOS 需要的檔案。
另外,因為 xcode 專案目錄管理自成一套,編譯過程會發現其他維護者的檔案路徑,造成編譯錯誤。
最後的執行結果非常糟糕,模型完全無法正常反應,而且還蠻詭異的,看起來有存取到不正確的記憶體位置。在 iPhone 16 pro 上跑會因為記憶體限制關係強制關閉,模擬器可以跑出來。
安裝過程蠻折騰人的,文件本身很多地方要改, issue 中有表示效果不好或回覆有問題。iOS 的範例專案有包含到其他維護者的電腦目錄路徑,導致檔案找不到。
coremltools 不支援 onnx 檔案格式,coremltools 跟 Apple 有一套自己的 llama 跟 transofmer fusion 的方法,如果可以移植,還是使用 safetensor 去移植比較有用。Apple WWDC 有一堆開發者影片展示如何轉換。
對於聯發科來說,量測或改進生 token 的速度才是最重要的事情,感覺我還有一大段路要走!
Executorch 很多文件沒有補齊,是個可以貢獻開源的好機會!
CoreML 與 mlmodelc
是蘋果的模型格式,早於 gguf 的模型格式,透過 coremltools
轉換現有 Pytorch 模型 pth
檔案,透過 Pytorch jit 技術追蹤模型網路組成,輸出蘋果支援格式。
CoreML 移植比較簡單,在 LLM 模型推出之後,huggingface 便推出 swift-transformer 等實作來使用,swift-transformer 本身使用 Swift 程式語言實作,提供類似 huggingface-cli
的模型下載跟使用的功能。
以下的 llama-to-coreml
專案跟 Swift-Chat
專案有使用到 huggingface 提供的套件,如果不是使用自製的語言模型,可以直接參考程式碼使用現有模型,套件會幫你自動下載。專案本身都沒有教學怎麼手動使用自己的模型。
llama-to-coreml
,這套件使用 huffingface 的 transformer
去讀取並下載模型。這個專案固定會從 huggingface 下載模型。轉換過程中會用到約 28 GB 記憶體,但是我的 16 GB 的電腦還是轉得過沒問題。tokenizer_config.json
與 tokenizer.json
LanguageModelWithStatefulKVCache
內容複製,程式碼目前主在 preview
分支。LlamaCoreml.swift
的每個路徑。我沒要求輸出 MarkDown 格式,它自己就輸出了。
想比 Executorch 設定環境,使用 CoreML 工具要為簡單很多,模型轉換後的檔案大小從 4.62 GB 降為 1.8 GB,CoreML 儲存不同精度。
執行過程中,在記憶體佔用上相比使用 Executorch 要少很多,在 Maxbook 上測試執行過程中約 4 GB ,執行過程中緩慢上升。