书接上文 https://linux.do/t/topic/2894800 之前跑了几个测试跑上瘾了，我感觉提示词还是不够复杂。于是我让gpt 2.5生图了一张，然后用这张图结合gpt6模型又继续写了一份比较详细实施细则和验收清单。主要的目的就是让模型不管手段去复现图片的场景建模； 如图这个就是本次要复现的场景，感觉还是比较复杂的。分别用k3-256k和1m的版本都跑了一次，结果还是比较惊讶的，见下文： 先把glm 5.3的结果拉上来溜溜先 用的glm 5.3加上53Flash子代理协作完成的。整体还是挺不错的，可圈可点，缆车、灯塔、小人骑车、船和电车都做出来了，而且识别到了这个参考图的阶梯式地形，有努力往这方面靠。可惜的是右边红桥和左边的阶梯长廊没有复现出来，均已失败告终； 然后是kimi发布的不明所以的k2.8模型，波浪地形起码看出来它努力过，可圈可点的只有缆车和这个电车，行进路线玩了点花样，其他的就没有新意了。整体还原度不如glm 5.3，比较明显的时钟以及小人骑车的bug都挺拉跨的。感觉这个模型真是哪哪都讨不到好 上面的雷霆之作出自于ds 4.1Flash模型，刚出来的时候我完全不知道该看哪里。这一次拉完了，我猜测可能是ds的多模态识图能力所导致的，因为工作文档有一张参考图，模型建模过程中都会不断的对着参考图进行校准测试，可能是因为ds的识图过于拉胯所导致的这一次结果吧。无法评价，skip； 这次是k3-256k版本给出的答案，人物出现明显的螃蟹步了，右边的地形还原以失败告终，缆车和风车都与地形产生较严重的冲突。感觉没什么好说的，意料之中的情况，只能说稍比k2.8强一点；整体稍强一点的就是电车和灯塔以及骑车小人了，稍微看上去像那么回事； 原本这次的测试应该告一段落了，过了几天在kimi code的cli中使用k3的时候，发现一个挺明显的问题的，似乎k3-1m的模型Id比k3-256k的要聪明一些。于是我又想起了这个建模任务，于是我也让k3-1m这个iD来跑了一下试试，没想到这次的结果比原先要好许多。为了避免上下文窗口不同的影响，我的上下文窗口是打在了300k去执行的任务。 这次k3-1m的结果出来确实很惊艳啊，我感觉整体的地形还原度是最高的。广场和码头都挺好看的。唯一美中不足的就是这个船到最后都没有修复好逻辑，以及缆车似乎高度不够。这一次询问k3怎么做到的，回答说用了相机拟合（Gauss-Newton）和锚点登记逐点定下来的空间布局关系。 然后经过尝试，也告诉大家k3-1m的消耗和k3-256k的消耗，怎么说跟官方的说法是一模一样的，2倍消耗，之前在kimi的飞书群就有一个说法是k3这2个id的内部会员订阅消耗的速率是一样的，费用不一样是因为k3-1m的上下文打起来比较长后，缓存的费用随之拉了上去。但是这次手动限制了上下文在300k的情况下，费用仍然呈现2倍的情况，以及智商不一样，因此我合理的怀疑就是k3的256k这个模型被降智了，2个id路由的是不一样的模型版本 另外大家可能会发现这个建模有点ds味，没错我一些低价值和重复的任务是用ds去跑的，主要是涉及一些场景房屋的建模，决定是否采用取决k3的判断，我后面也看了一下全过程以及询问k3的技术细节，整体上来说空间布局关系锚点都是由k3做判断的，ds做的只是听话按照要求去搭建了场景等房屋模型，相当于照着固定下来的js地图去做，后续的涉及bug修补调试都是k3自己完成的。因此这一次结果可以作为大家的日常模型选择搭配去做参考，ds作为牛马模型还是比较香的，但是舵手决策模型还是需要一个旗舰级的模型去做担当 以上仅供大家做参考，没有做过特别严谨的多维度题库测试，主要是没额度了，有额度的哥们可以自行复现一下，看看是不是这么一回事 顺带截图一下官方的模型版本说明 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：硬件与数码
  • 分类依据：内容涉及硬件、数码产品或通信卡
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/20 23:48:14