为什么 Embedding 模型是 RAG 的"地基"

做本地 RAG（检索增强生成）时，大部分人把精力花在 LLM 选型上——7B 还是 13B？量化到 4bit 够不够？但真正决定 RAG 检索质量的，往往是管道入口处的 Embedding 模型。

模型训练完只是一个 FP32 的"大胖子"——一个 8 bit 的比特、32 位浮点权重，参数动不动几 MB。手机、树莓派、边缘盒子内存有限，直接部署往往力不从心。量化就是把这段"高清视频压成 MP4"的过程：用更少的 bit 存权重（INT8 只用 8 bit），换更小的体积和更快的推理，代价是少量精度损失。今天我们用 onnxruntime 走一遍端侧模型 INT8 静态量化的完整套路：导出 → 校准 → 量化 → 移动端推理。

为什么要在端侧跑语音合成

上一篇《端侧语音识别实战》解决了"听懂"，这篇解决"说话"。语音合成（TTS）同样有云端方案解决不了的问题：儿童故事机、导航提示、无障碍朗读、本地语音助手，要么没网，要么把文本上传云端合成既花钱又泄露内容——刚输入的文字、个人笔记、聊天记录都是敏感数据。

为什么 Agent 需要 MCP？

想象你是老板，想雇一个全能的 AI 助手帮你管服务器。问题来了：助手很聪明，但不会开服务器——它看不到你的服务，也没法操作。

MCP（Model Context Protocol）就是给 AI 装上手的标准协议：把本地服务的 API 包装成 AI 能看懂、能调用的工具列表。2025 年 Anthropic 开源后，已经成为 Agent 生态的事实标准。

为什么要在端侧跑语音识别

智能音箱、会议纪要工具、车载语音助手、儿童故事机——这些场景的语音输入都有一个共同痛点：把音频上传云端识别，既慢又贵，还涉及隐私。端侧语音识别（On-Device ASR）把模型直接跑在设备 CPU 上，离线可用、零延迟感、音频不出设备。

手机跑大模型？先别急着说不可能

想象一下：你把 ChatGPT 装进手机里，不联网、不收费、不上传任何数据，它依然能陪你聊天、写文案、改代码——这就是端侧大模型的魅力。

2026 年，这不是科幻。参数 1B-4B 的小模型经过量化后，只需要 几百 MB 内存，在旗舰手机上能跑到 每秒 10-30 个 token（约等于"边想边说的语速"）。

为什么让手机自己"看"

云端识别 API 成熟好用，但三个痛点始终绕不开：隐私——画面要上传到别人服务器；时延——往返一次网络 200-500ms，实时视频流根本扛不住；成本——按次计费，摄像头一直开着就是烧钱。端侧部署把模型塞进手机，推理不出设备，隐私、时延、成本一次解决。这也是智能安防、工业质检、AR 应用的主流做法。

为什么你的 LLM 账单越烧越高

接入大模型三个月，账单比想象中高出一大截。翻日志发现一个扎心的事实：大量请求是重复的。

• 定时任务每天早上用同一份模板汇总数据，prompt 一字不差，却每次全价调用；
• 用户提问"帮我解释下这段代码"和"这段代码什么意思"，语义相同，模型却要重新推理一遍；
• 长 system prompt（几千 token 的角色设定 + 知识库）每次请求都重复计费。

LLM 按 token 计费，重复推理就是纯浪费。本文分享一套实战验证过的三层缓存方案，从上到下依次是：精确缓存 → 语义缓存 → 供应商 Prompt Cache，三层叠加通常能把成本降 50% 以上，顺带把响应延迟从秒级降到毫秒级。

本周新项目（7天内创建）

1. yc-software/qm ⭐ 6,833 [TypeScript] 🆕 2026-07-29 面向工作的多人智能体协作框架（Multiplayer Agent Harness）。

2. bashalarmistalt/decimen-optical-transfer ⭐ 3,564 [TypeScript] 🆕 2026-07-30 （暂无描述）

3. trycompai/crm ⭐ 1,671 [TypeScript] 🆕 2026-07-31 开源、Agent 优先的 CRM 客户关系管理系统。

GIL 终于不再是"标配"

如果你写过 Python 多线程，一定听过这句话：线程是并发的，但不是并行的。罪魁祸首就是 GIL（Global Interpreter Lock，全局解释器锁）——同一时刻只允许一个线程执行 Python 字节码，导致 CPU 密集型任务用多线程毫无加速，只能退而求其次用 multiprocessing 多进程。