微软新编程模型成本降至四分之一

微软用一轮“提速降价”重做编程模型的性价比

微软在 8 月 11 日发布了 MAI-Code-1.1-Flash，并于今天（2026 年 8 月 12 日）开始推动这款模型进入 GitHub Copilot。新版本的重点不是扩大参数规模，而是在代码能力、生成速度和推理成本三个方向同时优化：Terminal-Bench 2.1 表现提升 22%，.NET 任务表现提升 15%，Token 生成速度提升 25%，完成相同任务所需的 Token 数量减少 25%。

**MAI-Code-1.1-Flash 是微软面向代码生成、终端操作和软件工程工作流优化的低延迟编程模型。**它延续了 MAI-Code-1 系列强调推理效率的路线，主要服务于 GitHub Copilot 这类需要高频调用、持续读写代码和反复执行工具的场景，而不是追求聊天榜单上的全能表现。

更关键的变化来自价格。MAI-Code-1.1-Flash 每 100 万输入 Token 收费 0.20 美元，缓存输入为 0.02 美元，输出为 1.20 美元；上一代 MAI-Code-1-Flash 的对应价格分别为 0.75 美元、0.075 美元和 4.50 美元。按公开价计算，新模型三档单价都降到了旧版的 26.7%，即下降约 73.3%。

新旧版本价格对比：严格说是 26.7%，不是精确的 25%

**Token 定价是模型按照输入、缓存输入和输出文本数量计算使用成本的计费方式。**输入 Token 对应发送给模型的提示词、代码、文件内容和历史上下文，输出 Token 对应模型生成的分析、代码、补丁和工具指令；缓存输入则是被系统重复利用的上下文，通常比普通输入便宜很多。

MAI-Code-1.1-Flash 与上一代的公开价格如下：

| 计费项目 | MAI-Code-1-Flash | MAI-Code-1.1-Flash | 单价降幅 | 约合人民币 | |---|---:|---:|---:|---:| | 每 100 万输入 Token | 0.75 美元 | 0.20 美元 | 73.3% | 约 1.4 元 | | 每 100 万缓存输入 Token | 0.075 美元 | 0.02 美元 | 73.3% | 约 0.14 元 | | 每 100 万输出 Token | 4.50 美元 | 1.20 美元 | 73.3% | 约 8.1 元 |

**微软所说的“成本降至四分之一”更适合被理解为产品层面的近似表述。**从单价看，0.20/0.75、0.02/0.075 和 1.20/4.50 的结果都是 26.7%，而非严格的 25%；换句话说，公开价格约为原版的 4/15，而不是精确的 1/4。两者差距不大，但对于批量运行代码智能体的企业团队，最好按照实际单价而不是宣传口径做预算。

单看单价还低估了这次更新可能带来的总成本下降。微软表示，新模型完成相同任务所需的 Token 数量减少 25%；如果假设输入与输出 Token 都同比减少，并暂时忽略缓存命中率变化，那么单次任务的理论账单约为旧版的 20%，计算方式是 26.7% × 75% ≈ 20%。也就是说，在理想条件下，完成同一项任务的费用可能减少约 80%，而不只是价格表显示的 73.3%。

一个简化案例更容易说明差异。假设某次代码任务需要 10 万输入 Token 和 2 万输出 Token，且不计缓存，旧版费用约为 0.075 + 0.09 = 0.165 美元，新版在 Token 数量不变时约为 0.02 + 0.024 = 0.044 美元；如果新版确实能把总 Token 消耗再减少 25%，理论费用可进一步降至约 0.033 美元。

**实际账单不会总是达到理论上的 80% 降幅。**代码仓库大小、系统提示词、工具返回内容、上下文压缩策略和缓存命中率都会改变输入输出比例，而“完成相同任务减少 25% Token”也不代表每一个任务都固定减少四分之一。对于大型仓库，输入上下文可能占主要成本；对于需要长篇解释或多轮修复的任务，输出 Token 和工具循环次数则更重要。

速度提升 25%，对智能体比对补全更有价值

**Token 生成速度是模型在进入输出阶段后每秒能够生成的 Token 数量。**微软称 MAI-Code-1.1-Flash 的生成速度提升了 25%，这并不等于所有请求的端到端延迟都下降 25%，因为真实等待时间还包括排队、首 Token 延迟、代码检索、终端执行、测试运行和网络传输。

速度提升对代码智能体的价值通常高于对单行补全的价值。传统代码补全往往只生成几十个 Token，用户感知更多取决于首 Token 延迟；智能体任务则可能连续读取文件、制定计划、修改代码、执行测试，再根据错误日志进入下一轮，单个任务会触发多次长输出。每一轮快一点，累计等待时间就会明显缩短。

**生成速度提升与 Token 使用量下降还可能形成叠加效应。**如果一项任务所需输出量减少到旧版的 75%，而单位时间生成能力提升到旧版的 125%，在纯生成阶段且其他条件不变的理想情况下，耗时比例约为 0.75/1.25 = 0.60，即生成阶段可能缩短约 40%。这不是微软公布的端到端延迟数据，但可以解释为什么“少写 25%”和“每秒多写 25%”同时发生时，体感变化可能超过单一指标。

这次升级真正瞄准的是高频、批量和后台运行的工程负载。一个开发者每天偶尔调用几次模型，几美分的差价并不显著；一个团队同时运行代码审查、依赖升级、测试修复、漏洞排查和仓库问答时，Token 成本与执行时间会直接决定这些工作流能否默认开启。

Terminal-Bench 2.1 提升 22%，但还缺一个关键数字

**Terminal-Bench 2.1 是用于评估 AI 智能体在终端环境中完成真实计算机任务能力的基准测试。**它关注的不只是模型会不会写某个函数，还包括模型能否理解任务、调用命令行工具、操作文件、处理报错并最终完成可验证的目标，因此比单轮代码题更接近 Copilot CLI 的实际使用方式。

微软表示，通过 GitHub Copilot CLI 使用 MAI-Code-1.1-Flash 时，该模型在 Terminal-Bench 2.1 上比上一版本提升 22%。这个数字说明升级不只是把旧模型跑得更快，但微软目前披露的是相对提升比例，没有在参考资料中同步给出新旧版本的原始分数。

**“提升 22%”不能直接理解为增加 22 个百分点。**如果旧版得分为 40%，相对提升 22% 对应的新分数是 48.8%，绝对增加 8.8 个百分点；如果旧版得分为 60%，新分数则是 73.2%。缺少原始分数、重复测试方差和失败类型分布时，这项成绩更适合用来确认版本方向，而不足以单独证明它全面超过其他编程模型。

.NET 任务提升 15%则更能体现微软的生态取向。.NET 是微软主导的软件开发平台，广泛用于企业后端、桌面软件、云服务和内部业务系统；一个对 C#、解决方案结构、NuGet 依赖、构建工具以及 Azure 开发习惯更熟悉的模型，对微软现有企业客户会比通用榜单上的小幅领先更有商业价值。

**微软没有在现有信息中充分解释 .NET 测试的任务组成和评分方法。**因此，这个 15%应被视为微软提供的产品测试结果，而不是已经获得第三方复现的通用结论。开发团队仍然需要用自己的仓库进行评估，尤其是包含遗留代码、私有框架、复杂构建脚本和内部规范的项目。

原生视觉补上了从截图到代码的入口

**原生视觉能力是模型直接理解图像内容，并将视觉信息与文本、代码和工具操作结合起来的能力。**MAI-Code-1.1-Flash 新增图像理解后，可以处理界面截图、错误弹窗、架构图、设计稿和监控图表，不再要求用户先手动把图片内容转换成文字。

视觉能力对编程模型最现实的用途不是识图聊天，而是缩短问题描述链路。例如，前端开发者可以提交页面截图，让模型定位间距、颜色或响应式布局问题；运维人员可以提供终端报错截图或监控面板，让模型结合仓库代码排查故障；产品团队也可以把设计稿与现有页面同时交给模型，要求它列出差异并修改组件。

**视觉输入能否真正提高交付质量，取决于模型是否能把“看懂”转化为可靠修改。**识别出按钮位置只是第一步，模型还需要找到对应组件、理解样式系统、避免破坏其他页面并通过测试。MAI-Code-1.1-Flash 的视觉能力提升了输入上限，但不能替代浏览器验证、测试套件和人工代码审查。

Copilot 的 0.25 倍高级请求，比单纯降价更直接

**GitHub Copilot 的高级请求倍率是不同模型调用消耗订阅额度时使用的计量系数。**对于符合条件的年度 Copilot 订阅用户，MAI-Code-1.1-Flash 的高级请求倍率为 0.25 倍，意味着一次对应调用原则上只按四分之一个高级请求单位计量。

0.25 倍倍率会比 Token 单价更直接地影响普通 Copilot 用户。多数开发者不会逐项核算每百万 Token 的输入输出费用，他们更关心每月额度能运行多少次代码任务，以及模型是否会过快耗尽高级请求。低倍率可以让用户更愿意把模型用于日常问答、终端操作和批量修改，而不是只在复杂任务中谨慎启用。

**高级请求倍率与底层 Token 账单不是同一个概念。**一次 Copilot 任务可能包含多轮模型推理、代码检索和工具调用，0.25 倍不应简单理解为所有真实计算资源都只消耗四分之一，也不意味着任何场景下都能固定多运行四倍任务。具体可用额度仍取决于订阅方案、产品规则和任务执行方式。

微软要争的不是榜单第一，而是 Copilot 的默认模型

MAI-Code-1.1-Flash 的产品策略是用“足够好的代码能力”换取更低的单位成本和更高的调用频率。今年 6 月微软首次公布 MAI-Code-1 后，Flash 版本进入 GitHub Copilot，与 OpenAI、Anthropic 等供应商的模型同场竞争；但低价编程模型的竞争很快加速，GLM-5.2、Kimi K3 以及 OpenAI GPT-5.6 Luna 等产品持续压低用户对推理价格和响应速度的预期。

**编程模型的竞争正在从单次答案质量转向单位任务成本。**一次回答写得漂亮，并不代表它适合持续运行；真正进入软件工程流程后，模型需要反复读取上下文、执行工具、修改文件和处理测试失败。模型每轮多消耗一点 Token、每次多等待几秒，放大到数千名开发者和数百万次调用后，都会变成显著的基础设施成本。

| 评估维度 | MAI-Code-1-Flash | MAI-Code-1.1-Flash | 实际意义 | |---|---|---|---| | 输入价格 | 0.75 美元/百万 Token | 0.20 美元/百万 Token | 更适合读取大型仓库上下文 | | 输出价格 | 4.50 美元/百万 Token | 1.20 美元/百万 Token | 降低长补丁与多轮分析成本 | | Token 生成速度 | 基准 | 提升 25% | 缩短长输出等待时间 | | 相同任务 Token 用量 | 基准 | 减少 25% | 减少账单与上下文占用 | | Terminal-Bench 2.1 | 基准 | 提升 22% | 终端智能体任务更强 | | .NET 任务 | 基准 | 提升 15% | 强化微软企业开发生态 | | 视觉能力 | 未强调原生视觉 | 新增原生视觉 | 可处理截图、设计稿与图表 | | Copilot 高级请求倍率 | 更高 | 0.25 倍 | 同等额度可支持更多调用 |

微软最需要 MAI-Code-1.1-Flash 做到的，也不是在所有复杂代码测试上击败旗舰模型，而是成为 Copilot 自动选择机制里成本可控的常用选项。如果一个模型能覆盖大多数仓库问答、简单修复、测试生成和终端操作，只有少数高难任务才切换到昂贵模型，Copilot 的整体毛利和响应速度都会改善。

**这也是微软自研模型的战略价值所在。**微软可以继续在 Copilot 中提供多家模型，让开发者按任务选择，但自有模型能够让它更深入地控制训练方向、服务效率、产品集成与价格结构。对于拥有庞大开发者入口的平台而言，“默认使用哪一个模型”往往比“模型选择器里一共有多少个模型”更重要。

现阶段值得用，但不必急着把高难任务全部迁过去

MAI-Code-1.1-Flash 目前最值得尝试的场景包括高频仓库问答、测试生成、常规重构、批量格式修复、终端命令规划、.NET 项目维护，以及根据截图调整前端界面。这些任务对速度和成本敏感，同时通常有编译器、测试套件或界面验证作为结果约束。

高风险代码任务仍然不适合只凭价格做模型选择。涉及认证、支付、权限、数据库迁移、并发控制和生产基础设施时，团队更应该关注错误率、回归测试通过率和人工审查成本；一个便宜 73.3%的模型，如果需要更多返工或引入隐蔽缺陷，总交付成本仍可能高于更昂贵的模型。

**MAI-Code-1.1-Flash 这次最有说服力的不是某一个跑分，而是价格、速度和 Token 效率同时改善。**公开数据表明，它把三档 Token 单价都降低约 73.3%，同时减少 25%的任务 Token 用量，并把生成速度提高 25%。这组组合拳更符合真实工程系统的需求，也说明编程模型已经进入精细计算“每个完成任务多少钱、需要等多久”的阶段。

微软接下来仍需补充更多可验证信息。包括 Terminal-Bench 2.1 的原始分数、视觉任务评测、不同语言和仓库规模下的结果、端到端延迟分布，以及与 Copilot 内其他可选模型的同条件对比。价格已经足够有竞争力，现在需要证明的是：这款模型节省的不只是 Token，还能稳定节省开发者的时间。

参考来源

• IT之家：微软推出 MAI-Code-1.1-Flash 编程模型——整理了微软新模型的基准提升、Token 效率、Copilot 请求倍率及新旧版本价格。