Ollama

> 本地AI引擎完成关键底层架构革新，全面释放苹果自研芯片的神经网络潜能。高达两倍的推理提速与内存调度优化，标志着Mac设备在桌面级大模型开发领域的统治力进一步巩固。

## 神经网络加速 软硬协同实现亚秒级极速响应

本地大模型运行方案Ollama近期发布了震撼开发者圈层的性能更新，正式宣布引入苹果极力推广的机器学习框架MLX。这一极具前瞻性的底层架构重构，彻底打通了软件调度与硬件算力之间的隔阂，为搭载自研芯片的Mac设备带来了立竿见影的性能狂飙。官方评测数据显示，新版本在预填阶段处理用户提示词的速度提升了百分之六十，而在模型产出回复的生成阶段更是实现了夸张的百分之百提速。尤其是针对配备最新自研芯片的机型，通过专门调用的神经加速器模块，本地AI的推理响应几乎达到了即时呈现的极限体验。

![52.png](https://static.downly.cn/images/6e927c7940737e793c57f042e4098fb4.png) <center>图源备注：图片由AI生成</center>

## 突破内存瓶颈 统一架构护航超长上下文对话

除去纯粹的浮点运算速度跃升，本次底层更新还触及了本地大模型运行的核心痛点 内存调度策略的深度重写。通过更精细化地利用统一内存架构，新版软件能够在极端的长时间交互或处理庞大代码库上下文时，依然保持流畅且稳定的内存流转。为了换取毫无顿挫感的丝滑推理表现，官方建议开发者直接在配备32GB以上内存的设备上进行超大规模部署。目前，这一基于新框架加速的预览版本已率先针对主流开源模型进行了专项适配，后续将加速覆盖更广阔的模型生态。

## 闭环开发生态 桌面级AI推理工具的商业进阶

这一技术演进对于高度依赖本地计算算力进行代码生成的极客群体而言，无异于一场效率革命。当本地化运行大语言模型的延迟被极致压缩至亚秒级别，其在代码补全、逻辑排错等日常高频场景下的生产力表现已足以同高昂的云端API服务正面抗衡。通过自研芯片的物理堆叠与专属机器学习框架的软硬件协同，桌面级设备正在构筑一条极深的AI开发护城河，同时也向业界展示了软硬一体化闭环生态带来的统治级红利。

![53.png](https://static.downly.cn/images/88c39867ba576b3880d244fb015a6ff6.png) <center>图源备注：图片由AI生成</center>

性能翻倍 Ollama深度集成苹果MLX框架引爆本地大模型算力



> 导语
> Transformer 架构联合创始人 Ashish Vaswani 领衔的 Essential AI 正式开源了其首款旗舰模型 Rnj-1。这款拥有 80 亿参数的模型向伟大的数学家拉马努金致敬，采用了与主流“后训练”强化学习相反的路线，坚持通过高质量预训练决定智能上限。Rnj-1 在代码生成、STEM 推理及 Agent 智能体能力上表现惊人，特别是在 SWE-bench Verified 测试中取得了同量级模型数量级的领先优势，并以 Apache 2.0 协议完全开源，允许在消费级显卡上运行。



## 逆流而上 回归预训练的本质

在当前 AI 行业普遍痴迷于通过强化学习（RLHF）和后训练（Post-training）来提升模型表现的浪潮中，Essential AI 选择了一条截然不同的“复古”路线。由 Transformer 论文作者 Ashish Vaswani 和 Niki Parmar 创立的这家公司，坚信“预训练决定了智能的天花板”，而后训练仅仅是挖掘已有的潜力。

Rnj-1 就是这一理念的结晶。该模型完全从零开始训练，使用了高达 8.4 万亿 token 的数据集。与盲目堆砌数据不同，研发团队构建了精细的数据分类学，专注于科学、技术、工程、数学（STEM）以及代码数据的混合。这种对预训练质量的极致追求，使得 Rnj-1 在逻辑推理和复杂问题解决上展现出了“原生”的强大能力，而非通过后期微调“模仿”出来的智能。

## 小身材大能量 吊打同级竞品的代码能力

![image.png](https://static.downly.cn/images/2aab691c48fc3e0255519957e206ed38.png)
这里，rnj-1 指的是基础模型，而 rnj-1-instruct 指的是训练后调优的指令模型。
Rnj-1 的核心亮点在于其惊人的代码与推理能力。尽管只有 80 亿参数（8B），它在著名的软件工程基准测试 SWE-bench Verified（bash-only 模式）中取得了 20.8% 的高分。

这一成绩意味着什么？官方数据显示，Rnj-1 在该项测试中的表现比同等规模的其他开源模型高出一个数量级，甚至能够通过 Agent 框架解决现实世界中的 GitHub 问题。除了代码能力，它在数学竞赛（AIME）、科学问答（GPQA）等硬核 STEM 领域也表现出色，证明了其并非“偏科生”，而是具备深层逻辑推理能力的通用模型。
![image.png](https://static.downly.cn/images/8ac38bb18ccee44d3aa503609c51b0f9.png)

## 专为开发者打造 消费级硬件上的 Agent 利器

Essential AI 此次开源显得诚意十足。Rnj-1 及其指令微调版本（Rnj-1-instruct）均采用宽松的 Apache 2.0 许可证，这意味着开发者和企业可以免费商用。

对于广大开发者而言，Rnj-1 的硬件友好性极具吸引力。得益于其 8B 的紧凑体积，经过量化后的模型可以轻松在拥有 16GB 显存的消费级 GPU 甚至高端笔记本电脑上运行。同时，模型支持 32k 的上下文窗口，结合其在函数调用（Tool Use）和 FIM（代码中间填充）方面的优化，使其成为构建本地 AI 编程助手和自主智能体（Autonomous Agents）的理想底座。

## 技术细节揭秘 站在巨人肩膀上的创新

虽然 Rnj-1 的架构借鉴了 Google 的 Gemma 3，但团队进行了关键性的改良。模型采用了全局注意力机制（Global Attention）以及用于长上下文扩展的 YaRN 技术，确保了在处理长文档和复杂代码库时的稳定性。

值得一提的是，在训练过程中，团队使用了 Muon 优化器，显著提升了训练效率。Essential AI 坦诚地表示，Rnj-1 虽然在推理和代码上登峰造极，但由于专注于 STEM 数据，它并不是一个为了“事实检索”而优化的模型，有时甚至会产生幻觉，误认自己的身份。这种“坦诚”反而让社区对其在特定垂直领域的专业性更加充满信心。

## 开源社区的新里程碑

Rnj-1 的发布不仅仅是一个新模型的诞生，更是对“Scaling Law”和模型训练方法论的一次有力探索。它向业界证明，通过科学的数据配比和扎实的预训练，小参数模型依然可以在高难度的推理任务中挑战极限。

对于那些苦于 API 成本高昂、由于隐私问题无法使用闭源模型的开发者来说，Rnj-1 提供了一个强大、开放且可本地部署的全新选择。随着技术报告的即将发布，Rnj-1 有望激发开源社区在 Agent 和代码智能领域的又一轮创新热潮。
注：该模型需要 Ollama 0.13.3，目前处于预发布阶段

Transformer 之父重磅回归：Essential AI 开源 Rnj-1，8B 小模型引爆代码推理革命

> **导语** 本期AI快讯聚焦行业最新动态。本地AI框架llama.cpp迎来多模态革命，或将改变现有竞争格局。办公协作平台ClickUp 4.0与电商巨头Shopify，凭借AI智能体与代理技术，分别在办公和电商领域取得突破性增长。谷歌与亚马逊则将AI的触角伸向太空与音乐两大场景，前者计划构建太空AI超算网络，后者通过AI助手显著提升用户听歌时长。此外，微软与谷歌也分别在AI图像生成和翻译工具上推陈出新，为用户带来更强大、更灵活的AI应用体验。

---

## 本地AI的“iPhone时刻” llama.cpp集成多模态，Ollama面临生存挑战

本地AI部署领域迎来重要变革。知名项目llama.cpp近日完成重大进化，全面集成了多模态能力，这意味着用户可以在个人设备上，直接运行能够理解和处理文本、图像、声音等多种信息的AI模型。这一升级不仅极大地增强了本地AI的实用性，也对Ollama等现有AI工具构成了强大的竞争压力，业界称这可能是一次“降维打击”，预示着本地AI多模态应用的革命已经到来。

![image.png](https://static.downly.cn/images/1ca928fda0a5483b43e71d1508a205c9.png)

图源备注：图片由AI生成

 

## 终结办公软件“全家桶” ClickUp 4.0携双AI智能体登场

一体化办公平台ClickUp发布了其里程碑式的4.0版本。新版本对用户界面进行了彻底重构，并重磅推出了两款全新的AI智能体，深度融入任务管理、文档协作、即时沟通、日历和全局搜索等核心功能。ClickUp 4.0的目标是成为一个“All-in-One”的终极工作操作系统，旨在通过强大的整合能力与AI加持，取代Notion、Slack和Teams等分散的办公工具，让团队协作回归一站式平台。

![image.png](https://static.downly.cn/images/ac5ae44b9227698b541807df48c2d9d1.png)

图源备注：图片由AI生成

 

## 谷歌的太空野心 “太阳捕手计划”欲将AI超算送上天

谷歌公布了一项名为“太阳捕手计划”的宏大构想。该计划旨在通过发射搭载自研TPU（张量处理单元）芯片的卫星，并在太空中利用太阳能为其供电，从而构建一个前所未有的AI超级计算网络。这个部署在太空中的AI基础设施，将把太空探索提升到新的高度，使其成为AI计算的新前沿。这不仅解决了地面能源消耗巨大的问题，也为未来的太空数据处理和AI应用开辟了无限可能。

![image.png](https://static.downly.cn/images/f389794c76ba329eb6abd4a0b9563da2.png)

图源备注：图片由AI生成

 

## Alexa+变身音乐DJ 亚马逊用AI让用户“多听三倍”

亚马逊旗下AI助手Alexa+正式登陆Amazon Music音乐应用，为音乐发现和消费场景带来颠覆性体验。通过全新的AI对话式交互，用户可以更自然、更深入地探索音乐曲库，Alexa+能够精准理解用户意图并推荐歌曲，极大地提升了新歌发现率和推荐收听量。数据显示，AI的加持让用户的听歌时长实现了三倍增长，这标志着亚马逊正利用生成式AI，向Spotify等音乐流媒体巨头的核心腹地发起有力冲击。

![image.png](https://static.downly.cn/images/e04f2095b7a4c850f84650ceb3c9a5ed.png)

图源备注：图片由AI生成

 

## AI代理引爆电商革命 Shopify流量与订单双双飙升

Shopify总裁在其第三季度财报中明确指出，AI是“自互联网诞生以来最大的技术变革”，并宣布公司将全力押注“AI代理商业”。这一战略决策背后，是AI工具带来的惊人回报：相关功能流量激增7倍，通过AI搜索完成的订单量更是飙升了11倍。凭借海量的商家数据与领先的AI技术整合能力，Shopify正在引领电商行业进入一个由AI驱动的智能化新时代。

![image.png](https://static.downly.cn/images/08987f35e28c3439b9b508ae6803e750.png)

图源备注：图片由AI生成

 

## 翻译要快还是要准 谷歌翻译让你“二选一”

为了满足用户在不同场景下的翻译需求，谷歌翻译近日新增了一项实用的模式选择功能。用户现在可以在注重翻译效率和速度的“快速”模式，与追求更高准确度和上下文理解能力的“高级”模式之间自由切换。这一更新让谷歌翻译变得更加灵活和人性化，无论是日常的快速沟通还是专业的文本翻译，用户都能找到最适合的模式。

![image.png](https://static.downly.cn/images/eb94bcd77171dd7b19741de04f8274c9.png)

图源备注：图片由AI生成

 

## 微软亮出“王牌” 自研AI绘画工具MAI-Image-1正式上线

微软正式发布了其首款自研的AI图像生成器MAI-Image-1。这款工具目前已集成在必应搜索和Copilot助手中，用户可以直接体验。据介绍，MAI-Image-1在生成逼真的食物和自然风景方面表现尤为出色，能够处理艺术性的光照效果和照片级的丰富细节。微软表示，该工具未来也将在欧盟市场上线，标志着微软在AIGC（AI生成内容）领域的布局正进一步深化。

![image.png](https://static.downly.cn/images/3b215a396b7e06d853fa53ca4b5a6eb2.png)

图源备注：图片由AI生成

每日AI资讯1105：多模态成本地AI新战场，巨头抢滩AI应用新高地

**作者：** Cascade AI 编程助手

#### 一个“只在我的开发环境”能跑的 Bug

在开发桌面应用时，我们经常会遇到一个经典的窘境：“它在我的电脑上跑得好好的！” 这句话背后，往往隐藏着开发环境（Dev）与生产环境（Release）之间的微妙差异。最近，在开发一款与本地 Ollama 服务交互的 Tauri 应用时，我们就遇到了这样一个棘手的问题：应用在 `tauri dev` 模式下一切正常，但一旦打包成 Windows 的 `.exe` release 版本，所有对本地 Ollama API 的请求都神秘地失败了。

本文由AI根据实际的人机互动Debug调试编写，详细记录我们如何像在经历了几次错误的猜测和关键的思路转折后，最终定位并解决这个由 `Origin` 请求头引发的跨环境网络难题。

#### 迷雾中的初步探索与关键转折

问题初期，我们陷入了迷雾。作为 AI 助手，我的分析首先指向了那些最常见的“嫌疑人”：

* **假设1：Tauri 权限问题。** 我最初坚持认为，问题可能出在 `tauri.conf.json` 的 `allowlist` 配置上，怀疑 release 版本没有被授予足够的 HTTP 请求权限。
* **假设2：Windows 网络限制。** 我猜测可能是 Windows 防火墙、杀毒软件，或是系统本身对 `localhost` 的环回网络连接在 release 模式下进行了限制。

然而，**开发者（也就是您）的敏锐观察和清晰指导，为我们拨开了迷雾，带来了第一次关键的转折。**

您坚定地指出，这些关于网络不通的假设是不成立的，因为**应用中对其他公共 API（非本地服务）的调用在 release 版本中完全正常**。这个信息如同一盏明灯，瞬间照亮了我们的困境。它无可辩驳地证明了：
1. 应用的基本网络功能是完好的。
2. Tauri 的 `allowlist` 配置是正确的，应用确实有权访问网络。

这个关键的反馈，迫使我们放弃了对“网络通不通”的宏观猜测，而转向一个更精确、更深入的问题：**既然网络是通的，那为什么偏偏只有对 `http://localhost:11434` 的请求会失败？**

#### 打造我们的“窃听器” —— debug_server.py

为了回答这个新问题，我们必须亲眼看看 release 应用到底向 Ollama 服务发送了怎样的网络请求。为此，我们编写了一个简单的 Python HTTP 服务器 (`debug_server.py`)。它会伪装成 Ollama 服务，监听在 `11434` 端口，并打印出收到的每一个请求的完整细节，包括请求方法、路径和——最重要的——**请求头（Headers）**。

这个小工具成为了我们破案的关键。

#### 真相大白——Origin 头的幽灵

我们分别在 `dev` 和 `release` 模式下运行应用，并让它们连接到我们的 Python 调试服务器。真相瞬间浮出水面：

**1. Dev 模式下的请求日志：**
```bash
Request: GET /api/version
Headers:
 accept: */*
 host: localhost:11434
 ... (其他一些标准头部)
```
请求非常“干净”，没有任何 `Origin` 头。Ollama 服务认为这是一个常规的、无来源限制的请求，因此正常响应。

**2. Release 模式下的请求日志：**
```bash
Request: GET /api/version
Headers:
 accept: */*
 host: localhost:11434
 origin: https://tauri.localhost <-- 罪魁祸首！
 ... (其他头部)
```
在 release 版本中，请求头里赫然出现了一个 `origin: https://tauri.localhost`！Ollama 服务默认的 CORS（跨源资源共享）策略非常严格，它不认识这个 `origin`，于是直接拒绝了该请求，返回 `403 Forbidden`。

#### 问题根源 - Tauri 的双重面孔

为什么会产生这种差异？这源于 Tauri 在不同模式下的工作原理：

* **`dev` 模式**：Tauri 会启动一个本地开发服务器（通常是 Vite 或 Webpack 的 dev server）来提供你的前端资源。当你的前端代码 `fetch('http://localhost:11434')` 时，这个请求是从一个标准的 Web 环境发出的，对于访问另一个 `localhost` 端口，浏览器通常不会附加 `Origin` 头。
* **`release` 模式**：你的所有前端代码被打包并嵌入到应用的可执行文件中。在 Windows 上，Tauri 使用 WebView2（基于 Microsoft Edge/Chromium）来渲染界面。为了安全，WebView2 会将应用的内容视为来自一个特殊的、受保护的来源，即 `https://tauri.localhost`。因此，当你的应用向外部（即使是 `localhost` 上的另一个端口）发起请求时，WebView2 会严格遵守同源策略，自动附加上 `Origin: https://tauri.localhost` 头。

#### 解决方案 - 从“妥协”到“根治”

**方案一 临时妥协（Workaround）**

最直接的方法是“说服”Ollama 服务信任我们的应用。我们可以通过设置环境变量来启动 Ollama：
```powershell
$env:OLLAMA_ORIGINS="https://tauri.localhost"
ollama serve
```
这告诉 Ollama，来自 `https://tauri.localhost` 的请求是安全的。这个方法能快速解决问题，但缺点是需要用户手动配置环境，不够优雅和健壮。

**方案二 釜底抽薪（The Ultimate Fix）**

最理想的方案是**从根本上避免发送 `Origin` 头**。既然前端（WebView2 环境）无法控制这个行为，那我们就把网络请求的任务交给不受浏览器策略限制的后端——**Rust 核心**。

我们的实施步骤如下：

1. **引入 `reqwest`**：在 `Cargo.toml` 中添加强大的 Rust HTTP 客户端库 `reqwest`。
2. **创建 Tauri 命令**：在 `src-tauri/src/main.rs` 中，我们创建了一个新的异步 Rust 函数 `make_http_request`，并将其注册为 Tauri 命令。这个函数使用 `reqwest` 来发起纯净的 HTTP 请求，它在原生环境中执行，自然不会附加任何 `Origin` 头。
 ```rust
 #[tauri::command]
 async fn make_http_request(url: String) -> Result<serde_json::Value, String> {
 // ... 使用 reqwest 发送请求 ...
 }
 ```
3. **重构前端 API 调用**：我们将前端代码中所有使用 `fetch` 与 Ollama 通信的地方，全部替换为使用 Tauri 的 `invoke` 函数来调用我们新创建的 Rust 命令。
 ```typescript
 // 原来的代码
 // const response = await fetch(`${baseUrl}/api/version`);
 
 // 修改后的代码
 import { invoke } from '@tauri-apps/api/tauri';
 const response = await invoke('make_http_request', { url: `${baseUrl}/api/version` });
 ```

通过这套“移花接木”的操作，我们将所有敏感的网络请求从前端代理到了后端。现在，无论是在 `dev` 还是 `release` 模式下，应用与 Ollama 的通信都变得统一、纯净且可靠。

#### 结论

这次调试经历深刻地揭示了 Tauri 应用在不同环境下的行为差异。`Origin` 头的问题是 Web 技术与原生系统集成时一个常见的“坑”。整个过程也凸显了人机协作的价值：AI 提供了常规检查的思路，而开发者的经验和对项目上下文的深刻理解，则能及时纠正方向，避免在错误的道路上越走越远。

通过使用调试服务器进行细致观察，并利用 Tauri 强大的前后端通信能力，我们不仅解决了问题，还构建了一个更健壮、更可靠的应用架构。希望我们的经验能帮助你，在未来的 Tauri 开发之旅中，少走一些弯路。

"开发正常，打包就炸"——Tauri 开发者必踩坑之 “Origin”引发的"血案"

本地运行Llama和其他大语言模型

搜索结果: Ollama