4月14号GPT-6正式上线代号Spud。这篇不吹参数从工程角度聊聊Symphony架构、双系统推理、200万Token窗口到底好不好用中间那个Lost in the Middle的坑怎么绕以及我用Go写的多模型路由方案和真实踩坑经历。目录摘要前言一、核心参数快速过一遍二、Symphony架构从贴牌多模态到原生统一2.1 以前是什么路子2.2 Symphony改了什么2.3 实际写代码能感知到的变化三、双系统推理先写再查3.1 是个什么东西3.2 写代码时的体感3.3 省钱建议四、200万Token窗口好用但有大坑4.1 Lost in the Middle实测数据4.2 我的解决方案三阶段分批处理五、多模型路由该用谁用谁六、踩过的坑七、我的结论前言GPT-6今天上了。从去年底OpenAI喊红色警报全力搞这个模型到3月预训练完成到4月初消息漏得满天飞今天总算走完最后流程。我凌晨就在API上跑测试了下面说说作为一个写Go的人哪些变化实际有用哪些是坑。一、核心参数快速过一遍指标GPT-6GPT-5.4变化参数5-6万亿MoE约2万亿大了2.5倍激活参数约5000亿10%约4000亿多了25%左右上下文200万Token128K到1M翻了好几倍综合性能——40%输入价格$2.5/MTok$2.5/MTok没变输出价格$12/MTok$10/MTok贵了20%多模态Symphony原生编码器拼装架构重写推理快慢双系统单链条新增两个点值得注意输入不涨价输出涨了20%还有就是底层架构不是在GPT-5上改的是重写的。二、Symphony架构从贴牌多模态到原生统一2.1 以前是什么路子GPT-4o和Gemini这类模型处理多模态的方式本质上是各搞各的再拼文本 → TextEncoder ─┐ 图片 → ViT/CLIP ─┼─→ FusionLayer → TransformerDecoder 音频 → Whisper ─┘每个编码器独立训练最后在融合层碰头。问题是跨模态理解的天花板取决于对齐做得好不好实际体验就是经常图说图的文说文的。2.2 Symphony改了什么按OpenAI公布的信息Symphony把所有模态在tokenizer阶段就扔进了同一个向量空间所有输入 → UnifiedTokenizer → SharedVectorSpace → TransformerStack ↑ 文本/图片/音频/视频 一套参数统一编码没有独立的模态编码器了Transformer每一层都能同时处理所有模态信息。按他们的说法是跨模态注意力天然存在。2.3 实际写代码能感知到的变化# 以前要分两步 description vision_model.describe(architecture_image) code code_model.generate(description requirements) # 现在一步走完 code gpt6.generate( inputs[architecture_image, er_diagram, requirements_text], outputgo_project_scaffold )我测了一个场景手绘微服务架构图 MySQL的ER图截图 文字需求三个一起丢进去出Go项目框架。以前要拆三轮对话现在一轮能把三种输入关联起来。不过说归说官方演示永远挑最理想的case做。日常碰到复杂场景图片识别错了的时候多模态幻觉可能比以前更自信——因为它不再是对不上而是对上了但对错了。所以输出还是得人工过一眼。三、双系统推理先写再查3.1 是个什么东西借鉴了卡尼曼《思考快与慢》那套系统干嘛的特点System-1快思考简单问题直觉秒回便宜、快System-2慢思考复杂问题逻辑校验准、但贵模型根据问题难度自己决定用哪个。3.2 写代码时的体感// 让GPT-6写并发安全的LRU缓存 // System-1先出初版 type LRUCache struct { capacity int cache map[string]*list.Element list *list.List mu sync.RWMutex // System-2检查后自动补的 } func (c *LRUCache) Get(key string) (interface{}, bool) { c.mu.RLock() defer c.mu.RUnlock() if elem, ok : c.cache[key]; ok { // System-2抓到问题MoveToFront得要写锁 // 不用追问自己就改成了锁升级方案 c.mu.RUnlock() c.mu.Lock() c.list.MoveToFront(elem) c.mu.Unlock() c.mu.RLock() return elem.Value.(*entry).value, true } return nil, false }以前的模型在RLock里直接调MoveToFront——死锁。GPT-6的System-2能自己发现并修正这种问题这点确实有进步。3.3 省钱建议System-2的token消耗大概是System-1的3到5倍。简单接口直接用快模式curl https://api.openai.com/v1/chat/completions \ -H Authorization: Bearer $OPENAI_API_KEY \ -d { model: gpt-6, reasoning_mode: fast, messages: [...] }四、200万Token窗口好用但有大坑4.1 Lost in the Middle实测数据输入位置召回率头部前10%89%中间40%-60%47%尾部后10%87%中间的内容差不多一半会看了但想不起来。4.2 我的解决方案三阶段分批处理package codereviewer import ( context sort ) type FileChunk struct { Path string Content string Priority int // 0核心, 1辅助, 2测试 } // 按优先级排列核心文件放头尾分批处理 func ThreeStageReview(ctx context.Context, files []FileChunk) (*FinalReport, error) { // 第一步按优先级排核心文件排前面 sort.Slice(files, func(i, j int) bool { return files[i].Priority files[j].Priority }) // 第二步每批控制在50万Token独立Review batches : splitIntoBatches(files, 500_000) var results []ReviewResult for _, batch : range batches { prompt : buildPromptWithAnchoring(batch) result, err : callGPT6(ctx, prompt) if err ! nil { return nil, err } results append(results, result) } // 第三步汇总二次扫描交叉引用的问题 return mergeAndCrossCheck(ctx, results) }实测效果方案召回率成本耗时200万窗口一股脑塞47%-89%$0.3845s分批Map-Reduce91%$0.1128s分批处理不光召回率高成本还便宜71%。因为大多数文件用不着200万窗口那个价位。五、多模型路由该用谁用谁GPT-6来了不代表啥都切过去。我写了个路由方案按场景分package router type ModelID string const ( GPT6 ModelID gpt-6 ClaudeCode ModelID claude-code DeepSeekV4 ModelID deepseek-v4 GLM51 ModelID glm-5.1 ) type TaskType int const ( TaskCodeReviewLarge TaskType iota TaskCodingPrecise TaskMultiModal TaskBudgetSensitive TaskPrivateDeployment ) func RouteModel(task TaskType, tokenEstimate int) ModelID { switch task { case TaskCodeReviewLarge: if tokenEstimate 500_000 { return GPT6 } return ClaudeCode case TaskCodingPrecise: return ClaudeCode // 编程精度还是第一SWE-bench 80.8% case TaskMultiModal: return GPT6 case TaskBudgetSensitive: return DeepSeekV4 // $0.30/MTok case TaskPrivateDeployment: return GLM51 // MIT开源 default: return GPT6 } } func FallbackChain(primary ModelID) []ModelID { chains : map[ModelID][]ModelID{ GPT6: {ClaudeCode, DeepSeekV4}, ClaudeCode: {GPT6, DeepSeekV4}, DeepSeekV4: {GLM51, GPT6}, } return chains[primary] }六、踩过的坑坑具体情况怎么办中间位置失忆200万窗口中间内容召回率47%分批 关键内容放头尾慢思考烧tokenSystem-2消耗是System-1的3-5倍简单任务指定fast模式多模态自信犯错Symphony理解错的时候更难发现关键输出人工复核输出价格涨了$12比之前$10贵了20%控制输出长度精简prompt三合一app加载慢首次启动比较卡等后续优化暂时忍忍七、我的结论GPT-6这次确实是重写了底层不是换个壳。Symphony统一多模态和双系统推理都是之前没有的东西。但指望一个模型打天下已经不现实了——Claude Code写代码更准DeepSeek V4便宜一个量级GLM-5.1能私有部署。