手機上的 Llama Stack：以微調 Llama 4 模型自託管 Llama 代理

Llama Stack 是 Meta 為在 Llama 模型上建構代理的官方參考架構。代理、工具、安全過濾器、評估與 telemetry 坐落於單一統一的 API 表面背後。它是開源權重世界中最接近標準代理堆疊的東西,而其設計意圖很清楚：停止在每個專案中重新發明代理迴圈、安全層與評估套件。

對 Llama Stack 的多數報導假設伺服器部署——一個 Kubernetes 叢集、一個 GPU 池、一個你的 app 透過網路呼叫的 API 端點。這是顯而易見的路徑,也是再次製造每個開源權重生態系本應解決之經濟與隱私問題的路徑。按 token 成本維持為正。網路往返維持緩慢。使用者資料仍離開裝置。

較少被欣賞的是,Llama Stack 出貨一級的 Swift 與 Kotlin 用戶端 SDK。同一個代理抽象可在模型嵌入 iOS 或 Android app 中執行,與綁入二進位檔的本地推論伺服器對話。代理迴圈、工具分派器、安全過濾器、telemetry 管線——全部都可在使用者手機上執行,對抗 app 出貨的微調 Llama 4 衍生模型。

本指南走過該架構：完整的 Llama Stack 代理在裝置端執行,由在 Ertas Studio 微調並透過 Ertas Deployment CLI 出貨到行動 app 的 Llama 4 模型驅動。

架構

有三個元件,它們乾淨地契合在一起。

第一是裝置端推論。Llama Stack 的 Swift 用戶端 SDK 出貨由 ExecuTorch 支援的 LocalInference 類別,直接在主 iOS app 內執行模型——推論不需要獨立的 Llama Stack 伺服器程序。Kotlin 用戶端為 Android 提供等價的裝置端介面卡。模型在 app 的位址空間中執行,SDK 將 Llama Stack 的 API 呼叫轉譯為本地推論呼叫。

第二是模型本身。裝置端推論介面卡載入 app 出貨的 GGUF（或 ExecuTorch 格式）二進位檔——通常是在你的領域資料上微調並為行動端量化的 Llama 4 衍生模型。Ertas Deployment CLI 處理格式轉換與資產註冊。

第三是代理平台。Swift 與 Kotlin 用戶端在本地實作 Llama Stack 代理迴圈、工具分派、安全過濾與 telemetry——伺服器端 Llama Stack 部署會暴露的同樣原語,只是由裝置端推論驅動而非網路端點。從 app 的角度看,API 表面與遠端 Llama Stack 部署完全相同。

結果是乾淨的分離。app 程式碼說 Llama Stack。Llama Stack 用戶端驅動裝置端推論介面卡。推論介面卡透過 llama.cpp 或 ExecuTorch 與 GGUF 模型對話。這之中無需網路往返。

為什麼特別是 Llama Stack

這裡潛藏一個完全有效的問題：如果你反正要在裝置端執行 llama.cpp,為何要涉及 Llama Stack?為何不直接透過其 Swift 或 Kotlin 綁定呼叫 llama.cpp,跳過抽象層?

誠實的答案是,自己捲的行動推論設定跳過代理中容易跳過、難以加回的部分。工具呼叫變成定製解析器。安全過濾變成沒有,或變成手寫 regex。評估變成幾個一次性腳本。Telemetry 變成你還記得加的 Logfire 或 OpenTelemetry 呼叫。每個缺口在孤立中可解決;一起,它們產出讓裝置端 AI 感覺像 API 支援代理的降級之脆弱代理。

Llama Stack 將那些缺口閉合作為標準架構的一部分：

Agents API 給你具有多輪記憶與工具分派的結構化代理迴圈——無解析器要寫。
Tools API 以型別化 schema 註冊你的函式並自動處理路由。
Safety API 在輸入與輸出抵達使用者前對其執行 Llama Guard（或你選擇的安全模型）。
Eval API 對保留測試集執行基準,讓你在出貨新模型版本時偵測倒退。
Telemetry API 擷取每次代理執行的結構化軌跡,用於除錯與持續訓練。

你對在手機上、對本地模型,獲得這一切,而無需自己撰寫任何。這就是裝置端 Llama Stack 的實際價值主張——不是「推論包裝器」,而是恰好支援嵌入式執行的完整代理平台。

微調層

stock Llama 4 模型是通才。對多數代理行動使用情境——健身教練、財務協助、排程、客戶支援、任何領域特定——微調衍生模型大幅更可靠。在你的工具上的較低幻覺率、較少 schema 違規、更一致的風格、對範圍外請求的更佳拒絕。

管線看起來像這樣：

在 Ertas Studio 整理資料集。 Studio 的 Data Craft 模組將你的工具 schema 作為輸入,並產出涵蓋工具呼叫、多步驟流程與拒絕的結構化訓練對話。對於領域專屬代理,你通常想要 400 到 800 個範例——足以教會 schema,不至於開始擬合雜訊。
在 Studio 微調 Llama 4。 Llama Stack 最初與 2024 年 9 月的 Llama 3.2 一起出貨,並透過 Llama 3.3 與 Llama 4 追蹤 Llama 家族——Llama 4 衍生模型是新裝置端部署目前的標準基底,且無需轉譯即可與 Safety API 與 Eval API 整合。Studio 的預設設定是 QLoRA 在 rank 32 上 3 個 epoch。在 Llama 4 8B 基底上訓練 500 範例資料集通常在一小時內完成。
匯出為 GGUF。 Studio 的匯出流程在你指定的等級下產出量化 GGUF 二進位檔。對於手機上的 Llama 4 8B,Q4_K_M 在磁碟上落於約 5 GB,並在任何現代旗艦上乾淨執行。對於更積極的腳印,Q3_K_M 以小品質代價將其進一步降低。
透過 Ertas Deployment CLI 出貨到行動端。 CLI 將 llama.cpp 安裝到 iOS 或 Android 專案、將 GGUF 放入正確的資產目錄、設定 Llama Stack 的本地伺服器來提供模型,並接通 Swift 或 Kotlin 用戶端。從執行 CLI 到進行第一次代理呼叫通常少於十五分鐘。

ertas deploy mobile \
  --project ./fitness-app \
  --model ertas-fitness-coach-llama4-8b.gguf \
  --framework ios \
  --runtime llama-stack

--runtime llama-stack 旗標告訴 CLI 接通 Llama Stack 裝置端介面卡（iOS 上的 LocalInference、Android 上的 Kotlin 等價物）而非裸的 llama.cpp 呼叫。CLI 產生推論介面卡註冊程式碼、設定模型資產,並將 Swift 或 Kotlin 用戶端勾入主 app 的生命週期,使代理平台在 app 啟動時就緒。

工作範例：健身教練代理

這是我們將建構的代理。使用者開啟健身 app 並輸入類似「我做了 3x10 蹲舉,135 磅,記錄並告訴我下一步要做什麼」的東西。代理有三個工具：

log_workout(exercise: String, sets: Int, reps: Int, weight: Double) 記錄訓練
fetch_progress(exercise: String, weeks: Int) 回傳近期歷史
suggest_routine(goal: String, equipment: [String]) 提出下一個課程

在 Studio,我們整理約 600 個對話的資料集,涵蓋單工具呼叫、多步驟流程（記錄然後建議）、拒絕（醫療建議超出範圍）與驗證邊緣案例（缺失的重量預設為自體重）。在 3 個 epoch 上微調 Llama 4 8B。評估套件以 96% 工具名稱準確率、95% 參數名稱準確率、94% 參數值準確率通過。生產就緒。

執行 Deployment CLI、將其指向 iOS 專案、選擇 --runtime llama-stack。兩分鐘後,專案建置、裝置端推論介面卡與模型一起註冊,且 Swift 用戶端已接通。

這是整個用戶端側代理整合：

import LlamaStack

let client = LlamaStackClient(transport: .embedded)

let agent = try await client.agents.create(
    model: "ertas-fitness-coach-llama4-8b",
    instructions: "You are a fitness coach. Use the tools to log workouts and suggest routines. Refuse medical questions.",
    tools: [
        Tool(name: "log_workout", description: "Log a completed workout"),
        Tool(name: "fetch_progress", description: "Fetch recent workout history"),
        Tool(name: "suggest_routine", description: "Suggest the next routine"),
    ],
    safety: .llamaGuard
)

let session = try await agent.createSession()

let response = try await session.turn(
    messages: [.user("I did 3x10 squats at 135, log it and tell me what to do next.")],
    toolHandlers: [
        "log_workout": logWorkoutHandler,
        "fetch_progress": fetchProgressHandler,
        "suggest_routine": suggestRoutineHandler,
    ]
)

print(response.finalMessage.content)

大約三十行 Swift。代理迴圈、工具分派、透過 Llama Guard 的安全過濾、多輪會話記憶——Llama Stack 處理全部。主 app 提供三個工具處理器（實際記錄到 Core Data、查詢歷史並產出課程的 Swift 函式),Llama Stack 做其餘。

Kotlin 中的相同模式實質上完全相同：

val client = LlamaStackClient(transport = Transport.Embedded)

val agent = client.agents.create(
    model = "ertas-fitness-coach-llama4-8b",
    instructions = "You are a fitness coach. Use the tools to log workouts and suggest routines.",
    tools = listOf(
        Tool("log_workout", "Log a completed workout"),
        Tool("fetch_progress", "Fetch recent workout history"),
        Tool("suggest_routine", "Suggest the next routine"),
    ),
    safety = Safety.LlamaGuard,
)

之後發生的一切——推論、工具呼叫、安全檢查——在 iOS 與 Android 之間完全相同。Stack 乾淨地抽象執行期。

經濟模型

成本案例與每個裝置端代理架構成立的相同。對前沿 API 執行多輪健身教練流程,依上下文長度每次會話約三到八美分。在每天平均四次會話的一千名日活躍使用者下,那是一天一百二十到三百二十美元,即一個月三千六百到九千六百美元。帳單與使用者線性擴展。

在裝置端,每次推論的邊際成本是使用者手機上的 GPU/CPU 時間——通常為幾百毫秒與使用者電池的一小部分美分。固定成本是磁碟上的模型腳印。兩項都不隨你的使用者數量成長。

對行動 app 建構者,代理成本懸崖在五百到五千名使用者之間咬住,依會話強度而定。那是 API 成本開始比使用增長能跑贏更快地消耗訂閱營收的範圍。裝置端推論完全消除該懸崖,而裝置端 Llama Stack 消除它而不強迫團隊從零重建代理迴圈、安全過濾器或 telemetry 管線。

對於隱私敏感使用情境,計算更鋒利。健康、財務與法律領域對使用者資料居住何處有硬需求。裝置端代理永遠不會讓「使用者訊息送往 Meta」或「使用者訊息送往 OpenAI」成真。對某些 app 類別這是合規論據,與成本論據一樣多,且這是唯一重要的論據。

與其他裝置端方法的差異化

有其他方法在手機上出貨模型。你可以透過 Swift 綁定直接呼叫 llama.cpp。你可以在 iOS 26+ 上使用 Apple Foundation Models。你可以在 Android 上使用 Google 的 AICore。你可以在這些上面捲自己的代理迴圈。

裝置端 Llama Stack 提供替代方案沒有的是代理平台的其餘部分。Llama Guard 為安全過濾,已整合並設定。Eval API 為在你出貨新微調時捕捉倒退。Telemetry API 為你可回饋到下一輪訓練的結構化軌跡。Tools API 為型別化 schema 與自動分派。由 Agents API 處理的多輪會話記憶。

你不是從零建構那些層,也不是縫合半打開源函式庫來逼近它們。你是使用 Meta 為此目的設計的參考架構,模型嵌入 app 而非位於網路端點之後。

結語

出貨 AI 功能的行動建構者可以完全在使用者裝置上出貨完整代理堆疊——不只是推論。Meta 的參考架構、微調 Llama 4 衍生模型,加上少量黏合。Llama Stack、Ertas Studio 與 Ertas Deployment CLI 的組合,將過去一季的平台工程崩塌為一個下午的整合工作。

微調部分是 Studio 賺錢之處——stock Llama 4 模型是通才,而你需要的代理可靠性來自一個了解你工具透徹的模型。部署部分是 CLI 賺錢之處——將 llama.cpp（或 ExecuTorch）、Llama Stack 的裝置端推論介面卡、Swift 或 Kotlin 用戶端,以及 5 GB 模型檔案接到 iOS 或 Android 專案中,是多數 app 建構者從未完成的二十到四十小時建置設定。將三件作品堆疊在一起,從「我們想要裝置端代理」到「我們有裝置端代理」的路徑變成一個下午。

對於凝視代理成本懸崖的 app 建構者,那是路徑。Llama Stack 給你架構。Llama 4 給你基底模型。Studio 給你專業化。Deployment CLI 給你行動出貨管線。代理在使用者手機上執行、帳單停止隨使用擴展,且使用者資料永不離開裝置。