英伟达开源AI路由器PAIR实测:多机协同推理新突破

英伟达以收购Hugging Face和推出多机AI调度器PAIR为核心,系统布局本地AI赛道。
本文梳理了英伟达围绕「本地AI」的系统性战略:以约130亿美元收购Hugging Face、持续发布开放权重模型并公开训练配方,以及推出开源的个人AI路由器PAIR。PAIR的核心功能是在用户本地局域网内的多台GPU设备之间智能调度推理请求,让AI智能体的并行子任务真正实现并行执行,而非排队等待同一块GPU。它基于Apache 2.0许可证开源,目前支持Ollama与LM Studio,0.1版本已覆盖Windows、Linux与Mac。文章同时指出,PAIR不具备显存池化能力,网络延迟对高速本地推理的影响仍待验证,但其背后折射出英伟达对「多AI加速设备家庭普及」时代的完整战略押注。
英伟达的开源战略布局
过去一周被业内称为「AI大周」——Anthropic发布新模型,OpenAI推出最新版本,无数讨论围绕这些前沿闭源模型展开。但在这些喧嚣之外,一个更值得关注的动向来自英伟达:它正系统性布局「本地AI」赛道。
英伟达在开源领域的态度一向明确。它不仅发布开放权重模型,还同步公开训练论文、训练配方及数据集,让社区能够透明地了解模型构建过程并自主微调。凭借这种策略,英伟达已超越其他企业玩家,成为Hugging Face上贡献仓库数量最多的机构。

更具标志性的是,据消息透露,英伟达以约130亿美元收购了Hugging Face。与许多担忧「收购会损害开源生态」的声音不同,业内观点认为此举反而可能阻挡了其他意图将其封闭化的潜在收购方——因为保持开放本就符合英伟达的核心利益。
本地AI市场的临界点
为什么英伟达如此重视Hugging Face?因为它某种程度上是「本地AI的中枢」,而本地AI正走向大众市场的临界点。
一个清醒的判断是:技术社区并非「大众」,而是超前的早期采用者。真正的大众正逐渐认识到——AI确实能提升日常工作效率,同时在经历社交媒体时代的数据滥用后,他们不愿将所有数据交出去。这两点共同催生了本地AI的巨大市场需求。
数据印证了这一趋势。Hugging Face上开放模型数量相比去年同期增长超过四倍,生成式AI模型整体呈现大幅增长。更关键的是,开源模型追赶闭源模型的速度越来越快:Claude Opus Max在人工分析智能指数上的得分,已被后续发布的Qwen模型超越;视频模型领域,Gemini的表现也被MiniMax后来居上。虽然这些模型仍需相当算力才能本地运行,但「可本地运行」这一事实本身,就是趋势信号。
PAIR:面向多设备时代的AI流量调度器
正是在这样的背景下,英伟达推出了PAIR——Personal AI Router(个人AI路由器)。

英伟达押注的未来场景是:家庭中将出现多台具备GPU或AI加速器的设备。这一预判有现实基础——RTX Spark笔记本即将发布,多家硬件厂商已宣布推出内置RTX的Windows系统。可以预见,未来几年人们升级设备时,机器普遍会配备某种形式的AI加速芯片。PAIR要解决的,正是「当你拥有多台这样的设备时,如何让AI智能体充分利用它们」的问题。
PAIR与Switchyard的本质区别
PAIR常被拿来与Switchyard对比。Switchyard负责在API层面(无论云端还是自托管)根据质量与成本选择最合适的模型,处理的是「可能离开你网络」的决策;而PAIR针对的是你完全掌控的本地硬件,是本地推理的流量调度。
它要解决的核心痛点在于:像Hermes、OpenClaw这类AI智能体之所以强大,是因为主智能体能够把研究、编码等任务委派给并行的子智能体。但如果完全本地运行,这些子智能体往往并非真正并行——它们会排队等待同一块GPU空闲。PAIR的作用,就是把这些子智能体分散到网络中的多台设备上执行。
可以把PAIR理解为「虚拟推理流量调度器」:当它发现1号机忙碌时,就把请求转发给2号机。而智能体对此毫无察觉——它以为自己只是在调用Ollama或LM Studio,请求方式与从前完全一致,PAIR只是在中间默默分配流量。
Switchyard是一类「AI模型路由」中间件的代表,其核心逻辑是在多个模型API之间动态选择最优选项——综合考量响应质量、推理速度和调用成本,对上层应用透明。它通常作为一个兼容OpenAI API格式的代理层运行,支持在OpenAI、Anthropic、本地Ollama等多种后端之间自动切换或负载均衡。与PAIR最本质的区别在于控制边界:Switchyard的决策范围可以跨越本地与云端,而PAIR的设计原则是让推理请求永远留在用户可掌控的本地网络内,不涉及任何第三方云服务,从而在隐私保护层面提供更强的确定性保障。
重要说明:不是显存池化
需要明确的是:PAIR不是显存池化技术,它不会把多台设备合并成一台显存更大的虚拟机器。每个请求仍然只在单台设备上运行。更多节点带来的是更高的并行请求处理能力,而非单个任务的加速,也无法让你加载超大模型。
显存池化(VRAM Pooling)是一种更激进的分布式推理技术,其目标是将多台物理设备的显存在软件层面合并为一个统一的大显存空间,使单个模型的权重可以跨设备分片存储和并行计算。这类技术的代表方案包括基于NVLink的多GPU互联以及部分研究性分布式推理框架。显存池化的优势在于能够运行参数规模超出单卡显存上限的超大模型(如数百亿参数的模型在单张24GB显卡上无法完整加载),但其实现复杂度极高,对网络带宽和延迟要求苛刻,消费级局域网环境下瓶颈明显。PAIR明确放弃了这一方向,选择更务实的请求级调度,以实际可用性换取了架构简洁性。
开源协议与社区共建

PAIR最令人期待的特点在于它采用Apache 2.0许可证的开源项目——任何人都可以fork、修改和定制。目前它仅面向个人网络,但可以设想,交给先进的编码模型,它或许能被改造为支持云端网络。甚至有猜测,未来PAIR与Switchyard可能合并为一体。
目前项目处于0.1版本,开箱支持Windows、Linux与Mac,即便在Mac上运行Ollama也能接入PAIR,并不局限于英伟达GPU。当前仅支持Ollama和LM Studio,但英伟达团队已公开表示欢迎社区贡献。事实上,社区已经提交了支持Anthropic风格API、llama.cpp等的合并请求。正因为采用Apache 2.0许可证,即使英伟达过度限制,社区也可以fork出独立版本——而英伟达选择这一许可证,本身就表明它理解这一点。
Apache 2.0是目前商业友好度最高的主流开源许可证之一。与GPL系列许可证要求衍生作品必须同样开源(即「传染性」条款)不同,Apache 2.0允许任何人在保留原始版权声明的前提下自由使用、修改、分发和商业化,甚至可以将修改后的版本以闭源形式发布。这对企业参与者和个人开发者均具有极大吸引力。英伟达为PAIR选择Apache 2.0,意味着第三方云服务商、竞争对手乃至社区开发者均可在其基础上构建商业产品,无需向英伟达缴纳许可费或开放自身源码。这一选择在法律层面为「社区可以独立fork」提供了保障,也是英伟达向开源社区释放的重要信号。
实测体验与现实表现
从工作原理看,PAIR实际上是接管了Ollama和LM Studio的端口,作为流量调度器,再通过网络把请求导向对应设备上的对应引擎。好处是所有现有应用无需改动端口配置即可继续工作。
实测过程相当直接:安装Mac版后,它立刻识别到本机已安装的Ollama(不过未能识别LM Studio,推测官方目前仅支持较新的Apple芯片)。界面能显示可用显存与内存,也能列出Ollama中已有的模型。

在官方演示中,PAIR能把Qwen模型分配到RTX 5090上,把另一版本的Qwen MoE模型分配到DGX Spark上,甚至也能与Radeon显卡协同——前提是这些模型已加载就绪。
不过实测显示,0.1版本目前不会大幅改变现有工作方式。此前通过Tailscale等工具也能实现类似效果,为不同节点上的子智能体配置专用模型。PAIR最大的挑战在于速度:当本地Qwen模型已经能跑到约300 tokens/秒,批量处理时平均380 tokens/秒时,通过PAIR将推理委派给其他设备,网络与调度带来的延迟是否会影响整体表现,仍需更多测试验证。
本地AI的未来图景
PAIR本身或许还处于早期阶段,但它清晰揭示了英伟达对本地AI未来的思考:从收购Hugging Face、推动开放权重,到布局RTX Spark硬件,再到推出多机推理调度器,这是一条完整的战略链条。
对于已经拥有多台GPU设备的用户,PAIR值得尝试;而对整个开源社区来说,随着更多路由器与调度工具的接入,本地智能体的运行体验有望迎来质的提升。围绕本地AI的竞争,才刚刚开始。
相关推荐

Vercel AI SDK 更新:@ai-sdk/workflow 2.0.29 修复工具结果保留问题
Vercel AI SDK 发布 @ai-sdk/workflow 2.0.29 补丁版本,核心修复工作流在终止、延迟、暂停三种响应状态下 provider 工具执行结果的保留问题,并同步升级 ai@7.0.98 等核心依赖。

Vercel AI SDK 更新:@ai-sdk/xai 4.0.58 批处理与图像生成改进
Vercel AI SDK 发布 @ai-sdk/xai 4.0.58 版本更新,新增批处理图像生成支持,修复批处理请求类型校验及 DeepSeek 推理流问题,并同步升级 provider 相关依赖。

Litelm:给LiteLLM瘦身,轻量级LLM调用网关方案
Litelm 是一个主打轻量化的 LiteLLM 替代方案,去掉冗余功能,保留统一的多模型 LLM 调用接口。本文分析其定位、适用场景与选型权衡。