企业官网建设流程全解析

买平板这件事，最容易被忽略的问题不是屏幕、电池或者处理器，而是：买回来之后，这台设备到底是谁的。你付了钱，买下硬件，可设备里预装的 App、语音助手、云服务、账号体系，每一层都在把数据和能力引向厂商的服务器。所谓“拥有自己的平板电脑”，真正的意思是：把设备上的智能能力，拿回到本地，拿回到自己手里。

这篇文章想聊的不是一次冲动消费，而是一种值得复用的部署思路：用 266 美元级别的预算，在本地组合四个开源 AI 模型，让一台普通平板具备语音输入、OCR 识别、对话回答和图像理解能力。这不是异想天开。随着开源模型生态的成熟，这类任务已经被拆成了几个轻量模型就能完成的工程问题。

如果你也有一台吃灰平板，或者正准备在预算内做一台个人 AI 助手，这篇文章会给你一个可落地的方案。内容会包括：四个模型如何分工、硬件成本怎么取舍、代码怎么写、运行后怎么验证、最容易踩的坑在哪里。我会尽量把概念讲清楚，同时把示例代码放到可以直接复用的程度。

1. 这笔钱真正该花在哪里

266 美元放在平板市场里，属于中低端预算。如果目标只是看视频、刷网页，市面上随便一台新设备都能满足。但一旦把“AI 平板”作为目标，情况就变了。同样是 AI，不同实现方式成本完全不同。若依靠云端 App，你买到的是功能，不是能力；若依靠本地模型，你买到的是可以继续扩展的框架。

本地 AI 模型能解决的问题，正好是普通平板最尴尬的地方：离线失效、订阅昂贵、数据上云、功能封闭。离线语音输入、OCR 扫描、离线翻译、会议记录、图片找重点，这些场景在传统平板上要么需要专门 App，要么需要联网，要么需要按年付费。用开源模型本地部署后，这些能力变成了一组本地服务，可以自己组合、自己调整。代价是你要处理环境依赖、模型量化、资源调度这些问题。

所以第一笔预算不应该全部花在硬件上，还要预留时间成本。模型选型、环境安装、调用调试，都需要时间。这篇文章的立场很明确：与其买一台“看起来智能”但无法定制的平板，不如把 266 美元花在一台基础硬件加四个开源模型上，把它做成真正由你控制的设备。

2. 四个 AI 模型，为什么不是一个大模型

只部署一个多模态大模型，看似最简单，但对低预算设备是最不现实的方案。多模态大模型需要大量内存和算力，而且一旦模型体积过大，在 CPU 设备上延迟会高到不可用。更重要的是，很多平板场景里的输入是语音和图片，不是文本。如果为了偶尔一次 OCR，就常驻一个几十 GB 的多模态模型，预算和功耗都撑不住。

更好的方式是解耦：让专业模型做专业事。语音识别模型负责把声音变成文字，OCR 模型负责把图片里的文字提取出来，视觉语言模型负责理解图像内容，对话模型负责最终生成回答。四个模型各自参数不大，可以按需加载，互相之间用文本传递信息。这是边缘设备上最实用的架构。

下面这个表格可以帮你快速理解四个模型的分工：

为什么是这四个，而不是三个或五个？因为一个完整的“AI 平板助手指令闭环”正好覆盖了输入、提取、理解、生成四个环节。语音和图片是平板最常见的输入方式，OCR 把图片里的文字变成结构化文本，语音模型把声音变成文字，视觉模型负责处理图片中不单纯属于文字的信息，最后的对话模型把所有信息汇总成回答。

只要模型之间传递的是纯文本，组合方式就非常灵活。比如用户拍了一张购物小票，OCR 提取出所有商品，对话模型负责算总价；用户说一句话，ASR 转成文字，对话模型负责回答；用户问照片里是什么，视觉模型先描述，再由对话模型组织成最终回答。这种架构的扩展性，比绑定一个单一模型好得多。

3. 266 美元预算下的两种部署架构

先别急着买设备。266 美元预算下，要决定的是模型跑在哪里。我不推荐具体型号，因为硬件行情变化很快，但判断原则是稳定的。

方案 A：模型全跑在平板上。这条路适合已经有 8GB 以上内存、存储可扩展的安卓或 Linux 平板。优点是随身携带、完全离线；缺点是 CPU 和散热有限，只能跑量化程度较高的小模型，四个模型同时常驻不现实。可以用按需加载的方式，不同任务启动不同模型。

方案 B：平板做交互端，计算交给局域网里的另一台设备。这也是我更推荐的低预算方案。平板只负责拍照、录音、显示；计算设备可以是二手迷你主机、旧笔记本或带 NPU 的开发板。好处是模型性能可以上一个台阶，坏处是多了个设备，便携性下降。

从实际部署的角度看，266 美元总预算要同时承担平板和计算设备会很紧张，所以第一个建议是：先用手头已有的旧设备跑通，再决定要不要加钱买硬件。真正该花钱的地方是内存和存储，而不是 CPU 品牌。八个 GB 内存起步，尽量留出 128GB 存储，这比一块更快的屏幕更重要。模型文件占用空间很大，一个量化后的 7B 模型通常也要 4GB 到 6GB，存储不足会让整个系统频繁报错。

4. 开源模型怎么选：方向比版本重要

开源模型生态变化很快，任何具体版本号都可能过时。下面的选型是思路，不是唯一答案。

语音识别方向，Faster-Whisper 是一个很值得优先试的选项。它有多种大小的模型，tiny、base、small 都适合 CPU 运行，中文识别效果在可控范围内。如果你的场景里中文口音或者专业名词很多，可以试一下 Paraformer 等中文语音识别模型。重点不是选最准的，而是选一个加载时间你能接受的。

OCR 方向，PaddleOCR 在中文场景里效果明显好于 Tesseract。PaddleOCR 的问题是依赖较重，需要安装 PaddlePaddle 框架。如果只是做英文或数字识别，Tesseract 更轻量。但从中文平板使用场景来看，PaddleOCR 更值得投入。

对话生成方向，建议优先看 Ollama 能直接拉取的量化小参数模型。3B 级别是一个比较合理的起点，7B 量化版在 CPU 上会明显变慢。如果你有 MX 系列之类的 GPU，再考虑更大参数。这里不要被“参数越大越聪明”带偏，在低预算设备上，稳定可用比绝对的聪明重要。

多模态图像理解方向，LLaVA 和 Qwen-VL 都是值得关注的方向。但这类模型通常比纯文本模型更吃内存，如果硬件实在紧张，可以先把这一层放一放。四个模型并不是必须同时存在，前期先用“语音 + OCR + 对话”三个模型，也能跑通一半的使用场景。

模型量化是这里最重要的工程手段。简单说，就是把浮点权重压缩成 int8 或 int4，模型体积和内存占用下降，速度提升，准确率会有少量损失。低预算设备上，这个损失是值得的。你在 Ollama 中看到的很多带:3b或:7b标签的模型，本身已经包含了适合本地运行的量化方式。

5. 环境准备与基础安装

下面以一个 Linux 环境为例，Windows 也类似，但包管理器命令不同。建议使用 Python 3.10 以上版本。先把项目目录和虚拟环境建好。

mkdir -p ~/ai-tablet && cd ~/ai-tablet python3 -m venv venv source venv/bin/activate pip install --upgrade pip setuptools wheel

这一步创建虚拟环境很关键。四个模型涉及的 Python 依赖不少，如果不隔离，很容易和系统环境里的库产生冲突。项目目录建好后，安装运行代码所需的依赖。

pip install faster-whisper paddleocr paddlepaddle requests

这里没有写死版本号，是因为 PaddleOCR 和 PaddlePaddle 的版本对应关系经常变化。建议你安装时参考 PaddleOCR 官方文档，确认 Python 版本和系统架构是否匹配。

对话模型部分，我这里选用 Ollama 作为推理服务。Ollama 的价值在于，它把模型下载、量化、启动、HTTP API 集成到了一起，非常适合本地设备。安装命令建议以官方文档为准，下面这种方式通常是可用的。

# 安装并启动 Ollama curl -fsSL https://ollama.com/install.sh | sh ollama serve

执行完上面命令后，Ollama 会监听本机的 11434 端口。另开一个终端，拉取一个适合 CPU 运行的对话模型。

ollama pull qwen2.5:3b curl http://localhost:11434/api/tags

如果curl能返回模型列表，说明 Ollama 服务已经就绪。这个模型就是我们第四个角色里的对话生成模型。语音和 OCR 模型不通过 Ollama 管理，直接在 Python 代码中初始化。

6. 核心流程拆解：从语音和图片到最终回答

整个系统的流程可以拆成六步，这六步就是代码模块的骨架。

第一步，输入采集。平板端拍照、录音或截图，把原始文件保存到本地路径。这一步看起来简单，但要注意文件格式。语音尽量保存为 wav 或 mp3，图片不要太大，超过 2000 像素宽可以先压缩，否则模型推理时间会显著增加。

第二步，格式判断与预处理。代码需要根据输入类型决定走哪条链路。图片交给 OCR，音频交给 ASR，纯文本直接进对话模型。预处理还包括去噪、旋转矫正、统一编码等操作。大部分情况下，PaddleOCR 和 Faster-Whisper 能自动处理常见问题，但输入路径不能有中文乱码。

第三步，感知模型提取文本。OCR 模型从图片中提取文字，ASR 模型从语音中提取文字。这一层输出的不是最终答案，而是中间结果。我们可以把它打印出来，方便判断识别是否准确。

第四步，Prompt 组装。把识别出来的文本和用户问题拼成一个清晰的指令。这里非常影响最终效果。比如 OCR 识别出的内容是一段会议纪要，用户问“总结重点”，Prompt 就要把“这是识别出的文本”和“请总结重点”两件事分开说清楚。

第五步，对话模型推理。把组装好的 Prompt 发送给 Ollama，对话模型生成答案。由于是本地模型，回答速度会受到设备性能影响。3B 模型在 CPU 上通常需要几秒到十几秒，如果超过一分钟，优先检查模型是否选得太大。

第六步，结果输出。把最终回答显示在平板上，或者通过 TTS 模块读出来。如果想做语音助手，这个 TTS 环节可以单独加一个开源语音合成模型，第五个模型就出现了。

这个流程的关键点在于：感知模型只负责把非结构化数据变成文本，对话模型永远接收文本。这让四个模型可以独立替换、独立升级，不用每次改动整条链路。

7. 完整示例：多模型协同代码实现

下面是一个最小可运行的多模型协同示例。项目结构如下：

ai-tablet/ ├── config.py ├── main.py └── services/ ├── __init__.py ├── asr_service.py ├── llm_service.py └── ocr_service.py

先写配置文件config.py，统一保存模型和服务信息。

# 文件路径：config.py OLLAMA_URL = "http://localhost:11434" CHAT_MODEL = "qwen2.5:3b" ASR_MODEL_SIZE = "small" ASR_DEVICE = "cpu" ASR_COMPUTE_TYPE = "int8" OCR_LANG = "ch"

然后是对话模型服务。这里用requests调用 Ollama 的 HTTP API，不依赖额外的 ollama Python 库，逻辑更透明。

# 文件路径：services/llm_service.py import requests from config import OLLAMA_URL, CHAT_MODEL class LLMService: def __init__(self, model=CHAT_MODEL, base_url=OLLAMA_URL): self.model = model self.base_url = base_url def chat(self, user_prompt: str, system_prompt: str = "") -> str: messages = [] if system_prompt: messages.append({"role": "system", "content": system_prompt}) messages.append({"role": "user", "content": user_prompt}) resp = requests.post( f"{self.base_url}/api/chat", json={ "model": self.model, "messages": messages, "stream": False, }, timeout=180, ) resp.raise_for_status() return resp.json()["message"]["content"]

OCR 服务负责从图片中提取文字。不同版本的 PaddleOCR 接口略有差异，下面代码演示的是常见调用方式。如果你安装的是新版，请以官方示例为准。

# 文件路径：services/ocr_service.py from paddleocr import PaddleOCR class OCRService: def __init__(self, lang=OCR_LANG): self.engine = PaddleOCR(use_angle_cls=True, lang=lang) def extract_text(self, image_path: str) -> str: result = self.engine.ocr(image_path, cls=True) lines = [] for block in result: if not block: continue for item in block: lines.append(item[1][0]) return "\n".join(lines)

语音识别服务使用 Faster-Whisper，它在 CPU 上的表现比原版 Whisper 好很多，因为底层使用了 CTranslate2。

# 文件路径：services/asr_service.py from faster_whisper import WhisperModel from config import ASR_MODEL_SIZE, ASR_DEVICE, ASR_COMPUTE_TYPE class ASRService: def __init__(self, model_size=ASR_MODEL_SIZE, device=ASR_DEVICE, compute_type=ASR_COMPUTE_TYPE): self.model = WhisperModel(model_size, device=device, compute_type=compute_type) def transcribe(self, audio_path: str) -> str: segments, _ = self.model.transcribe(audio_path, language="zh") text = "".join(segment.text for segment in segments) return text.strip()

最后是主调度程序main.py。它根据输入类型，分别调用 OCR、ASR 或直接调用 LLM。

# 文件路径：main.py import argparse from services.asr_service import ASRService from services.llm_service import LLMService from services.ocr_service import OCRService def build_prompt(context: str, question: str) -> str: return ( f"下面是从输入内容中提取到的信息：\n{context}\n\n" f"用户问题：{question}\n" "请用简洁的中文回答。" ) def main(): parser = argparse.ArgumentParser(description="本地 AI 平板调度入口") parser.add_argument("--type", choices=["text", "image", "audio"], required=True) parser.add_argument("--path", help="图片或音频路径") parser.add_argument("--content", help="纯文本输入") parser.add_argument("--question", default="请总结上面内容的重点。") args = parser.parse_args() llm = LLMService() if args.type == "text": if not args.content: raise SystemExit("text 类型需要 --content 参数") answer = llm.chat(args.content) elif args.type == "image": if not args.path: raise SystemExit("image 类型需要 --path 参数") ocr = OCRService() extract_text = ocr.extract_text(args.path) print("[OCR] 识别结果：\n", extract_text) answer = llm.chat(build_prompt(extract_text, args.question)) else: if not args.path: raise SystemExit("audio 类型需要 --path 参数") asr = ASRService() transcript = asr.transcribe(args.path) print("[ASR] 转写结果：\n", transcript) answer = llm.chat(build_prompt(transcript, args.question)) print("[LLM] 回答：\n", answer) if __name__ == "__main__": main()

还需要在services目录下创建一个空的__init__.py文件，否则 Python 无法把它识别为包。

touch services/__init__.py

代码不多，但已经覆盖了“语音识别、OCR、对话生成”三个模型的调用流程。多模态图像理解模型，建议在硬件允许后再接入，核心思路也是一样的：把图像转成一段文字描述，再交给 LLM 处理。

8. 运行结果与效果验证

写代码只是第一步，关键还是验证整个链路是否真正跑通。建议按照下面顺序测试，不要一上来就同时测试所有能力。

先做基础对话测试，确认 Ollama 服务正常：

python main.py --type text --content "用一句话解释什么是本地AI模型"

如果接通正常，控制台会输出一段通顺的中文回答。如果这一步失败，先检查 Ollama 是否在运行，curl http://localhost:11434/api/tags是否能返回结果，再检查模型名称是否与config.py中一致。

然后测试 OCR 链路。准备一张包含标题和正文的截图，执行：

python main.py --type image --path ./docs/screenshot.png --question "这张截图里最重要的结论是什么？"

预期输出是：先打印 OCR 识别出的文本，再打印 LLM 根据文本生成的回答。判断标准不是“OCR 是否识别了所有字”，而是关键信息是否出现。如果 OCR 输出空白，优先确认图片路径是否正确，图片中文字是否清晰。

最后测试语音链路。录制一段安静环境下的中文语音，保存为 wav 文件，执行：

python main.py --type audio --path ./docs/question.wav --question "用户刚才在问什么？"

预期是：先打印转写结果，再打印回答。如果转写结果和原语音内容基本一致，说明 ASR 链路正常。如果转写结果乱码或缺失，可以把ASR_MODEL_SIZE从small改成base，或者换一个更安静的录音环境。

我建议准备一个最小回归集：两张图片、两段录音、三个文本问题。每次改完代码，依次跑一遍。这个回归集不用很大，但能帮你快速定位问题是出在模型、代码还是数据上。

9. 常见问题与排查思路

实际部署时，最容易出问题的是依赖环境、模型加载和资源占用。下面这张表整理了高频问题。

以“多模型同时加载导致内存不足”为例，这和本文的架构选择直接相关。四个模型不可能同时都保存在内存里，尤其是一台 8GB 内存的设备。正确做法是，OCR 只在需要识别图片时初始化，ASR 只在处理语音时初始化，LLM 服务常驻，但只占一个模型的内存。如果调用频率高，可以把服务拆成独立进程，各自加载，通过 HTTP 或消息队列通信。这样做的好处是进程退出后内存会释放，不会越积越多。

很多新手在部署时容易犯一个错误：把所有依赖一次性装到一个环境里，然后把四个模型全部初始化，结果系统直接卡死。这不是模型的问题，而是缺少工程层面的资源规划。

10. 最佳实践与工程建议

从“能跑”到“好用”，还有不少距离。下面这几条建议，是我认为低预算本地 AI 项目里最值得注意的。

第一，按需加载和进程隔离。不要把四个模型都放在同一个主进程里。更好的做法是拆成独立服务：OCR 服务、ASR 服务、LLM 服务各自常驻或按需启动，主进程只负责调度。这样单个模型崩溃不会拖垮整个系统，内存也能更精细地控制。

第二，量化优先。CPU 部署时，int8 和 int4 量化是标配。Faster-Whisper 可以直接指定compute_type="int8"，Ollama 拉取的模型通常自带量化标签。不要追求高精度大模型，在低预算设备上速度就是体验。

第三，Prompt 模板要独立管理。把系统提示词、用户问题、OCR 上下文分开保存，最好放在一个模板文件里。后面调参时，不用改代码，直接改模板。比如系统提示词可以写“你是一个运行在本地平板上的助手，只能使用用户提供的信息回答”。

第四，局域网安全不能忽略。如果你的架构是“平板 + 计算设备”，计算设备上的服务不要直接暴露到公网。可以在内网中使用，并在 HTTP 接口层加一个简单的 Token 认证。操作任何服务时遵循最小权限原则，只开放必要的端口。

第五，数据和模型管理。本地模型不自动上传数据，但OCR结果和语音转写文本仍然属于敏感数据。测试时尽量使用脱敏数据，不要拿真实身份证、账单、聊天记录去跑。模型文件比较大，建议定期备份，并记录每个模型的名称、来源和版本，方便以后重建环境。

第六，日志要分层。主程序至少要有三级日志：请求入口、模型调用耗时、错误堆栈。不要只靠print排查问题。写一个简单的日志函数，统一输出到控制台和文件，后续维护会轻松很多。

如果你的目标是长期使用这个“AI 平板”，建议把main.py改造成一个常驻 API 服务。平板端只负责展示界面和上传文件，通过 HTTP 请求访问本地服务。这样界面和模型逻辑完全解耦，之后换平板、换计算设备，都不用重写核心代码。

11. 写在最后：成本之外，更重要的是可控制性

现在回到标题：花了 266 美元和四个 AI 模型，终于拥有了自己的平板电脑。这句话的重点不是 266 美元这个数字，而是“自己的”。本地部署开源模型，意味着你可以决定功能边界，可以离线使用，可以修改代码，也可以在硬件升级时保留软件资产。它当然不适合所有人，也不适合所有任务。但如果你想在预算内搭建一个真正可定制、可离线、可扩展的个人 AI 平板，这套“感知模型 + 对话模型”的分层架构是成本最低的起点。

下一步建议很直接：从一台闲置设备开始，先跑通文本对话，再加语音，再加 OCR。不要一上来就追求四个模型同时在线。模型是手段，稳定可用的工作流才是目标。等你跑通了这个最小系统，就会发现，所谓“拥有自己的平板电脑”，真正值钱的不是硬件，而是你亲手搭起来的这套本地智能管道。