最开始触发我想折腾这件事的是一次很普通的出差。我在酒店里打开随身带的平板想查一份资料结果国内数据源没收录国际站点又打不开云端笔记应用因为登录态失效直接把我隔在了自己的笔记外面。更别提那段时间我对“云端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}, timeout60, ) return resp.json()[response]这个阶段的核心目标不是做出一个很酷的界面而是先让对话能力稳定可用。只有当你对着命令行输入文字、能稳定得到回复时才可以进入下一步整合。2.3 图像模型让图形输出回到本地语音和对话解决的是文字世界的问题但一个真正有用的AI终端还应该能处理视觉内容。我这边部署了轻量级的文生图模型用来实现“你说一个概念我帮你生成一张参考图”的工作流。文生图模型在低功耗设备上跑起来会比较吃力我的建议是选择 SD 系列的量化小版本或者社区专门针对集成显卡优化的模型分支。不要试图在这类设备上追求高分辨率多批次生成一次只生成一张 512x512 的图作为灵感草稿或笔记配图完全够用。一个实用技巧是让对话模型和文生图模型联动。比如我对设备说“帮我画一个森林里的木质工作台”语音模型转成文字后对话模型判断用户意图是画图就把这段描述改写成一个更适合出图的英文 prompt然后传给底层画图接口最后返回图片路径。整个过程看起来只发生了一步交互实际上是三个模型各干各的活。如果你想要的只是“能出图”可以先用一个最小 Python 调用验证模型好坏from diffusers import StableDiffusionPipeline pipe StableDiffusionPipeline.from_pretrained( 示例模型路径或HuggingFace ID, local_files_onlyTrue ) 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”的最小链路跑通一遍感受一下本地模型的实际能力是否符合预期再决定要不要投入硬件成本。毕竟这个项目真正重要的不是那块屏幕而是数据是否在自己手里以及你对这套系统是否真正理解。