获取下载链全程约 1 分钟

打开微信，搜索「软件教程管家」关注，或长按下方二维码关注
回复关键词 foundry-local
公众号自动回复网盘链接，点击即可保存下载

Foundry Local：微软开源本地AI推理运行时，设备端离线跑聊天与语音转写

打开微信扫一扫关注
或搜索【软件教程管家】

30 秒速读：想在自己的应用里加聊天补全或语音转写，又不想把用户对话发到云端？Foundry Local 是微软开源的本地AI推理运行时，一个约 20MB 的轻量包，模型直接在用户设备上跑：离线可用、不用 API Key、没有按 token 计费，还兼容 OpenAI 接口。本篇讲清楚它适合谁、SDK 与 CLI 该怎么选、装完必须改的 4 个配置，以及它不适合的场景。

Foundry Local 软件信息表

软件名称	Foundry Local
开发方	微软（Microsoft）
开源协议	SDK 为 MIT 协议；CLI 遵循微软软件许可条款；各模型另有自己的许可
适用平台	Windows、macOS（Apple Silicon）、Linux
运行方式	设备端本地推理，支持离线运行
开发语言	SDK 支持 C、C++、C#、JavaScript、Python、Rust
模型类型	聊天补全（GPT OSS、Qwen、DeepSeek、Mistral、Phi 等）与 Whisper 语音转写
CLI 版本	公开预览版 0.11.0（发稿时数据，具体以 GitHub Releases 页为准）

版本选择：SDK 集成、CLI 体验与本地服务器怎么选

结论先行：只是想先试试效果，用 CLI；要把它做到自己的产品里，用 SDK；多个进程或工具要共享同一个本地模型，再考虑本地服务器。三者不是三个版本，而是同一套运行时的三种用法。

用法	适合谁	上手成本	推荐度
CLI 命令行	想快速验证某个模型在本地跑起来的效果	最低，下载对应平台的包即可	体验首选
SDK 集成	要把聊天或转写做到自己应用里的开发者	中等，按语言装对应的 SDK 包	做产品首选
本地服务器	多进程共享模型，或用 LangChain 等工具走 REST 调用	较高，需管理进程与端口	按需使用

新手容易踩的坑是反过来：先搭服务器再去试模型。官方文档也明确说，核心是进程内 SDK，服务器只是给开发流程准备的可选项，多数嵌入式场景不需要它。

Foundry Local 安装步骤

下面以最快的两条路写，任选其一即可，全部命令均来自官方 README。

路线一：CLI 五分钟体验

打开 GitHub Releases 页，找到 cli-preview-0.11.0，下载自己平台对应的包并解压。
运行一个模型：foundry run qwen2.5-0.5b，首次运行会自动下载模型文件，需要联网。
查看本地可用模型：foundry model list，确认目录里有哪些聊天与转写模型。
在命令行里直接对话，确认响应速度与效果符合预期，再决定要不要往应用里集成。

路线二：Python SDK 集成

安装 SDK：pip install foundry-local-sdk（JavaScript 则是 npm install foundry-local-sdk）。
初始化管理器并选模型，例如 qwen2.5-0.5b，调用下载与加载接口。
创建聊天客户端并发送消息，拿到返回后按需卸载模型释放资源。
语音转写同理：选 whisper-tiny 这类 Whisper 模型，创建音频客户端后传入音频文件即可得到转写文本。

本地AI推理装完必改的 4 个设置

下面 4 项是官方文档明确提到、但新手最容易跳过的配置，装完先过一遍：

模型版本固定还是跟随更新：模型目录支持版本固定或自动更新。做产品时建议在配置里写死模型版本号，避免模型静默升级后回答风格或效果变化；自己体验时可以放开跟随更新。
硬件执行提供程序：运行时会自动检测 NPU、GPU 或 CPU 并选最优路径。目标设备如果是核显本或无独显机器，先确认该设备上实际走的是哪条路径，性能不达标时再手动指定，不要默认“自动一定最快”。
本地服务器端口与生命周期：启用可选本地服务器时，端口与进程启停要自己管。只在确实有多进程共享需求时才开，单应用场景用进程内 SDK 即可，少一个常驻进程就少一份运维负担。
隐私数据收集配置：README 明确提到，Foundry Local 可能收集使用数据并发送给微软。隐私要求高的场景，上线前先读隐私声明并确认相关配置，不要等用户问起才处理。

注意事项：先看完这 6 条再决定上不上

首次运行必须联网下载模型。模型在首次使用时下载并缓存到本地，之后才能离线跑。所谓“完全离线”指的是推理阶段离线，首次启动流程要在应用里规划好模型预置或下载策略。
模型目录是精选过的，不是全量模型库。官方明确说，目录只收经过端侧优化与硬件测试的模型，不追求大而全。选型前先查目标模型在不在目录里，不在就别硬套。
硬件决定体验上限。自动加速依赖设备实际的 NPU、GPU 或 CPU 能力，不同机器上同一模型的速度与可用范围可能差很多，务必在目标设备上实测，不要只看开发机的数据。
不适合当服务器推理栈。官方 FAQ 写得很直接：它是为单用户端侧设备优化的，不做多用户并发排队、连续批处理与 GPU 共享。多并发服务请用 vLLM 或 Triton 这类服务器推理框架。
推理取消是协作式的。官方说明低层请求可以取消，但取消要到当前生成步骤完成才生效，且没有内置超时。长生成任务要自己在应用层加超时与取消逻辑。
各模型许可另算。SDK 是 MIT 协议，但目录里的每个模型都有自己的许可与使用限制，商用或再分发前先看对应模型的说明页。

适用人群与同类方案分工

适合谁：需要在用户设备本地跑聊天补全或语音转写的应用开发者，尤其适合已有 OpenAI SDK 调用习惯的团队——把请求地址指向本地端点，改造成本很低；也适合对离线、延迟和按量计费敏感的桌面端或端侧应用。

不适合谁：需要集中式多用户服务的团队、需要跑目录外大模型的场景、以及对隐私数据出境零容忍又没时间审配置的项目，这三类先别选它。

与同类方案的分工：Ollama 更适合个人在本地快速跑模型、做实验；llama.cpp 更适合想自己抠性能与部署细节的开发者；Foundry Local 的差异点是“为放进别人的应用而设计”——约 20MB 的运行时、多语言 SDK、模型版本管理与 OpenAI 兼容接口，目标是让终端应用直接带上端侧 AI 能力，而不是再搭一个聊天工具。