PPIO上线MiniMax-M1-80k:全球首个开源大规模混合架构推理模型

PPIO上线MiniMax-M1-80k:全球首个开源大规模混合架构推理模型

今天,PPIO 首发上线 MiniMax-M1,这是全球首个开源大规模混合架构的推理模型。

MiniMax-M1 采用混合专家 (MoE) 架构,并结合闪电注意力机制。该模型总共包含 4560 亿个参数,每个令牌激活了 459 亿个参数。M1 模型原生支持 100 万个令牌的上下文长度,是 DeepSeek R1 上下文大小的 8 倍。同时MiniMax-M1 结合 CISPO 算法与混合注意力设计的高效强化学习训练,在长输入推理与真实软件工程场景中实现了业界领先的性能。

因为相对高效的训练和推理算力使用,该模型可以以业内最低的价格提供 API 服务。PPIO 平台的 MiniMax M1-80k 价格为:输入¥4/百万 tokens,输出 ¥16/百万 tokens,上下文窗口为128k。

快速体验入口:

https://ppio.cn/llm/minimaxai-minimax-m1-80k

第三方平台集成 API:

https://ppio.cn/docs/third-party/overview

API 开发者文档:

https://ppio.cn/docs/model/llm


# 01

在 PPIO 在线体验 MiniMax M1

M1 在面向生产力的复杂场景中能力是开源模型中的最好一档,超过国内的闭源模型,接近海外的最领先模型,同时又有业内最高的性价比。

在 PPIO 官网,输入提示词:

Create an HTML page with a canvas-based animated particle background. The particles should move smoothly and connect when close. Add a central heading text over the canvas。

生成代码的网页效果如下:

M1 有一个显著的优势是支持目前业内最高的 100 万上下文的输入,跟闭源模型里面的 Google Gemini 2.5 Pro 一样,是 DeepSeek R1 的 8 倍,以及业内最长的 8 万tokens 的推理输出。

于是,我们进行了一番测试,直接让 M1 翻译了一份中文版的 M1 的技术报告,点击查看:

https://ppio-cloud.feishu.cn/wiki/SeBiwQQIWiNMGOkrNz7c8I1Hnzf?from=from_copylink


# 02

在第三方平台接入 PPIO API

目前 PPIO 支持在 20+ 主流平台中调用平台模型,具体包括:

  • 通用对话客户端:CherryStudio、Chatbox、LobeChat、Nextchat、ChatHub、
  • 通用 AI 助手:OpenManus、UI-TARS
  • 代码开发工具:Cursor、CLINE
  • 开发/ API 平台:Dify、OneAPI、RAGFlow、FastGPT
  • 生产力套件集成:Word、WPS Office AI,这些是办公软件集成AI功能。
  • 智能翻译工具:沉浸式翻译、欧路词典、流畅阅读、沉浸式导读。
  • 知识管理工具:思源笔记、Obsidian、AnythingLLM

我们以 Cherry Studio 为例接入PPIO API。

(1)获取并保存【 API key 】、【 Base URL 】和【模型名称】

注册并登录 PPIO,然后打开 API 密钥管理页面,点击【创建】按钮,输入自定义密钥名称,生成 API 密钥。

!!!注意:密钥在服务端是加密存储,请在生成时保存好密钥(比如记录在备忘录里);若遗失密钥,可以在控制台上删除并创建一个新的密钥。

然后到模型广场获取模型名和 Base URL,固定地址为:

https://api.ppinfra.com/v3/openai

(2)在 Cherry Studio 中配置 API 密钥

下载并安装 Cherry Studio,官网地址为:

https://cherry-ai.com/download

打开 Cherry Studio,点击设置,选择【PPIO派欧云】,输入官网生成的 API 密钥。

点击【添加】,填入所需模型名称

minimaxai/minimax-m1-80k。

添加后点击【检测】,选择 MiniMax-M1-80k,会显示检测通过。

回到对话窗口,点击@,选择 MiniMax M1 模型后即可使用。


# 03

API 开发者文档

通过 PPIO 的 API 接口,可以将 LLM API 无缝集成到你的应用程序、工作流或聊天机器人。PPIO 提供多语言 SDK(cURL、Python、JavaScript 等)。

以 Python 为例:

主要特点:

  • OpenAI 兼容接口:使用 /v3/openai 统一接口,兼容 openai.ChatCompletion 调用方式。
  • 无需部署模型:无需管理模型权重或基础设施,后端完全托管。
  • 输出方式:支持流式和一次性返回

API 开发者文档:

https://ppio.cn/docs/model/llm


Read more

如何保障AI代码安全运行?深入拆解PPIO沙箱五大Agent实战场景

如何保障AI代码安全运行?深入拆解PPIO沙箱五大Agent实战场景

AI 写出的代码,你敢直接跑在生产环境吗?代码执行失控、用户数据泄露、环境冷启动拖慢体验……这些不是假设,而是每一个 Agent 开发者迟早会踩的坑。PPIO 沙箱是一款专为 Agent 场景设计的新一代运行时基础设施,提供了一个安全隔离的云端沙箱环境来执行 AI 生成的代码。从 Vibe Coding 到自动化测试,五个真实场景告诉你:一个好的沙箱,是 Agent 从 Demo 走向生产的最后一块拼图。 场景一:Vibe Coding Vibe Coding 的核心体验是“生成即运行”——用户希望 Agent 写出代码后立刻看到执行结果,并根据结果继续迭代。但如果每次执行都要拉起一个新的空白环境,依赖重新安装、项目重新初始化,等待时间会严重割裂体验,等待期间计算资源不释放的话也会造成大量的成本浪费。多用户同时使用时,还要保证各自的代码执行环境完全隔离,不能互相干扰。PPIO 沙箱为每个用户提供独立的持久化沙箱。亚秒级冷启动保证环境随时就绪;

By shalina
创建Agent云沙箱,为什么传统容器和云主机不够用?

创建Agent云沙箱,为什么传统容器和云主机不够用?

你用 AI 写出的代码,敢直接跑在生产环境吗? 答案往往是否定的。这就是沙箱(Sandbox)存在的意义——给 AI 安装一个可控的安全围栏,无论 AI 怎么折腾,也始终控制在沙箱的范围内。 过去两年 Agent 的爆发催生了大量的沙箱需求。但问题是,传统的容器、云主机等沙箱创建方案都不是专门为 Agent 任务需求而设计的。能用,但不够好。 在此背景下,PPIO 推出了国内第一个真正为 Agent 量身定制的沙箱,一举满足 Agent 任务对沙箱的安全性、完整性、低成本、开箱即用等专属需求。 PPIO 沙箱为什么能做到?本文从技术角度深入拆解。 1、传统技术方案的三个矛盾 首先看一下 Agent 执行任务的具体需求。Manus 在他们关于沙箱的技术文章里对这件事描述得很直接: “最强大的莫过于一台真正的云电脑——它拥有完整的能力:网络、文件系统、

By shalina
PPIO上线DeepSeek-V4预览版

PPIO上线DeepSeek-V4预览版

今天,PPIO 已上线备受关注的 DeepSeek-V4 新模型。 DeepSeek-V4 预览版包含两个 MoE 模型:DeepSeek-V4-Pro(1.6T 总参数/49B 激活)和 DeepSeek-V4-Flash(284B/13B 激活),均支持 100 万 token 上下文。 DeepSeek-V4 在架构创新和上下文效率上作出了新的突破,在 Agent 能力、世界知识和推理性能上做到了国内与开源领域最强模型。 DeepSeek-V4-Pro 大幅缩小了与顶级闭源模型的差距,Agent 能力优于 Sonnet 4.5,交付质量接近 Opus 4.6 非思考模式,但仍与 Opus 4.6 思考模式存在一定差距。 DeepSeek-V4-Flash 能够提供更加快捷、

By shalina
新品内测|延迟从500ms降至50ms!PPIO Sandbox TURN发布,彻底打通Agent实时交互网络

新品内测|延迟从500ms降至50ms!PPIO Sandbox TURN发布,彻底打通Agent实时交互网络

PPIO Sandbox TURN,打通 Agent Sandbox实时通信通路。 进入 Agent 时代,云沙箱(Sandbox)已成为智能体执行代码、调用工具、操作浏览器的基础设施。然而,当你的 Agent 试图进行音视频处理、远程桌面操作或人机实时协同等“延迟敏感型”任务时,往往会遭遇滑铁卢:画面撕裂、操作迟钝、哪怕在同城也卡成 PPT。不是带宽不够,而是底层的网络协议走错了路。PPIO Sandbox TURN 实时通信服务正式开启内测,专为实时类 Agent 应用优化,一举将端到端延迟从 300-500ms 暴降至 50-100ms。 挑战:沙箱的网络层不是天生为实时交互而设计 标准云沙箱的网络层并非天生为实时交互类请求而设计,很难满足延迟敏感型 Agent 场景的需求。大多数云沙箱的网络架构是为 HTTP 服务场景优化的——流量走 TCP(

By shalina