传统输入法的候选词排序本质上是一套词频统计系统——它记录的是全体用户最常用这个词而不是你在当前这段话里最可能用这个词。两者之间的差距就是语境理解。这个问题不是工程问题而是架构问题。词频表天然无法理解上下文。而大语言模型恰好把语境理解做到了极致。一个有意思的想法#大语言模型在生成文字时做的事情本质上是给定前面的所有文字预测下一个词出现的概率。它把整个上下文都考虑进去了——你说了什么话题用了什么风格前一句用的哪个词这些都影响它的预测结果。那如果我们把这个能力嫁接到输入法里会怎样思路其实很直接用户输入拼音拼音作为一个过滤条件在所有能匹配这个拼音的词里让 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 模型仓库pnpm run model:download3. 启动服务# 终端 1后端 pnpm run server:dev # 终端 2前端 pnpm run web:dev打开 http://127.0.0.1:5173 就能在浏览器里打字了。现在的状态和接下来的计划#说实话现在的效果还有不少值得打磨的地方。候选词排序有时候很准有时候会有些奇怪的词冒出来这和模型的 token 粒度、量化精度都有关系。长句联想的效果也不如短词组稳定。这也是为什么我选择先做 Web 验证——在浏览器里可以很直观地看到引擎的表现方便调参和改进逻辑。接下来想做的事引擎层面继续优化候选词评分策略改善长句联想的稳定性前端层面视规划接入 RIME 框架或者直接写一个原生输入法前端让它真正能在日常打字中用起来模型层面探索更适合这个场景的量化方案在速度和准确率之间找更好的平衡点目前这更像是一个思路验证阶段如果你觉得这个方向有意思欢迎一起聊聊或者直接来 GitHub 提 Issue / PR。写在最后#做这个项目的出发点很简单我觉得现在大家在讲 AI 应用时总在讲对话、RAG、Agent但 AI 和更基础的工具的结合比如输入法反而很少有人认真做。拼音输入法这个场景天然适合 LLM——有明确的约束拼音有丰富的上下文你打过的字有即时反馈你选不选这个词。结果出乎意料地不错350 MB 的模型跑出来的效果比我预想的要好。当然离真正好用还有距离但这个方向我觉得值得继续探索。
用本地大模型驱动中文输入法，我做了一个实验性的项目
传统输入法的候选词排序本质上是一套词频统计系统——它记录的是全体用户最常用这个词而不是你在当前这段话里最可能用这个词。两者之间的差距就是语境理解。这个问题不是工程问题而是架构问题。词频表天然无法理解上下文。而大语言模型恰好把语境理解做到了极致。一个有意思的想法#大语言模型在生成文字时做的事情本质上是给定前面的所有文字预测下一个词出现的概率。它把整个上下文都考虑进去了——你说了什么话题用了什么风格前一句用的哪个词这些都影响它的预测结果。那如果我们把这个能力嫁接到输入法里会怎样思路其实很直接用户输入拼音拼音作为一个过滤条件在所有能匹配这个拼音的词里让 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 模型仓库pnpm run model:download3. 启动服务# 终端 1后端 pnpm run server:dev # 终端 2前端 pnpm run web:dev打开 http://127.0.0.1:5173 就能在浏览器里打字了。现在的状态和接下来的计划#说实话现在的效果还有不少值得打磨的地方。候选词排序有时候很准有时候会有些奇怪的词冒出来这和模型的 token 粒度、量化精度都有关系。长句联想的效果也不如短词组稳定。这也是为什么我选择先做 Web 验证——在浏览器里可以很直观地看到引擎的表现方便调参和改进逻辑。接下来想做的事引擎层面继续优化候选词评分策略改善长句联想的稳定性前端层面视规划接入 RIME 框架或者直接写一个原生输入法前端让它真正能在日常打字中用起来模型层面探索更适合这个场景的量化方案在速度和准确率之间找更好的平衡点目前这更像是一个思路验证阶段如果你觉得这个方向有意思欢迎一起聊聊或者直接来 GitHub 提 Issue / PR。写在最后#做这个项目的出发点很简单我觉得现在大家在讲 AI 应用时总在讲对话、RAG、Agent但 AI 和更基础的工具的结合比如输入法反而很少有人认真做。拼音输入法这个场景天然适合 LLM——有明确的约束拼音有丰富的上下文你打过的字有即时反馈你选不选这个词。结果出乎意料地不错350 MB 的模型跑出来的效果比我预想的要好。当然离真正好用还有距离但这个方向我觉得值得继续探索。
