2. Linux.do
  3. glm-5.2叽里咕噜地说啥呢，没偷偷骂我两句把

glm-5.2叽里咕噜地说啥呢，没偷偷骂我两句把

wawaeryu 2026-06-28 23:17 1


改代码改着改着突然开始说胡话，我以为是我理解能力下降了，结果是它自己搁着幻想上了。


这是纯的官方glm-5.2吗，我是opencode go渠道。

很难绷得住 ^-^

最新回复 (15)
  • 毛毛虫 06-28 23:18
    1楼

    我也发现了上下文长了就会这样子^-^不过没有严重到乱码的程度

    同样来自go渠道

  • dtemiemie 06-28 23:20
    2楼

    官方有时候读起来也挺费劲的 有时候给我一种 5.4 的口癖感觉

    我读 5.5 都还好

  • wawaeryu 楼主 06-28 23:24
    3楼

    我这上下文才不到200k啊，而且刚刚又出现了，我感觉可能它的上下文只有160k才能正常用。

  • 还是不懂 06-28 23:24
    4楼

    https://linux.do/t/topic/2474945?u=arxiv


    go渠道流口水太狠了 感觉被蹬废了

    一点都不美轮美奂

  • 毛毛虫 06-28 23:27
    5楼

    就跟Gemini3一样^-^给你1M的上下文不会真想用1M吧

    还是要及时压缩看来

  • wawaeryu 楼主 06-28 23:28
    6楼



    感觉已经完全废了，没见过这么抽象的。

  • wawaeryu 楼主 06-28 23:28
    7楼

    及时压缩也不至于20%的压缩把，这真太抽象了

  • 毛毛虫 06-28 23:31
    8楼

    因为go渠道有三家glm供应商，似乎有一家供应商量化的很厉害^-^


    看了一下OpenCode Go的官方文档，第一供应商是deepinfra
    [image]
    然后打开deepinfra官网查看模型卡
    [image]
    而官方在HF发布的满血版本则是BF16的
    [image]

    不知道FP4量化版本跟满血的BF16版本的差距有多大。。。
    有佬有能感觉出区别吗？
  • EFL 06-28 23:47
    9楼

    OpenCode 创始人说那个 deepinfra 向 OpenCode 提供的仍然是 fp8 满血版；并且这么大的模型哪怕量化到 fp4 也不会有太大差别。


    楼主的问题就是上下文塞满了。GLM-5.2 实际可用的上下文 200K，很多模型用到一半上下文窗口就会出现性能降级，还是要学一下编排 context

  • wawaeryu 楼主 06-28 23:48
    10楼

    我以为是1M上下文呢，opencode go上下文只有200K啊，我对context windows还是比较了解，只是没想到上下文超200K就淌口水成这样，之前用gpt的时候都是45-60%的context窗口压缩的，第一次碰到这么抽象的。

  • listening 06-28 23:48
    11楼

    我之前用mimo就有这种感觉，一过200k就蠢得流口水。

  • EFL 06-28 23:50
    12楼

    诶我刚刚翻了一圈没找到，不一定只有 200K，但是超过 200K 就成弱智是真的

  • wawaeryu 楼主 06-28 23:51
    13楼

    没找到，不一定只有 200K，但是超过 200K 就成弱智是真的



    那应该就是模型能力的问题了，说明glm在context这块的注意力是有严重短板的。

  • yeluo001 06-28 23:52
    14楼

    200k应该不至于，我之前白嫖某个渠道的token，在claude code经常到300k左右也没这个问题，上下文越长性能越差，但200k我感觉还算是比较稳定的区间

  • EFL 06-28 23:52
    15楼

    看情况，有可能相应提供商部署有问题

* 帖子来源Linux.do
附近帖子
返回
飞读
随机推荐