手机离线跑大模型ReactNative实战

01 你还在为每次调用 LLM 交"税"吗

去年我做一个健康类 App 的智能问答，第一个月 token 账单就干到了两千多。更难受的是，用户输入的身体状况要绕一圈云服务器，合规评审每次都皱眉。

后来我一直想一件事：现在手机算力这么强，为什么非得把每一个 prompt 都送到云端？

2026 年这件事终于不用纠结了。Meta 的 ExecuTorch 加上 Software Mansion 的 react-native-executorch，让一个 3B 参数的模型能直接在手机上跑，首 token 延迟压到 100ms 以内，每次对话的边际成本等于零。

这篇文章我不讲概念，只带你在 React Native 里把一个能离线对话的 LLM 真正跑起来。

我把自己跑通的全过程、踩的坑、还有模型怎么选，都摊开写在这里，照着做就能在真机上对话。

02 端侧推理到底解决了什么

先说清楚为什么值得做，不然你不会想踩这一堆原生坑。

隐私是第一根稻草。推理在端上，prompt 和回答永远不离开手机。医疗、金融、日记这类应用，这一条直接消掉一整类合规风险，不用再为每个接口写脱敏。

延迟是体感。云端来回至少加 200-800ms 才出第一个字。端侧在骁龙 8 Elite 上首 token 不到 100ms，对话的"跟手感"完全不一样，打字机效果才像真的在聊。

成本最实在。模型下载一次之后，不管多少用户、多少条消息，边际成本都是零。我那个健康 App 如果全走端侧，一年省下的 token 钱够再招半个人。

离线是兜底。工厂车间、医院病房、飞机上，网络不稳的地方端侧 AI 照样干活，不会因为断网变成智障。

代价我也得说清楚：端侧模型小，3B 在复杂推理上确实打不过 GPT-4。但摘要、翻译、快问快答、图片描述、工具增强工作流，质量完全够用，而且量化技术每个月都在进步。

2026 年的实测数据更直白：骁龙 8 Elite 上 1-5GB 的端侧模型已经能做到 GPT-3.5 级别的质量，子 20ms 的推理延迟不再是实验室里的数字，而是真机上的体感。

03 选型：为什么是 react-native-executorch

2026 年 RN 端侧 AI 有三个主流选择，我一个个踩过。

react-native-executorch（Software Mansion，底层 ExecuTorch）：模型覆盖最广，LLM、语音识别、图像分类、OCR 一个不落，而且给的是 React Hooks 优先的 API，前端写着最顺手。

react-native-ai（Callstack）：兼容 Vercel AI SDK，一行配置就能在云端和本地模型之间切换，适合已经用 Vercel AI SDK 的项目，但模型覆盖没那么全。

llama.rn：GGUF 模型、底层控制最强，但得自己接一大堆胶水代码，不是"装上就用"的路线。

我的目标最快跑通一个聊天：要 Hooks、要覆盖广、要少写胶水。选 react-native-executorch 基本没有悬念。它把模型加载、内存管理、流式输出全包了，我只管写 UI。

如果你做过原生 AI 集成的老路子，会懂少写多少胶水代码意味着什么------那往往是劝退的第一步。

04 环境准备（先避开两个大坑）

硬性前提，少一个都跑不起来，我按踩坑顺序列：

• Expo SDK 54 及以上

• 新架构（New Architecture）必须开，这个库不兼容老 bridge

• 真机，或分配了至少 4GB RAM 的模拟器

安装核心包和资源拉取器：

npx expo install react-native-executorch @react-native-executorch/expo-resource-fetcher expo-file-system expo-asset

注意：因为包含原生代码，必须用 development build，expo run:ios 或 expo run:android，Expo Go 不行。

第一个坑就在这------很多人拿 Expo Go 直接跑，白屏报错半天找不到原因。这是原生模块，不是 Web，Expo Go 加载不了原生代码。

确认新架构有没有开，看 Expo 项目里 app.json 的 expo.newArchEnabled 是不是 true。很多从老模板升级的项目这项是漏的，模型 Hook 一调用就报原生模块找不到。

// app.json
{ "expo": { "newArchEnabled": true } }

第二个坑是 RAM。模拟器默认只给 2GB，模型加载直接 OOM 崩。我第一次就是卡在这，改到 4GB 才稳住。

05 初始化：一次就够

在应用入口调用一次 initExecutorch，它负责注册资源拉取器，把模型二进制下载并缓存到本地存储。

// app/_layout.tsx
import { initExecutorch } from 'react-native-executorch';
import { ExpoResourceFetcher } from '@react-native-executorch/expo-resource-fetcher';

initExecutorch({
  resourceFetcher: ExpoResourceFetcher,
});

就这一行配置，后面所有页面都不用再管模型加载的细节。它会在首次需要模型时自动去拉取并缓存，之后离线也能用。

06 核心：用 useLLM 写一个能离线的聊天

真正的活儿都在 useLLM 这个 Hook 里：模型加载、token 流式输出、对话历史管理、内存清理，它全包了，你不用碰任何 C++。

下面这个 ChatScreen 我精简过，但逻辑完整，复制进 Expo 项目就能跑。

// app/chat.tsx
import React from 'react';
import { View, Text, TextInput, FlatList, Pressable, ActivityIndicator, StyleSheet } from 'react-native';
import { useLLM, QWEN3_0_6B, type Message } from 'react-native-executorch';

export default function ChatScreen() {
  const [input, setInput] = React.useState('');
  const [history, setHistory] = React.useState([]);

  const llm = useLLM({ model: QWEN3_0_6B });

  React.useEffect(() => {
    llm.configure({
      chatConfig: { systemPrompt: '你是一个简洁、有帮助的手机端助手。' },
      generationConfig: { temperature: 0.7, topp: 0.9 },
    });
  }, [llm]);

  const send = async () => {
    if (!input.trim() || llm.isGenerating) return;
    const next = [...history, { role: 'user', content: input }];
    setHistory(next);
    setInput('');
    const reply = await llm.generate(next); // 自动追加 assistant 消息，流式刷新
    setHistory([...next, reply]);
  };

  return (
    
       String(i)}
        renderItem={({ item }) => (
          {item.content}
        )}
      />
      {llm.isGenerating && }
      
        
        发送
      
    
  );
}

const styles = StyleSheet.create({
  container: { flex: 1, padding: 16, gap: 8 },
  user: { alignSelf: 'flex-end', backgroundColor: '#0a84ff', color: '#fff', padding: 8, borderRadius: 8 },
  bot: { alignSelf: 'flex-start', backgroundColor: '#1c1c1e', color: '#fff', padding: 8, borderRadius: 8 },
  inputBar: { flexDirection: 'row', gap: 8 },
  input: { flex: 1, borderWidth: 1, borderColor: '#333', borderRadius: 8, padding: 8, color: '#fff' },
});

跑 npx expo run:ios 或 run:android，首次会下载 Qwen 0.6B 模型（几百 MB），装完直接对话，全程不联网、不耗 token。

llm.isGenerating 帮你管住"正在生成时别重复发"，llm.configure 里的 generationConfig 控制温度和采样------这些参数和你在云端调 API 时一模一样，迁移成本几乎为零。

如果你的 UI 要打字机效果，流式输出这块和云端没区别：生成期间监听中间状态，把 partial 文本实时写进气泡，配合 llm.isGenerating 的 loading 态，体验上和调用 OpenAI 流式接口一致，差别只是数据根本没出手机。

底层快的关键在 JSI（JavaScript Interface）。老架构每次原生调用都要把数据 JSON 序列化过桥，一帧相机画面要 8-15ms 开销；新架构通过 JSI 直接拿到 C++ 对象引用，单次调用开销降到 1ms 以内。端侧推理能跑流畅，New Architecture 是地基。

07 模型怎么选，以及三个容易翻车的点

模型不是越大越好，手机上三个约束卡着你：RAM、存储空间、推理速度。2026 年中可用的参考：

• LFM2.5 1.2B：约 900MB，质量/体积比最好，默认推荐

• Qwen2.5 0.5B：约 400MB，中端机也能跑，首 token 快到 45ms

• Llama 3.2 3B：约 2GB，质量更高，但首 token 慢一倍

量化选 INT4（GGUF 里常是 Q4_K_M）最划算：质量损失对多数任务只有几个百分点，内存比 FP16 直接降 4 倍。别用 INT3 或 Q2，质量肉眼可见地崩。

第一个翻车点：New Architecture 必须开。RN 0.84（2026 年 3 月）已经把老 bridge 从 iOS 构建里彻底删了，老项目要么迁移，要么换库。

第二个翻车点：首次下载体积。别在发版时让用户现下，最好接入预下载，或在 WiFi 下静默拉取，否则首屏体验会很糟，用户以为 App 坏了。

第三个翻车点：内存峰值。3B 模型推理时峰值 RAM 可能到 3GB，低端机容易后台被杀。用 llm.unload() 在页面卸载时主动释放，别等系统回收。

还有一个容易被忽略的点：端侧模型对 systemPrompt 的指令遵循比云端弱。prompt 要写得短而硬，别堆长指令，否则它容易跑偏。我一般把 systemPrompt 控制在两句话以内，反而更稳。

想更进一步，可以接工具调用做混合架构：简单请求走端侧，复杂推理走云端，UI 一行切换，业务代码不重写。这才是端侧 AI 真正落地的姿势。

08

你手机上现在跑着多大的模型？是已经上了 ExecuTorch，还是在观望？端侧 AI 这波我判断两年内会成 App 标配，尤其隐私敏感的场景。评论区聊聊你踩过的坑，或者你最想先在端侧落地的功能。