AI 开发者日报

• 中国开源攻势：7月，中国实验室发布了一系列功能强大且采用宽松许可证的模型，这一趋势由@Yuchenj_UW重点提及。主要发布包括智谱AI的GLM-4.5和GLM-4.5-Air、Wan-2.2（视频）、阿里巴巴的Qwen3 Coder和Qwen3-235B系列，以及Moonshot AI的Kimi K2。这与西方开源发布速度放缓形成鲜明对比，@corbtt指出，那些回避这些模型的机构将面临“显著的竞争劣势”。
• 智谱AI的GLM-4.5模型：智谱AI发布了GLM-4.5（3550亿参数的MoE模型，320亿活跃参数）和GLM-4.5-Air，两者均采用MIT许可证。公司宣布正在扩展资源以满足高需求。这些模型被认为与Claude 4 Opus竞争，并在某些基准测试中击败了Gemini 2.5 Pro。社区迅速将其部署到MLX和DeepInfra等平台。
• Qwen3与Kimi K2模型：阿里巴巴的Qwen3 Coder表现出色，在Cline中的差异编辑失败率仅为5.32%，与Claude Sonnet 4和Kimi K2并列据@cline。一个300亿参数的MoE模型（30亿活跃参数），支持256K上下文，现可通过MLX和Ollama本地运行据@reach_vb和@ollama。Moonshot AI的Kimi K2是一个1万亿参数的MoE模型（320亿活跃参数），采用修改版MIT许可证发布，在LiveCodeBench和AceBench等基准测试中超越其他开源模型据@DeepLearningAI。
• 视频与图像生成：xAI推出了Grok Imagine，一款图像和视频生成工具，目前处于等待名单阶段。Wan2.2 5B视频模型因其图像到视频（I2V）方法令开发者印象深刻，其中每个潜在帧都有独立的去噪时间步，可能实现无限长的视频生成据@ostrisai。Ideogram发布了Ideogram Character，一款仅需单张参考图像即可实现角色一致性的模型据@hojonathanho。
• 视觉与机器人技术：Figure展示了其Figure-01与更新的Figure-02人形机器人的对比，突出了硬件和能力的进步据@adcock_brett。**ViTPose++**展示了令人印象深刻的姿态估计能力，准确追踪篮球运动员之间的复杂互动，现正被整合到一款篮球分析AI中，可判断球员是否处于禁区据@skalskip92。
• SmolLM3代码发布：SmolLM3的完整训练和评估代码已发布，包括预训练脚本（nanotron）、后训练代码（TRL/alignment-handbook用于SFT+APO）和评估脚本，以及100多个中间检查点，全部采用Apache 2.0许可证据@LoubnaBenAllal1。

• ChatGPT 学习模式：OpenAI 正在推出 ChatGPT 的 学习模式，这是一项交互式功能，旨在逐步引导用户学习概念，充当导师角色而非仅仅提供答案。这一消息由 @gdb 和 @sama 宣布。
• Runway Aleph 上下文视频模型：Runway 开放了 Runway Aleph 的访问权限，这是一个用于多任务视觉生成的新型上下文视频模型。@c_valenzuelab 展示了其强大功能，通过对比复杂的“白天转黑夜”手动视频编辑流程与仅需提示 Aleph“变成夜晚”的效果。类似对比还展示了从场景中移除汽车 和 添加爆炸效果。
• Google 搜索中的 AI 模式：Google 将其 AI 模式 扩展至英国，并新增了多项功能，包括上传照片和 PDF 进行查询、“画布”用于项目整理，以及“实时搜索”提供即时帮助。详情可见 @Google。
• LangChain 与 LangGraph 实现智能体工作流：LangChain 发布了一份指南，介绍如何利用 LangGraph 应用六种常见的上下文工程方法，并提供了视频和代码示例 详见推文。他们还展示了如何构建一个用于代码生成的自校正 RAG 智能体。生态系统持续扩展，LangSmith Traces 现已集成服务器日志，以提升可观测性。
• Perplexity 的 Comet 浏览器：Perplexity 的 Comet 浏览器初期采用率很高，CEO @AravSrinivas 提到其默认搜索引擎为 Perplexity，可能带来大量查询流量。他还演示了 Comet 完成一项复杂任务：在美联航预订航班，包括选座。
• 开发与工具：BlockDL 是一个免费开源的 GUI 工具，用于可视化设计 Keras 神经网络，由 @fchollet 发布。在工具方面，新的 Hugging Face jobs CLI 现由 uv 驱动，以加速环境设置，详见 @_lewtun。对于构建智能体应用的开发者，@_avichawla 分享了一种方法，仅需 10 行代码即可将任何模型、RAG 或智能体部署为 MCP 服务器。

• H200上的长上下文训练：@StasBekman展示了在单个H200 GPU上训练120万序列长度的Llama-8B模型已成为可能。这一成果得益于ALST、FA3（FlashAttention-3）和Liger-Kernel的结合使用，后两者最近修复了int64索引问题。
• TRL中的GSPO：阿里巴巴的Group Sequence Policy Optimization (GSPO)算法备受关注，现已在Hugging Face的TRL库中提供，@_lewtun宣布了这一消息。
• AMD对llama.cpp的贡献：@ggerganov指出，AMD团队正在积极参与llama.cpp代码库的开发，这意味着这一流行的推理框架将获得更广泛的硬件支持。
• StepFun开源StepMesh：中国AI公司StepFun开源了StepMesh，这是一个专为使用Attention-FFN解耦的推理系统设计的通信库，@teortaxesTex对此进行了报道。
• Qdrant Edge用于设备端向量搜索：Qdrant推出了Qdrant Edge的私有测试版，这是一个轻量级嵌入式向量搜索引擎，专为机器人、移动设备和物联网应用设计，@qdrant_engine宣布了这一消息。

• 反向传播的历史：@SchmidhuberAI 详细梳理了反向传播的发展历程，明确指出其现代形式最早由 Seppo Linnainmaa 在 1970年 发表，而更早的雏形可以追溯到 Henry J. Kelley 在 1960年 的工作。他强调，反向传播不仅仅是链式法则，而是其在神经网络中的高效应用。
• 评估危机：越来越多的人认为标准基准测试的可靠性正在下降。@ShunyuYao12 提出疑问：“当基准测试数据不再可信时，如何评估大模型？” @teortaxesTex 对此表示赞同，并认为只有当模型发布时附带“全新的评估套件”时，才会真正令人兴奋。DailyBench 由 @jacob_dphillips 发布，旨在通过自动化每日基准测试追踪前沿模型在新问题上的表现。
• 新优化技术：一篇关于反思式提示词进化的论文显示，其性能超越了 GRPO，突显了通过自然语言反思进行学习的强大能力，由 @lateinteraction 分享。阿里巴巴的 Group Sequence Policy Optimization (GSPO) 论文成为7月Hugging Face上第三受欢迎的论文，@ClementDelangue 预测它将产生巨大影响。
• 大模型的物理学：研究人员发布了“语言模型的物理学”相关代码，声称他们的 8B@1T 模型仅用 7%的计算资源 就击败了 Llama-3.1-8B，由 @giffmana 分享。
• 推理与意识：关于什么是推理的讨论兴起，@teortaxesTex 大胆提出推理是一种“超图灵计算”，应该能够解决停机问题。与此同时，@jxmnop 回顾了领域的发展，从争论GPT-2是否理解否定，到如今讨论“几乎有意识且能赢得IMO”的模型。

• Meta 4亿美元报价的故事：一个热议话题是顶级AI人才拒绝了Meta开出的4亿美元高额报价，这条来自@willdepue的推文迅速走红。这引发了人们对其他公司正在开发什么项目的猜测，以至于研究人员会拒绝如此丰厚的条件。
• 能源成为瓶颈：一位前Meta员工的评论浮出水面，指出能源是扩展计算能力的最大瓶颈，甚至比GPU的资金问题更为突出。这条推文被@code_star转发。
• API与开源模型的安全性之争：@ClementDelangue反驳了API模型比开源模型更安全的观点。他认为，通过让模型更易用，API可能会“数量级地”增加恶意行为者的滥用，而并未显著增加控制力度。
• 招聘与社区动态：Anthropic宣布扩展其Fellows计划，该计划将外部研究人员与内部团队配对，共同解决安全问题。Sakana AI则举办开放日活动，为其应用工程师团队招募人才。
• 地缘政治：多条高关注度推文涉及政治气候，包括佩洛西议长批评特朗普关于台湾地区领导人赖清德访问的决定，由@zacharynado分享。

• 发光花园与建筑扩散：一条推文开玩笑说“我的花园有一半在黑暗中发光了”，这是对一则关于发光植物的新闻的回应，这条推文通过@nptacek获得了大量关注。另一条“他们在检查笔记房子上做了扩散”的梗图也广为流传，被@sedielem转发。

• 离奇历史与密码：@DavidSHolz分享了一条1930年代的提案，提议在金门大桥上建造一条时速190英里的过山车。另一条病毒式传播的帖子中，@jxmnop分享了一张用户密码为“Woman”的截图，并评论道“这简直编不出来”。

• AI恶搞：@AravSrinivas用Comet浏览器发布了一个“热狗还是非热狗”的例子。@typedfemale则发布了一个关于“双性恋Luke Farritor”的梗图。

• 工程师的共鸣生活：一条关于被物理锁在房间里的帖子引发了人们对项目“被锁住”的共鸣，由@stevenheidel发布。a16z的一个“魔法会说话的狗和人类金字塔”的提案被@KevinAFischer分享。

• Qwen3 Coder 30B-A3B 明天发布！！！ (评分：429，评论：49)：帖子提到即将发布的 Qwen3 Coder 30B-A3B，这是 Qwen3 Coder 模型的 AutoAWQ 量化版本（A3B 暗示），表明开源大模型社区对此充满期待。图片可能暗示或确认发布时间，进一步推动了 Qwen 近期发布的竞争势头。用户评论中的技术背景显示，大家对 Qwen 的快速进展充满热情，并暗示其对竞争对手（如 Llama/Lizard 和 Altman）的影响。 评论者特别兴奋于 Qwen 的创新速度，认为它已经超越其他替代品（“与 Lizard boy 的友谊结束了”），并幽默地提到与 OpenAI 领导层的竞争紧张关系（“骗子 Altman”）。

一位评论者指出 Qwen3 Coder 30B-A3B 变体与假设的 Qwen3 Coder 32B（所有参数完全激活）之间的区别，表明 30B-A3B 版本可能涉及一定程度的参数停用或剪枝，而 32B 版本则利用了全部 320 亿参数。这种区别可能对运行这些模型时的性能或内存需求产生影响。

🚀 Qwen3-30B-A3B-Thinking-2507 (评分：414，评论：104)：图片似乎是对新模型 Qwen3-30B-A3B-Thinking-2507 的非技术性宣传，突出了其在推理任务（数学、科学、代码）、工具使用能力以及原生 256K token 上下文窗口（可扩展至 1M）上的竞争力。链接到 Hugging Face 和 ModelScope 提供了模型详情。帖子是近期 Qwen3 发布系列的一部分，评论者提到即将推出的编码器变体和 GGUF 量化版本的可用性，以便高效推理。 评论者对即将发布的版本（如 Qwen3-30B-A3B-Coder）表示兴奋，其他人则讨论了量化 GGUF 版本的实用性。一些用户对 Qwen 新版本的频繁发布感到疲劳。

• 分享了 Qwen3-30B-A3B-Thinking-2507 的基准测试结果，突出了其竞争力。图片链接显示了该模型与其他 30B-70B 级别大模型的排名对比，表明在当前评估基准中，其性能接近或处于同类模型的顶端。
• GGUF 格式的模型下载现已在 Hugging Face 提供：https://huggingface.co/unsloth/Qwen3-30B-A3B-Thinking-2507-GGUF，确保用户可以使用量化版本进行优化推理，适用于 llama.cpp 等框架。

Qwen/Qwen3-30B-A3B-Thinking-2507 · Hugging Face (评分：127，评论：32)：帖子讨论了在 P40 24GB GPU 上运行 Qwen3-30B-A3B-Thinking-2507 模型（Hugging Face 提供），使用 Q4 UD XL GGUF 量化，上下文窗口高达 90,000 token。性能基准显示，在零上下文时解码速度为 ~40 token/秒，40k 上下文时降至 ~10 token/秒，最大上下文时读取速度为 110 token/秒。模型在涉及 GUI/游戏仪表盘创建的复杂多步代码生成任务中进行了评估，通过 Roo Code 迭代提示处理，与 Flash 2.5 模型相比，初始错误更少。 评论者提供了技术资源（GGUF），分享了基准测试环境的截图，并指出在高上下文下性能稳定，使 Qwen3-30B 适合扩展的代码生成任务。

• 一位用户报告在 P40 24GB GPU 上运行 Qwen3-30B-A3B-Thinking-2507，使用 Q4 UD XL 量化和 90k 上下文长度，实现了 40~25~10t/s（token/秒）的生成速度（从 0 到 40k 上下文）。他们描述了一个涉及多步提示（9 个核心任务和多个修复提示）的复杂编码任务，并观察到在 40k 上下文窗口下的性能为 10t/s 写入和 110t/s 读取，指出初始错误比 Flash 2.5 少，这是他们常用的基准模型。
• 一位社区成员分享了 Qwen3-30B-A3B-Thinking-2507 的 GGUF 格式权重，并在 Hugging Face 上提供下载，便于本地量化推理和与 llama.cpp 等工具的广泛兼容性。

Qwen3-30b-a3b-thinking-2507 性能惊人 (评分：341，评论：85)：帖子询问最近发布的 Qwen3-30B-A3B 是否与 Qwen3-235B 的性能相当。评论者指出，Qwen3-30B-A3B 以显著更低的价格（$0.30-.45/百万 token）实现了与专有大模型 API（如 Gemini 2.5 Flash、Claude Haiku）相当的结果，表明成本效益的重大转变。A3B 变体在廉价笔记本电脑（无 GPU）上实现了 5-10 token/秒 （量化），文档建议对复杂任务使用极长的输出长度（32,768 至 81,920 token），挑战了近期文献中认为较短“思考”可能更优的观点。 讨论突出了对主要提供商利润率的怀疑，以及对 Qwen3-30B-A3B 作为本地高性能低成本推理模型的兴趣，尤其是在边缘设备（笔记本电脑/CPU 级别）上。技术辩论对比了近期论文提倡较短输出与 Qwen3 建议为复杂基准最大化输出长度的观点。

• 多位评论者强调，Qwen3-30B-A3B-Thinking-2507 模型以显著更低的成本（$0.30-0.45/百万 token）与专有大模型（如 Gemini 2.5 Flash/o3 mini/Claude Haiku）竞争，尽管性能相似，但封闭产品的价格高出 5-10 倍。
• 模型的效率值得注意：通过量化，用户报告在无 GPU 的普通笔记本电脑上实现了 5-10 token/秒的生成速率，使大规模部署和本地推理对非企业用户变得可行。
• 技术建议引用了近期关于输出长度的研究，推荐对大多数查询使用 32,768 token，对复杂数学或编程基准使用 81,920 token，较长的输出特别提高了在挑战性任务上的性能。

向 Qwen 3 团队致敬！ (评分：125，评论：17)：帖子讨论了阿里巴巴发布的 Qwen3-30B-A3B-Instruct-2507，称赞其质量，但指出较旧的 Qwen3-32B 目前在标准化基准测试中表现更优。发帖者请求发布更多变体，如 Qwen3-32B Instruct/Thinking 和 Qwen3-30B-A3B-Thinking-2507，表明对更广泛模型可用性和进一步基准比较的兴趣。评论者还表达了对高性能编码器模型（14B 和 30B）的需求，并寻求澄清新旧版本（Qwen3-32B 和 Qwen3-30B-A3B-Instruct-2507）之间的技术性能差距。 技术讨论围绕对更多编码器导向和竞争性模型的需求展开，特别是那些能够超越 Sonnet 3.5 等基准的模型，以及对 Qwen3-30B-A3B-Instruct-2507 和 Qwen3-32B 直接基准测试的疑问。

• 讨论指出，Qwen-32B 通常在基准测试中优于 Qwen-30B，但代价是推理速度显著更慢和硬件要求更高——具体来说，Qwen-32B 通常需要高内存 GPU，而 Qwen-30B 在低端硬件（包括某些 CPU）上更可行。这种区分突显了模型选择在性能和资源可访问性之间的权衡。
• 多位用户对 14B 参数范围内的 Qwen3 编码器模型表现出兴趣，认为其可能超越 Sonnet 3.5，反映了当前对高容量和专用编码器模型的兴趣，以及在开源模型领域的比较野心。
• 一个技术上的不满是关于 HuggingFace 上新 Qwen 版本缺乏实时推理（API）端点，影响了测试和部署工作流的即时可访问性。

经过 6 个月的本地 AI 折腾，这是我的精选模型列表，满足 90% 的需求。你的呢？ (评分：104，评论：65)：用户分享了其本地 AI 模型设置的详细总结，主要使用多个量化大模型（多为 Unsloth UD Q4_K_XL），如 Mistral-24B 用于问答、Gemma3-27B（IQ3 量化）用于通用任务、Qwen3-30B 用于编码、Medgemma 用于医疗查询，均在 Llama.cpp 上运行，共享 48GB RAM 和 Vulkan 后端。他们报告了实际推理性能（如 Mistral-24B 4t/s、Gemma3-27B 5t/s、Qwen3-30B 20-22t/s），上下文长度为 10-12k，并描述了这些模型的分工（如使用 Gemma3n-2B 作为 AI 增强的 Siri、Granite3.3-2B 用于摘要）。 技术评论讨论了使用 Gemma3-27B IT QAT 量化带来的显著性能提升，并批评了 Medgemma 在读取胸部 X 光片时的可靠性——虽然对一般建议表现良好，但可能忽略细微/关键细节。另一条评论无关地列出了历史上的国家作为最爱。

• Gemma3-27B IT QAT 提供了比标准量化模型显著的性能提升，用户报告其感觉类似于 Q5KM 量化的质量，特别是如果用户的硬件支持；这突显了量化感知训练在效率和推理速度上的进步。
• MedGEMMA 在特定领域（如读取胸部 X 光片）的性能受到质疑，因为它倾向于忽略细微但临床显著的特征，强调了 LLM 在医学影像任务中的挑战以及临床使用前彻底评估的必要性。然而，它也被称赞为一种隐私保护的本地运行 LLM，适用于一般健康对话，在某些属性上与全科医生匹配，提供私密、离线的医疗建议。
• GLM 4.5 Air 的发布导致用户模型库的显著整合，一位用户提到其模型库从 1.2TB 减少到 411GB，表明 GLM 4.5 Air 的能力和全面性可能取代本地系统上多个较小模型的需求。

• GLM4.5 EQ-Bench 与创意写作测试 (得分：133，评论：24)：帖子分享了一张关于 GLM4.5 在 EQ-Bench 和创意写作评估中的表现排行榜，重点关注开源与闭源模型（如 QWEN、DeepSeek、OAI 的 Sonnet、Kimi 2）在创意写作方面的对比。图片展示了多种大模型的排名，其中开源模型在基准测试中表现突出。评论中有人指出，以 LM 作为评判标准的基准测试逐渐被认为过时，且当前的评估方法往往无法充分体现长文本创意写作的能力，而 OAI 和 Google 的模型因其对长上下文的处理能力更受认可。 评论者对这些排名的实际应用价值提出质疑，认为基准测试结果（尤其是创意写作）常常无法真实反映用户体验，例如在长文本中保持叙事一致性和上下文连贯性方面的问题。一些用户对某些模型的高排名表示怀疑，指出这些模型在实际使用中可能难以保持时态一致或遵循提示词，而一些不太知名的模型（如 Mistral Nemo）在实际应用中表现意外出色。

多位用户提到，当前的创意写作基准测试（如 EQ-Bench）可能已经过时，因为它们依赖 LM 作为自动评判工具，这种方法类似于 LMSYS 的 AutoArena，可能无法全面评估大模型的创意或上下文能力。

• 对故事写作基准测试的批评指出，QWEN、GLM 和 DeepSeek 在短篇角色任务中表现良好，但在接近其宣称的上下文窗口长度时（通常不到 1/10），会变得重复或失去叙事结构。相比之下，OAI 和 Google 的模型（如宣称支持 1M 上下文的模型）在长文本中表现更优（能保持连贯性至 100K tokens）。
• 针对具体模型的反馈提到，Kimi 2 并未比 Mistral Small 3.2 等小型模型带来显著改进，批评主要集中在文本质量上，尽管其提示词遵循能力更强。此外，QWQ 在时态一致性（尤其是第一人称叙事）方面表现不佳，而有经验的用户仍认为 Mistral Nemo 在整体叙事质量上表现出色，但也指出其在角色细节上偶尔存在不一致。

glm-4.5-Air 推荐帖 - 如果你还没试过，不妨一试 (得分：127，评论：54)：帖子推荐了 glm-4.5-Air（4-bit 量化，mlx 实现），称其在高性能大模型中表现出色，擅长多步骤工具链和项目管理集成，在复杂工作流中既快速又上下文稳定。用户指出，glm-4.5-Air 能够提供深入分析而不丢失上下文，在日常助手任务中表现优于 Qwen 32B，尤其是在支持的硬件（如 Mac 的 mlx 后端）上。 热门评论关注 llama.cpp 的当前不支持问题（待 PR #14939），指出平台限制（尤其是双 3090 用户），对未来 GGUF 兼容版本的乐观期待，并讨论了量化级别（3-bit 与 4-bit）在参数数量与模型质量之间的权衡。

• 目前 GLM 架构缺乏 llama.cpp 和 GGUF 支持，限制了非 Mac 硬件的使用（尤其是双 3090 GPU 用户），但活跃的 Pull Request 表明兼容性升级即将到来。
• 多位用户报告成功以激进量化级别（如 3-bit 和 4-bit）运行 GLM-4.5-Air，表明该模型的大参数数量弥补了量化带来的质量损失，部分用户认为其性能与最近的 Qwen3-30B 量化模型相当或更优。
• 关于非 Mac 硬件（如使用 DDR4 RAM 的系统，如 i7-13700k 配 64GB DDR4）性能的讨论和担忧，因内存速度瓶颈可能影响推理速度，与 Mac 的高带宽内存相比。

• 再见了，Meta AI，曾经的美好时光。 (评分：1098，评论：366)：Meta CEO马克·扎克伯格发布了一份声明，概述了Meta在AI超级智能领域的未来方向，并指出出于安全考虑，公司将对其最先进模型的开源采取更严格的控制（详见官方声明：meta.com/superintelligence）。这标志着Meta从之前的开放策略（例如以宽松许可发布Llama衍生模型）转向更专有的模式，尤其是在技术能力提升的情况下。这一决定与其他组织持续发布开源前沿模型的做法形成鲜明对比，暗示Meta未来可能不会将其顶级技术贡献给开放社区。 评论者普遍批评Meta的这一转变，指出其此前曾公开倡导开源AI，并推测这一转变更多是出于商业化而非安全考虑。有人提到，目前已有开源模型在性能上媲美或超越Llama 4，因此Meta的退出对开源前沿进展的影响可能有限。

一条评论指出，目前已有多个开源前沿模型被认为比Llama 4更强，暗示Meta在开源AI竞赛中的相对落后，并质疑其改变开源模型部署的理由。

• 另一条评论提到Meta领导层此前（例如致国会的信函）曾倡导开源AI对社会更安全、更有利，指出其现在转向商业化和降低透明度的做法可能违背了此前对开放的承诺。

中国模型崭露头角 (评分：291，评论：35)：这张图片（https://i.redd.it/727keqreo3gf1.png）可能是一张图表或性能对比指标，显示了中国开源语言模型（如Qwen）相对于西方模型（如Llama和Mistral）的快速进步和性能提升。讨论中，用户提到他们正从Meta的Llama和Mistral模型转向更新、审查更少且性能更高的中国模型（尤其是Qwen3-30B-A3B）。评论者注意到Mistral仍在持续开发，但也承认中国模型在某些基准测试和应用中的主导地位。 一些评论者就西方与中国大模型的未来采用展开辩论，有人对Llama曾经的统治地位表示怀念，并继续支持Mistral，但也承认中国替代品的技术吸引力和快速进步。

• 用户分享了开源大模型采用的演进过程：从LLaMA 3.1-3.2开始，转向Mistral 3 Small，再到经过蒸馏的R1-Mistral变体（如Dolphin，减少了审查），现在则转向Qwen3-30B-A3B，这表明中国模型（如Qwen）因其持续的技术改进和开放性吸引了高级用户。
• Mistral模型因其持续强劲的表现受到关注，尤其是本月多次发布的小型模型。技术社区对Mistral预计在今年晚些时候发布的大型新模型充满期待，这表明Mistral的开发仍在积极进行。
• 对于实际编码用例（尤其是前端开发），评论指出Mistral模型表现优异，外部资源（如designarena.ai）展示了其能力。这表明尽管面临Qwen等新竞争者的挑战，Mistral在应用编码任务中仍保持竞争力。

• 更多关于 GPT-5 的片段，似乎发布真的迫在眉睫。 (评分：390，评论：69)：这篇帖子讨论了据称来自 GPT-5 的新片段，并暗示其公开发布可能即将到来，引用了当前泄露中缺少“gpt-5-mini”模型的情况，这与 OpenAI 以往的发布模式形成对比。图片可能是截图或信息片段，进一步支持了关于发布时间和模型分段的猜测。 技术讨论集中在发布策略上：一些用户猜测 OpenAI 会首先发布最大、最能吸引头条的模型，随后推出较小的“mini”模型和可能的开源版本，这与之前的行为有所不同。

一位用户注意到尽管之前的泄露表明“gpt-5-mini”模型存在，但当前泄露中并未出现，推测 OpenAI 可能会优先发布高调、强大的模型以最大化头条效应，随后再推出较小或开源的变体。

ChatGPT 官方 Twitter 账号的神秘帖子…… GPT-5 明天发布？ (评分：192，评论：77)：这张图片由 ChatGPT 官方 Twitter 账号发布，显示了用日语片假名书写的“ChatGPT”，以及一个红色的汉字符号，意为“幸运”、“好运”或“祝福”。这引发了社区对潜在公告（如 GPT-5）的猜测，尤其是帖子提到明天是周四——通常是科技产品发布的日子。图片的技术内容有限，主要是一个没有明确技术细节或公告的预告。 一位评论者澄清了日语文本，纠正了最初关于隐藏提示的猜测，并指出片假名和汉字的使用，将讨论重点放在语言学而非技术新颖性上。一些人猜测“GPT-5 甚至 GPT-6”的发布，但这只是猜测，并未基于图片本身的任何证据。

• 一位评论者指出，视觉中与公告相关的日本水墨画笔触可能象征性地暗示了即将发布的模型具有“成熟、深度和深思熟虑”的特点，可能暗示其在推理或解释细微差别方面的改进。

“gpt-5-auto”和“gpt-5-reasoning”作为模型已添加到 ChatGPT MacOS 应用的最近更新中 (评分：289，评论：39)：截图显示 ChatGPT MacOS 应用的模型选择菜单中出现了两个新模型：“gpt-5-auto”和“gpt-5-reasoning”。这表明 OpenAI 正在准备推出或测试这些 GPT-5 变体，分别针对不同的操作重点——“auto”可能用于通用目的，“reasoning”可能针对更复杂的逻辑任务进行了优化。没有提供基准测试或官方发布说明；仅通过视觉证据确认了它们在用户界面中的存在。 一种关键的用户情绪强调了手动选择模型的重要性，表达了对能够在模式之间（如路由器/自动和明确的单一模型选择）进行选择的赞赏。没有深入的技术辩论，大多数评论都是兴奋的期待而非批判性分析。

• 一位评论者将新的“gpt-5-auto”/“gpt-5-reasoning”模型区分与 xAI 的方法进行了类比，用户可以在“快速/自动”和“高级”模型选项之间选择，并指出“reasoning”模型的持续存在表明“auto”并非一个完全统一的、全功能模型。这暗示 GPT-5 系列内部可能存在专业化分工（例如“auto”用于速度/路由，“reasoning”用于复杂任务），而非单一的整体模型。

GPT 5 被发现！它快来了！ (评分：150，评论：17)：这篇标题为“GPT 5 被发现！它快来了！”的帖子可能引用了关于 GPT-5 潜在发布的谣言或猜测性发现，但图片内容无法分析技术细节。讨论集中在 GPT-5 的发布日期（可能是即将到来或八月底）的期待上，并希望它能与新的推理模型一起发布，反映了对 GPT-5 是否能单独超越 OpenAI 的“o3”模型的怀疑。 评论者讨论了可能的发布时间表，并表达了对 GPT-5 对就业市场影响的期待和焦虑，呼应了行业对高级语言模型可能颠覆就业的持续担忧。

• 一位用户对 GPT-5 在发布时是否能明显超越 OpenAI 自己的“o3”模型表示怀疑，强调了当前对最先进模型和下一代发布之间性能差异的不确定性。同时，人们对传闻中的“推理模型”充满期待，并推测它与 GPT-5 一起发布可能会显著提升能力。

有些事情正在发生 (评分：147，评论：63)：图片似乎展示了 ChatGPT 的截图，其中选择了“gpt-8-auto”模型，暗示存在未来的未发布模型变体（可能是 GPT-5 或更高版本）。评论者指出，通过在 URL 中输入任意模型名称可以产生类似的用户界面结果，表明这不是真实的模型，而是通过直接 URL 操作（例如 https://chatgpt.com/?model=gpt-8-auto）可访问的用户界面伪影或占位符。背景是围绕 GPT-5 即将发布或公告的猜测，得到了最近的泄露和高度社区期待的支持。 一些用户讨论了截图的真实性，一些人将其归因于 URL 操作而非实际的模型泄露，另一些人则基于行业谣言和最近的活动推测可能的发布时间表。

• 一些用户注意到，在 ChatGPT 的网页界面中操作模型查询字符串（例如 https://chatgpt.com/?model=gpt-8-auto 或 ?model=gpt-5-auto）只会更改显示的模型名称，但不会加载任何未发布的模型；实际的请求仍然路由到已建立的模型（如 GPT-3.5）。这一点从无论查询中的模型名称如何变化，功能都未改变以及未观察到后端模型差异中可以明显看出。

• 基于最近的泄露和行业传闻，有技术性猜测认为新的 GPT 模型（可能是 GPT-5）可能即将发布，引用了泄露中的“LMarena Anon”等模型名称以及之前模型发布的时间。然而，没有官方发布确认或检测到的基础设施变更（如直播或发布公告），这增加了对这些说法的怀疑。

• 直接检查和截图分享表明，尽管进行了查询字符串操作，后端的安全性仍然完好，防止通过用户界面未经授权访问未发布的 GPT 模型，确认了 OpenAI 模型端点的预期安全性。

• WAN 2.2将为独立动画带来革命性变化（评分：415，评论：94）：**WAN 2.2作为独立动画模型的更新，在视觉效果上较WAN 2.1有所提升，但用户发现其在提示词遵循方面存在局限，尤其是动作和镜头运动控制（例如难以生成静止主体同时动画化镜头运动）。关于WAN 2.2在生产环境中的实用性存在争议，因其输出可能因未解决的问题而对开发者声誉构成风险。**评论指出，尽管WAN 2.2在美学上有所进步，但其在提示词解析和可靠性方面的持续问题使其不适合专业或开发者使用，引发了关于社区负面反馈的担忧。

技术用户讨论了WAN 2.2相对于2.1的实际改进，认为这些改进更多是视觉上的小幅提升而非突破性变化，质疑其“改变一切”的说法。

• 一个实际的提示词工程问题被指出：即使使用明确的负面提示词（如“行走”和“说话”），WAN 2.2中的角色仍会持续执行不期望的动作，表明其在动画任务中的提示词忠实度和模型控制存在局限。
• 一些人指出，尽管视觉有所改进，但由于持续问题（输出一致性、控制机制），该模型对开发者来说仍基本无法用于生产，部署到项目中可能带来声誉风险而非实质性收益。

我为WAN 2.2创建了一个详细的提示词生成器，完全免费使用。（评分：364，评论：30）：**该图片展示了一个新的、免费的、基于浏览器的提示词生成器UI，专为WAN 2.2（可能是Stable Diffusion模型的变体）设计，可通过dengeai.com/prompt-generator访问。界面直观地展示了提示词组件，支持详细的视频提示词创建，旨在通过直观的视觉提示提升可用性。技术用户询问了本地部署的可能性，表明社区对开源或可下载版本的需求，以扩展其适用范围。**讨论围绕将该工具作为本地或通用应用程序的益处和可行性展开，社区对协作开发以扩展其用途表现出兴趣。

• 一位评论者询问是否可以将提示词生成器作为本地独立软件发布，强调社区对通用工具的需求，建议通过协作开发将其扩展到其他模型或工作流。

WAN 2.2 I2V游戏角色与SeerV2（评分：288，评论：55）：**该帖子详细介绍了使用WAN 2.2和SeerV2的图像到视频（I2V）工作流，强调WAN 2.2在游戏角色渲染中的效果。工作流在ComfyUI中实现，使用LightXv2强度0.5、20步、CTF 3.5、ModelSamplingSD3设为5，采样器为dpmpp_2m，调度器为Beta。最终输出以832x512渲染，并使用SeedVR提升至4K（参考指南：one-step-4k-video-upscaling-and-beyond-for-free-in-comfyui-with-seedvr2）。**评论者称赞WAN 2.2的高质量，但未展开深入技术讨论。

• 一位用户详细描述了使用ComfyUI的SeerV2 I2V游戏角色生成工作流，强调使用WAN 2.2和LightXv2强度0.5、20步CTF 3.5、ModelSamplingSD3设为5，采样器为dpmpp_2m，调度器为Beta。他们以832x512渲染，并使用SeedVR提升至4K，参考了ComfyUI中的4K提升指南。工作流包含特定负面提示词（“Slow, Slowed in negative”）以调整角色动作。

对WAN2.2文本到图像质量的惊喜（评论中附工作流）（评分：224，评论：94）：**该帖子讨论了WAN2.2文本到图像模型（14B参数，FP16）的结果，附有工作流和示例输出链接。用户强调了其强大的纹理和皮肤真实感，指出提示词遵循性中等，但与Flux结合时有所改善（例如使用Nunchaku生成潜在图像后，在WAN2.2中重新处理，生成时间减少约40%）。社区寻求改进的控制工具（如tile/blur controlnet）以更灵活地操作输出。**共识认为WAN2.2在照片真实感和纹理质量上超越Flux，但Flux在精细提示词控制上更优；两者的实际混合可产生引人注目的结果并提高效率。

• 用户报告WAN2.2在生成细节纹理（如皮肤）方面表现出色，优于Flux Dev等模型。一位用户建议使用14B FP16版本以获得最佳效果，并推荐查看未压缩样本以欣赏纹理保真度，同时建议添加tile/blur controlnet支持以增强模型的多功能性。
• 描述了一种工作流优化：用户用Flux Dev（通过Nunchaku生成半潜在图像）替换高噪声通道，然后重新编码到ksampler中以获得“WAN完成效果”。这种混合流程据称在保持WAN 2.2输出质量的同时，将图像生成时间减少约40%。
• 确认了WAN 2.1 LoRA的向后兼容性，允许用户重用现有资源。此外，提到了未来视频渲染功能的潜力，表明功能正在持续扩展。

WAN 2.2模型合并：4步、1 CFG、1模型，速度提升（支持T2V和I2V）（评分：199，评论：108）：**该帖子详细介绍了一种定制的WAN 2.2模型合并方案，用于文本到视频（T2V）和图像到视频（I2V），将“高”和“低”WAN 2.2模型（作为第一/中间块）与WAN 2.1输出块整合为单一架构。该模型集成了VAE和CLIP以简化部署，包含Lightx2v和PUSA LoRA以支持蒸馏，并支持4步、1分类器自由引导（CFG）采样，同时保持WAN 2.1 LoRA兼容性。该方法推荐使用sa_solver和Beta调度器，支持原生检查点加载，强调速度/简洁性，同时可能牺牲运行更大独立模型的性能。**一位评论者请求与基线模型的定量比较，并询问是否有人会量化（“quant”）该合并模型，表明对实证基准测试和进一步速度/效率提升的兴趣。

• 用户对量化版本的WAN 2.2合并模型表现出兴趣，以提高效率。有人呼吁使用相同种子进行直接比较，以评估原始双模型/加速流程与合并模型在速度和输出质量上的差异。
• 提出了关于合并步骤和模型可能导致质量下降的技术担忧：一位用户特别询问与完整20步和独立模型相比是否存在质量下降，表明对性能权衡的关注。
• 一位用户指出，在12GB GPU上，该合并模型在T2V任务中表现强劲，但输出多样性似乎减少——输出更接近WAN 2.1而非WAN 2.2的广泛范围。尽管运行时间更长，用户更倾向于使用原始模型和lightx2v强度1.0以获得更好的多样性。

WAN 2.2 I2V确实令人惊叹！目前为止（评分：191，评论：34）：**该帖子讨论了WAN 2.2 I2V（图像到视频）模型的性能，强调其在将图像动画化为视频时的显著能力和细节表现，尤其是使用完整的WAN 2.2 f16 32GB模型通过kijai包装工作流时。比较表明，完整模型的输出比缩小版变体更详细和动态，凸显了使用完整模型进行高保真视频合成的重要性。**评论者指出，用户社区对这种先进的生成视频技术缺乏足够的欣赏，并推测了其潜在用途，例如将其整合到独立游戏过场动画中以减少制作时间和资源需求。

• 一位用户比较了使用Kijai包装工作流的WAN 2.2输出与完整WAN 2.2 F16 32GB模型，指出完整模型生成的视频具有更多动作和细节，表明模型大小与输出细节保真度之间存在技术权衡。
• 性能和硬件成为关注点，围绕生成时间和硬件要求的问题被提出，以运行WAN 2.2全分辨率。讨论表明硬件规格和模型大小（F16需32GB）对工作流可行性和结果质量有重大影响。

WAN 2.2 I2V连续运动尝试（评分：130，评论：44）：**OP尝试使用WAN 2.2进行图像到视频（I2V）生成，通过从静态图像（WAN t2i）迭代外推视频，然后使用每段的最后一帧作为种子链接段。技术讨论集中在处理退化（如运动模糊、光照、不一致特征）和潜在缓解措施上。工作流为720p@16fps，提升/插值至1080p@60fps；关键问题是帧选择因运动模糊阻碍连续性。**评论者指出WAN 2.2模型在链接迭代中保持质量，视觉退化极少，可能表明模型的鲁棒性。技术辩论围绕是否在反馈最后一帧前应用图像到图像（I2I）细节增强展开，但WAN 2.2的稳定性可能使此步骤变得不必要。

• 一位评论者观察到，与迭代帧扩展工作流中常见的视频质量退化相反，WAN 2.2在连续帧生成中保持高质量——起始帧和最终帧几乎没有可见退化，表明该模型版本在视频帧一致性上表现稳健。
• 技术推测围绕使用中间图像到图像（I2I）通道增强最后一帧的细节后再循环生成。然而，鉴于WAN 2.2的输出稳定性，这一额外步骤可能不再必要，从而简化连续视频合成，减少手动质量干预。
• 一位用户指出，尽管存在一些拼接或过渡瑕疵，但在关注故事内容时这些瑕疵可以忽略，表明WAN 2.2在帧链接中的视觉伪影对沉浸式应用来说处于可接受水平。

现在生成的视频已经逼真到第一眼可能误以为是真实的。（评分：607，评论：64）：**该帖子讨论了AI生成视频的最新进展，强调仅用少量提示词（“每个仅一两句话”）生成的片段在视觉上已足够逼真，可能被误认为是真实镜头。内容突出了生成模型真实感的显著进步，可能涉及Sora或类似文本到视频合成模型的改进。**热门评论反映了对AI输出真实性和娱乐价值的积极评价，但未提供技术讨论或批评。

• AndrewH73333指出了当前AI模型在视频生成中的一个局限：由于训练数据不足，AI难以生成对较少记录事件（如“钢琴在水下后会发生什么”）的合理结果。这表明生成模型在边缘案例或罕见场景中合成真实输出的能力依赖于全面多样的数据。
• eOMG注意到当前AI生成语音的一个特点：尽管高度先进且初看真实，但细心的听众仍能识别出将其与真实人类语音区分开的细微人工痕迹。这一观察反映了文本到语音或多模态生成模型在韵律、语调或上下文意识上的持续小缺陷。

• Claude 现在可以通过移动设备帮你发短信、写邮件和安排日程 (评分：214，评论：45)：Anthropic 的 Claude AI 移动应用现在支持起草邮件、短信和会议邀请，用户只需轻点一下即可通过原生应用发送（公告）。技术实现上，尤其是 Android 版本，可能利用了 Android 操作系统的 Intent 系统来预填充邮件主题和正文，但保留收件人字段为空以保护隐私。这种设计减少了应用权限需求，符合隐私优先的理念。 热门评论提到高等级计划（如“Max x5 计划”）的速率限制问题，并倾向于这种间接方式，避免直接访问通讯录。用户认为这消除了使用 Signal 等平台进行 DIY 自动化的需求。

一位评论者推测，Claude 的 Android 实现可能通过原生 Intent 系统启动邮件草稿，仅传递主题和正文，而将收件人字段留给用户填写，从而优先保护隐私。

• 讨论的技术限制包括 Claude 的对话长度上限可能打断工作流；用户希望增加类似 GPT 的早期警告、上下文总结或滚动对话功能，以更高效地管理长线程和上下文保留。
• 技术用户的对比反馈指出，20 美元档的 GPT 桌面体验优于 Claude 更高价计划（20 倍），认为其在长对话和集成方面更优，并希望 Claude Code 能原生集成 Gmail 和日历，无需额外权限或中间件。

Claudeholism：新时代的上瘾症 😞 (评分：132，评论：58)：帖子报告了用户对 Claude Code（Anthropic 产品）的高度依赖，认为其在生产力和代码生成方面优于 GitHub Copilot、Google Gemini、JetBrains AI Assistant 和本地 StarCoder 2 模型。用户提到 Claude Code 能生成可运行代码（如 Pulumi 脚本、Clean Architecture）和流畅的上下文感知代码注释，而其他工具存在幻觉、代码理解不足或硬件要求高等问题。 评论者一致认为 Claude Code 显著提升了生产力（快速原型设计、迁移和工具开发），并形成了令人上瘾的工作流；其上下文集成（包括访问本地文件）使其他大模型相形见绌，尽管偶尔会出现幻觉。有人指出，这种无缝的 LLM 辅助开发改变了使用模式和期望。

• 一位用户详细描述了 Claude 如何快速完成原型设计，将论坛从劣质平台迁移到自定义 Nuxt + Supabase 架构仅用数小时，并快速构建咨询工具，强调其效率提升和与传统工作流的对比。
• 另一位用户提到，LLM 与本地计算机访问的结合极大简化了开发流程，尽管偶尔出现幻觉，但其流畅性和生产力优势远超其他解决方案。
• 关于 Opus 订阅档位的讨论显示，从 200 美元降级到 100 美元（Pro 计划）会显著限制使用量，高等级计划对重度创意用户是刚需。用户还提到，“氛围编码者”的需求激增可能进一步限制访问，导致低档位计划仅能满足约 70% 的工作需求。

你们在构建什么项目让 Claude Code 达到极限？ (评分：105，评论：110)：发帖者是一位资深工程师，拥有深厚的后端、全栈和机器学习经验，询问哪些项目会耗尽 Claude Code（Sonnet 和 Opus 模型）的上下文窗口。他们指出，代码迭代通常是团队协作过程，平台复杂性（如 Supabase、PlanetScale）只是额外层级，而非核心问题。他们希望了解具体的工作流或代码库如何真正挑战 Claude Code 的极限。 评论者提到，重度使用通常是为了最大化上下文窗口，而非项目规模——包括为模型加载完整文件上下文、相关类、文档和提示词中的代码规范。这导致令牌快速耗尽，有用户报告在 5-6 次提示后就用完了 Opus 计划的配额。讨论还暗示，部分使用可能并非高效工作，而是生成“垃圾”代码或滥用配额。

• Claude Code 的主要技术瓶颈是其上下文窗口：与熟悉项目的人类开发者不同，每次新会话都像为新开发者提供完整上下文，包括相关文件、类、抽象层、实现示例和文档。这种“入职”开销加上严格的代码规范和生成后检查，迅速消耗令牌——用户报告在几小时内用完 100 美元 Opus 计划配额，有时甚至单次提示后就会收到令牌警告。
• 部分用户将会话视为批量“入职”，加载大型代码库和参考资料以生成符合标准的精确代码和自动检查。这种工作流令牌消耗高，但对深度调试或大规模重构是必要的，凸显了当前上下文/令牌架构在处理复杂项目时的局限性。

Claude 现已入驻 X（@claudeai） (评分：210，评论：51)：帖子宣布 Anthropic 的 AI 模型 Claude 现已正式入驻社交平台 X（原 Twitter），账号为 @claudeai。附图中未提供技术细节，但可能展示了账号或相关公告。评论主要关注账号真实性，未涉及技术讨论。 有用户询问“这是真的吗？”，但未展开关于模型实现、能力或与 X 集成的技术讨论。

• 一位用户提到 Claude 的某些响应行为无法通过定制功能（如 Claude.md）抑制，例如反复出现的短语“You’re absolutely right!”。这表明模型的核心行为可能覆盖用户偏好，反映了当前提示词定制或扩展性的潜在限制。

Anthropic 与 xAI 对比 (评分：792，评论：47)：帖子对比了 Anthropic 和 xAI 两家知名 AI 公司，隐晦提及它们的商业策略、声誉差异以及与重大合同（如军事）的关联。评论者指出 Anthropic 专注于争取军事合同，而 xAI 的起源和意图存在争议，尤其是创始人动机和利润驱动。图片本身作为视觉对比引发社区讨论，未直接提供技术基准或模型细节。 评论者对 xAI 的动机表示怀疑，引用 Elon Musk 的言论并暗示其追赶或利润动机；其他人则对比两家公司的伦理品牌和财务重点。

• 讨论简要提到军事合同是塑造 AI 模型格局的关键战略因素，暗示这是大规模 AI 开发中常被忽视的重要点（如 Anthropic 可能已获得此类合同）。
• 对主要 AI 玩家（Anthropic、xAI 和 OpenAI）商业模式的隐晦比较表明，合同收入（包括军事和企业）对其长期可持续性和竞争定位至关重要。
• 参与者讨论了品牌命名、模型功能和领导者公开声明的声誉与伦理影响，凸显了对 AI 实验室宣称的安全伦理与实际产品方向之间一致性的持续担忧（如对 Elon Musk 在 xAI 和 OpenAI 中动机的怀疑）。

• Qwen3挑战GPT-4o争夺AI霸主地位: Qwen发布了Qwen3-30B模型，宣称其在英语和中文基准测试中与GPT-4o不相上下，通过Unsloth GGUF版本运行时仅需33GB RAM。用户反馈量化版本仅需17GB RAM，引发了关于其在实际应用中与OpenAI的GPT-4o性能对比的讨论。该模型因其在多语言任务中的潜力而令工程师兴奋，基准测试显示其在某些测试中与GPT-4o持平甚至超越。
• GPT-5传闻点燃AI竞争热潮: 工程师推测GPT-5可能在8月初发布，线索包括在ChatGPT Mac应用缓存文件中发现的“gpt-5-auto”字样（详见X）。讨论将其与Gemini 2.5 Pro等竞争对手进行比较，并提到可能集成到Microsoft Copilot以及对模型排名的影响。用户根据泄露的架构细节，争论GPT-5是否会在推理任务中占据主导地位。
• GLM 4.5 Air模仿Gemini的技巧: 工程师测试了GLM 4.5 Air，发现其在聊天和诗歌分析中模仿了Gemini的行为（详见博客文章）。工具使用在vllm中失效，但在文档搜索中表现良好，引发了与GPT-4o的对比。该模型凸显了阿里巴巴对多功能替代方案的追求，用户注意到尽管存在一些小问题，但其稳定性仍然值得称赞。

• API 阻止低质量量化操作：OpenRouter 的 API 允许工程师指定量化级别，以避开低精度模型（如 FP4），具体可参考供应商路由文档。这一功能阻止了不支持的格式，确保模型在跨平台路由时的高效性。用户称赞这种控制能力减少了生产环境中的错误。

• MCP 服务器遭遇上下文危机：工程师们讨论了在云端部署的 MCP 服务器 中添加用户上下文分离层，以防止数据泄露，相关讨论见问题 #1087。某次配置通过 Cursor 连接成功，但在 Claude Desktop 上失败，突显了集成中的缺陷。这强调了在多客户端环境中需要更健壮的协议。

• Litellm API 避免连接混乱：用户报告了 litellm.APIConnectionError 解析问题，但指出功能仍能正常运行，通常与不正确的分块格式有关。工程师分享了在 API 调用中使用双引号属性名的修复方法。这一错误揭示了 AI API 链中的常见陷阱，推动了对更好错误处理标准的需求。

• 量化技术显著提升计算速度：Unsloth的量化技术不仅减少了内存需求，还降低了带宽占用并提升了计算速度，这一点在Qwen3-30B的测试中得到了验证。工程师们发现，将视觉操作（如卷积层）保留为FP32会导致性能瓶颈，因此建议采用混合精度以实现平衡。这种方法在不牺牲准确性的前提下大幅缩短了推理时间。

• Gemma 3在微调后完全去除了水印：在16k上下文环境下对Gemma 3 4B进行微调后，实验完全移除了水印，从而提升了模型的稳定性，具体效果可参考截图。工程师们对此进行了权衡讨论，同时一项在X上宣布的竞赛将在7天后结束。微调增强了模型在技术任务中的实用性，使其成为无审查应用的理想选择。

• 专家并行在Qwen的测试中表现不佳：工程师们发现，在Qwen32B和Qwen 235B中，专家并行（EP）的表现不如张量并行（TP），原因是all-reduce操作的开销过大，具体分析详见博客文章。EP仅在具有MLA和DP注意力的模型中表现优异。这一发现为高效扩展的硬件选择提供了指导。