1. 舊手機跑本地大模型這件事到底靠不靠譜手里那臺吃灰的舊安卓機除了換不銹鋼盆之外其實還有一條更硬核的出路——讓它變成一臺24小時在線的本地大模型推理終端。這個想法聽起來像是折騰但實測下來一臺驍龍845級別、6GB內(nèi)存的老機器跑一個量化后的7B模型生成速度能穩(wěn)定在每秒3到5個token日常問答、文本摘要、簡單代碼補全完全夠用。核心思路就是利用開源推理框架在安卓端做本地部署把模型權(quán)重和推理引擎全部塞進(jìn)手機里不依賴任何外部網(wǎng)絡(luò)請求數(shù)據(jù)不出設(shè)備隱私性和離線可用性直接拉滿。這件事適合誰呢一類是手里有閑置安卓機、想拿來跑點實際任務(wù)的開發(fā)者另一類是對本地大模型部署感興趣、但不想額外買硬件的新手。你不需要精通Kotlin或者NDK開發(fā)只要會基本的adb操作、能看懂配置文件就能跟著走通整個流程。我前后在四臺不同年代的安卓設(shè)備上做過部署從安卓9到安卓14都試過踩過的坑包括內(nèi)存溢出、模型格式不兼容、后臺被殺進(jìn)程等等下面會把完整方案和避坑經(jīng)驗全部攤開講。2. 整體方案設(shè)計與技術(shù)選型拆解2.1 為什么選端側(cè)推理框架而不是遠(yuǎn)程調(diào)用很多人第一反應(yīng)是手機跑不動大模型直接調(diào)云端API不就行了但這里有個關(guān)鍵區(qū)別——本地部署的核心價值在于數(shù)據(jù)不出設(shè)備和離線可用。你如果只是想要一個問答機器人云端API確實更省事但一旦涉及個人文檔處理、隱私對話、內(nèi)網(wǎng)環(huán)境使用本地推理就是剛需。而且舊手機本身閑置著電費幾乎可以忽略24小時開機跑推理相當(dāng)于白撿了一臺低功耗推理服務(wù)器。端側(cè)推理框架的選擇上目前安卓平臺比較成熟的有幾種路線一種是基于llama.cpp的安卓移植版本另一種是專門為移動端優(yōu)化的推理引擎。我最終選的是OlliteRT這條路線原因是它對量化模型的支持比較完善內(nèi)存占用控制得不錯而且提供了相對清晰的JNI接口方便用Kotlin做上層封裝。相比之下直接拿Python方案往安卓上搬基本不現(xiàn)實性能損耗太大發(fā)熱也壓不住。2.2 模型選型的核心邏輯模型選型是整個方案里最關(guān)鍵的決策點。舊手機的內(nèi)存和算力都有限不能盲目上大參數(shù)模型。我的經(jīng)驗是6GB內(nèi)存的設(shè)備模型量化后體積控制在3.5GB以內(nèi)比較穩(wěn)妥8GB內(nèi)存可以放寬到4.5GB左右。超過這個線系統(tǒng)隨時可能因為內(nèi)存不足把推理進(jìn)程殺掉。具體到模型版本7B參數(shù)級別的模型經(jīng)過4-bit量化后體積大約在3.8GB到4.2GB之間是舊手機比較理想的甜點區(qū)。再小的模型比如3B級別雖然跑得快但回答質(zhì)量下降明顯復(fù)雜一點的邏輯推理就容易胡言亂語。再大的13B模型量化后也要6GB以上舊手機基本扛不住。所以我的建議很明確優(yōu)先選7B級別的4-bit量化版本在質(zhì)量和資源占用之間取平衡。這里要特別提醒一點模型文件格式必須和推理框架匹配。常見的格式有GGUF、GGML等不同框架支持的不一樣。下載模型之前一定要確認(rèn)框架文檔里寫的支持格式否則下回來加載失敗白白浪費時間和流量。2.3 安卓版本與硬件門檻安卓版本方面實測安卓9及以上都能跑但安卓11以上會更穩(wěn)定因為后臺進(jìn)程管理機制相對寬松一些。安卓9的問題在于部分設(shè)備對后臺服務(wù)的限制比較激進(jìn)需要手動關(guān)閉電池優(yōu)化才能保證24小時運行。安卓14則引入了更嚴(yán)格的前臺服務(wù)類型限制需要在Manifest里正確聲明服務(wù)類型否則啟動就崩。硬件門檻其實不高但有幾個硬指標(biāo)內(nèi)存至少4GB存儲至少留出8GB空閑空間CPU最好是驍龍835或同級別以上。我試過一臺驍龍660的機器跑是能跑但生成速度掉到每秒1個token以下體驗就很差了。另外散熱也很重要舊手機長時間滿載推理背面溫度能到45度以上最好加個散熱背夾或者放在通風(fēng)處。3. 核心細(xì)節(jié)解析與實操要點3.1 開發(fā)環(huán)境搭建與項目結(jié)構(gòu)整個項目用Android Studio開發(fā)語言選Kotlin。項目結(jié)構(gòu)上核心分三層JNI底層負(fù)責(zé)調(diào)用推理引擎的C接口中間層用Kotlin封裝模型加載和推理調(diào)用上層用Compose或者XML做簡單的交互界面。如果你只想跑通推理界面甚至可以不要直接用adb shell觸發(fā)推理任務(wù)就行。搭建環(huán)境時需要注意幾個點。NDK版本建議選r25以上CMake版本3.22以上這兩個版本對C17特性支持比較完整。Gradle配置里要開啟externalNativeBuild把推理引擎的源碼或者預(yù)編譯庫鏈接進(jìn)來。如果用的是預(yù)編譯的.so文件記得在jniLibs目錄下按ABI分目錄放置arm64-v8a是必須的armeabi-v7a可選。// build.gradle.kts 關(guān)鍵配置片段 android { ndkVersion 25.2.9519653 defaultConfig { externalNativeBuild { cmake { cppFlags -stdc17 arguments -DANDROID_STLc_shared } } ndk { abiFilters listOf(arm64-v8a) } } externalNativeBuild { cmake { path file(src/main/cpp/CMakeLists.txt) } } }注意如果推理引擎依賴OpenMP或者特定數(shù)學(xué)庫需要在CMakeLists里顯式鏈接否則運行時會報符號找不到的錯誤。這個坑我踩過兩次排查了半天才發(fā)現(xiàn)是鏈接順序問題。3.2 模型文件放置與內(nèi)存映射加載模型文件不能放在assets里因為assets有壓縮加載大文件時會出問題。正確做法是把模型文件推到設(shè)備的內(nèi)部存儲或者外部存儲的私有目錄下然后用**內(nèi)存映射mmap**的方式加載。mmap的好處是操作系統(tǒng)按需分頁不會一次性把整個模型讀進(jìn)物理內(nèi)存對舊手機來說這點非常關(guān)鍵。具體操作上先用adb把模型推上去adb push model-q4.gguf /sdcard/Android/data/com.example.localai/files/models/然后在Kotlin層通過文件路徑傳給JNIJNI里用mmap打開文件把指針交給推理引擎。這里有個細(xì)節(jié)文件路徑的權(quán)限要確保應(yīng)用能讀取如果是Android 11以上訪問外部存儲需要走M(jìn)ediaStore或者使用應(yīng)用私有目錄。我一般直接放在應(yīng)用私有目錄下省去權(quán)限申請的麻煩。加載時的內(nèi)存占用要提前估算。一個4GB的模型文件mmap之后實際物理內(nèi)存占用大概在2.5GB到3GB之間加上推理時的KV Cache和中間激活值峰值可能到3.5GB。所以6GB內(nèi)存的設(shè)備系統(tǒng)本身占掉1.5GB到2GB留給推理的余量其實很緊張。建議在加載模型之前先調(diào)用Runtime.getRuntime().gc()做一次強制回收能擠出幾百MB的空間。3.3 推理參數(shù)調(diào)優(yōu)與線程綁定推理參數(shù)直接決定生成速度和輸出質(zhì)量。核心參數(shù)有這么幾個上下文長度context length、批大小batch size、線程數(shù)threads、溫度temperature。舊手機上上下文長度建議設(shè)2048或者4096再大內(nèi)存扛不住。批大小設(shè)1就行設(shè)大了內(nèi)存暴漲但速度提升不明顯。線程數(shù)一般設(shè)成CPU大核的數(shù)量比如驍龍845是4個大核就設(shè)4設(shè)多了反而因為調(diào)度開銷導(dǎo)致速度下降。溫度參數(shù)看用途。做事實性問答溫度設(shè)0.1到0.3輸出穩(wěn)定做創(chuàng)意寫作可以設(shè)0.7到0.9。我一般默認(rèn)設(shè)0.6兼顧穩(wěn)定性和多樣性。另外top-p和top-k也建議設(shè)一下top-p設(shè)0.9top-k設(shè)40能有效避免生成重復(fù)內(nèi)容。// 推理參數(shù)配置示例 val params InferenceParams( contextLength 2048, batchSize 1, threads 4, temperature 0.6f, topP 0.9f, topK 40, repeatPenalty 1.1f )提示線程綁定這塊可以用Process.setThreadPriority把推理線程優(yōu)先級調(diào)到THREAD_PRIORITY_URGENT_AUDIO級別能減少被系統(tǒng)調(diào)度打斷的概率。實測下來生成速度能提升10%到15%。3.4 前臺服務(wù)與保活策略24小時運行的核心難點在于?；?。安卓系統(tǒng)對后臺進(jìn)程的管理越來越嚴(yán)格如果不做處理鎖屏后幾分鐘推理服務(wù)就被殺了。解決方案是啟動一個前臺服務(wù)在通知欄常駐一個通知這樣系統(tǒng)就不會輕易回收。前臺服務(wù)的實現(xiàn)要注意安卓版本差異。安卓9到安卓10直接startForeground就行安卓11以上需要在Manifest里聲明foregroundServiceType安卓14更是要求聲明具體類型比如dataSync或者specialUse。如果類型聲明不對啟動時直接拋異常。// 前臺服務(wù)啟動示例 class InferenceService : Service() { override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { val notification buildNotification() if (Build.VERSION.SDK_INT Build.VERSION_CODES.Q) { startForeground(1, notification, ServiceInfo.FOREGROUND_SERVICE_TYPE_DATA_SYNC) } else { startForeground(1, notification) } // 啟動推理線程 startInferenceLoop() return START_STICKY } }除了前臺服務(wù)還需要關(guān)閉電池優(yōu)化。在設(shè)置里找到應(yīng)用把電池優(yōu)化設(shè)為“不優(yōu)化”否則系統(tǒng)在低電量時還是會限制后臺活動。另外如果設(shè)備有廠商的省電策略比如某些品牌的“后臺高耗電管理”也要手動加白名單。這些操作因設(shè)備而異但思路是一樣的讓系統(tǒng)認(rèn)為這個應(yīng)用是用戶主動在用的不能隨便殺。4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 從零開始的項目初始化新建一個Android項目選Empty Activity模板語言選Kotlin最低API級別設(shè)26安卓8.0目標(biāo)API級別設(shè)34。項目建好后先在app/build.gradle.kts里加上NDK和CMake的配置然后把推理引擎的源碼或者預(yù)編譯庫放到src/main/cpp目錄下。如果用的是源碼集成需要在CMakeLists.txt里把推理引擎的源文件全部加進(jìn)來同時鏈接log、android、OpenMP等系統(tǒng)庫。如果用的是預(yù)編譯的.so就在jniLibs/arm64-v8a下放好然后在CMakeLists里用add_library以IMPORTED方式引入。# CMakeLists.txt 關(guān)鍵片段 cmake_minimum_required(VERSION 3.22) project(localai) add_library(localai SHARED native-lib.cpp inference_engine.cpp ) find_library(log-lib log) find_library(android-lib android) target_link_libraries(localai ${log-lib} ${android-lib} # 如果推理引擎是預(yù)編譯的 ${CMAKE_SOURCE_DIR}/../jniLibs/${ANDROID_ABI}/libinference.so )編譯時如果報undefined reference錯誤大概率是鏈接順序問題。把依賴庫放在被依賴庫的后面這是CMake鏈接的一個基本原則。我一開始沒注意排查了快一個小時才反應(yīng)過來。4.2 JNI接口封裝與Kotlin調(diào)用JNI層要做的事情很明確加載模型、執(zhí)行推理、釋放資源。對外暴露三個native方法就夠了。加載模型時傳入模型路徑和參數(shù)配置推理時傳入prompt字符串返回生成的文本。// native-lib.cpp 核心接口 extern C JNIEXPORT jlong JNICALL Java_com_example_localai_InferenceEngine_loadModel( JNIEnv* env, jobject thiz, jstring model_path, jint threads) { const char* path env-GetStringUTFChars(model_path, nullptr); auto* engine new InferenceEngine(); bool success engine-load(path, threads); env-ReleaseStringUTFChars(model_path, path); if (!success) { delete engine; return 0; } return reinterpret_castjlong(engine); } extern C JNIEXPORT jstring JNICALL Java_com_example_localai_InferenceEngine_generate( JNIEnv* env, jobject thiz, jlong handle, jstring prompt) { auto* engine reinterpret_castInferenceEngine*(handle); const char* input env-GetStringUTFChars(prompt, nullptr); std::string output engine-generate(input); env-ReleaseStringUTFChars(prompt, input); return env-NewStringUTF(output.c_str()); }Kotlin層用external關(guān)鍵字聲明native方法然后在協(xié)程里調(diào)用避免阻塞主線程。推理過程可能持續(xù)幾秒到幾十秒必須放在Dispatchers.IO或者自定義的線程池里執(zhí)行。// Kotlin調(diào)用層 class InferenceEngine { private var handle: Long 0 external fun loadModel(modelPath: String, threads: Int): Long external fun generate(handle: Long, prompt: String): String external fun releaseModel(handle: Long) suspend fun load(modelPath: String, threads: Int 4): Boolean { return withContext(Dispatchers.IO) { handle loadModel(modelPath, threads) handle ! 0L } } suspend fun infer(prompt: String): String { return withContext(Dispatchers.IO) { if (handle 0L) returnwithContext 模型未加載 generate(handle, prompt) } } }注意JNI層的內(nèi)存管理要特別小心。模型加載后占用的內(nèi)存不會自動釋放必須在應(yīng)用退出或者模型切換時手動調(diào)用releaseModel。否則反復(fù)加載幾次內(nèi)存就爆了。4.3 推理性能實測與數(shù)據(jù)記錄我在三臺設(shè)備上做了對比測試統(tǒng)一用7B Q4量化模型上下文長度2048線程數(shù)按大核數(shù)量設(shè)置。測試prompt是“用三句話解釋什么是量子糾纏”記錄首次token延遲和生成速度。設(shè)備型號處理器內(nèi)存首次token延遲生成速度背面溫度小米8驍龍8456GB1.8秒4.2 token/s43度一加7 Pro驍龍8558GB1.2秒6.5 token/s41度紅米Note 8驍龍6654GB4.5秒1.8 token/s46度從數(shù)據(jù)看驍龍845和855級別的設(shè)備體驗比較理想生成速度能到4 token/s以上日常問答基本感覺不到明顯卡頓。驍龍665就有點吃力了首次token延遲接近5秒生成速度不到2 token/s適合做后臺批處理任務(wù)不適合交互式對話。內(nèi)存方面6GB設(shè)備在加載模型后剩余可用內(nèi)存大約1.2GB跑推理時峰值會掉到500MB左右系統(tǒng)會頻繁觸發(fā)內(nèi)存回收偶爾導(dǎo)致推理中斷。8GB設(shè)備就從容很多剩余可用內(nèi)存2.5GB以上跑起來很穩(wěn)。所以如果手頭有8GB的舊旗艦優(yōu)先用那臺。4.4 24小時運行穩(wěn)定性驗證?；钆渲米鐾曛笪易屝∶?連續(xù)跑了72小時每10分鐘發(fā)一次推理請求記錄成功率和響應(yīng)時間。結(jié)果是成功率98.7%平均響應(yīng)時間3.2秒最長一次延遲8.5秒發(fā)生在系統(tǒng)夜間自動更新時。失敗的那1.3%主要是系統(tǒng)內(nèi)存回收導(dǎo)致的推理中斷重新加載模型后恢復(fù)。為了進(jìn)一步提升穩(wěn)定性我加了兩個措施一是定期重啟推理服務(wù)每6小時自動重啟一次釋放累積的內(nèi)存碎片二是監(jiān)控內(nèi)存水位當(dāng)可用內(nèi)存低于300MB時主動卸載模型再重新加載。這兩個措施加上之后連續(xù)運行一周沒有出現(xiàn)崩潰。// 定期重啟邏輯 val handler Handler(Looper.getMainLooper()) val restartRunnable object : Runnable { override fun run() { restartInferenceService() handler.postDelayed(this, 6 * 60 * 60 * 1000L) // 6小時 } } handler.postDelayed(restartRunnable, 6 * 60 * 60 * 1000L)提示重啟服務(wù)時要注意先釋放模型內(nèi)存再重新加載。如果直接殺進(jìn)程重啟模型文件可能因為mmap未釋放導(dǎo)致文件鎖殘留下次加載會失敗。正確做法是調(diào)用releaseModel等JNI層確認(rèn)釋放完畢后再重啟。5. 常見問題與排查技巧實錄5.1 模型加載失敗的五種典型原因模型加載失敗是最常見的問題表現(xiàn)是應(yīng)用啟動后卡在加載界面或者直接閃退。根據(jù)我的排查經(jīng)驗原因基本集中在五類問題現(xiàn)象可能原因排查方法解決方案加載時閃退模型格式不匹配查看logcat中推理引擎報錯確認(rèn)框架支持的格式重新下載對應(yīng)格式模型加載后無響應(yīng)內(nèi)存不足adb shell dumpsys meminfo查看內(nèi)存換更小量化版本或關(guān)閉其他應(yīng)用報文件找不到路徑權(quán)限問題檢查文件路徑和權(quán)限放到應(yīng)用私有目錄避免外部存儲權(quán)限問題加載極慢存儲讀取速度慢測試存儲讀寫速度把模型放到內(nèi)部存儲不要放SD卡加載后推理亂碼模型文件損壞校驗文件MD5重新下載確保下載完整其中模型格式不匹配是最容易踩的坑。不同推理框架支持的格式不一樣有的只支持GGUF有的只支持GGML下載之前一定要看清楚。我有一次下了一個GGML格式的模型結(jié)果框架只認(rèn)GGUF加載直接報錯白白浪費了兩個小時下載時間。5.2 推理速度突然變慢的排查思路推理速度突然變慢通常不是模型本身的問題而是系統(tǒng)資源被搶占了。排查順序建議這樣先看CPU占用adb shell top看看是不是有其他進(jìn)程在跑再看內(nèi)存水位adb shell cat /proc/meminfo確認(rèn)可用內(nèi)存最后看溫度adb shell cat /sys/class/thermal/thermal_zone*/temp讀取CPU溫度。如果CPU溫度超過70度處理器會主動降頻推理速度直接腰斬。這時候要么加散熱要么降低線程數(shù)減少發(fā)熱。我試過把線程數(shù)從4降到2速度雖然降了30%但溫度從75度降到62度反而更穩(wěn)定不會因為降頻導(dǎo)致速度忽快忽慢。另一個常見原因是后臺有其他應(yīng)用在同步數(shù)據(jù)。舊手機如果還登著賬號系統(tǒng)會定期同步照片、郵件等這些操作會搶占IO和CPU。建議把不用的賬號全部退出關(guān)閉自動同步能明顯改善推理穩(wěn)定性。5.3 后臺服務(wù)被殺的應(yīng)對策略后臺服務(wù)被殺的表現(xiàn)是鎖屏后一段時間推理請求沒有響應(yīng)解鎖后發(fā)現(xiàn)服務(wù)已經(jīng)沒了。這個問題在不同品牌設(shè)備上表現(xiàn)不一樣有的品牌殺得特別狠有的相對寬松。應(yīng)對策略分三層第一層是前臺服務(wù)加通知這是基礎(chǔ)第二層是電池優(yōu)化白名單在系統(tǒng)設(shè)置里手動添加第三層是廠商特定的?；钤O(shè)置比如某些品牌需要在“手機管家”里單獨設(shè)置“允許后臺運行”。三層都做完基本能保證24小時存活。如果還是被殺可以考慮雙進(jìn)程守護方案啟動兩個服務(wù)互相監(jiān)聽一個被殺另一個把它拉起來。但這個方案比較耗電而且安卓高版本對后臺啟動服務(wù)有限制不一定能成功。我的建議是優(yōu)先做好前三層雙進(jìn)程守護作為最后手段。注意?；畈呗砸胶夤暮头€(wěn)定性。過度?；顣?dǎo)致電池消耗加快舊手機本來電池就不行了可能半天就沒電。建議插著充電器跑同時把屏幕亮度調(diào)到最低關(guān)閉所有不必要的無線連接。5.4 輸出質(zhì)量不達(dá)預(yù)期的調(diào)優(yōu)方法輸出質(zhì)量差的表現(xiàn)包括答非所問、重復(fù)啰嗦、邏輯混亂。這些問題大多可以通過調(diào)整推理參數(shù)改善。溫度太高會導(dǎo)致輸出發(fā)散重復(fù)懲罰太低會導(dǎo)致復(fù)讀機現(xiàn)象上下文長度不夠會導(dǎo)致模型忘記前面的對話。我的調(diào)優(yōu)順序是先把溫度降到0.3看輸出是否穩(wěn)定如果還是重復(fù)把重復(fù)懲罰從1.1提到1.2如果邏輯混亂檢查上下文長度是否夠用2048對于多輪對話可能不夠可以試試4096。另外prompt的寫法也很重要清晰的指令能顯著提升輸出質(zhì)量。比如不要只寫“解釋量子糾纏”而是寫“用三句話向高中生解釋量子糾纏每句話不超過20個字”。還有一個容易被忽略的點模型的chat template。不同模型有不同的對話模板如果模板用錯了模型就不知道哪些是用戶輸入、哪些是系統(tǒng)指令輸出質(zhì)量會大打折扣。加載模型時要確認(rèn)框架是否自動應(yīng)用了正確的template如果沒有需要手動在prompt里加上特殊標(biāo)記。6. 進(jìn)階玩法與擴展方向6.1 接入OpenAI兼容接口本地推理跑通之后可以進(jìn)一步封裝成OpenAI兼容的HTTP接口這樣其他應(yīng)用就能像調(diào)用云端API一樣調(diào)用本地模型。實現(xiàn)方式是在安卓端起一個輕量HTTP服務(wù)器收到請求后轉(zhuǎn)成推理調(diào)用再把結(jié)果按OpenAI的響應(yīng)格式返回。// 簡易HTTP接口示例 val server NanoHTTPD(8080) { override fun serve(session: IHTTPSession): Response { val body session.parseBody() val request JSONObject(body[postData] ?: {}) val prompt request.getJSONArray(messages) .getJSONObject(0).getString(content) val result runBlocking { engine.infer(prompt) } val response JSONObject().apply { put(choices, JSONArray().put(JSONObject().apply { put(message, JSONObject().put(content, result)) })) } return newFixedLengthResponse(response.toString()) } } server.start()這樣一來局域網(wǎng)內(nèi)的其他設(shè)備就能通過http://手機IP:8080/v1/chat/completions調(diào)用本地模型。實測下來局域網(wǎng)內(nèi)響應(yīng)延遲增加不到100毫秒基本無感。這個玩法適合把舊手機當(dāng)成家庭內(nèi)網(wǎng)的AI推理節(jié)點所有設(shè)備共享一個本地模型。6.2 多模型切換與任務(wù)路由如果手機存儲夠大可以放多個不同大小的模型根據(jù)任務(wù)類型自動切換。簡單任務(wù)用3B模型速度快復(fù)雜任務(wù)用7B模型質(zhì)量高。實現(xiàn)上就是在推理層加一個路由邏輯根據(jù)prompt長度或者關(guān)鍵詞判斷用哪個模型。模型切換的開銷主要在加載和卸載上一次切換大概需要3到5秒。如果頻繁切換體驗會很差。優(yōu)化方法是保持兩個模型常駐內(nèi)存但這對內(nèi)存要求很高8GB設(shè)備勉強可以6GB設(shè)備基本不可能。所以更實際的方案是默認(rèn)加載7B模型遇到簡單任務(wù)也不切換反正7B跑簡單任務(wù)也不慢。6.3 語音輸入與TTS輸出閉環(huán)舊手機有麥克風(fēng)和揚聲器加上本地語音識別和語音合成模型就能做成一個完全離線的語音助手。語音識別可以用Whisper的小型量化版本語音合成用Android自帶的TTS引擎。整個鏈路全部本地完成不依賴網(wǎng)絡(luò)。這個玩法的技術(shù)難點在于音頻流的實時處理。麥克風(fēng)采集的音頻要分幀送入識別模型識別結(jié)果再送給大模型推理推理結(jié)果再送TTS合成。整個鏈路延遲大概在2到4秒比云端方案慢一些但勝在完全離線。我試過在小米8上跑這套鏈路日常問天氣、設(shè)提醒、查百科都能用體驗還算流暢。7. 個人實操心得與最后分享折騰舊手機跑本地大模型這件事我從年初開始陸續(xù)做了幾個月前后換了四臺設(shè)備刷過三次系統(tǒng)踩過的坑包括模型格式不匹配、內(nèi)存溢出閃退、后臺服務(wù)被殺、推理速度斷崖式下降等等。最大的體會是舊手機的瓶頸不在CPU而在內(nèi)存和散熱。CPU性能夠用但內(nèi)存不夠會導(dǎo)致頻繁回收散熱不好會導(dǎo)致降頻這兩個問題解決了體驗就能上一個臺階。另一個心得是不要追求一步到位。一開始不要想著跑最大的模型、開最長的上下文、接最復(fù)雜的接口。先把最基本的推理跑通確認(rèn)模型能加載、能生成、速度可接受然后再逐步加功能。我一開始就想直接上13B模型結(jié)果折騰了兩天都沒跑起來后來換成7B半小時就通了。先跑通再優(yōu)化這個順序很重要。最后分享一個小技巧如果舊手機存儲空間緊張可以把模型文件放在外置存儲卡上但一定要用高速卡低速卡會導(dǎo)致加載時間從幾秒變成幾十秒。另外模型文件可以壓縮存放用的時候再解壓能省不少空間但解壓需要額外時間適合不頻繁切換模型的場景。