端侧LLM三大应用场景

可视化演示

展示读未提交、读已提交、可重复读、串行化四种隔离级别下两个并发事务的交互行为，直观对比脏读、不可重复读、幻读问题。

输入法即时响应——小厨的“读心速记台”

小厨最拿手的第一道菜，是读心术。你刚张嘴，还没来得及说出“盐”，他已经把盐罐递到你手上。手机输入法里的端侧LLM就是这么干的：你才敲出“jin tian“几秒，候选栏已经跳出”今天”“今年”“金田”——不是它聪明，而是它一直站在你手指边，等你一个眼神。

把镜头拉远一点，你就能看清输入法的本质矛盾：用户打字是高频打断式交互，每敲一两个字母就盼着候选词。人等待的耐心是按“帧”计算的，一旦超过零点几秒，就会觉得“卡”。云端的LLM当然也能做这个活，但请求要坐一趟“网络电梯”去云端转一圈——这趟电梯本身就要几十到几百毫秒，端侧模型则把电梯拆了。

于是，端侧输入法LLM的技术方案就清晰了：一个轻量模型常驻App进程，用户每输入一个拼音前缀，模型就做一次“下一个词预测”，输出Top-K候选。为了把时间压进预算，工程师用三招：一是免网络传输，省掉往返；二是预计算加速，把常用前缀的编码结果提前算好；三是词级流式预测，只预测接下来一两个词而不是整句。

$$T_{\text{总}}$$为整体预算

小厨为什么能读心？因为他就在你手边，动作快，而且不用跑出厨房去问大厨——端侧推理正是把“跑出去取食材”这一步整个省掉了。这道菜的秘诀不是菜多好，而是“距离产生速度”。

助手多轮对话——小厨的“私房记事本”

小厨的第二道菜，靠的是他的私房记事本。上次你随口说“下周要请客户吃素”，他悄悄记下；今天你问他“晚宴准备什么”，他开口就是“按您上次说的，准备素宴如何？”——这不是读心，这是记事。智能助手要做的，就是这种跨越好几轮的“记得住”。

但小厨的记事本有个硬伤：纸就那么几页。大语言模型的上下文窗口就是这本记事本的页数，它不可能无限长大。你问一句他答一句，历史消息越积越多，记事本总有写满的一天。更麻烦的是，每多记一页，他翻本子的时间就多一分——对应到技术上，prompt越长，编码耗时越长，响应就越慢。

工程师的解决办法是“分层记账”：保留最近几轮完整对话，确保当下的上下文连贯；更早的内容则压缩成摘要，叫“记忆压缩”；同时给每次对话打上任务标签，比如“订餐”“定行程”，让助手知道该翻哪一页。这样，助手既记得住你上周的口味，又不会被泛黄的旧账拖慢速度。

小厨的记事本从不贪多，他只留最近几页写满，旧页都撕下来烧成“摘要灰烬”揣在兜里。聪明的助手也一样：它清醒地知道，记得住该记得的，比什么都记得更专业。

翻译流式低延迟——小厨的“同声传译窗”

第三道菜是压轴戏。宴会上来了位只说英语的客人，他刚开口说“Good morning，各位…”，小厨已经凑到你耳边：“他说早上好，还有各位……”——这就是同声传译：话没说完，译文已经跟上。翻译最怕的是冷场，对方说一句，你愣三秒才听到翻译，整个交谈节奏就断了。

云端翻译也是这个道理：如果请求要飞上云端再飞回来，等译文回来时，对方已经快说到下一句了。端侧LLM做翻译的优势在于“近距离作战”，但光有距离还不够，还要换一种输出方式——流式。传统翻译是“听完整句再译”，像记者会后整理发言稿；流式翻译则是“边听边译”，语音被切成几百毫秒的小片，每来一片就增量刷新一次译文。

技术链路上，端侧翻译耳机通常是：语音分片 → 端侧语音识别（ASR）→ 增量编码 → 流式解码 → 逐片吐出译文。这里有个关键指标叫“尾延迟”：从说话人语音结束，到最后一个字的译文显示出来，这段等待越短，交谈越自然。工程师还会做质量与速度的权衡：允许译文前几版粗糙，随后用增量修正让翻译“越说越准”。

小厨的同传本事不是他语速快，而是他“不等你说完就开始翻”。这种“永远比你快半步”的节奏，才是实时翻译的灵魂：让对话像溪水一样不断流。

资源约束挑战——小厨的“口袋与体力”

小厨再好，也只有一个双肩包——这是端侧LLM逃不掉的宿命。云端大模型可以住在有几十GB显存、有空调机房、有无限电力的“米其林后厨”里；端侧模型却要挤在手机的角落里，和所有App抢内存，靠一块小小的电池过活，还没有风扇给它散热。

先看内存：一个模型要被塞进手机，它占的空间由三块构成——模型参数（权重）、推理过程中的KV缓存（记录已经算过的历史token）、还有每层神经网络的中间激活值。翻译会话持续一小时，KV缓存就像小厨记菜名的便签纸，越攒越厚；助手的多轮对话也一样，聊得越久缓存越肥；输入法则相反，每次任务短小精悍，但极其高频，像小厨一晚上被叫去递调料五百次。

再看算力和功耗：手机处理器（NPU）的算力远不及云端GPU，模型每一层都要精打细算地跑；连续翻译时芯片持续高负荷，发热会让手机降频，速度反而更慢。这三个约束——内存、算力、功耗——构成了端侧LLM的“三角牢笼”，三个场景在里面各有各的苦衷：输入法怕内存碎片、助手怕KV缓存膨胀、翻译怕持续发热降频。工程师的一切技巧，本质上都是在三角牢笼里腾挪。

小厨的背包只有那么大，所以每次出门前他都要做选择题：带多少食材、带几本记事本、带多少冰块（翻译要保鲜）。懂得取舍，才是端侧工程的第一课。

端侧部署优化——小厨的“食材预处理”

为了让小厨的背包装下更多东西，聪明的做法是“预处理”：他每天晚上把肉切成丝、腌入味、分装成小袋，早上直接背上就走。模型部署到端侧前的那一套流程，就是这种预处理——目标只有一个：让模型“恰好装进口袋，还能跑得动”。

第一招是量化压缩。大模型参数默认用32位浮点数存储，像用大行李箱装菜；工程师把它换成8位甚至4位的整数，相当于把每份菜都抽真空压扁，体积立刻缩小到原来的四分之一甚至八分之一。第二招是剪枝，把模型里作用不大的连接“剪掉”，像把用不上的调味料留在家里；第三招是知识蒸馏，让云端的大模型当老师，手把手教一个小模型学会它的本事——小厨的刀工未必有大厨好，但专切那几道菜已经够用。

第四招是KV缓存复用，这是实打实的运行加速：上一轮已经算过的历史token结果缓存下来，下一轮直接调用，不再重复计算。最后一招是框架适配，把模型算子替换成手机NPU认识的方言，就像把菜谱翻译成小厨的母语。四招合并，模型才能从容不迫地在这巴掌大的芯片上“掌勺”。

小厨的菜之所以上得快，不是因为他在厨房里手忙脚乱，而是因为他昨晚已经把一切备妥。聪明的工程是把功夫花在“上场之前”，让每一次推理都轻装上阵。

落地实践指南——小厨的“排班表”

故事的最后，小厨要开一周的菜单了。他得根据场合决定带什么：周一的日常便当要快，周末的西餐晚宴要精，出差的翻译任务要稳。落地端侧LLM也一样，第一步永远是“场景选型”——根据业务对速度、记忆、隐私、离线的真实需求，决定用多大的模型、优化到什么程度。

三场景的选型矩阵大致如下：输入法最看重实时性，延迟预算最紧，但任务独立、无需历史，适合超小模型加预计算；智能助手看重连续性和记忆深度，需要中等模型配合上下文管理和记忆压缩；实时翻译看重持续低延迟和稳定性，需要流式解码和语音识别的协同，对模型要求最高。评测指标也要分场景：输入法看候选词延迟和命中率，助手看多轮任务完成率和上下文一致性，翻译看尾延迟和译文质量。

迭代流程则是“基线→评测→优化→再评测”的循环：先用一个开源小模型做基线，跑通全流程；用评测数据找出瓶颈（是编码慢还是解码慢？是内存超了还是功耗爆了？）；再针对性地量化、蒸馏、改算子；每一轮优化都拿同一套评测集对比，绝不拍脑袋调参。

小厨的排班表从不贪心：他知道自己不是米其林大厨，但选对了场景、备好了菜，照样能让客人竖起大拇指。端侧LLM的落地之道，就是这句朴素的大白话——先想清楚你要什么，再决定怎么优化。

AI 应用场景

Python 演示

import timeimport random  class TinyLLM:    """模拟一个运行在手机上的迷你语言模型"""     def __init__(self, max_hist=4):        self.history = []        self.kv_cache = {}        self.max_hist = max_hist     def _infer(self, prompt, n):        """模拟单次推理，返回按概率排序的候选词列表"""        time.sleep(0.005)  # 模拟端侧推理耗时        words = ["天气", "开会", "吃饭", "翻译"]        random.shuffle(words)        return words[:n]     def suggest(self, prefix, k=3):        """输入法场景: 给定拼音前缀, 返回k个候选词"""        return self._infer("prefix:" + prefix, k)     def chat(self, user_msg):        """助手场景: 拼接历史后生成回复"""        self.history.append("用户:" + user_msg)        prompt = "\n".join(self.history[-self.max_hist:])        reply = self._infer(prompt, 1)[0]        self.history.append("助手:" + reply)        return reply     def translate_chunk(self, speech_chunk):        """翻译场景: 每个语音分片到来时, 增量产出一段译文"""        self.kv_cache[len(self.kv_cache)] = speech_chunk        return "[译] " + speech_chunk + " -> " + self._infer(speech_chunk, 1)[0]  if __name__ == "__main__":    llm = TinyLLM()    t0 = time.time()    print("输入法候选:", llm.suggest("jin tian", 3))    print("助手第一轮:", llm.chat("帮我安排周二的会议"))    print("助手第二轮:", llm.chat("改到周三下午"))    print("翻译输出:", llm.translate_chunk("Good morning"))    print("翻译输出:", llm.translate_chunk("everyone"))    print("总耗时(ms):", round((time.time() - t0) * 1000, 1))

1. time.sleep(0.005) # 模拟端侧推理耗时模拟每一次推理的固定耗时，端侧推理虽然快，但也不是零开销。
2. self.history.append("用户:" + user_msg)助手场景把用户消息写入历史，这就是“记事本”的一行。
3. prompt = "\n".join(self.history[-self.max_hist:])只保留最近几轮，实现上下文窗口的“裁剪”，对应公式中的Trim。
4. reply = self._infer(prompt, 1)[0]从候选词里取最高概率那个作为助手回复。
5. self.kv_cache[len(self.kv_cache)] = speech_chunk翻译场景把每个语音分片存进缓存，模拟KV缓存的持续累积。
6. return "[译] " + speech_chunk + " -> " + ...每来一个语音分片就产出一段译文，这就是“边说边译”的流式结构。

常见误区

面试题