1. 把10月29日权重公开与此前预览分开
Mistral在10月29日公开了改进版Large 4权重；此前10月6日上线的是公开预览。正式公告说明，期间继续进行了强化学习，并调整了推理行为。这是两个不同的发布阶段：更早可以调用预览API，不代表同一权重版本当时已经开放下载。评估时应分别记录发布日期、资料读取时间和实际测试的产物。
当前API模型卡仍标注Public Preview。公开权重本身不会把每一种托管服务升级为正式可用，也不构成可用性承诺。同样，持续变化的API别名、模型最初发布日期和具体下载修订版是不同对象。资产清单应把它们分别保存，不能让一个日期替代所有版本信息。
本文的工程问题是：组织获得自行运行模型的能力后，多了哪些选择，又需要自行承担哪些运行工作。下面区分官方已说明的能力与我们建议的设计和验收标准。我们没有下载权重、租用加速器、调用付费模型或在生产任务上测量该版本；供应商基准仍是供应商报告，不能当成本站的验收结果。
本节来源： Mistral：10 月 29 日改进版 Large 4 权重公开公告 · Mistral 当前 API 模型卡与预览状态
2. 选择交付方式之前，先读许可证原文
该版本使用Mistral Ecosystem Open-Weight License，是修改版MIT许可证。原文在条件约束下授予广泛的使用、修改和分发权利，同时要求保留版权与许可声明。只写“MIT”或“无限制开源”，会遗漏团队决定如何对外提供产品之前必须知道的信息。
其中有区别性的条件，涉及经营Model-as-a-Service业务的被许可人或其关联方。在这种情形下，条文要求商用前另行取得商业许可。定义涵盖向第三方提供推理或后训练访问，并让第三方对输入、参数或训练数据具有实质控制的服务。仅凭一个产品名称或营销描述，不能判断这项条件是否适用。
定义中排除了只在特定功能或编排框架内嵌入模型能力的终端产品，以及单纯转发给其他方托管模型的服务。另一条款又把不向第三方开放模型的内部使用，以及通过Mistral官方产品访问的使用，排除在该项条件之外。这些限定与许可限制标题同样重要，不能只转述限制而丢掉例外。
部署审查应保存实际许可证文件和修订版，写清谁运行模型、谁能访问，以及访问者可以控制什么。在商业上线前，对不确定安排向权利人确认适用性。这里是对已发布条文边界的解释，不是对某个具体应用符合例外条件的法律认定。
3. 按全权重计算内存，不按活跃参数计算
官方卡片将总参数描述为约1万亿，API卡进一步写为1.05T。权重卡还区分了每Token约490亿活跃参数，以及把嵌入和输出层计入后约520亿的口径。这是混合专家模型：活跃参数描述计算路径，不承诺整个服务只需在内存里提供这些参数。
第一步估算可以把总参数乘以每个权重的理想字节数。表格特意采用取整的1T参数、十进制容量，不加任何开销。这只是透明的算术示例，不是在给出最低加速器数量，不证明任意量化版本都受支持，也不预测现有硬件的吞吐量。
实际容量还包括量化缩放与元数据、未量化组件、运行时缓冲、通信工作区、复制及注意力状态。官方权重卡另外提供面向Blackwell的NVFP4版本；它是特定产物与硬件路径，不是任意四比特转换都保持质量、适用所有设备的证据。应该评估自己真正准备运行的格式。
| 理想表示 | 取整1T参数的算术 | 未包含的要求 |
|---|---|---|
| 16比特／2字节 | 约2TB权重 | 运行时、KV缓存、元数据、复制 |
| 8比特／1字节 | 约1TB权重 | 相同的额外要求 |
| 4比特／0.5字节 | 约0.5TB权重 | 打包与缩放、不支持量化的层及全部运行开销 |
4. 1M上下文与并发是两道不同的容量题
文档中的1M Token上下文是模型上限，不是每种服务配置都能以有用并发处理该长度的承诺。一个短请求与大量长请求，对系统提出不同要求。容量规划必须写出实际提示长度分布、输出预算、同时运行任务数，以及可以接受的排队延迟。
测量时应拆开提示准备、预填充、首Token延迟、生成和等待工具的时间。等待仓库调查的用户体验的是整条链路。只在预填充后测出的漂亮生成速度，无法说明大文档多久开始回答，也无法说明繁忙服务怎样处理第二个请求。
官方服务说明建议，在内存不足时降低上下文长度或并发。我们建议用短、典型和长输入，配合逐级增加的并发建立矩阵，记录内存、延迟分位数、失败及任务质量。在资源耗尽前定义拒绝或排队行为，不要先接受所有请求，再依赖重试收拾容量问题。
裁剪上下文也是产品决策。应保留任务所需指令、相关证据与历史工具结果，并比较裁剪后的输出。更大上下文可能增加覆盖，也增加成本，并带入无关或恶意材料。达到长度上限或命中缓存，都不保证回答使用了正确证据；这仍需要独立检查。
本节来源： Mistral 官方权重卡：架构、推理和服务说明
5. 函数调用是动作提议，不是业务执行结果
Mistral说明模型支持函数调用和结构化输出，服务示例还将工具调用解析器与推理解析器分开。前者要保留函数名称、参数与标识符，后者要把推理内容和面向用户的内容放入正确通道。端点接受熟悉的请求格式，并不能证明这两条路径已经解析正确。
先从无害的只读工具样例开始：有效调用能否解析、错误参数是否明确失败、结果是否匹配正确调用，以及模型能否在工具报错后继续。如果应用允许并行或重复调用，也应覆盖这些情况。原始诊断轨迹需要访问控制，因为提示与工具结果可能包含保密数据。
应用应验证参数，确定当前用户与租户，检查权限，再执行操作并返回明确结果。不能让模型生成的账号标识拥有跨租户访问权。模型写出“成功”一句话，也不能证明数据库已经写入、支付完成或部署发生；这些操作必须以相应系统的结果为依据。
启用不可逆动作前，要明确所需审批和独立回执。工具名称与JSON Schema是接口契约，不是授权。这些是我们提出的集成要求，不代表模型自动提供。只读检索、拟议变更的预览和最终提交动作，应使用不同状态并分别记录，避免把草案当成实际外部结果。
6. 先固定权重版本与推理档位，再比较结果
改进模型的文档列出low、medium和high三档推理，high默认；low取代此前的none档。模型标签没变，不代表延迟、Token使用和行为等价。应把支持的推理档，与权重版本、分词器、模板、推理引擎版本及解析器配置一起明确记录。
不要同时改动多个变量后才判断收益。先建立固定评估集与一致验收规则，再比较日常修改、含糊请求、长证据和工具失败等场景。一次成功尝试更便宜当然有价值，但快速生成后反复修复，可能消耗更多总资源。模型选择应以完整工作流为对象。
升级测试期间保留此前可用的产物，并保存产生每项结果的配置，使回归能够复现。供应商在某个基准上的提升，是值得调查的信号，不是某种语言、仓库或内部政策任务必然同比改善的保证。本文没有复现公告中的基准，也不把其分数转换为客户通过率。
本节来源： Mistral：10 月 29 日改进版 Large 4 权重公开公告 · Mistral 官方权重卡：架构、推理和服务说明
7. Gemini API CLI说明客户端状态与服务端存储是两回事
Google于10月27日发布gemini-api测试版客户端。它面向Shell调用，与交互式Gemini CLI不同，可以在另一个编码代理内部运行。文档列出显式交互ID、后台任务、结构化输出及落地为本地文件的媒体结果。这些是集成方式，不会把可执行程序直接变成完整的编码代理运行时。
CLI所说的无状态，是命令不保留隐藏的本地工作流状态。历史交互ID、已上传文件URI或后台任务ID，让继续执行变得显式。调用方仍要持久化这些标识，并决定进程重启后由谁接管任务。输出文件路径可以避免二进制塞进代理上下文，但不代表远端请求从未包含那些内容。
Google还从10月26日起，调整新付费项目的Generate Content默认存储行为；旧项目保留原设置。请求级store覆盖项目默认，Interactions存储支持服务端历史。因此，无状态客户端与服务端已保存交互可以同时存在。应该检查当前日志政策和实际项目，而不是复制历史默认值。
测试版指南建议固定版本，因为小版本也可能破坏兼容。客户端支持HTTP、SSE和轮询，不支持双向WebSocket；实时交互应使用对应文档中的独立接口。本文未执行任何CLI命令或API示例，此处比较的是状态归属和传输边界，不是说所有Gemini能力都在本周首次上线。
本节来源： Google：Gemini API 更新记录 · Google：Gemini API CLI 的状态、后台任务与限制 · Google：Gemini API 日志、默认存储与保留期
8. 与真正购买的托管层比较，而非只比模型接口
当前OpenAI Agents API文档描述托管的Codex编排：OpenAI管理会话、编排、上下文压缩和恢复，应用提供工具并选择执行环境。这是与当前已说明服务的比较，不意味着表中每项能力都在10月29日才发布，也不能泛化为所有OpenAI API具有完全相同的责任与政策。
这与把模型权重放到兼容端点后提供推理，是不同的责任分工；也不等同于在自己应用中运行SDK。架构审查应分别列出模型推理、代理循环、执行计算和业务集成。即使执行环境由自己托管，也不会因此自动把托管编排及其全部状态搬到自己的服务器。
会话指南说明回合异步执行，并提醒idle不等于成功，即使回合completed也不证明每个工具都成功。自建代理也应采用同样区分：保存进度，检查实际结果与产物，再向用户报告完成。传输事件是有用证据，但产品仍须定义完成验收，而非仅把接口状态转发给用户。
| 责任 | 自托管模型端点 | 托管代理对照 |
|---|---|---|
| 推理与模型产物 | 自己运行选定权重和服务栈。 | 供应商运行所选模型服务。 |
| 代理循环与持久状态 | 由自己的集成或所选框架提供。 | 已说明的托管编排提供其中部分能力。 |
| 工具与执行 | 自己选择执行器及其权限。 | 应用函数与环境选择仍然重要。 |
| 业务验收 | 由自己的测试和回执确定成功。 | 仍由自己的测试和回执确定成功。 |
9. 图像输入不等于端到端语音产品
Large 4支持文本和图像输入、文本输出，可用于图表、文档或可视化编码上下文；但原生多模态不意味着权重本身提供电话、语音识别、语音合成和打断处理。应确认具体输入输出模态，不能把一个通用宣传标签延伸成整套产品能力。
Mistral于10月20日推出Voxtral 3音频家族和语音代理管线，更新记录将四款音频模型标为Public Preview。公告描述识别、带工具的通用推理模型与语音生成组成流式系统。这是本批扩展日期范围内的更新，也是另一套架构，不是静默增加到Large 4权重文件中的音频功能。
语音工作流要分别测试轮次结束判断、打断、转录错误、工具等待和口头确认。转录错一个账号，可以产生格式完全正确、对象却错误的工具调用。每个连接系统都要评估同意、录音保留和操作权限。供应商延迟示例不能证明自己部署的端到端延迟或合同服务水平。
本节来源： Mistral 官方权重卡：架构、推理和服务说明 · Mistral：10 月 20 日 Voxtral 3 公告 · Mistral：Voxtral 3 预览与 API 更新记录
10. 按验收任务计成本，并核查真实数据边界
Mistral在公告中报告编码能力与Token效率提升，但这些结果来自特定任务和评估条件。我们建议以独立验收通过的任务为成本分母：模型使用、重试、工具、计算、运维和人工审查全部计入，再除以满足约定检查的输出数量。仅输出Token减少，不能证明总成本更低。
建立固定且已获授权的任务集，明确成功标准：测试通过、要求行为存在、没有无关改动、引用证据支持结论、没有向禁止目的地发送数据。未解决案例也应保留。运行失败、模型拒绝、参数无效、貌似合理却错误的结果要分开记录，揉成一个失败率会隐藏真正需要修复的环节。
数据主权也需要具体边界。Meta于10月28日宣布支持五所美国高校研究；所述医疗项目在机构自身环境运行，患者和临床数据不向Meta提供。这是限定范围的研究安排，不是新的通用API，也不是所有Muse使用场景的数据承诺。它说明处理地点和合同适用范围必须精确说明。
部署时应盘点提示、检索文档、工具结果、轨迹、临时文件、备份和外部请求。本地运行权重，不阻止集成层把证据发往其他服务；区域端点也不能回答全部保留和继续传输问题。应核查每个实际组件，不用一个“主权”标签代替完整的数据流与责任图。
本节来源： Mistral：10 月 29 日改进版 Large 4 权重公开公告 · Meta：10 月 28 日高校研究合作与数据边界 · OpenAI：Agents API 托管编排概览
11. 用分阶段验收、持久记录和可用回滚上线
先从隔离的只读评估开始，在候选方案满足书面标准前保留现有生产路径。下面是我们建议的发布流程，不是已经执行过的测试报告。它特意同时检查模型周边集成和模型生成的文本，避免只有展示答案可用、外部操作和恢复却没有验证。
请求中断后需要对账。应用应知道工具处于提议、批准、开始、完成还是失败状态；为有副作用的操作保存持久化操作标识与回执，在不确定时先查记录再决定是否重复。重试推理不同于重试已提交业务操作，模型供应商的消息去重不能替代业务系统自身的幂等控制。
只有候选与基线在相同验收集和负载下完成比较，才扩大流量。保留足以解释失败的脱敏证据，同时避免无限期保存秘密。出现回归时将流量退回已知配置，并对未完成任务对账。开放权重的实际收益是一种新部署选择，必须让许可证、容量、执行和运维同时适配任务，才能兑现。
- 固定许可证修订、权重、量化格式、分词器、引擎及解析器配置。
- 验证只读工具调用、结构化输出、推理分离及明确的错误传播。
- 在代表性并发下测短长输入，包含排队、内存不足和失败情况。
- 用无害样例覆盖重启、取消、响应丢失和重复提交。
- 核查租户权限、审批、外部数据目的地、保留期和最终业务回执。
- 以小流量灰度和明确停止阈值发布；保留旧产物及配置，回滚或重试前对未完成任务对账。