Omnimind获数千万元天使+轮：端侧AI的价值不在模型上限，而在持久稳定与持续学习

当大模型厂商仍在比拼千亿参数和榜单得分时，一个更棘手的问题正在端侧浮出水面：如何让一个参数量小了两个数量级的模型，在手机、耳机、录音卡这类资源极度受限的设备上稳定跑通，并且不要一天比一天笨。这不是一个“能不能跑”的问题，而是一个“怎么跑得久、跑得稳”的问题。

主流推理引擎几乎都围绕云端 GPU 集群或桌面级一体机构建。Claude Code 这类 Harness 工具的预设前提更是“你背后是一个足够大的模型”——工具调用、推理引导和重试机制全部按照模型拥有充裕算力和超强泛化能力来设计。当开发者把同样一套工具链搬到端侧 SoC 上，任务直接崩溃。不是模型智能不够，是基础设施根本不认识这个环境。端侧的异构性远比云端复杂：手机与手机之间、手机与 IoT 设备之间，甚至同一品牌不同代际的芯片，在指令集、内存带宽、功耗约束和算子支持上的差异，都意味着同一套推理引擎很难直接复用。每一个终端品类，甚至每一个具体型号，需要的底层适配方案都可能不同。这种碎片化程度在云端几乎不存在，但在端侧却是决定模型能否落地的先决条件。

北京万象智维科技有限公司（品牌 Omnimind）正试图填补这个空白。这家 2025 年成立的端侧 AI 基础设施公司，近日完成了由韶音领投、瀚晖投资、知行资本与宝尔爱迪跟投的新一轮融资。多数报道指向“数千万元”规模，投资界、新浪财经等信源确认了该口径；亿欧则称金额未披露。两种说法并存可能反映了信息释放的阶段性差异，但可以确定的是，加上去年年底星连资本领投的千万元天使轮，Omnimind 一年内已连续完成两轮早期融资。源合与浪潮在本轮中担任财务顾问，但融资的具体资金用途公司未做详细披露。

一个清华博士团队选择押注“持久稳定”，而非“模型上限”

Omnimind 的核心班底来自清华大学泛在智能实验室（THU OmniLab），这张学术标签在端侧计算领域有持续的积累。创始人兼 CEO 王拓为目前仍是清华计算机系在读博士生，他的学生身份意味着这家公司的技术基因从一开始就与学术前沿深度绑定。公司发起人任炬则是该系副教授、长江学者特聘教授，后者在国内学术体系中的重量级身份可能为公司带来两重价值：一是端侧系统方向上的研究积累可以直接转化为工程技术路线图，二是在早期融资和人才招募中提供信用背书。加上来自北大、上海交大以及腾讯、阿里、字节的工程师，团队目前约 30 人，过半负责研发。对于一个需要同时解决推理引擎、Harness 重构和端侧微调三大技术难题的创业公司来说，这种人员结构意味着高研发密度，但也可能是短期内商业化和工程化能力相对紧张的一种反映。

王拓为对端侧 AI 的定位有一段直白的表述：“做端侧 AI，我们并不想过度追求模型智能的上限，而更关注如何让模型在设备上运行得更持久、更稳定、更高效。长期来看，端侧 AI 最大的价值并不只是保护隐私或节省 Token 成本，而是让 AI 真正具备持续学习和长期记忆的能力，最终成为一个真正长期陪伴用户的智能助手。”

这段话隐含着一个判断，这个判断也是理解 Omnimind 整条叙事的关键：当前主流端侧叙事的两大卖点——隐私保护和 Token 成本下降——在王拓为看来只是短期优势。“端侧成本这件事，不会成为大家永久的痛点。”他在接受采访时明确表示。如果成本终将被产业链上卷起的规模效应摊平，那么端侧 AI 的长期护城河只能建立在另一件事上：模型能否在设备上持续学习、累积个人化上下文，从而形成他人无法复制的用户粘性。这个判断本身是合理的，但它同时也给 Omnimind 设定了一条极高的技术门槛——持续学习不是功能点，而是天花板。天花板的高度，直接决定这家公司最终能走多远。

把推理引擎和 Harness 为端侧小模型彻底重写

Omnimind 的技术栈由三层构成：底层的端侧推理引擎 OmniInfer，中间的端侧小模型 Harness 层 OmniClaw，以及面向上层的一站式部署平台 OmniStudio。这种分层架构在软件工程中并不新鲜，但每一层在端侧场景下需要解决的问题都远比云端复杂。

OmniInfer 的切入点很具体。王拓为指出，“端侧的异构性非常复杂，不同品类的终端设备、甚至同一品类不同型号的终端设备，需要的 Infra 都有所不同。”已有的推理引擎要么围绕云端 x86 CPU 和 NVIDIA GPU 构建，要么针对苹果 M 系列这类桌面一体式芯片优化。这些引擎的算子库、内存管理策略和调度逻辑在手机 SoC、IoT 芯片上直接套用会出现严重的兼容性和效率问题——最典型的场景是，一个在高通骁龙 8 Gen 3 上跑通的推理方案，移到了上一代骁龙 8 Gen 2 上可能因为缺少某个指令集优化而导致延迟飙升，更不用说移植到瑞芯微、恒玄这类更边缘的 IoT 芯片上。OmniInfer 的设计目标就是覆盖各类端侧 SoC 品类，成为一个真正的跨芯片底层基座。这意味着它需要在编译层做大量的算子适配和自动代码生成工作，而不是像云端那样依赖少数几种成熟架构。

在 OmniInfer 之上，OmniClaw 承担了更关键的角色。现有的主流 Harness，如 Claude Code，完全围绕云侧大模型构建——它们的核心假设是模型足够大、足够强，因此工具调用、推理引导和重试机制都按这个前提设计。举个具体的例子：当模型在一次工具调用中失败时，Claude Code 会依赖模型自身的泛化能力来调整调用参数或切换策略。但一旦底层模型换成一个端侧小模型，这种高自由度的纠错机制立刻失灵——小模型可能在第一次调用失败后就陷入循环错误，或者直接停止执行。OmniClaw 为小模型重新设计了整套工具接口和智能路由体系：端侧能独立完成的任务在本地执行，复杂任务自动引入云侧模型协同，在保证最终任务完成度与纯云侧方案对齐的同时，最大限度压降 Token 消耗。

这套“端云协同”路由的逻辑，与简单粗暴的“能端侧就端侧”策略有本质区别。它不是静态的开关，而是动态判断任务的复杂度、模型能力边界和当前系统资源状况，再决定执行路径。比如简单的本地文件整理任务完全留在端侧；涉及复杂多步推理的外卖点单可能部分调用云端；而像跨应用打车这种需要同时处理多个 U 界面的任务，可能需要端侧先做实时 U 识别，云端再做决策规划。这种设计也意味着 Omnimind 必须同时理解端侧和云侧两套技术栈，而不仅仅是把云端方案做裁剪——它需要在两个完全不同的计算范式之间建立一个平滑的桥接层。

第三层 OmniStudio 是直接面向 B 端客户的产品形态，适配 Windows、Mac、Linux、iOS 和安卓，落地场景覆盖手机、PC、智能家居、AI 玩具和机器人。从技术栈到产品层的完整覆盖，意味着 Omnimind 不仅想做一个引擎供应商，更想成为端侧 AI 部署的操作系统级入口。但 OmniStudio 目前更像一个集成封装层，其真正的竞争力取决于底层 OmniInfer 和 OmniClaw 在真实异构环境中的表现。

用 1%-2% 的参数量做微调，把持续学习的成本压到推理级别

持续学习能力是 Omnimind 技术叙事中最激进的部分，也是风险最大的假设。如果这一层跑通了，它可能改变端侧 AI 的竞争维度；如果跑不通，Omnimind 的故事大概率要坍缩回“做足适配、降低 Token 成本”的红海竞争。

该公司研发了一套端侧微调算法 OmniTune。其做法是在周期性微调的基础上，将用户白天积累的交互数据用来做大量前向推理，每次只针对性微调一个极小的参数模块，约占 1%-2% 的 LoRA 参数量。公司宣称，这种极小规模微调的效果“能趋近于传统微调”，但每一步的成本仅相当于一次推理。

这意味着什么？传统微调需要把用户数据回传云端、在 GPU 集群上跑完整训练流程，成本高、隐私风险大，且在端侧设备上几乎不可能实时执行。OmniTune 试图把这个过程完全留在设备上：模型和数据都不出端，夜间利用空闲算力完成自学习，把白天的交互内容内化进模型参数。公司计划在每一台 Taste 硬件上部署一个用户独立的 LoRA 模块，随着时间推移，每个用户的模型权重都将演变成一个专属版本。这种“一人一模型”的构想如果实现，理论上会产生极强的迁移壁垒——用户换设备或换品牌时，不仅需要迁移一个模型参数文件，还需要确保目标硬件兼容同样的推理引擎和 LoRA 结构。

从工程角度看，这个方案面临的挑战是多层的。首先，“效果趋近于传统微调”这一说法尚未见第三方评测数据支撑，目前仅有公司口径。其次，1%-2% 的 LoRA 参数量虽然大幅降低了计算开销，但也意味着模型可被调整的容量极为有限——在长期、高频的用户交互累积下，这个极小参数空间是否足以承载复杂且不断变化的个人化信息，仍然是一个开放问题。第三，独立 LoRA 在设备端的存储、管理、跨设备迁移（用户换手机时怎么办）、隐私保护（如何防止 LoRA 权重泄露用户行为特征）同样需要配套基础设施。第四，持续学习的本质是对模型的权重做增量更新，每次微调都可能引入微小的累计偏差，长期来看如何保证模型不出现“灾难性遗忘”或性能退化，是需要经过真实用户场景长期运行才能验证的命题。

这是 Omnimind 整条故事线里最值得长期跟踪的部分。如果跑通了，持续学习确实能形成竞争对手无法复用的数据护城河——每一个用户设备上积累的个人化权重，都是他人无法通过训练一个通用模型来替代的独特资产。如果跑不通，或者效果被证明在边际递减，那么端侧 AI 的差异化最终可能还是要回到成本竞争上——而王拓为自己说过成本不会成为永久的痛点。

从 B 端 NRE+License 切入，同时押注一个名为 Taste 的 C 端硬件

2026 年 5 月，Omnimind 正式启动商业化，走了一条典型的 B 端先行路线。公司披露已签下多个百万级订单，预计全年累计订单额达到千万元级别——客户名称未披露。对于一个约30人的团队来说，这个收入预期在早期阶段是合理的，但无法判断这些订单的实际落地深度。百万级合同可能是针对单款终端的试点部署，也可能是覆盖多产品线的批量授权。客户身份的缺失让外界很难判断 Omnimind 的技术是否已经被真正集成到量产产品中。

B 端商业模式是 NRE（非重复性工程费用）加 License。NRE 覆盖前期针对不同终端厂商的定制开发和适配成本，后续按产品规模收取 License 费。这种模式在半导体 IP 和嵌入式软件领域相当成熟，对于需要深度适配不同 SoC 和操作系统的端侧基础设施来说，也是比较自然的商业路径。但 NRE 本质上是对定制化服务的收费，其边际成本并不会随规模显著下降——每一个新客户、每一款新机型都可能需要投入新的适配工程。Omnimind 的目标是从定制化逐步走向标准化产品，但当前阶段，这种模式在收入结构上仍然倾向于项目制。项目制的天花板在于团队规模：团队约30人，其中超过一半负责研发，即使全部研发人员投入到 NRE 交付中，能同时承接的客户数量也是有限的。

更引人瞩目的变量是 C 端硬件 Taste。根据王拓为的披露，Taste 定位为面向未来个人智能交互的新型终端，形态类似卡片大小、可磁吸在手机背板上，拥有独立 SoC 芯片、麦克风、扬声器、小电子屏和独立电源，带有录音功能。目前已完成首轮样机研发与生产验证，计划明年量产。从形态描述来看，Taste 既不像智能手机那样企图取代主设备，也不像智能耳机那样做单品垂直功能——它的定位更像是一个依附于手机但独立运行的 AI 记忆与交互模块。

为什么做硬件？王拓为给出了两个具体理由：一是手机作为端侧 AI 载体存在硬伤——用户频繁更换手机导致个人上下文难以迁移，不同品牌的生态互相封闭。二是独立硬件可以直接触达消费者，无需受制于操作系统权限。这两个理由指向同一个结论：手机不是端侧 AI 落地的理想容器。这个判断有它的合理性。iOS 和安卓对后台进程、传感器访问和系统级操作的权限管控各不相同且日趋严格，一个第三方的端侧 AI 服务想要在不同品牌的手机上获得统一且完整的系统调用权限，几乎是不可能的。

但独立硬件的商业逻辑需要回答另一个问题：用户是否愿意为 AI 能力额外购买并随身携带一个新设备？Taste 的路径是“依附于手机而非替代手机”——磁吸在手机背板上，降低用户携带的心理门槛。但过去十年，从智能手表到智能戒指，再到 AI Pin 等前两年短暂火热的形态，消费电子领域几乎所有的独立 AI 硬件尝试都面临同一个困境：在手机性能过剩的时代，说服用户为第二设备付费的难度远超预期。这些设备大多解决了“存在”的问题，但没能解决“为什么非买不可”的问题。Omnimind 试图用持续学习能力来突破这个瓶颈——如果 Taste 确实能在使用一个月后比使用第一天更懂用户，那么它就不再是一个静态的功能设备，而是一个随时间增值的个人资产。但这个价值主张需要真实的产品体验来兑现，从样机到量产之间还存在大量的工程和品控挑战。

一位领投方是消费电子厂商，投资逻辑超出财务回报范畴

本轮融资的领投方韶音值得专门审视。韶音自身是骨传导耳机和开放式耳机领域的消费电子厂商。耳机作为当下端侧 AI 落地最积极的品类之一，天然需要端侧推理和低延迟处理能力。一个合理的推测是：韶音对其自有产品线的端侧智能化有切实需求，投资 Omnimind 可以获得优先适配和技术共创的机会。这种产业资本的投资逻辑超出了单纯的财务回报计算——即使 Omnimind 作为独立公司回报率一般，只要其技术能加速韶音自有产品的 AI 能力构建，这笔投资在战略上就是成立的。

同理，跟投方中的宝尔爱迪同样可以放入类似的产业协同逻辑框架中观察。瀚晖投资和知行资本则更接近财务投资机构。加上上一轮的星连资本，Omnimind 的股东结构呈现出“产业资本+财务投资人”的混合形态，这在早期硬件基础设施类项目中并不罕见。产业资本的进入意味着 Omnimind 的技术方向至少在一个垂直领域内得到了产品层面的需求确认，但也可能意味着它未来的技术路线需要在一定程度上服务于产业方的战略需求，这种张力在公司的 B 端业务和 Taste 硬件上可能分别体现。

一个免费 App 做能力验证，但距离规模化仍有距离

2025 年 12 月，Omnimind 推出了首款产品“小万 App”——一个完全免费、在本地运行的 Android Agent，用户安装后即可完成点外卖、打车等跨应用操作。这种跨应用 Agent 能力的实现，意味着 Omnimind 确实在消费级手机的底层操作上取得了一定程度的系统级权限——这对于所有试图在手机上落地端侧 AI 的团队来说都是一个关键关卡。

小万 App 的定位更像一次技术验证而非商业产品。它证明了 Omnimind 有能力在消费级手机上实现系统级 Agent，这个能力对于 Taste 等后续产品的说服力至关重要——如果连在手机上跑一个本地 Agent 都做不到，那么独立硬件上实现更复杂的持续学习就更难令人信服。但免费 App 本身不产生收入，公司也未披露其用户量级或留存数据。从商业化角度看，小万 App 的价值在于为 B 端客户展示技术可行性，而非自建 C 端流量。这种“先做技术 demo 再谈商业化”的路径在基础设施类项目中比较常见，但它的局限性在于，技术 demo 的实验环境和真实量产产品的工程环境往往存在显著差距。

待验证的假设：持续学习能成为护城河吗？

Omnimind 承载着多条尚未闭合的逻辑链。每一项都指向一个核心问题：端侧 AI 的护城河到底是什么？

技术层面，OmniTune 的极微调方案需要在真实用户场景中长期运行才能验证其效果。1%-2% 的 LoRA 参数量究竟能承载多少个人化信息，以及当用户交互数据累积到一定量级后是否需要更大的参数空间来容纳，目前没有公开数据可以回答。同时，持续学习本身就是一个尚未被行业内充分解决的问题——端侧场景下的算力、内存和电池约束会让这个问题的难度再上一个台阶。这种“未经验证的核心能力”本身既是 Omnimind 估值想象力的来源，也是它风险的最大源头。

商业层面，B 端订单虽然已有百万级签约，但客户身份未披露使得外界无法判断订单的实际落地深度——是试点合作还是规模化部署，这两者之间差距巨大。如果订单来自头部手机或 IoT 厂商，意味着 Omnimind 的技术已被量产品牌认可，但同时也可能意味着它将在产品节奏上受制于大厂的开发周期。如果订单来自中小厂商，则可能在营收规模上更受限。千万元级别的全年订单预期对于一个约30人的团队来说足以支撑短期运营，但距离证明产品市场契合度仍有路程。

硬件层面，Taste 从样机到量产不仅是工程挑战，更是商业决策。量产需要供应链管理、库存、渠道和售后体系的搭建——这些能力几乎完全不在一个以算法和引擎为核心的团队原有禀赋之内。Taste 的卡片形态虽然在便携性上有优势，但它对加工精度、无线连接稳定性和电池续航的控制要求可能不低，尤其是当设备需要在夜间自主完成微调计算时。Omnimind 需要证明它能够在消费电子硬件的全链条上与成熟厂商竞争，或者它最终会选择将 Taste 授权给合作伙伴量产，而自己回归基础设施层。后一种路径更符合其 B 端基础设施公司的原始定位，但也会削弱“一人一模型”这个故事中最动人的那部分——直接触达用户并拥有端到端的体验控制权。

创始团队的技术背景毋庸置疑，清华泛在智能实验室在端侧计算领域有持续积累。但从实验室到工程化产品，再到可规模化复制的商业模型，每一步都在穿越不同的筛选器。Omnimind 的叙事试图把端侧 AI 从“省钱工具”重新定义为“长期陪伴的价值载体”——在行业普遍追逐模型参数上限的时刻，这是一个逆向选择。逆向选择的风险在于，在持续学习的价值被验证之前，市场可能已经按照成本逻辑为端侧 AI 完成了定价。剩下的问题是，Omnimind 需要多快跑通这条验证路径，才能在定价逻辑完成锁定之前打开真正的差异化空间。

RecodeX 极客视：端侧 AI 正在走过一条经典的技术落地曲线——从“能不能跑”进入“怎么跑得久”。Omnimind 的 OmniInfer 和 OmniClaw 解决了端侧推理的工程适配问题，这更像是基础设施层面的必要补课。真正让它与众不同的赌注是 OmniTune，一个试图用极小参数量实现持续学习的端侧微调方案。如果它成立，个人 AI 的竞争将从模型能力转向数据积累的不可转移性——每个用户设备上积累的专属权重，将是竞争对手无法用更大参数、更多数据训练出来的独特资产。如果它需要更长时间验证，或者效果被证明随时间递减，那么端侧 AI 在短期内的差异化可能仍然要回到成本结构上——而王拓为自己说过，成本不会是永久的护城河。从样机到量产、从项目制到标准化、从技术 demo 到用户留存，Omnimind 需要跨过的每道坎都在同时检验一个假设：持续学习究竟是不是端侧 AI 的终极答案？我们拭目以待。