最开始触发我想折腾这件事的，是一次很普通的出差。我在酒店里打开随身带的平板，想查一份资料，结果国内数据源没收录，国际站点又打不开，云端笔记应用因为登录态失效直接把我隔在了自己的笔记外面。更别提那段时间我对“云端AI”越来越不安：我对着手机说了一段工作想法，App 确实给了我一个不错的回答，但我知道这段音频被上传到了某个不在我手里的服务器上。
于是我生出一个有点反直觉的想法：我要的不是一台更快的平板，而是一个完全归自己控制的AI终端。它不用多贵，不用跑分很高，但它要能离线听懂我说话、能在没有网络的时候和我对话、能根据我的文字生成图片、还能把纸面上的内容“读”进系统里。
这个想法最终变成了一个花了 266 美元左右的硬件项目。核心不是那块屏幕、那个外壳，而是我部署在里面的四个AI模型。这篇文章我就把整个思路、选型、部署流程和踩坑记录完整写出来。如果你也想把一台普通便携主机改造成“只属于你自己的AI平板”，这篇文章应该能帮你少走不少弯路。
1. 为什么不是直接买一台平板，而是自己重新造一台
1.1 一台 266 美元的设备，听起来就不像平板
先说说硬件。我选的不是什么高性能工作站，而是一台低功耗迷你主机，类似市面上常见的 Intel N100 或 AMD 低功耗平台，配了一块 7 到 10 寸的便携触摸屏，再加上电源、散热片、几根转接线，总价大概在 266 美元上下。
很多人听到这里会问：这个组合能叫平板电脑吗？如果按消费级平板的定义，刷视频、玩大型游戏、长时间持握，它确实不合格。但我的目标从一开始就不是复刻一个 iPad 或者安卓平板。我的目标非常具体：
- 能装 Linux，因为我要自己控制整个系统；
- 能跑模型推理，因为我要部署本地AI模型；
- 能接触摸屏，因为我要在桌面环境下用手点、用手写；
- 能低功耗连续运行，因为我希望它平时像一个桌面助手一样随时待命。
所以这台设备的第一判断标准不是“贵不贵”“快不快”，而是“我能不能完全控制它”。这一点，大多数消费级平板做不到。消费级平板的系统更新由厂商决定，有些应用商店还会限制你能安装什么软件，哪怕你用侧载绕过，也会经常遇到系统完整性校验。而一台 Linux 迷你主机没有这些问题：root 权限在你手里，系统环境由你决定，装什么模型、启动什么服务、开机有没有后台遥测，全部由你说了算。
1.2 目标不是“复刻平板”，而是“重排AI入口”
传统平板电脑的逻辑，是提供一块触摸屏入口，背后绑着一整套商业生态。比如你想用语音助手，它是厂商预设的；你想让 AI 帮你处理文档，你得用某个特定 App；你想离线翻译一段外文，基本要看网络脸色。
而我这台“自制AI平板”的逻辑完全不同。我的核心诉求是：屏幕永远停在我的AI桌面上，而不是停在某个App网格里。开机之后，系统直接进入一个轻量级前端页面，左侧是语音输入按钮，中间是对话窗口，右侧可以显示图像生成结果。所有能力都由本地的模型服务提供，不需要厂商账号，不需要云服务订阅，也不需要担心哪天某个服务下线导致功能失效。
这就是我所说的“重排入口”。平板不再是服务商的入口，而成为我自己的私有AI工作台。你打开它，不是进入某个生态，而是进入你自建的一套服务里。这个区别，才是整个项目最关键的出发点。
1.3 四个模型不是堆料，而是一套完整输入输出链
很多类似项目教程只教你跑一个对话大模型，跑完就结束了。但真实使用场景根本不是这样。一个能随身用的AI终端，至少需要四种能力：
- 把语音转成文字；
- 和用户围绕文字展开对话；
- 根据意图生成图像；
- 把相机拍到或屏幕上看到的文字内容识别出来。
四个能力分别对应四个AI模型：语音识别模型、对话大模型、文生图模型、视觉理解/OCR模型。它们不是各自独立的玩具，而是一条完整的输入输出链：语音进入系统，变成文字；文字进入对话模型，产生回复；如果用户想要图片，对话模型可以调用文生图模型生成；纸面上的内容则通过视觉理解模型转成结构化文本，再交给对话模型进一步加工。
这条链路决定了硬件选型、内存大小和模型参数的取舍，也决定了你后续所有部署顺序。先有这条链路，再选硬件，而不是反过来。
2. 四个AI模型分别承担什么角色
2.1 语音模型：先从“说话”开始
我做的第一件事，不是部署大模型，而是让设备能“听懂”我说话。因为一台不能语音交互的AI平板，本质上和一台普通迷你主机没什么区别。我希望的是，我对着麦克风说“帮我记录一个想法”，设备能自动转成文字并交给后续模型。
语音识别模型我选择的是社区里比较成熟的离线方案，比如 whisper 家族的轻量量化版本，或者 sherpa-onnx 这类更适合低功耗设备推理的引擎。具体选哪个，要看你设备的 CPU 和内存。我最早试过完整版模型，效果很好，但在我的设备上推理速度不太理想，一句话要转好几秒，后来换成了参数量更小的版本，速度明显提升，日常听写足够用。
这里有一个容易被忽视的细节：麦克风权限和音频采集。在 Linux 桌面环境下，如果默认音频设备没有指向你的 USB 麦克风，语音识别服务根本拿不到声音。我第一次跑的时候，程序没有任何报错，但转写结果一直是空文本，排查了很久才发现是 PulseAudio 的默认输入设备不对。建议你先用arecord或者系统录音工具录一段音频，确认麦克风真正工作，再启动语音识别服务。
从工程视角来看，语音模型最好和后续对话模型分开部署，方便独立升级。我一般用一个小脚本完成“录音 -> 转写 -> 把文本写入队列”的流程，后续对话模型从队列里取文本，这样解耦之后排查问题会非常高效。
2.2 会话模型：真正的对话中枢
对话模型是整个设备的“大脑”。这里我用的是 Ollama 作为运行框架，因为它对模型下载、命令行调用和接口暴露都做了很好的封装，特别适合做本地原型。模型本身选择的是 qwen 或者 llama 家族的中小尺寸版本，经过量化后大约 4GB 左右，既能塞进我的设备内存，又有足够的中文理解能力。
为什么选中小尺寸模型而不是十几GB的大模型？原因很简单：内存容量和内存带宽决定了生成速度。如果模型太大，加载后系统会频繁交换内存，输出一个字要等半天，体验非常糟糕。在低功耗设备上，“能跑”和“跑得动”是两回事。宁可选择参数量小一点、但能稳定输出的模型，也不要盲目追求最大参数。
启动 Ollama 服务后，我会先做一次最小验证：
ollama run qwen2.5:3b "用一句话介绍你自己"这一步能确认模型文件是否完整、推理服务是否正常。然后我再处理两个关键配置项：
OLLAMA_HOST：默认是127.0.0.1:11434，如果后续前端页面跑在同一台设备上，保持默认即可；如果需要局域网内其他设备访问，再改成0.0.0.0。- 模型存储路径：可以通过环境变量指定，方便单独挂载到容量更大的存储盘，避免系统盘塞满。
实际使用中，我推荐用一个简单的 Python 脚本统一封装对话接口，而不是每次手动敲命令。这样后续接入语音模型或者前端页面时，只需要调用同一个函数：
import requests def chat(prompt: str) -> str: resp = requests.post( "http://localhost:11434/api/generate", json={"model": "qwen2.5:3b", "prompt": prompt, "stream": False}, timeout=60, ) return resp.json()["response"]这个阶段的核心目标不是做出一个很酷的界面，而是先让对话能力稳定可用。只有当你对着命令行输入文字、能稳定得到回复时，才可以进入下一步整合。
2.3 图像模型：让图形输出回到本地
语音和对话解决的是文字世界的问题，但一个真正有用的AI终端，还应该能处理视觉内容。我这边部署了轻量级的文生图模型，用来实现“你说一个概念，我帮你生成一张参考图”的工作流。
文生图模型在低功耗设备上跑起来会比较吃力，我的建议是选择 SD 系列的量化小版本，或者社区专门针对集成显卡优化的模型分支。不要试图在这类设备上追求高分辨率多批次生成，一次只生成一张 512x512 的图，作为灵感草稿或笔记配图完全够用。
一个实用技巧是让对话模型和文生图模型联动。比如我对设备说“帮我画一个森林里的木质工作台”，语音模型转成文字后，对话模型判断用户意图是画图，就把这段描述改写成一个更适合出图的英文 prompt，然后传给底层画图接口，最后返回图片路径。整个过程看起来只发生了一步交互，实际上是三个模型各干各的活。
如果你想要的只是“能出图”，可以先用一个最小 Python 调用验证模型好坏：
from diffusers import StableDiffusionPipeline pipe = StableDiffusionPipeline.from_pretrained( "示例模型路径或HuggingFace ID", local_files_only=True ) image = pipe("a wooden workbench in the forest").images[0] image.save("output.png")需要提醒的是，这一步最容易踩的坑是依赖版本冲突。diffusers、transformers、torch这三个库之间经常有版本兼容要求，建议用虚拟环境隔离，不要把文生图模型和对话模型的依赖装在同一个 Python 环境里，否则升级一个库很可能搞坏另一个。
2.4 视觉理解模型：读懂屏幕和纸质内容
最后一个模型我称之为“回读能力”。一个平板类设备最常干的活，其实是看文档、看题、看纸质笔记。如果没有视觉理解模型，这些内容就只是“图片”，不能被检索、不能被摘要、不能被进一步加工。
视觉理解这一层，我拆成了两个路径：第一个是轻量 OCR，专门处理印刷体和常见中英文文档；第二个是小型多模态模型，用来处理更复杂的图文混合内容。严格来说，我不一定需要第二个模型承担“看”的任务，它更像是一个把图像转成结构化文本的桥梁。
比如我拿设备对着纸质会议记录拍一张照片，OCR 先识别出文字，然后多模态模型负责判断段落结构、补充上下文，最后把整理后的内容存成 Markdown 文件。这一步对经常阅读纸质资料、又希望把内容数字化的人来说，价值非常高。
实际部署时，OCR 类模型通常有独立的 Python 库和自己的模型文件目录，安装过程相对独立。你需要重点检查两个东西：一是模型文件路径是否拼写正确，很多报错都是因为路径少了层目录；二是输入图片的分辨率，太小的截图识别效果会明显变差。建议先拿一张清晰的印刷体图片试试，再逐步过渡到手机拍的模糊照片。
到这里，四个模型已经组成了一个完整闭环：语音进、文字处理、图像出、视觉理解回读。但只是把模型跑起来还不够，你还需要把它们真正用起来。
3. 完整搭建路径：从系统到模型再到界面
3.1 硬件准备和系统选择
整个项目如果按阶段拆分，大概可以分成四步：硬件准备、系统安装、模型部署、前端串联。我强烈建议按照这个顺序推进，不要跳到第三步才开始思考硬件够不够用。
硬件方面，你的清单不会太复杂：
- 一台低功耗迷你主机或 ARM 开发板；
- 一块支持触摸输入的便携显示器；
- 一套稳定的供电方案；
- 一个 USB 麦克风；
- 一个至少 128GB 的 SSD 或高速 TF 卡，用来装系统、模型和输出文件。
系统方面，我建议选主流的 Linux 发行版本，社区适配好，碰到问题时更容易搜到解决办法。如果你对命令行不熟，选带桌面环境的版本会更友好；如果你习惯自己折腾，可以选一个轻量窗口管理器，减少系统资源占用。
这一阶段最容易碰到的坑是触控屏驱动。很多便携触摸屏并不是即插即用，需要在系统里安装厂商驱动或校准工具。我的建议是：先不要急着装 AI 模型，先把屏幕点亮、触摸驱动校准好。否则后面模型部署到一半，发现屏幕点不了，排查起来会非常痛苦。
3.2 模型部署：运行环境与下载方式
模型部署这一步，核心原则是“分开装、逐个验”。不要试图一口气把所有模型装完，每装好一个就立刻验证一次，确认问题出在哪一层。
以对话模型为例，安装 Ollama 之后，需要设置一个专门存放模型文件的目录：
export OLLAMA_MODELS=/path/to/your/models ollama serve然后下载模型：
ollama pull qwen2.5:3b这里有一个容易忽略的点：模型文件可能有好几个 GB，下载前要确认存储空间充足。我遇到过下到一半磁盘满了，模型文件损坏，只能删掉重新下载。更好的做法是先df -h看一下磁盘剩余空间，再决定模型下载位置。
语音模型和视觉模型不一定走 Ollama，可能要走各自的 Python 库。这时候一定要创建虚拟环境：
python3 -m venv myenv source myenv/bin/activate pip install 相关依赖为什么要分开环境？因为不同模型依赖的 PyTorch 版本、CUDA 版本、甚至 Python 版本都有可能冲突。把它们放在同一个环境里，最后往往变成“装新模型把旧模型搞坏”。
3.3 简单界面和触控方案
模型跑通之后，你需要一个界面才能像平板一样使用。我不建议一上来就搭很重的应用，先用一个轻量前端解决核心交互。
可选方案有三个：
- Open WebUI：功能齐全，适合 Chat 场景，但依赖较重；
- Gradio：写一个小页面很快，适合原型验证；
- 纯 HTML + JavaScript：启动最快，资源占用最低，适合低功耗设备。
我的选择是优先保证“语音输入、对话回显、图像输出”三个能力可用，所以用了一个纯 HTML 页面加几个本地服务接口。界面不用好看，关键是触控友好：按钮要大，字体要清晰，输入框要能弹出虚拟键盘。
如果你希望它开机就像平板，可以配置窗口管理器开机自启，然后自动打开浏览器进入固定本地地址。这样你按下电源键，看到的不是命令行，而是你的 AI 工作台。
3.4 把四个模型串成一个工作流
模型都跑通、界面也能显示之后，最后一步是把四个模型串起来。这一步才是项目的灵魂。
我写了一个简单的 Python 脚本，流程大致如下：
- 监听语音输入按钮；
- 调用语音识别模型，把录音转换成文本；
- 把文本交给对话模型；
- 对话模型判断是否需要生成图像；
- 如果需要，调用文生图模型生成图片并保存；
- 把文本回复和图片路径展示在界面上。
这里最核心的是设计好“工具调用”逻辑。对话模型不一定要直接输出图片，而是可以输出一个特殊标记，让脚本识别到标记后去调文生图模型。这种解耦方式的好处是，以后你想换更强的画图模型，只需要改调用接口，不需要改对话模型。
实际整合时，可以用一个粗粒度的伪代码来理解：
text = speech_to_text(audio_file) response = chat_model(text) if "生成图片" in response or detect_image_intent(text): prompt = rewrite_for_image(response) image_path = text_to_image(prompt) show_image(image_path) else: show_text(response)做到这一步，你已经不是在“跑模型”了，而是在搭建一个属于自己的 AI 工作环境。这个环境是私有的、离线的、可扩展的。
4. 实际体验：当它成为日常工具之后
4.1 流畅度真的能当平板用吗
先说结论：如果你把它当一台普通平板电脑来刷网页、看高清视频、玩大型手游，它大概率会让你失望。低功耗主机的图形性能、解码能力和消费级旗舰平板相比，差距非常明显。复杂网页滚动起来会有卡顿，在线视频如果涉及高码率和高级硬解，也可能出现发热和掉帧。
但如果你把它定位成“AI 生产力终端”，体验就完全不一样。处理文档、做笔记、看 PDF、进行对话、生成图片、整理 OCR 结果，这些工作负载对图形性能要求并不高，更重要的是系统稳定性和数据是否受控。在这类场景下，它比普通平板更专注，因为我不需要在上面回复消息、刷视频、被各种推送打断。屏幕一亮就是你自己的 AI 工作台，没有广告，没有推荐流，没有账号登录。
所以我的建议是：不要拿消费级平板的体验标准来衡量这类自制设备。它的价值不在娱乐，而在可控。
4.2 离线能力才是最大红利
真正让我觉得这个项目没有白做的，是离线能力带来的底气和数据隐私保护。
出差时我可以在高铁上用它整理材料，完全没有网络也能完成语音转写、对话、OCR 和简单出图。以前用云端笔记时，离线状态下经常只能看不能写，同步还时不时冲突；现在所有数据都在本地，不再依赖服务商的可用性，也不会因为账号过期而被锁在门外。
另一个好处是数据路径完全本地闭环。我说的话、写的文字、生成的图片，都只存在于我自己这块硬盘上。对隐私敏感的人，这个点比任何跑分都重要。你可能不会一开始意识到这一点，等你真正需要处理一些比较敏感的工作内容时，就会发现本地部署的不可替代性。
当然，离线能力的代价是需要自己维护：模型不会自动更新，系统不会自动适配新设备。你需要偶尔手动拉取新模型版本，定期检查磁盘空间。这是一个持续的运维过程，但带来的自主权也远大于云服务。
4.3 踩坑记录：内存、精度、模型路径
项目做下来，我遇到的主要问题集中在三个地方。
第一个是内存不足。低功耗主机容易在同时加载对话模型和图像模型时出现内存耗尽，表现为系统卡顿甚至直接杀掉进程。解决思路是不要同时启动所有模型，或者给系统配置 swap。但 swap 只能缓解，不能替代物理内存。如果你打算长期使用，至少要保证 16GB 内存，否则还是老老实实一次只跑一个模型比较好。
第二个是模型路径和权限问题。很多模型服务默认把缓存写到用户目录下，如果磁盘分区空间太小，模型下载会失败。另外，如果你通过 systemd 启动服务，脚本的工作目录和权限可能和手动启动时不一样，导致找不到模型文件。排查这类问题，必须先看日志，不要猜。通常按“服务运行用户 -> 目录权限 -> 模型文件是否存在 -> 接口能否访问”的顺序检查。
第三个是中文乱码。这个问题和模型无关，更多出在字体和终端编码上。系统如果没有安装中文字体，界面会显示方块；如果文件编码不是 UTF-8，文本处理和程序输出可能会出错。建议在安装系统后立刻装好中文字体，并统一把文件编码设为 UTF-8。
4.4 长期维护和升级路径
自己搭的设备，最大的成本不是硬件，而是维护。模型版本更新、系统安全补丁、库依赖升级，这些都需要你花时间处理。
我一般维护策略是这样的：
- 模型文件分开存放，按版本命名，不覆盖旧模型；
- 每次升级前，先把当前能跑的配置备份一份；
- 升级时逐个模型升级，不要一次性全部更新；
- 升级后跑一遍冒烟测试，确认语音、对话、出图、OCR 四个核心功能都正常；
- 把整套部署步骤写成脚本文档，这样即使系统崩了，也能快速恢复。
这套维护思路才是项目能否长期用下去的关键。模型只是工具，真正决定体验上限的是你的维护体系。
5. 这类项目到底适合谁，不适合谁
5.1 适合谁
如果你符合下面这些特征，这个项目很可能会让你获得超出预期的回报：
- 喜欢自己掌控软硬件，不满足于厂商预设的体验；
- 对数据隐私敏感，不愿意把工作内容和私人语音到处上传；
- 经常出差或处于弱网环境，需要离线也能用的文档处理工具；
- 正在学习模型部署和本地应用开发，想练手：
- 不追求多模态效果的行业顶级水平，更看重可控和可组合。
这类人往往能接受前期折腾，也愿意在后期持续维护。他们的收益不是省了一台平板钱，而是获得了一套完全属于自己、并且能随技术栈升级持续进化的 AI 基础设施。
5.2 不适合谁
反过来，下面这些情况就不太适合：
- 想代替 iPad 或安卓平板用来娱乐和重度使用；
- 完全不接受命令行和排错；
- 希望本地模型效果和云端最大模型一样强；
- 没有耐心维护，只想装一次用一年；
- 预算紧张但不想亲手折腾，更想要“开箱即用”。
如果你的核心诉求是最好用的语音助手、最聪明的云端大模型、最丝滑的娱乐体验，那直接买现成产品才是正确选择。自制设备的价值从来不是和你比参数，而是在另一个维度上给你选择权。
5.3 排查链路：问题出在哪一层
在整个项目里，你几乎一定会遇到问题。我的排查顺序固定如下：
| 层级 | 先确认什么 | 常用手段 |
|---|---|---|
| 现象 | 是报错、卡住、无输出，还是结果不对 | 捕捉完整日志，记录触发条件 |
| 输入 | 音频是否录到、文字是否完整、图片是否清晰 | 直接打印原始输入，查看文件大小和编码 |
| 环境 | 系统版本、依赖版本、用户权限、磁盘空间 | df -h、pip list、systemctl status |
| 参数 | 模型路径、端口、上下文长度、批次数 | 检查配置文件和服务启动参数 |
| 模型边界 | 该模型是否真的支持这个任务，尺寸是否合适 | 回退到官方示例，换更小模型对比 |
这个顺序能覆盖 90% 的问题。不要一上来就怀疑模型效果不好，更不要直接重装系统。大部分问题其实出在输入、路径和环境上。
5.4 值得复用的框架：三问定方案
如果你也想做一个类似的本地 AI 终端，我建议动手前先问自己三个问题：
- 我要解决的核心场景是什么？是语音记录、文档整理、出图还是多模态理解？
- 这个能力必须离线吗？如果网络稳定、隐私要求不高，云端方案更省心；
- 模型选型由什么决定？内存和生成速度是硬约束，效果是软目标，先满足硬约束，再谈效果。
这三个问题决定了你的硬件预算、模型尺寸和部署顺序。如果连场景都没想清楚，就急着买硬件，大概率会陷入反复折腾但始终没有落地价值的循环。
回到这次项目本身，我真正收获的，不是“我拥有一台自制平板电脑”这个概念，而是 AI 能力可以不再依赖云端账号、不再受制于厂商提供 App，而是可以像搭积木一样，按照自己的需求组合成一套私有的服务。语音负责输入，对话负责思考，图像负责表达，视觉负责理解，四者串起来就是一个不依赖外界、完全归自己所有的 AI 工作台。
如果你看完这篇文章也想动手，我的建议是：先不要急着买屏幕和迷你主机。找一台手头闲置的旧笔记本，或者甚至就在你的主力电脑上，先按“语音识别 — 对话模型 — OCR”的最小链路跑通一遍，感受一下本地模型的实际能力是否符合预期，再决定要不要投入硬件成本。毕竟这个项目真正重要的不是那块屏幕，而是数据是否在自己手里，以及你对这套系统是否真正理解。
