你有没有用输入法时遇到这样的情况打了一段话下一个词的候选列表里排第一的偏偏不是你想要的那个但你知道那个词一定在后面几位因为你刚才已经用过它了。传统输入法的候选词排序本质上是一套词频统计系统——它记录的是全体用户最常用这个词而不是你在当前这段话里最可能用这个词。两者之间的差距就是语境理解。这个问题不是工程问题而是架构问题。词频表天然无法理解上下文。而大语言模型恰好把语境理解做到了极致。一个有意思的想法#大语言模型在生成文字时做的事情本质上是给定前面的所有文字预测下一个词出现的概率。它把整个上下文都考虑进去了——你说了什么话题用了什么风格前一句用的哪个词这些都影响它的预测结果。那如果我们把这个能力嫁接到输入法里会怎样思路其实很直接用户输入拼音拼音作为一个过滤条件在所有能匹配这个拼音的词里让 LLM 按当前语境打个分分最高的排第一。举个例子你正在写一篇关于编程的文章打了ji这个拼音。传统输入法可能给你「几」「记」「技」「机」因为这几个字词频都很高。但如果 LLM 知道你在聊编程它会给「技」技术更高的权重因为这在编程上下文里更自然。这不是魔法这是语言模型本来就有的能力只是以前没有被用在输入法这个场景。本项目受到 lime 的启发探索一种新的输入法思路利用本地大语言模型的语言理解能力来驱动候选词排序而非依赖传统的 N-gram 统计词库。llm-ime 是什么#llm-ime 是我做的一个实验性项目把上面这个思路实现出来验证它是否真的可行。项目的核心是一个 Node.js 服务加载本地 GGUF 格式的量化模型接收拼音输入返回按语境排序的候选词。配套一个 React 写的 Web Dashboard可以直接在浏览器里打字体验效果顺便看看输入统计和引擎状态。重要说明这是一个实验性项目目前处于 Web 验证阶段。我用 Web 界面来验证引擎逻辑和响应速度是否达标而不是真的打算让你把浏览器当输入法用。如果引擎跑通了下一步才是接入真实的输入法框架比如 RIME或者自己写一个原生前端。用的什么模型#Qwen3-0.6B-IQ4_XS阿里的 0.6B 参数量化版本文件大小约350 MB。选这个模型的理由够小350 MB 完全可以接受不像动辄几十 GB 的大模型让人望而却步够快CPU 推理也能在秒级出结果不会让打字等到怀疑人生够准Qwen3 系列对中文理解做了专门优化候选词的语境匹配效果比你想象的要好模型完全在本地运行不联网没有任何数据上传隐私有保障。技术实现简介#对技术感兴趣的读者简单说说实现思路。整个项目是一个 pnpm monorepo分为三块apps/serverLLM 推理引擎 HTTP API用 Hono 框架提供接口node-llama-cpp 做 GGUF 模型加载和推理apps/webReact 前端TanStack Router Tailwind CSS shadcn/ui支持深色/浅色主题packages/ui共享组件库架构上有几个我觉得还挺有意思的地方端到端类型安全用 Hono RPC 做类型共享服务端定义路由前端用hcAppType()创建客户端请求和响应类型全自动推导不用写任何手动类型定义。防卡顿设计打字这种场景对响应延迟很敏感。LLM 推理天然有延迟如果每个按键都触发一次推理并等待结果打字体验会很差。项目里做了几层处理按键时立即更新输入显示同步无延迟候选词请求经过防抖再发出用 React 的useTransition把候选词更新降为低优先级渲染后端用版本号机制跳过过时的队列请求前端用AbortController取消已发出的旧请求。这几层叠加下来打字基本感觉不到卡。模糊拼音内置声母/韵母模糊匹配z↔zh、c↔ch、s↔sh、an↔ang、en↔eng 这些常见错误都能容忍打快了也不怕。快速上手#如果你想本地跑起来试试步骤很简单。1. 克隆项目git clone https://github.com/Deali-Axy/llm-ime.git cd llm-ime pnpm install2. 下载模型项目提供了一个脚本只下载需要的那个文件350 MB不会拉完整的 20 GB 模型仓库
一个有意思的想法#
你有没有用输入法时遇到这样的情况打了一段话下一个词的候选列表里排第一的偏偏不是你想要的那个但你知道那个词一定在后面几位因为你刚才已经用过它了。传统输入法的候选词排序本质上是一套词频统计系统——它记录的是全体用户最常用这个词而不是你在当前这段话里最可能用这个词。两者之间的差距就是语境理解。这个问题不是工程问题而是架构问题。词频表天然无法理解上下文。而大语言模型恰好把语境理解做到了极致。一个有意思的想法#大语言模型在生成文字时做的事情本质上是给定前面的所有文字预测下一个词出现的概率。它把整个上下文都考虑进去了——你说了什么话题用了什么风格前一句用的哪个词这些都影响它的预测结果。那如果我们把这个能力嫁接到输入法里会怎样思路其实很直接用户输入拼音拼音作为一个过滤条件在所有能匹配这个拼音的词里让 LLM 按当前语境打个分分最高的排第一。举个例子你正在写一篇关于编程的文章打了ji这个拼音。传统输入法可能给你「几」「记」「技」「机」因为这几个字词频都很高。但如果 LLM 知道你在聊编程它会给「技」技术更高的权重因为这在编程上下文里更自然。这不是魔法这是语言模型本来就有的能力只是以前没有被用在输入法这个场景。本项目受到 lime 的启发探索一种新的输入法思路利用本地大语言模型的语言理解能力来驱动候选词排序而非依赖传统的 N-gram 统计词库。llm-ime 是什么#llm-ime 是我做的一个实验性项目把上面这个思路实现出来验证它是否真的可行。项目的核心是一个 Node.js 服务加载本地 GGUF 格式的量化模型接收拼音输入返回按语境排序的候选词。配套一个 React 写的 Web Dashboard可以直接在浏览器里打字体验效果顺便看看输入统计和引擎状态。重要说明这是一个实验性项目目前处于 Web 验证阶段。我用 Web 界面来验证引擎逻辑和响应速度是否达标而不是真的打算让你把浏览器当输入法用。如果引擎跑通了下一步才是接入真实的输入法框架比如 RIME或者自己写一个原生前端。用的什么模型#Qwen3-0.6B-IQ4_XS阿里的 0.6B 参数量化版本文件大小约350 MB。选这个模型的理由够小350 MB 完全可以接受不像动辄几十 GB 的大模型让人望而却步够快CPU 推理也能在秒级出结果不会让打字等到怀疑人生够准Qwen3 系列对中文理解做了专门优化候选词的语境匹配效果比你想象的要好模型完全在本地运行不联网没有任何数据上传隐私有保障。技术实现简介#对技术感兴趣的读者简单说说实现思路。整个项目是一个 pnpm monorepo分为三块apps/serverLLM 推理引擎 HTTP API用 Hono 框架提供接口node-llama-cpp 做 GGUF 模型加载和推理apps/webReact 前端TanStack Router Tailwind CSS shadcn/ui支持深色/浅色主题packages/ui共享组件库架构上有几个我觉得还挺有意思的地方端到端类型安全用 Hono RPC 做类型共享服务端定义路由前端用hcAppType()创建客户端请求和响应类型全自动推导不用写任何手动类型定义。防卡顿设计打字这种场景对响应延迟很敏感。LLM 推理天然有延迟如果每个按键都触发一次推理并等待结果打字体验会很差。项目里做了几层处理按键时立即更新输入显示同步无延迟候选词请求经过防抖再发出用 React 的useTransition把候选词更新降为低优先级渲染后端用版本号机制跳过过时的队列请求前端用AbortController取消已发出的旧请求。这几层叠加下来打字基本感觉不到卡。模糊拼音内置声母/韵母模糊匹配z↔zh、c↔ch、s↔sh、an↔ang、en↔eng 这些常见错误都能容忍打快了也不怕。快速上手#如果你想本地跑起来试试步骤很简单。1. 克隆项目git clone https://github.com/Deali-Axy/llm-ime.git cd llm-ime pnpm install2. 下载模型项目提供了一个脚本只下载需要的那个文件350 MB不会拉完整的 20 GB 模型仓库
