https://linux.do 论坛的话题更新通知频道。
@iceroad 在 WSL2 终端交互极其卡顿、断联 中发帖
使用 Tabby 终端操作时,响应极慢,存在明显的输入延迟。
环境运行一段时间后会进入“假死”状态,SSH 无法连入。
已尝试限制内存并在 .wslconfig 中禁用 Swap,但改善不明显。
本人新手,今天进行在VPS上部署openclaw明显感觉这种卡顿感,尤其是过了一会没用就有死机的感觉,有没有大佬能解答我的困惑
@LucentSnow 在 在gpt5.5出来之前,炮轰一下gpt5.4 中发帖
今天又是被gpt整红温的一天,gpt5.5据说要来了,并且还开始讲人话了,但是我又转念一想,再不骂就没机会了,就把我遇到的恶心事都给分享出来。
首先就是gpt5.4满嘴的黑话,l站的这种帖子真是屡见不鲜,其实这都是gpt最小的问题了,毕竟codex自己慢慢搞,我也懒得看他在做什么,大家估计也都习惯了,日常生活中可能也会用“落”“砍”这种词(习惯了真的没问题吗)
第二个我把不说人话拆分出来就是输出极其复杂和八股,他默认的输出就非常非常长,网页端还能看,在codex里终端本来就黑,md还没法渲染,gpt自己的分段形式还不好,你要是提示词不好,基本都要中译中,比如你让他分析一个仓库,他百分之一百给你一堆代码片段和位置,密密麻麻贼恶心。
指令遵循能力“过强”,完全不知道变通,也不带脑子思考,你说错了他肯定执行到结尾。举个我之前的例子,我发现他某个地方搞错了,赶紧停止然后让他撤回,结果他直接跳...
DEDE-cn F 在 CRS 服务不稳定,显示 reconnecting 中发帖
[mmexport1776958214550]
如上图,下午 3-4 点特别不稳定,难道是因为用的人多了?有人遇到过这中情况吗?升级机器是否有帮助呀
@Piscesbody 在 [Qwen3.6]27B-FP8 VLLM本地部署主观个人测评 中发帖
硬件配置
组件
规格
CPU
Intel i5-13600K
GPU
RTX 4090 48G + RTX 4070Ti 12G
内存
DDR4-3600 128G (4x32G)
主板
华硕 Z690-P D4
系统
Windows 11 LTSC
WSL
Ubuntu 22.04
VLLM版本:0.19.1
部署指令:
uv venv vllm-env --python 3.12 --seed --managed-python
source vllm-env/bin/activate
uv pip install vllm --torch-backend=auto
启动参数:
vllm serve /root/LLM/Qwen3.6-27B-FP8 --host 0.0.0.0 --port 8000 --tensor-parall...
JARK006 在 蚂蚁inclusionAI在OpenRouter上线了Ling-2.6-1T模型 中发帖
此前在 OpenRouter 的神秘模型 “Elephant Alpha” 确认为 inclusionAI 研发的 Ling-2.6-flash,如今上线了 Ling-2.6-1T 正式版,参数量不小,目前可免费用。
猫猫团子 (@Kuhlman_Trever) 在 官瘾犯了,想当官了 中发帖
《清代野史》记载了这么一个故事:
光绪间,有皖人张传声者,入资为河南候补道,加花翎二品衔。其面目臃肿有痴态,腹如五石瓠,食兼数人。需次汴省无差委,每日晨起盥漱早食毕,即冠珊瑚冠、孔雀翎,数珠补服,由内室而出,中门置一云板,出则击之,仆则高呼“大人下签押房矣”。既就坐,一仆进茗碗,一阍者持手版十余如折扇式,口称“某某等禀见”,其实并无一人也。张则手举茗碗,作官腔曰“道乏罢”,阍者斜步出,则又高呼曰“传伺候,大人下来矣”。张乃雅步登肩舆,出门拜客矣。亦每日如是,如演剧然。此叶孝廉士芬为予言。叶、张之同乡也,癸卯借汴闱报罢后即馆其家,初见此状,不觉大笑,以为此公殆官痴也。张丁外艰,奔丧归,死于中途逆旅中。
说这光绪年间,安徽有个叫张传声的人,花钱捐官,做了河南候补道台,二品大官,戴着孔雀花翎。
这个张传声长得胖胖憨憨,肚子很大,饭量也惊人。
因为当时当官名额早就满了,他一直候补、一直...
@agi_is_coming 在 百尺竿头,更进一步。连续100天了 中发帖
[Screenshot_2026-04-24-00-15-12-722_com.android.chrome-edit]
兜兜转转咋也是连续登录100天了 :tieba_066:
希望后续在L站,发布宣传我更多的开源项目吧 🤓
kairo (@Deng_Roo) 在 GPT-IMAGE-2生图有问题? 中发帖
为什么生成的绝大多数图片有这么多的噪点,还有这个模型生成的图片细节“丰富”的太夸张了,好像只有海报/产品/视觉设计这一块可以。
[image]
@agi_is_coming 在 疑似codex中5.5上线了,原来设置得gpt5.4,1m上下文被路由了. 中发帖
[CleanShot 2026-04-24 at 02.15.51@2x]
登录的是codex pro 20x的账号
在使用codex cli时刚刚给我跳出上下文长度超过了的提示,
怀疑是路由到了新的gpt 5.5,上下文长度只有256k.
没有gpt-5.4的 1M上下文
@VrianCao 在 GPT新模型(大概率为GPT-5.5)已确认将在稍候发布 中发帖
OpenAI在Codex的模型列表中
移除了对GPT-5.4“最新最前沿”的相关描述
[20260424001008]
此内容被X网友 @JasonBotterill 看到后引用并说
OpenAI has updated codex model list so gpt-5.4 no longer says “latest frontier”
随后 Codex 负责人 Tibo(@thsottiaux)回复:
👀
[IMG20260424001225]
[IMG20260424001236]
Mozi (@yeahhe) 在 AI绘画大赛:谁的原子弹画的最好(要求使用GPT image 2) 中发帖
参考文章
奥特曼首次体验 GPT-5!被吓到眩晕瘫坐
[PixPin2026-04-2400-10-27]
[image]
@puppywang 在 VSCode insider + Copilot BYOK + CLIProxyAPI 超低资源占用爽用Codex 中发帖
RT,Codex随着不断优化,在VSCode中交互的确越来越好,甚至给Copilot都慢慢有点向Codex的交互靠拢,但是OpenAI家的工具啥都好,就是资源占用太高了,Codex打开一个会话,不管聊不聊,分分钟占满一个内核,而且根本不带释放,加上权限要么默认,要么给全部权限,前者动不动就弹窗要权限,打断工作流,后者看到各位佬的删库消息心惊胆战,都不敢用,找了一圈佬们用的方案,大部分是反代出来给CC用,但说实话,作为GUI党,CC的VS扩展也就那样了,感觉还不如Codex,转来转去终于找到了一个好用的方案,那就是安装 VSCode insider, 然后配置 Copilot的 BYOK,搭配CPA来反代GPT,好处有三:
Copilot 在VSCode 是一等公民,交互最棒
Copilot 资源占用极低,开几个窗口,CPU占用还么有一个Codex高,而且不工作就不占CPU
Copilo...
Space (@Space1) 在 求解,为什么CPA里使用gpt,/models正常,/responses 404 中发帖
[image]
=== REQUEST BODY ===
{“model”:“gpt-5.4”,“instructions”:"You are Codex,
=== RESPONSE ===
Status: 404
Access-Control-Allow-Headers: *
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
@Caphhh 在 gpt-5.5 似乎忘了markdown的语法是什么了? 中发帖
如题, 是在使用cherry Studio时发现, 今晚频繁出现代码块渲染不正确的问题, 看了md源码发现gpt5.4(按理说应该灰度到5.5了) 竟然稳定地在代码块尾部少了一个"`"
我使用的是CPA+自建plus号池, 保证是真模型
[PixPin2026-04-2400-01-18]
[PixPin2026-04-2400-01-37]
ironfish 在 关于CPA配置GPT-IMAGE-2的一些收货(CLAUDE整理,大家也帮忙指正一下) 中发帖
核心结论
CLIProxyAPI(CPA)是将 Codex CLI OAuth 会话包装成 OpenAI 兼容 REST API 的反代工具。其图像生成不是独立接口,而是通过 gpt-5.4-mini Chat 模型的 image_generation 工具调用实现的。暴露的 gpt-image-2 模型名是硬编码别名。
主要价值:调用走 chatgpt.com/backend-api/codex 路径,不产生聊天记录,无 chat 侧边栏副作用。
主要局限:Plus 订阅下质量封顶 medium,transparent 背景不支持。
部署要点(Docker)
docker-compose.yml 关键配置
services:
cli-proxy-api:
image: eceasy/cli-proxy-api:latest
pull_policy: always...