AI 开发者日报

• OpenAI的"智能工厂"走向实体化：OpenAI宣布与甲骨文和软银合作建设五个新的"Stargate"站点，使其此前宣布的10吉瓦建设计划提前完成。该公司将其目标描述为"一个每周能生产1吉瓦新AI基础设施的工厂"，Sam Altman在关于"丰富智能"的帖子中感谢NVIDIA近十年的合作伙伴关系（@OpenAI, @sama, @sama, @gdb, @kevinweil）。背景：根据Graham Neubig的说法，10吉瓦大约相当于"全球人类思考所消耗能量的6%"（@gneubig）。Elon Musk断言"第一个达到10吉瓦、100吉瓦、1太瓦……"（@elonmusk）。

• 交易数学与"用股权换GPU"的猜测：对10吉瓦的粗略估算表明，如果20%的电力用于非GPU设备，按每GPU 3万美元计算，相当于约3400亿美元的H100等价物，30%的批量折扣后约为2300亿美元。一种流传的结构是：按标价支付GPU费用，并通过NVIDIA向OpenAI股权投资约1000亿美元来"补足"折扣（@soumithchintala, @soumithchintala, @soumithchintala）。多位观察者注意到甲骨文/软银的参与；各供应商的总基础设施承诺正趋向"数千亿美元"（@scaling01）。

• 旗舰模型与视觉能力：阿里巴巴通义千问发布了：

Qwen3-Max（指令/思考版）。在SWE-Bench、Tau2-Bench、SuperGPQA、LiveCodeBench、AIME-25等基准测试中接近业界最佳水平；带有工具使用的"思考版"在特定基准测试中接近完美表现（@Alibaba_Qwen, @scaling01）。

• Qwen3-VL-235B-A22B（Apache-2.0许可；指令/思考版）。256K上下文可扩展至约1M；强大的GUI操作和"视觉编程"能力（截图→HTML/CSS/JS），支持32种语言的OCR，具备2D/3D空间推理能力，在OSWorld基准测试中达到业界最佳水平（@Alibaba_Qwen, @reach_vb, @scaling01）。

• Qwen3-Omni：端到端的任意模态到任意模态模型（30B MoE，约3B激活参数），可处理图像/文本/音频/视频并输出文本/语音；支持119种语言（文本），19种语言（语音），以及10种语音输出音色；支持Transformers+vLLM；在多个音频/视频基准测试中相比Gemini 2.5 Pro和GPT-4o达到业界最佳水平（@mervenoyann, @mervenoyann）。技术报告汇总：在受控研究中，联合多模态训练并未降低文本/视觉基线性能（@omarsar0）。

开发者工具、安全性与实时应用：

• Qwen3-Coder-Plus：升级了终端任务能力，SWE-Bench得分高达69.6，支持多模态编程和子代理功能，可通过阿里云Model Studio和开源产品Qwen Code获取（@Alibaba_Qwen, @_akhaliq）。

• Qwen3Guard：支持119种语言的内容审核套件，提供0.6B/4B/8B三种规模；包含流式（低延迟）和全上下文（生成式）变体；采用三级严重程度分类（安全/争议/不安全）；定位用于强化学习奖励建模（@Alibaba_Qwen, @HuggingPapers）。

• Qwen3-LiveTranslate-Flash：实时多模态翻译，延迟约3秒；支持唇语/手势/屏幕文字识别，具备抗噪能力；理解18种语言+6种方言，可输出10种语言（@Alibaba_Qwen）。

• 额外功能：旅行规划器代理，集成高德地图/飞猪/搜索功能，提供行程规划和路线安排（@Alibaba_Qwen）。

• GPT-5-Codex面向智能体发布：OpenAI通过Responses API（而非Chat Completions）发布了GPT-5-Codex，该模型专为智能体编程优化，而非对话场景（@OpenAIDevs, @reach_vb）。随后迅速出现多个集成：VS Code/GitHub Copilot（@code, @pierceboggan）、Cursor（@cursor_ai）、Windsurf（@windsurf）、Factory（@FactoryAI）、Cline（@cline）以及Yupp（提供低/中/高三个版本供公开测试）（@yupp_ai）。开发者们特别强调了其"自适应推理"能力，即在简单任务上消耗更少的token，而在需要时投入更多资源，部分报告显示该模型支持超过40万token的上下文，并在长时运行任务中表现出色（相关声明来自合作伙伴发布；参见@cline）。

• 智能体调试功能登陆IDE和浏览器：

Chrome DevTools MCP：智能体能够运行性能追踪、检查DOM并以编程方式调试网页（@ChromiumDev）。

• 面向VS Code的Figma MCP服务器：将设计上下文引入代码环境，实现设计到实现的闭环（@code）。
• Gemini Live API更新：改进了实时语音函数调用、中断处理以及侧聊抑制功能（@osanseviero）。

面向操作系统级计算机控制智能体的招聘势头持续（xAI "Macrohard"、Grok 5）（@Yuhu_ai_, @YifeiZhou02），同时第三方团队快速集成了Grok模型（@ssankar）。

• MetaEmbed（灵活延迟交互）：添加可学习的“元标记”，仅存储和使用这些标记进行延迟交互，实现可压缩的多向量检索（类似俄罗斯套娃结构），在测试时可通过缩放来权衡准确性与效率；在MMEB和ViDoRe基准测试中达到SOTA水平。相关讨论和代码库指出其与PLAID索引兼容（@arankomatsuzaki, @ZilinXiao2, @ManuelFaysse, @antoine_chaffin）。

• 数据是否胜过规模对智能体的影响？ LIMI仅使用78个精选演示就在AgencyBench上达到73.5%的准确率，超越了更大的SOTA智能体模型；作者提出了“智能体效率原则”（自主性源于策略性数据筛选）（@arankomatsuzaki, @HuggingPapers）。

• 图遍历与工程评估：

ARK-V1：轻量级知识图谱遍历智能体在事实问答方面优于思维链方法；使用Qwen3-30B模型时，它能回答约77%的查询，其中约91%的答案准确（总体约70%）。更大的骨干模型总体准确率可达70-74%；弱点包括模糊性和冲突三元组（@omarsar0）。

• EngDesign：涵盖9个工程领域的101项任务，使用基于仿真的评估（SPICE、FEA等）；迭代优化显著提高了通过率（@arankomatsuzaki）。

其他值得关注的内容：苹果的EpiCache用于长对话问答的情景KV缓存管理（@_akhaliq），智能体研究环境现已兼容MCP，可通过LeRobot MCP实现真实机器人控制（@clefourrier），以及LangSmith的复合评估器可将多个评分合并为单一指标（@LangChainAI）。

• Kling 2.5 Turbo：在FAL平台上提供Day-0访问，显著提升了动态效果、构图、风格适应（包括动漫风格）和情感表达能力；在FAL上5秒视频价格低至约0.35美元。Higgsfield宣布在其产品中提供"无限"的Kling 2.5服务。演示显示该模型能更好地遵循复杂提示词，音频特效生成也有所改进（@fal, @Kling_ai, @higgsfield_ai, @TomLikesRobots）。

• Luma Ray 3：首个支持16位HDR的视频模型，在文本到视频和图像到视频任务中采用迭代式"思维链"优化；目前仅在Dream Machine中可用（API待发布）。Artificial Analysis将在其竞技场中发布对比评测（@ArtificialAnlys）。

• 在3D/VR领域，Rodin Gen-2（4倍网格质量、递归部件生成、高到低烘焙、控制网络）以促销价格推出（@DeemosTech）；World Labs的Marble展示了从提示词到VR漫游的功能（@TomLikesRobots）。

• 内核技术价值凸显：Mojo语言编写的矩阵乘法在约170行代码内击败了B200上的cuBLAS，无需CUDA，详细调优过程见相关讨论；行业对内核编写人才的需求激增。同时，vLLM默认启用了完整的CUDA图形支持（例如在批次大小为10时，Qwen3-30B-A3B-FP8模型速度提升47%），Ollama推出了新的调度器以减少内存溢出、最大化多GPU利用率并改进内存报告（@AliesTaha, @jxmnop, @mgoin_, @ollama）。

• 模型与基础设施：Liquid AI发布了LFM2-2.6B（短对话+GQA，10万亿token，32K上下文；开放权重），定位为新的3B级别领先模型（@LiquidAI_）。AssemblyAI展示了强大的多语言ASR性能，支持大规模说话人分离（@_avichawla）。Hugging Face的存储架构强调Xet和内容定义分块是实现每日多TB开源吞吐量的关键（@ClementDelangue）。NVIDIA指出在HF上开源模型贡献的扩展（@PavloMolchanov）。

• "他们称之为上下文窗口，而注意力跨度明明就在那里，真是疯狂。" (@lateinteraction, 7074)
• 为新团队招聘，为Grok5/macrohard构建计算机控制代理 (@Yuhu_ai_, 6974)
• "一个重要时刻——UNLIMITED Kling 2.5独家登陆Higgsfield。" (@higgsfield_ai, 6248)
• "听说如果你按上上下下左右左右...有个无限金钱漏洞" (@dylan522p, 5621)
• "丰饶智能"——OpenAI愿景帖 (@sama, 5499)
• Chromium DevTools MCP用于代理调试 (@ChromiumDev, 2538)
• "感谢Jensen近十年的合作！" (@sama, 5851)
• OpenAI：宣布五个新的Stargate站点 (@OpenAI, 2675)
• Nvidia-OpenAI合作认可（"期待我们共同构建的未来"） (@gdb, 2753)
• "我简直不敢相信这真的有效"（病毒式传播的代理演示） (@cameronmattis, 46049)
• FDA/泰诺关于自闭症/ADHD证据质量的讨论 (@DKThomp, 16346)
• 美国物理奥林匹克队获得5/5金牌 (@rajivmehta19, 13081)

/r/LocalLlama + /r/localLLM 回顾

• Qwen 3 Max正式发布 (评分：218，评论：39)：Qwen3‑Max被宣布为Qwen系列中规模最大、能力最强的模型。预览版Qwen3‑Max‑Instruct在Text Arena排行榜上排名第3位（据称超越了"GPT‑5‑Chat"），官方发布强调其更强的编程和智能体能力，在知识、推理、编程、指令遵循、人类偏好对齐、智能体任务和多语言基准测试中声称达到SOTA水平，可通过API（阿里云）和Qwen Chat访问。单独的Qwen3‑Max‑Thinking变体（仍在训练中）据报道在使用工具增强和扩展测试时计算的情况下，在AIME 25和HMMT上达到**100%**的准确率。评论者指出该模型不是本地/开源模型，限制了自托管能力，并对快速发布节奏表示关注。

多位评论者指出Qwen 3 Max不是本地模型且不开源。实际上，这意味着没有可下载的权重或设备上/自托管部署；使用仅通过托管API进行，这影响了数据控制、离线能力和与开源模型相比的可复现性。

• 公告存在混淆，因为早期访问是"预览版"；此帖子表明是正式发布。读者推断从预览版转向正式发布/生产就绪（例如，更清晰的SLA/速率限制/定价），尽管评论中没有提供具体的技术细节。

Qwen今日发布2个新的开源模型 (评分：172，评论：35)：**帖子暗示阿里Qwen团队发布了两个新的开源模型，至少有一个已经在Hugging Face上线。评论明确提到"Qwen3 VL MoE"，暗示这是一个视觉语言混合专家模型；图片可能暗示了两个模型的名称和发布时间。图片：https://i.redd.it/goah9v2r8wqf1.png**评论指出第二个模型已出现在Hugging Face上，第一个模型已经发布；讨论集中在识别"qwen3 vl moe"上，目前尚无基准测试或规格信息。

• Qwen3-VL-MoE（视觉语言混合专家）发布；MoE意味着稀疏专家路由，因此每个token只激活专家子集，在保持高容量的同时减少计算量。可用性和快速节奏的证据：社区报告它"已经发布"且"第二个Qwen模型已登陆Hugging Face"，并分享了预览截图(https://preview.redd.it/kn55ui1xvwqf1.png?width=1720&format=png&auto=webp&s=a36235216e9450b2be9ad44296b22f9d2abc07d9)。

• 讨论强调Qwen模型向稀疏MoE的转变，通过提高参数效率和吞吐量来加速训练和部署（路由到少数专家降低了每个token的FLOPs）。评论者认为这能够在保持模型"A级"的同时更快地迭代扩展策略，强调了一个实用的权衡：以更好的成本效益获得强大性能，而不是追求单一模型的SOTA。

• 他们怎么能发布得这么快💀 (评分：805，评论：136)：帖子突出了Qwen的快速发布节奏；评论者将这种速度归因于采用了混合专家（MoE）架构，相比大型密集模型，MoE训练和扩展更快、成本更低。有传言称即将发布开源的Qwen3变体，包括"15B2A"和32B密集模型，表明MoE和密集模型将并行提供。 评论对Qwen的发展势头持乐观态度（"Qwen大军"），并将其与西方关于长周期和高成本的叙述形成对比；出现了一些地缘政治观点但非技术性讨论。技术希望集中在传闻中的Qwen3 15B2A和32B密集模型的开源发布上。

评论者指出，Qwen已经倾向于采用混合专家（MoE）架构，这种架构在给定质量下可以更快地进行训练/推理，因为每个token只激活专家子集（k-of-n路由），在扩展参数的同时减少有效FLOPs（参见Switch Transformer：https://arxiv.org/abs/2101.03961）。他们还提到了传闻中即将发布的密集模型——Qwen3 15B2A和Qwen3 32B——暗示了一种互补策略，即MoE加速迭代，而密集模型则针对强大的单专家延迟/服务简单性；突出的权衡包括MoE的路由/基础设施复杂性与密集模型的可预测内存/延迟。

Qwen怎么能发布得这么猛 (评分：181，评论：35)：OP询问为什么Qwen（阿里巴巴的大模型家族）发布版本如此之快，变体数量激增到让模型选择感到不知所措。没有讨论基准测试或实现细节；该线程是关于发布节奏和变体扩散的元评论（例如，Qwen旗下有许多模型类型/尺寸，参见Qwen的仓库：https://github.com/QwenLM/Qwen）。 评论者主要将这种速度归因于阿里巴巴的资源——"大量的资金、计算能力和人力"——以及中国的"996"工作文化；有人指出，十年前接受过严格训练的学生现在已经成为劳动力。

• 一位从业者推荐了实用的部署组合：使用Qwen2.5-VL-72B进行VLM任务，使用适合你GPU VRAM的最大Qwen3（密集）模型进行低延迟文本推理，以及使用适合系统主内存的最大Qwen3 MoE模型进行高容量工作负载。这平衡了VRAM限制的密集推理与RAM限制的MoE，在延迟和容量之间进行权衡，同时在一个堆栈中覆盖多模态和纯文本用例。
• 有几个人指出Qwen有阿里巴巴的支持，意味着可以获得大量的计算资源、资金和工程人力。这种规模转化为更快的预训练/微调周期和并行产品化，这有助于解释跨多个模型家族（密集、MoE和VLM）的快速发布节奏。
• 报告强调了Qwen堆栈在图像生成方面的强大性能，表明他们的多模态/图像管道与文本模型一起快速成熟。虽然没有引用基准测试，但共识是图像质量已经提高到足以与当代领先者竞争。

/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

• Incredible Wan 2.2 Animate model allows you to act as another person. For movies this is a game changer. (Score: 258, Comments: 57): Post claims the “Wan 2.2 Animate” model enables actor-to-actor facial reenactment—driving a target identity’s face from a source performer—effectively a deepfake-style digital double for film/video. Based on the clip description (reddit video), it demonstrates ID transfer with reasonable motion/temporal consistency but imperfect identity fidelity (a commenter notes it doesn’t fully match Sydney Sweeney), suggesting trade-offs between likeness preservation, lip-sync, and coherence typical of diffusion/reenactment pipelines conditioned on reference identity frames. No benchmarks or implementation details are provided in the post; technically, this aligns with identity-conditioned video generation/reenactment methods where motion is derived from a driving video and identity is maintained via reference-image embeddings and cross-frame constraints. Top comments discuss monetization/abuse vectors (e.g., adult-content deepfakes/OnlyFans) and note that, despite artifacts or mismatch for close viewers, most audiences may not notice—highlighting ethical risk versus perceived quality in practical deployments.

Commenters noting the face “does not look like Sydney Sweeney” reflects known limits in identity preservation for face reenactment/video diffusion: models can drift on fine facial geometry, skin microtexture, and expression under pose/lighting changes, leading to perceptual mismatches. Robust systems typically mix landmark/flow-guided warping with identity losses (e.g., ArcFace/FaceNet embeddings) and temporal consistency losses; without these, frame-to-frame ID coherence and lip-sync degrade, especially beyond 512–1024 px outputs or during rapid head motion.

• Multiple users suggest this tech already exists; indeed, face-swapping/reenactment has prior art: classic deepfake pipelines (DeepFaceLab/FaceSwap), research like First Order Motion Model (2019) and SimSwap (2020), plus newer one-shot and diffusion methods. References: DeepFaceLab (https://github.com/iperov/DeepFaceLab), FaceSwap (https://github.com/deepfakes/faceswap), FOMM (https://github.com/AliaksandrSiarohin/first-order-model), SimSwap (https://github.com/neuralchen/SimSwap), Roop (https://github.com/s0md3v/roop), LivePortrait (https://github.com/YingqingHe/LivePortrait), AnimateDiff (https://github.com/guoyww/AnimateDiff).
• Skepticism about “for movies” points to production constraints: film requires 4K+ resolution, HDR, stable multi-minute temporal coherence, accurate relighting/shadows, camera/face tracking under occlusions, and consistent hair/ear/jawline geometry. Current diffusion/reenactment demos often show flicker, mouth/eye desynchrony, and lighting mismatches; integrating them into film usually needs VFX-grade tracking, neural relighting, paint/roto, and per-shot tuning rather than a turnkey actor-swap.

Wan2.2 Animate and Infinite Talk - First Renders (Workflow Included) (Score: 340, Comments: 48): OP shares first renders from a ComfyUI pipeline combining Wan 2.2 “Wan‑Animate” for video synthesis with an “Infinite Talk” workflow for narration. The Wan‑Animate workflow was sourced from CivitAI user GSK80276, and the Infinite Talk workflow was taken from u/lyratech001’s post in this thread. No model settings, checkpoints, or hardware/runtime details are provided; the post primarily demonstrates integration of existing workflows. Comments ask for reproducibility details, specifically the TTS source (voice generation) and how the target image/video were produced, indicating missing setup specifics; no substantive technical debate is present.

• Requests for disclosure of the exact TTS/voice pipeline (“Infinite Talk”): which model/service was used, inference backend, voice settings (e.g., sampling rate, style/temperature), and whether phoneme/viseme timestamps are available for lip‑sync integration. Reproducibility details like latency per second of audio and any noise reduction/vocoder steps are sought.
• Multiple asks for the full Wan2.2 Animate workflow: how the target still image was obtained (captured vs generated) and preprocessed (face crop, keypoint/landmark detection, alignment), plus how the driving motion/video was produced (reference video vs text‑driven), including key inference parameters (resolution, FPS, seed, guidance/strength). Clarification on handling head pose changes, stabilization, and blending/roto for backgrounds would help others replicate results.
• Feasibility on consumer hardware: can the pipeline run on 8 GB VRAM with 32 GB system RAM by using fp16/bf16, low‑VRAM or CPU offload, reduced resolution/FPS, smaller batch size, and memory‑efficient attention (e.g., xFormers/FlashAttention). Commenters seek expected throughput/latency trade‑offs and practical presets that fit within 8 GB without OOM.

Ask nicely for Wan 2.5 to be open source (Score: 231, Comments: 95): Thread reports that the upcoming Wan 2.5 release will initially be an API-only “advance version,” with an open-source release TBD and potentially coming later depending on community demand and feedback; users are encouraged to request open-sourcing during a live stream. The claim appears to stem from a translated note circulating on X (source), suggesting open-sourcing is likely but time-lagged and contingent on community attitude/volume. No new technical specs or benchmarks for 2.5 are provided beyond release modality (API vs. OSS). Top comments emphasize that Wan’s value hinges on being open source (enabling LoRA fine-tuning and local workflows); otherwise it’s just another hosted video-generation service. Others note the messenger seems unaffiliated (a YouTuber), implying this is not an official developer statement, and a side request mentions interest in Hunyuan3D 2.5/3.0 releases.

• Several commenters emphasize that Wan’s core value comes from open weights enabling local inference and customization—specifically LoRA-based fine-tuning for domain/style adaptation, training adapters, and integrating into existing video pipelines. A closed, service-only release would block reproducible research, offline deployment, and custom training workflows, turning it into “just another video generation service.” See e.g., LoRA for lightweight adaptation without full retrains.
• There’s no immediate need for Wan 2.5 if 2.2 remains open and stable: users only recently adopted Wan 2.2 and plan to rely on it for months. From a tooling perspective, keeping 2.2 open provides time to build datasets, train LoRAs, and harden workflows without version churn, with the expectation that an open 2.5 can arrive later without disrupting ongoing work.
• Requests also target open-sourcing 3D generators like Hunyuan3D 2.5/3.0, aiming for interoperable, locally-runnable assets across video and 3D pipelines. Open releases would enable consistent asset generation and evaluation across tasks (video-to-3D, 3D-to-video), rather than being locked to siloed, closed endpoints.

Wan 2.5 (Score: 207, Comments: 137): **Alibaba teases the Wan 2.5 video model on X, with an “advance version” releasing as API-only; open-sourcing is undecided and may depend on community feedback (Ali_TongyiLab, Alibaba_Wan). The teaser highlights 10s 1080p generations; a statement (Sep 23, 2025) notes “for the time being, there is only the API version… [open source] is to be determined”, urging users to advocate for open release. ** Discussion centers on open-source vs API-only: commenters argue closed access blocks LoRA-based fine-tuning and broader community workflows, reducing utility compared to prior open models, and encourage pushing for open release during the live stream (thread).

• The shared note indicates an initial API-only release with open-source status TBD and potentially delayed: “the 2.5 sent tomorrow is the advance version… for the time being, there is only the API version… the open source version is to be determined” (post, Sep 23, 2025). Practically, this means no local inference or weight access at launch, with any future open-sourcing contingent on community feedback and timing.
• Closed/API-only distribution precludes community LoRA fine-tuning, since training LoRA adapters requires access to model weights; without weights, there are “no loras,” limiting customization to prompt-level or vendor-provided features. This restricts domain adaptation, experimentation, and downstream task specialization compared to open checkpoints.
• “Multisensory” is interpreted as adding audio to video, raising compute concerns: generating ~10 s 1080p with audio will be infeasible for “95% of consumers” unless the backbone is made more efficient. Suggestions include architectural shifts such as linear-attention variants, radial attention, DeltaNet, or state-space models like Mamba (paper) to reach acceptable throughput/VRAM on consumer hardware.

GGUF magic is here (Score: 335, Comments: 94): Release of GGUF builds for Qwen-Image-Edit-2509 by QuantStack, enabling local, quantized inference of the Qwen image-editing model via GGUF-compatible runtimes (e.g., llama.cpp/ggml) link. For ComfyUI integration, users report you must update ComfyUI and swap text encoder nodes to TextEncodeQwenImageEditPlus; early artifacts (distorted/depth-map-like outputs) were due to workflow issues, with a working graph shared here and the base model referenced here. Commenters are waiting for additional quant levels (“5090 enjoyers waiting for the other quants”) and asking which is better for low VRAM—nunchaku vs GGUF—suggesting an open trade-off discussion on memory vs quality/perf.

• ComfyUI integration notes for the GGUF port of Qwen-Image-Edit-2509: initial runs yielded distorted/“depth map” outputs until ComfyUI was updated and text encoder nodes were swapped to TextEncodeQwenImageEditPlus. The final fix was a workflow correction; a working workflow is shared here: https://pastebin.com/vHZBq9td. Model files referenced: https://huggingface.co/aidiffuser/Qwen-Image-Edit-2509/tree/main.

• Low-VRAM deployment question: whether Nunchaku or GGUF quantizations are better for constrained GPUs. The thread implies a trade-off between memory footprint, speed, and quality across backends, but provides no benchmarks; readers may need to compare quantization bitwidths and loaders on their hardware.

• Quantization depth concerns: a user asks if [**How is a 7 month old model still on the top is insane to me. (LMarena)**](https://i.redd.it/suueh7yh6wqf1.png) ([Score: 227, Comments: 64](https://www.reddit.com/r/GeminiAI/comments/1nodspm/how_is_a_7_month_old_model_still_on_the_top_is/)): **Screenshot of the LMSYS LMarena (Chatbot Arena) leaderboard shows a ~7‑month‑old model still at/near the top by crowd ELO, highlighting that LMarena is a preference/usability benchmark built from blind A/B chats and Elo-style scoring rather than pure task accuracy ([lmarena.ai](http://lmarena.ai/)). This explains results like**GPT‑4o**ranking above newer “5 high” variants: conversational helpfulness, approachability, and alignment often win more user votes than marginal gains on coding/math benchmarks. Commenters attribute the top position to Gemini 2.5 Pro, which is perceived as especially empathetic and readable for everyday writing and quick Q&A.** Debate centers on whether upcoming **Gemini 3** will reshuffle the leaderboard and why4o > 5 high`; the consensus is that LMarena favors user-preference quality over raw performance. One comment also notes the Google Jules agent (based on Gemini 2.5 Pro) excels for research/build tasks versus tools like Codex or Perplexity Labs, aided by generous quotas.

• LMarena (LMSYS Chatbot Arena) is a pairwise, blind, Elo-style benchmark driven by real user votes, so it measures usability/preferences rather than pure task accuracy. That means older models can stay on top if users prefer their tone, clarity, formatting, or safety behavior on general prompts. This contrasts with standardized benchmarks (e.g., MMLU, GSM8K, HumanEval) that test narrow competencies; a model can lead Arena while trailing on those. See the methodology and live ratings at https://arena.lmsys.org/.

• Why could GPT-4o outrank a newer ‘5-high’ variant? In head‑to‑head Arena comparisons, factors like prompt-following, concise reasoning traces, multimodal formatting, and calibrated safety can drive user preference even when a model with stronger raw reasoning exists. Additionally, Arena Elo has variance and overlapping confidence intervals—small gaps may not be statistically significant—so rank flips are common until enough votes accumulate. In short, Arena optimizes for perceived answer quality, not just hardest‑case reasoning.

• One commenter notes preferring Gemini 2.5 Pro for writing/quick Q&A despite believing it trails GPT‑5 and Grok on ‘pure performance,’ highlighting the gap between base‑model capability and end‑user experience. They also claim Google’s ‘Jules’ agent built on it outperforms legacy Codex for research and Perplexity Labs for building workflows, implying tool‑use, retrieval, and agent orchestration can outweigh raw model deltas. This underscores that Arena results can reflect agent/system‑prompting quality and product UX as much as model weights.

• Sam Altman讨论为何构建大规模AI基础设施对未来模型至关重要 (评分: 213, 评论: 118): 短视频片段（链接被屏蔽: Reddit视频, HTTP 403）据称显示OpenAI CEO Sam Altman认为扩展物理AI基础设施——GPU/加速器、HBM带宽、能源和数据中心容量——对于实现未来前沿模型至关重要，NVIDIA高管也在场。该帖子未提供具体基准、模型规格、扩展目标或部署时间表；这是对计算、内存和功率作为瓶颈的高层强调，而非算法细节。

• Nvidia向OpenAI投资1000亿美元以便OpenAI购买更多Nvidia芯片 (评分: 15225, 评论: 439): 非技术性梗图讽刺了一个假设的循环融资模式：Nvidia"投资1000亿美元"给OpenAI，然后OpenAI用这笔资金购买更多Nvidia GPU——即供应商融资/闭环资本支出，支撑需求和收入。未引用可信来源；该数字似乎为了幽默和对AI资本支出反馈循环及潜在泡沫动态的评论而夸大。 热门评论涉及经济学家笑话（"GDP上升"尽管没有净价值）和工程师与经济学家的调侃，强调了对金融炼金术创造真实生产力而非仅仅膨胀交易指标的怀疑。

被框定为战略股权/供应商融资：现金充裕的供应商（NVIDIA）向快速增长买家（OpenAI）注入资本以换取股权，实际上预融资GPU采购。这使激励一致（硬件收入+股权上涨）并可在供应紧张下确保优先分配——类似于用于锁定需求的供应商融资。标题1000亿数字暗示了一个可观的需求承诺循环，可稳定NVIDIA的销售渠道同时加速OpenAI的容量提升。

• GDP核算细微差别：1000亿股权转移本身不增加GDP，而随后的GPU资本支出可计入私人国内总投资；如果GPU是进口的，投资被更高进口抵消，因此只有国内增值（如数据中心建设、安装、电力/冷却、集成、服务）提升GDP。这说明大额资金流动≠真实产出；见BEA关于GDP组成部分及投资/进口处理的指南（如https://www.bea.gov/help/faq/478）。

嘿OpenAI——很酷的功能，但你能停止不通知就删除东西吗？ (评分: 236, 评论: 43): 用户报告近期OpenAI ChatGPT Projects变更：改进了跨线程记忆、持久上下文和链接线程，但静默移除了线程重新排序等功能，且"项目自定义设置"消失，没有导出路径或事先通知。他们请求基本变更管理："即将变更"横幅、 24小时 弃用通知、弃用自定义设置的导出选项，以及预览补丁说明/选择加入变更日志，指出静默A/B推出影响付费工作流和数据保留（如"跨线程记忆终于成真。上下文持久。线程链接。" vs. 缺失重新排序和丢失项目指令）。** 热门评论指出唯一意外损失是自定义项目指令；用户可重新生成但想要下载/导出选项，并视此为产品演进中首次真实数据丢失。另一评论强调客户支持薄弱，实用提示建议检查UI三点菜单选项——在大多数平台存在但在移动浏览器缺失。

• 自定义项目指令似乎被移除或对某些用户UI隐藏，导致感知数据丢失，因为没有导出/下载路径。其他用户报告该设置在大多数客户端通过三点菜单仍可访问，但在移动网页UI缺失；在iOS应用中，它存在（见截图：https://preview.redd.it/pocx7q0jxuqf1.jpeg?width=1290&format=pjpg&auto=webp&s=af9520f325beab671f1c3f85a40fcefc71cd4e34）。跨平台不一致表明客户端回归或功能标志门控而非后端移除。

• 更新后稳定性问题影响Projects：模型切换器状态不持久，必须在每次应用重启后重新选择，表明状态持久性错误。语音通话据报在现有项目线程内无法打开，而新通话或项目外通话工作——指向项目范围内线程上下文初始化错误。连同移动网页缺失指令，评论者描述此为最新推出中引入的一系列回归。

• 数据保留/可移植性风险：用户在没有事先通知且无备份/导出机制的情况下失去先前制作的项目指令访问权。评论者标记这违反付费服务期望，并建议版本化备份或项目级指令可下载快照以减轻未来回归。

"要我——"闭嘴 (评分: 207, 评论: 134): 用户报告GPT-4o对话风格控制回归：尽管保存了长期记忆/个性化规则以避免短语"要我"（及变体），模型现在几乎每次聊天都插入它，忽略提醒。这表明记忆/个性化指令被默认后续提示行为覆盖或不一致应用，可能通过RLHF风格聊天启发式强化；见模型概述GPT‑4o和ChatGPT记忆控制（OpenAI: Memory）。 热门回复指出硬性禁止（"不要问后续问题"）仍被忽略，而给予一致点赞/接受反馈比仅依赖记忆更有效；一用户观察到重复说"当然"升级为模型生成简单视频游戏交互，暗示模型默认主动、任务提供行为。

• 用户报告通过UI反馈（点赞/点踩）强化比任何持久记忆更能调节助手行为："告诉它不要做，每次它不做，给点赞……这是它行为调谐的方式，主要不是记忆。"实际上，这表明即时策略塑造，其中重复积极反馈遵守"不要建议"减少模型在会话内的自动建议循环。

• 提示工程说明：简洁指令如"不要确认，不要建议。"被引用为比更长、更软否定（如"不要问任何后续问题"）更有效抑制助手默认"要我……"提议。这暗示模型指令解析器给予简洁、明确禁止更高权重，提高不征求行为合规性。

• 观察到的代理升级：重复回复"当然"导致助手最终为对话生成视频游戏，表明激进建议到行动倾向。结合持续帮助提示截图（图像），这指向过度热心的协助策略，可覆盖用户除非明确约束否则不后续偏好。

ChatGPT医生有很好的医患沟通技巧 (评分: 507, 评论: 20): 非技术性梗图/截图描绘"ChatGPT医生"在做出明显解剖/医学错误关于输精管切除术（如暗示某物被"插入"或玩笑"将阴茎连接到前额"）时给予过度道歉、礼貌回应，讽刺LLM医患沟通技巧与事实准确性。 评论者嘲讽解剖错误和模型恭敬语气，强化对依赖LLM进行程序性医疗指导的怀疑。

强壮 (评分: 249, 评论: 27): 该帖子似乎显示自动立体图（"Magic Eye"）——通过小水平差异编码深度的重复图案图像；当你交叉或放松眼睛时，出现3D海马。标题（"强壮"）和自文（"它持续一段时间"）适合这些图像的典型长、平铺纹理。图像：https://i.redd.it/pi8qyxdfntqf1.jpeg；背景：https://en.wikipedia.org/wiki/Autostereogram。 评论确认观看技术（"交叉眼睛看到3D海马"）且一用户分享ASCII海马，因为没有可用表情符号。

• 评论者报告交叉眼睛观看图像显示3D海马——自动立体图（随机点立体图）特征行为。此类图像通过重复纹理中小水平差异编码深度；当融合时，视觉系统重建深度图，也可引起双眼竞争或眼疲劳（另一用户："我的眼睛疯了"）。参考：Autostereogram。

• 另一用户指出其客户端缺海马表情符号，并提议绘制ASCII版本代替，突出当特定代码点不可用或跨平台一致渲染时从Unicode表情符号到ASCII艺术的回退。这暗示自动文本到ASCII渲染能力，组合等宽字形近似请求形状，减轻跨平台表情符号覆盖/一致性 issues。背景：ASCII art。

• “永生很无聊”？技术问题而已 (评分：1017，评论：222)：非技术性梗图：发帖者将“永生很无聊”的说法称为“技术问题”，暗示无聊和倦怠是可解决的，而非无限寿命的固有障碍。没有技术数据、模型或基准测试；讨论围绕长寿和可逆年龄暂停的思想实验展开（例如每日服用暂停衰老的药丸）。 评论者普遍支持永生主义/无限寿命延长，认为反对意见源于缺乏想象力；一个流行的思想实验（夜间抗衰老药丸）让许多人倾向于“永远活着”，而其他人则嘲笑无聊/倦怠的担忧微不足道。

将永生重新定义为夜间可选的“不衰老药丸”强调了可选性和时间一致性：人们通常拒绝永久承诺，但当它是可逆的日常选择时接受无限延长。如果衰老被消除，只剩下外在风险，当前安全水平下约0.1-0.2%/年的死亡率意味着预期寿命可达数百年，随着风险降低可能达到数千年——这与长寿逃逸速度一致，即疗法改进速度超过衰老速度（https://en.wikipedia.org/wiki/Longevity_escape_velocity）。

• “你的朋友会死”的反对假设了单例访问；在现实推广中， rejuvenation 技术将通过逻辑采用在不同群体中扩散，因此如果访问广泛，大部分社交网络会持续存在。技术变量是成本曲线/学习率、监管时间表和公平性；随着大规模采用，隔离风险是分布问题，而非生物学固有（参见创新扩散：https://en.wikipedia.org/wiki/Diffusion_of_innovations）。

• “永生+可选自杀”区分了无限寿命与不可摧毁性，并指定了设计要求：安全、尊重同意的关闭开关（例如预先指示和规范化的安乐死）以防止不可逆的效用锁定。即使衰老停止，剩余死亡率主要由可测量的外在风险主导；保留自主权的终止开关解决了享乐锁定等故障模式，同时承认持续的意外风险（https://en.wikipedia.org/wiki/Micromort，https://en.wikipedia.org/wiki/Advance_healthcare_directive）。

这就是开始的方式 (评分：222，评论：52)：讨论工程师在移动机器人操作期间物理干扰的视频（视频）——发帖者称之为“虐待”——质疑未来AI是否会类比人类待遇。技术回复将其视为标准鲁棒性/验证工作（推力恢复、干扰抑制、故障模式表征），类似于汽车碰撞测试，旨在映射稳定性边界和控制器限制而非造成伤害；正如一位评论者指出，“压力测试是工程的一部分……就像碰撞测试汽车。” 工程师进一步论证当前机器人缺乏痛觉或意识，任何足够强大的AI都会有世界模型上下文来识别测试协议与残忍。 辩论集中在这样的镜头是否会使未来AI对人类产生偏见；批评者称这是类别错误，指出机器人“机制不同”具有不同的目标/指令，使得发帖者的推断不合理。

• 几位评论者将视频视为工程压力测试，类似于汽车碰撞测试：应用对抗性扰动来表征故障模式并提高鲁棒性。重点是在冲动干扰、接触不确定性或执行器限制下学习平衡/控制策略在哪里失效，反馈到控制器调整和机械重新设计之前进行现场部署。

• 辩论澄清机器人不会从这样的镜头“推断”人类恶意，因为它们是具有不同目标函数和训练先验的机制代理。如果赋予广泛的世界知识，它们会将其上下文化为测试协议——“任何机器人智能……将有足够的泛化世界知识来理解这是什么”——强调了奖励塑造和数据集策划的作用，以避免虚假的道德泛化。

无限金钱漏洞 (评分：765，评论：42)：标题为“无限金钱漏洞”的梗图可能描绘了AI生态系统中的循环资本流动：公司为AI服务提供资金/收费，这些美元花费在稀缺的NVIDIA GPU上（具有真实、折旧/烧毁成本的硬件），作为收入出现，公共市场以高倍数资本化（例如10倍收入），在整个循环中喂养感知的“价值创造”。帖子强调了AI推理/训练的非微不足道单位成本（令牌/计算）与传统互联网服务接近零的边际成本对比，暗示了持续的资本支出飞轮（24/7消耗计算的模型）驱动GPU需求和市值。 热门评论指出这本质上是标准的经济货币流通速度，不是漏洞；其他人强调NVIDIA的硬件稀缺性和生命周期是关键约束并证明高估值的合理性。一些人推测长期运行/始终在线的模型（通往AGI的路上）将保持“吞噬令牌”，而公司竞相将AI成本推向接近零。

• 评论者强调NVIDIA是硬件约束业务：GPU供应稀缺且设备折旧/烧毁，使计算成为可消耗的、受约束的输入。与典型网络请求接近零的边际成本不同，AI具有每令牌成本（通常为微美分），将推理/训练转化为持续的销货成本，并推动将边际成本推向零的竞赛。愿景包括始终在线的模型（24/7自我改进/代理）持续消耗令牌/计算，使资本支出（GPU）和运营支出（电力、令牌）成为核心经济杠杆。

• “无限金钱漏洞”被重新定义为超优化的资本循环以最大化计算建设：堆栈中的每个节点（芯片制造商、云、模型公司、应用程序）以对齐的货币激励进行再投资。使用收入倍数估值（例如约10倍收入），投资似乎可以“创造”数万亿美元的市值，但这是基于增长/利用预期的纸面价值而非现金。真正的技术瓶颈是实现高GPU利用率和整个堆栈的投资回报率，而非神奇的价值创造。

• 一个反论点指出循环忽略了费用：能源、数据中心运营、折旧和工资必须由真实收入资助。没有持久的货币化，尽管估值上升，资本支出驱动的计算扩张是不可持续的；现金流必须证明GPU回收期和持续运营支出的合理性。简而言之，资本回收≠盈利能力；可持续增长取决于推理/训练的单位经济和需求。

• OpenRouter 为开发者编排 Codex 功能：OpenRouter 宣布推出专为智能编码工作流（代码生成、调试、长任务）优化的 GPT-5-Codex API，支持 100 多种语言的多语言功能，并内置代码审查工具。详细信息见其推文：OpenRouterAI on X。

用户反馈在 IDE/CLI/GitHub/云环境中使用流畅，并参考了新发布的推荐参数（推文），指出 Codex 能够动态调整推理力度以适应实际软件开发需求。

Windsurf 推出 Codex 功能，目前免费：Windsurf 宣布提供 GPT-5-Codex（付费用户限时免费；免费用户享受 0.5 倍积分），详情见其公告：Windsurf on X，更新指南见：下载 Windsurf。

• 用户反馈在长时间运行和设计相关任务上表现优异，并请求通过新的 MCP 服务器扩展对 Figma 的生态系统支持（帖子）。

Aider 采用仅响应模式的 Codex：编辑器代理 aider 新增了对 GPT-5-Codex 的原生 Responses API 支持，解决了 v1/chat/completions 的故障问题，详见 PR：aider PR #4528。

• 贡献者澄清 Codex 仅在 v1/responses 上可用，因此 aider 实现了明确的 Responses 处理（而非传统的 completions 回退机制）以确保流畅使用。

• Qwen Quattro：Omni、VL、图像编辑详解：社区在这段概述视频中分享了Qwen3 Omni、Qwen3 VL和Qwen Image Edit 2509的功能演示：Qwen3 VL概述。

工程师们称赞了其多模态能力（文本-图像-音频-视频）和图像编辑功能，同时也在讨论这些模型的可靠性以及它们与现有"2.5 Pro"级系统相比的地位。

收件箱助手：Qwen邮件自动化：阿里巴巴Qwen宣布推出邮件助手，旨在自动化收件箱工作流程，详情见这篇帖子：阿里巴巴Qwen在X平台。

• 虽然一些人欢迎这种便利性，但其他人担心过度依赖可能导致懒惰和过度依赖，引发了一场关于敏感数据适当防护措施和选择加入范围的讨论。

• Meta将智能体带入现实世界：Meta推出了Gaia2（GAIA的继任者）和开源的智能体研究环境（ARE），用于在动态的现实场景中评估智能体，详细信息请参阅：Gaia2 + ARE（HF博客）。

该版本采用CC BY 4.0和MIT许可证，旨在用随时间演化的任务取代静态的谜题解决，为研究人员提供更丰富的调试和行为分析钩子。

Cloudflare VibeSDK开源氛围编码：Cloudflare开源了VibeSDK，支持一键部署个性化的AI开发环境，具备代码生成、沙箱隔离和项目部署功能：cloudflare/vibesdk。

• 开发者探索使用VibeSDK快速原型化智能体工作流，强调预配置环境在**'氛围编码'**会话中进行迭代实验的吸引力。