V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ClericPy  ›  全部回复第 1 页 / 共 137 页
回复总数  2721
1  2  3  4  5  6  7  8  9  10 ... 137  
@blushyes 都有这问题,linux 上还有 tmux 用,Windows 上的终端真都一坨。。。

terminal 分屏用了一会,后来也放弃了

现在各种生态工具雨后春笋一样,感谢开源
早晨一睡醒还刷到个叫 nezha 的类似的

反正 vscode 还够用继续观望着,让子弹飞一会,现在的浏览器和编辑器动辄三四 GB 内存真的很蛋疼
下午 5.1 国内版的慢的要死,都以为没法用了,换回 turbo 勉强够使了。控制台里它怎么有脸说 pro 版 tps 在 80+ 的
@teaguexiao 我试试打印时间,CCSwitch 有计算每个请求的 Token ,这样应该可以搞定,感谢。
现在对输出速度快的爱不释手。
@qf19910623 没点到回复你。看上面吧

opencode go 折腾一晚上,最后还是靠代理模式转的。

ollama 倒是一下就配置好了,也是代理模式

点测试就没比 glm5 turbo 快的( 600ms ),其他所有国内外的都 2s+
ollama cloud 试了免费的,马马虎虎不快不慢的

买了一个月 opencode go ,官方文档给的方式没法直接配到 cc 里,靠 complete 接口开代理( cc-switch )用上了,速度不是很快的感觉

准备试试 highspeed 的 M2.7

唉,如果能有个平替 GLM5 turbo 的也行,这东西首 token 也快 TPS 也高,太爽了。。。最后实在没选的再看看买它吧,续费不让用 starter 套餐了
@longxinglink 看到有个老外评测各种模型,买的 pro 套餐量很足,就想知道它这个网络连通性需要科技么

刚退了 copilot ,找不到靠谱的就想直接买 minimax highspeed 了。 不知道 ollama 那边模型 tokens/s 能到多少,20 刀挺实惠
11 天前
回复了 imgse 创建的主题 程序员 GLM lite 国际版都$18 了,还不支持退款
glm5 turbo 爽用了一周多,非常不错

如果 5 月开始用量恢复三倍,那就只好跳 minimax highspeed 了。

国内的基本用了个遍,没试上 mimo2 和 qwen3.6 plus ,最后结论就是 glm5.1 很强但慢,glm5 turbo 是我现在首选;性价比来说 minimax highspeed 据说能到 100 tps 但实际用下来 60~80 多,glm5 turbo 倒是稳定 90+

模型质量对 plan+linter 各种约束好的 coding agent 来说只能算锦上添花,tps 性能才是我关心的
3 月 28 日
回复了 beetlerx 创建的主题 GitHub Copilot 关于 github copilot 0x 的模型
@ztm0929
我问了 gemini ,也问了 github 官网上的 copilot ,都说违规,问了豆包也这么说。。。

明明人家和 opencode 都友好集成,唉

反正 claude code + 国产模型已经解决问题了,先退订了,省下的钱多试试几个国产模型
3 月 27 日
回复了 beetlerx 创建的主题 GitHub Copilot 关于 github copilot 0x 的模型
@ztm0929 前天刚续费上,昨天刚从 cc-switch 挂代理用上它,今天听你这句话,取消续订了一年的了,唉
coding plan 赌的不是人买完忘记用,赌的是大量相似代码命中缓存或者优化的 tokens 。结果一群人拿来养龙虾,不好使了
3 月 25 日
回复了 xitler 创建的主题 程序员 [纯吐槽]没想到 minimax 会这么难用
我好奇 highspeed 套餐真那么快吗?
3 月 22 日
回复了 tw93 创建的主题 Claude Code 你不知道的 Claude Code:架构、治理与工程实践
当赞
总结了很多之前朦胧懵懂蒙蔽的东西,隐性知识显性化是个很难得的产出
性能这东西,去年还挺关注,今年估计直接拿日志和源代码让 cc 分析一波找到瓶颈,pyo3 会不会更贴合一点

这么多年了,Cython pypy 什么的也一统江湖,反而 rust for python 越来越接近主流的样子

现在 coding agent 这么强,faster-python 真的有一种不进则退的感觉了。。。
这个方案之前 v2 里没搜到,在老外那边搜到过

谢谢分享,cc-switch 这段时间貌似也有个 pr 合了就是这功能
1 月 28 日
回复了 refsdiary 创建的主题 生活 今早上班路上见闻!
他们也知道自己是骗子,也知道别人知道他们是骗子,那他们为什么有收入?

自从发现有放生巴西龟、清道夫、矿泉水的以后,说明这个世界不缺那种喜欢感动自己的人,总有人明知是骗也会刷点“功德”,毕竟成本足够低,万一有用呢
都分别用了 3 天以上,oh my opencode 没体验到特别惊艳,可能没让它做大项目,就冲 cc 新版本的 vscode 插件兼容性比 oc 舒服,就暂时不用 oc 了

实际体验中,oc 写 Python 在 python -c 里对 diff 做单元测试感觉挺有意思的

然后就是配置。。。cc-switch 上的 skill 什么的折腾的头晕眼花,oc 和 cc 在 vscode Windows 上一个劲弹 nodejs 的黑框很头疼
1 月 21 日
回复了 frankyzf 创建的主题 计算机 有能用的住的鼠标吗?
买了俩迈从了。。。不知道能用多久,打游戏习惯了就办公也搞了个。。
曾经也遇到过,CPU 密集型把协程卡死出现过 3 次,两次是 selectolax 、lxml 的解析十几万字符的 HTML ,一次也是类似你的情况解析十几 MB 的大 JSON (特么的有人把一大堆图片做 base64 放 JSON 里了)。最后 hadoop 直接超时杀死还没看到报错

python 在有些场景确实体现了并发上的先天不足:

1. 多线程不能利用多核,所以有些时候要自己开进程池,明明是无副作用的纯函数却要共享个 GIL 。子解释器希望有用但不太期待

2. to_thread 能让协程不至于因为一个 CPU 特别忙的任务一直 hang 在那。

但是现在非常尴尬的一个地方是,我也不知道哪个函数是敏捷的小函数还是 CPU 秘籍的大函数

在协程里的一个困境就是:

1. 同步函数无脑放 to_thread ,对于特别多的小函数开销很浪费。
2. 为了计算密集型的放 ProcessExecutor 里,子进程也很费事。

现在的协程,只能尽最大可能保证全程协程,不耦合太多同步函数进来

PS:当年 hang 死的问题,现在看书知道 asyncio 开 debug 模式就行了,然后在公司里 langchain 的一个项目日志里,几百条阻塞 warning 日志。。。。。。
1  2  3  4  5  6  7  8  9  10 ... 137  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   5501 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 63ms · UTC 06:46 · PVG 14:46 · LAX 23:46 · JFK 02:46
♥ Do have faith in what you're doing.