这周的AI圈，信息密度高到有点离谱。从9月28日到10月4日，短短七天里，DeepSeek直接把昇腾全家桶开源了，OpenAI一天之内甩出20款新品，Google那边Gemini 4 Argon上线当天就屠了各个榜单，任何一个单拎出来都是能撑起一个月的选题。作为一个长期关注开源模型和部署工具的开发者，周三那天我光是看release notes就看到半夜。
这篇周报不打算逐条罗列新闻。我更想聊聊这三件事背后到底发生了什么变化，以及作为普通开发者，哪些信息值得真正跟进，哪些只是看着热闹。本周三条主线其实指向同一个问题：大模型的能力已经卷到边际递减，接下来拼的是工具链、算力适配和生态绑定。DeepSeek、OpenAI、Google三家，恰好在这周给出了三种完全不同的答案。
1. DeepSeek 开源昇腾全家桶，国产算力栈终于摘掉了“勉强能跑”的帽子
1.1 这个“全家桶”里到底装了什么
DeepSeek这波开源，不是简简单单丢出几个权重文件。它把“昇腾上的DeepSeek方案”完整地拆了出来，我关注到的有几块：
- 模型权重层：包含fp16高精度版本、各类量化版本，覆盖不同显存规模的部署需求。
- 推理引擎层：针对昇腾CANN和MindIE的适配配置，包括vLLM-Ascend、MindIE等推理引擎的Docker镜像和启动参数模板。
- 算子适配层：针对昇腾的算子补丁、自定义算子so库，以及PyTorch模型转换为昇腾格式的脚本。
- 训练与评估层：微调脚本、RL训练脚本、评测harness，甚至包含性能分析工具。
- 文档层：完整的性能调优指南、多卡并行策略、常见问题排查手册。
为什么叫“全家桶”？因为过去你想在昇腾上跑DeepSeek，需要自己把这些东西一个一个凑齐，而且大概率凑不齐。现在DeepSeek直接把一条从训练到推理、再到性能验证的完整链路开源了。对开发者来说，这里的核心价值是“官方样板间”：不用再自己猜怎么跑，照着文档走，先跑通再优化。
1.2 昇腾部署DeepSeek，过去的痛和新方案
我在昇腾上折腾模型的经历，总结起来就是三个字：缺、乱、慢。
首先是算子缺失。CUDA上跑得好好的模型，切到昇腾之后经常报“算子不存在”。一个Transformer模型里有大量自定义算子、融合算子，昇腾的CANN平台虽然也在快速补齐，但往往需要自己写tiling逻辑，这活真不是普通开发者能干的。
其次是推理引擎不兼容。vLLM、SGLang这些主流推理框架，很长一段时间并不原生支持昇腾。社区里的做法是fork一份源码，自己打补丁，再重新编译。编译一次半小时起步，遇到框架版本升级又得重来一遍。
第三是量化工具链的缺失。昇腾上做INT8量化，工具链经常要自己造轮子，量化后的精度损失也没有成熟方案的保障。
这次DeepSeek开源全家桶，相当于一次集中补课：算子层的适配做了，推理引擎的配置给了，量化方案也放了几个可选版本。最直接的改变是，普通开发者终于可以把精力放在业务上，而不是被“让模型在昇腾上跑起来”这件事卡住。
1.3 昇腾部署DeepSeek的实操要点
基于目前的公开资料和我的实操经验，在昇腾上部署DeepSeek系列模型，大致可以按这个流程走：
- 确认硬件与驱动。Atlas系列训练/推理卡，确认CANN版本在8.x以上。
- 安装推理引擎。推荐优先尝试MindIE或vLLM-Ascend，这两个对昇腾支持最成熟。注意Docker镜像要选对CANN版本，否则起容器就报错。
- 模型权重转换。如果拿的是PyTorch权重，需要转成昇腾可加载的格式。DeepSeek全家桶里提供了转换脚本，跑一遍就行。
- 启动服务。设置max-seq-len、block-size、tensor-parallel-size等参数。这里不要照搬CUDA版本的习惯，昇腾显存分配逻辑和CUDA有差异，KV Cache的预留要按昇腾的内存模式来估算。
- 验证性能。用官方评测harness跑一遍子集，再压测吞吐。
实际部署中最容易踩的坑有三个：
- 算子下沉没做好。昇腾的图模式里，如果算子没有正确下沉到NPU，会在Host端反复拷贝数据，性能直接掉一个量级。
- 显存估算不准。很多在CUDA上习惯按“权重显存+KV Cache”估算的人，在昇腾上会翻车，因为昇腾的缓存分配和内存碎片管理策略不同。
- 多卡并行环境。用HCCL通信时，环境变量配置错了会陷入无限超时，但日志里又不会直接报错，排查起来很费时间。
提示：如果你是第一次在昇腾上部署，建议先用量化版权重跑通全流程，确认服务和接口都没问题，再上高精度权重做性能调优。一上来就用大模型加高精度，容易在模型转换阶段卡住，排查问题也难。
2. OpenAI 一天狂发20款新品，重头戏不是模型而是Codex CLI
2.1 一天20条公告，拆开看只有两条主线
OpenAI在这一周搞了一次非常典型的“开发者日”式发布，一天内铺开20款新品和更新。很多朋友看到这个数字第一反应是“又来卷模型了”，但把公告拆开看，主线其实只有两条。
一条是Agent产品化。Codex CLI正式向开发者开放，还有桌面应用、Sandbox沙箱环境等一系列配套工具。这部分的逻辑很清楚：OpenAI想把大模型能力从“聊天窗口”搬到“开发工作流”里。
另一条是API平台深化。Responses API增加了新能力，实时语音接口做了升级，safety工具链和微调接口也有更新，还补了一批轻量级模型供不同延迟/成本场景调用。
对绝大多数开发者来说，需要动手试的其实是Codex CLI。因为API层面的更新通常是渐进式的，但Agent工具链的爆发是今年最大的范式迁移。
2.2 Codex CLI和Claude Code、Copilot CLI的正面PK
Codex CLI不是第一个做“终端里的AI编程助手”的产品。Claude Code早就把这条路走通了，GitHub Copilot CLI也有自己的用户群。为什么Codex CLI出来还是有这么大讨论度？我把它和另外两个放在一起对比了一下：
| 维度 | OpenAI Codex CLI | Claude Code | GitHub Copilot CLI |
|---|---|---|---|
| 定位 | 终端Agent编程工具 | 终端Agent编程工具 | 终端补全/轻量修改 |
| 执行环境 | 本地沙箱，代码运行受控 | 本地会话管理 | 直接在当前环境执行 |
| 模型绑定 | 可配置第三方模型提供方 | 绑定Anthropic模型为主 | 绑定GitHub Copilot后台模型 |
| 适合场景 | 多步重构、写测试、跨文件改动 | 复杂长任务、大规模重构 | 快速补全、简单单文件修改 |
| 上手成本 | 中，需要配置API | 中，官方CLI装完即用 | 低，GitHub账号直接用 |
我为什么最看好Codex CLI这波？关键在于它把自己定位成了“模型无关的Agent runner”。你可以在它里面配置不同的模型提供方，包括接入DeepSeek这类第三方模型。这意味着Codex CLI不是一个被OpenAI模型绑死的产品，而是一个独立的Agent执行环境。这个思路恰好和本周DeepSeek开源形成一种化学反应：开源模型负责便宜和私有部署，Codex这类工具负责执行力和交互体验。
2.3 亲手把Codex CLI接到DeepSeek，30分钟跑通
这周我实际试了把Codex CLI接到DeepSeek上，整体流程比想象中顺利。步骤大致如下：
- 安装Codex CLI本体。npm全局安装即可，装完命令行直接多了codex命令。
- 登录认证。用codex login走ChatGPT账号认证，生成访问凭证。这一步的目的是拿Codex相关权限。
- 配置第三方模型。在Codex的配置文件里新增一个provider，把base_url指向你使用的兼容OpenAI API规范的端点，把认证key换成DeepSeek的API key，模型名填deepseek-chat或deepseek-reasoner。
- 指定模型启动。运行codex命令时通过配置项指定使用DeepSeek的provider，然后正常提需求就行。
实测下来，三十分钟内跑通完全没问题。我自己试了几个典型场景：
- 代码补全类任务。DeepSeek接进Codex之后，生成速度挺快，单文件函数补全基本上没有明显延迟。但涉及跨文件依赖分析时，推理深度和闭源旗舰模型还是有差距。
- 写单元测试。这类任务DeepSeek表现很香。让Codex给一个老项目补测试用例，生成的测试覆盖度不错，而且token消耗比闭源API低一个量级。
- 解释陌生代码库。丢给它一个没见过的项目目录，让它分析架构和核心调用链，效果也算可用。
踩过的坑也分享一下：第三方模型对Codex系统提示词兼容性并不是完美的，个别格式指令可能被忽略，导致输出结构不一致。另外，Codex的沙箱环境对网络权限有限制，如果你的业务代码需要联网跑测试，记得在配置里放开对应域名。最后一点安全提醒：不要把API key写进公共仓库，环境变量方式优先。
提示：Codex CLI接入第三方模型的配置里，base_url别填错协议和路径后缀。很多兼容OpenAI协议的框架，路径前缀不是默认的/v1，需要根据文档调整，否则会一直在404和401之间来回跳。
3. Gemini 4 Argon 登场即屠榜，谷歌这次把旗舰压到了新刻度
3.1 Argon凭什么一上来就屠榜
Gemini 4 Argon这周发布后，几乎是在一夜之间刷遍了各大榜单。这个名字也挺有意思，氩（Argon）本来就是惰性气体，谷歌内部一直喜欢用元素周期表给大版本模型起代号。从命名就能看出来，这代的定位是“稳定、强大、不容易翻车”。
从公开信息和初步测评来看，Argon能屠榜不外乎几个因素：
一是模型规模继续往超大MoE方向走。现在的旗舰模型，单一大模型已经很难在效果和成本之间取得平衡，MoE架构几乎是标配，Argon在专家激活粒度和路由策略上做了不少文章。
二是强化学习继续往推理链路里深挖。这代模型明显吸取了之前推理大模型的成功经验，把RL训练从“结果奖励”扩展到了“过程奖励”，长链条的数学和代码任务表现提升明显。
三是原生多模态能力的持续强化。文本、图像、音频、视频的统一理解已经不是卖点，而是基本功。Argon在这方面属于“没有明显短板”的类型。
说穿了，Argon的屠榜不是某个单项能力的突飞猛进，而是模型综合能力的全面拉满。这种“水桶型”旗舰的优势在于：你不用去猜它擅长什么不擅长什么，大多数任务给它都能给出可用的结果。
3.2 “屠榜”也要看怎么读榜
各家大模型发布后的常规操作都是“全榜单第一”，但作为开发者，我更建议大家把榜单拆开看。不同榜单考察的能力维度完全不同：
| 榜单名称 | 考察能力 | 参考价值 | 注意点 |
|---|---|---|---|
| LMArena | 用户盲测偏好 | 反映真实对话体验 | 样本有语言/地域偏差 |
| SWE-bench Verified | 真实GitHub代码问题 | 反映工程能力 | 已经被大量模型针对性训练过 |
| GPQA Diamond | 科学推理 | 反映知识深度 | 专家级问题，普通场景用不上 |
| AIME 2025 | 数学竞赛 | 反映推理一致性 | 对日常任务参考有限 |
读榜的正确姿势是：先看自己的主要任务属于哪一类，再去找对应的榜单和评测集。比如你是做代码工具的，SWE-bench和LMArena的编程盲测比GPQA重要得多；你是做RAG应用的，多跳问答类评测比AIME更有参考价值。
另外警惕“榜单通胀”。一个模型刚发布时，由于没有经过充分的“数据污染”对抗测试，跑分往往会虚高。最好的验证方式永远是自己准备几十条跟业务强相关的Prompt，模型发布后第一时间跑一遍，和旧模型对比。跑分再高，也不如你自己的工作集靠谱。
3.3 Gemini 4 Argon 对普通开发者的实际影响
既然Argon这么强，是不是所有项目都应该切过去？我的建议是分场景判断。
适合优先切换到Argon的场景有三类：
- 复杂Agent编排。多步骤工具调用、跨系统交互，这类任务对模型的指令跟随和长期计划能力要求高，Argon的表现值得迁移。
- 超长文档分析。Argon在非常长的上下文窗口里保持注意力的能力明显增强，做数百页报告的问答和总结，比老模型靠谱很多。
- 多模态结构化解析。图表、表格、扫描件混合场景，Argon的OCR和结构理解能力属于第一梯队。
暂时不用急着换的场景也有三类：
- 传统RAG应用。简单问答和检索增强，老模型完全够用，新旗舰的边际收益不大。
- 高并发低延迟接口。Argon这种旗舰模型响应不慢但量级大，如果只是做轻量分类、抽取，选个小模型更划算。
- 成本敏感的批处理任务。把大量文本丢给旗舰模型做离线处理，性价比是真不行，开源模型加一张卡够跑很久。
API使用层面，这一代模型给我的感觉是“系统指令控制力变强了”。同样一套系统提示词，在Argon上能更好地保持输出格式和风格稳定，这对做自动化流程的团队来说很有价值。当然，具体能不能用到这个红利，还是要看你的应用场景和数据量。
4. 这一周的生态信号：开源、闭源与算力，三方终于把牌摊开了
4.1 三件事其实是三条路线的正面对撞
把DeepSeek、OpenAI、Google三家的本周动作放在一起看，本质上是三种完全不同的生态策略：
DeepSeek走的是“开源模型+算力适配+极致性价比”。开源昇腾全家桶，本质上是把“DeepSeek模型+昇腾算力”这套组合变成开箱即用的标准方案。这条路的优势是用户永远有选择的自由，不用担心被单一云厂商绑定。
OpenAI走的是“闭源模型+Agent工具链+开发者体验闭环”。Codex CLI的意义不在于多了一个终端工具，而在于它代表了OpenAI想把大模型能力沉到开发者日常工作流的决心。模型的护城河不再只是参数，而是整个工具生态。
Google走的是“全能旗舰+全栈平台覆盖”。Gemini 4 Argon的屠榜是在宣告：谷歌依然有最强模型的能力。加上它在搜索、Android、云端的布局，这套组合适合那些已经深度使用Google生态的团队。
三家的策略谈不上谁优谁劣，但有一点在收敛：模型本体能力之外的东西，正在成为竞争的关键变量。
4.2 个人开发者和中小团队该怎么选型
这周的新闻看完，最直接的问题就是：我的新项目到底该用谁家的模型？
我给团队的选型建议是分层的：
- 成本敏感、需要私有化部署的项目：优先DeepSeek系列加昇腾或者其他国产算力卡。开源模型在这类场景的性价比优势是闭源API给不了的，尤其是你要在客户机房或者内网环境跑模型的时候。
- 要最快搭建Agent功能、重视开发体验的项目：优先Codex CLI配合闭源API使用。工具链的成熟度对开发效率影响很大，Codex的沙箱和会话管理做得确实顺手。
- 多模态理解、超长文档、复杂推理的项目：Gemini 4 Argon值得认真评估。这类场景模型能力上限决定应用效果下限，选个能力强的准没错。
成本策略上有一个经验值得分享：不要只看API单价。闭源模型虽然按token计费，但如果模型能力强、能一次写对，实际开销往往比“便宜但反复返工”的模型更低。开源模型真正的优势不是零边际成本，而是你能完全掌控部署方式和推理链路。
4.3 我这一周的实测观察
这周我实际花了不少时间在跑实验。DeepSeek昇腾部署这边，因为我手上的昇腾环境刚好符合全家桶的要求，所以照着文档完整跑了一遍部署流程，整体感受是“终于不用自己瞎折腾了”。Codex CLI接DeepSeek也实际用在了几个小项目上，写测试和做代码解释的效率确实高。Gemini 4 Argon的API我也试了样例，在做长PDF总结和复杂图表解析时表现确实明显强于上一代。
但同时我也发现，这三条新闻里的“宣传浓度”都比实际体验高出一截。昇腾全家桶虽然解决了部署问题，但性能调优的深度指南还需要时间沉淀；Codex CLI的第三方模型支持还存在兼容性小毛病；Argon的屠榜成绩放在自己的业务场景里，未必能百分百兑现。
我的判断是：这周真正值得长期关注的信息只有两条。一条是Agent工具链正在从IDE走向终端，编程方式的底层逻辑在变；另一条是开源模型和特定硬件适配的combination会越来越常见，算力门槛在肉眼可见地降低。至于谁家的模型又拿了第一，反而没那么重要。
最后分享一个我坚持了很久的习惯：每周留出半天，把这一周出现的所有新模型、新工具都拉下来，在自己的测试集上跑一遍，记录时间和结果。半年后再回看这份实验日志，你会比任何新闻标题都更清楚什么值得用、什么只是昙花一现。下周如果这三家还有新动作，线索其实这周就已经埋下了：开源模型向下沉，Agent工具向终端走，旗舰模型向上卷能力。沿着这三条线继续观察，基本不会跑偏。
