抡锤者

可能跑分不太能精准表达模型的能力，但是这张质价比图还是有些信息量的：

看起来值得关注的是长上下文后decode速度不掉。

但是，strata我用的时候长上下文decode速度也不怎么掉……

关键得看他这个显卡是不是定制的超丐。戴尔特别喜欢这么玩。

如果是FE，那直接显卡拔下来，就值回票价还小赚。

综合能力、速度等角度，我觉得降个量化精度到Q3级别，也就如此了。
qwen3.6-35B-A3B肯定会快，但是能力降太多了，没有实际意义。

@imbiplaza-ASUS agent同步执行主要的问题就是抽卡的代价太大。通过API调用进去的工作流任务是无法通过web页面更换种子重跑的。对于一些抽卡就能解决的场景，用agent执行个“换个种子重跑”这种东西太不环保了。

然后就是LLM对于图、视频的QC能力目前还是差，多腿、手指异常、违反物理、生物学的运动，这种很容易错漏。所以音视频任务目前我还是不太相信agent自己loop出来的结果。

h3这种耗时非常长的重任务，有必要同步执行吗？

我都是要么让LLM给我提示词，我自己编辑进去。
要么是让LLM调用comfyUI的API执行接口，然后归档，统一执行。队列执行完毕我再告诉LLM来验收。

但是那个被动散热+暴力扇的外形，真的是5000和6000之间的产物吗……

怎么看怎么像6000D+暴力扇……

你看我说啥来的，抡锤娘就秒过

@jian-xu 说:

请问DSH接本地模型，上下文满了，怎么清理

如果配置正确的话（上下文长度，最大输出长度和模型端一致）那么在最后一次请求中，当剩余上下文余量小于输出长度时，就会触发压缩。

偶尔的越过现象可以通过在strata侧配置"fit_max_tokens": true,来一次性解决问题。

越过的本质就是strata的逻辑，只要你的最后session余量小于输出长度，就直接400报错拒绝执行。所以导致边缘情况有可能轻微越过从而压缩失败。
fit_max_tokens就是根据目前的session余量动态配置输出长度，从而规避这个问题。

strata-desktop的agent功能直接集成的就是dsh的实现，只不过版本稍有差异。所以界面几乎一样。
所以从理论上讲，strata-desktop运行的效果和dsh其实是一致的。

只是说会有一些适配上的方便性。

@terry 说:

所有使用IDE写程序的，都是Low B，这就是古法程序员的信仰。

一般这种梗，不是都要上升到用记事本写程序一把编译过。然后再玄幻到手戳纸袋、针扎光盘、口述01这个层级的吗，锤哥怎么不走流程。

前言：本文依旧，无任何AI含量，请放心阅读。

---

先放地址：https://thinkrail.ai/ https://github.com/JetBrains/thinkrail

---

背景：在过去的古法编程时代，编程工具分为两派，一个是以eclipse等为首的“免费派”，以及以Visual studio 以及 IDEA系列为首的收费派。

收费的编程工具有更贴心的一站式操作功能，以及更精细的工作流把控，比如通过编程工具可以直接串联数据库，比如能够有更强大的debug界面等。

但随着AI Coding的来临，这一切都变得没有了意义。就像是汽车来临时，人力脚夫和人力三轮车夫之间的选择。

---

废话少叙，JetBrain推出的thinkRail，本质上是Pi（https://github.com/earendil-works/pi ）的UI再封装。这也是为何其也是开源应用的本质原因。

从界面也能看出，thinkRail充满着对于“古法程序员”控制欲的满足。你随时可以看到当前的目标，todoList，对代码的changes历史。

同样的竞品还有vscode Copilot以及 cursor、TRAE。

thinkRail在立意上的优势，就是其采用了目前人气最高的Pi内核。规避了用户对于Agent应用内核能力的不信任。

但也仅此而已了，以上。

执行力可以的。赞

rtx pro 5000.15秒 x 24fps x 768p ，每step大概150~160秒。

@terry 从官方的说法上讲，所有qwen系列的官宣跑分都是号称在cc+针对性提示词环境下测得的。可以大概理解为qwen系的“专武”是claude code也没错。

claude code的问题还是老样子，一个是冷启动提示词巨大，一个是闭源，一个是提示词针对他自家模型，以及其混合模型调用分工有优化，导致有点“教做人”。

尤其是最后一点，这就导致有时候cluade code盲目相信模型能力，不做校验就完成。要么是极度不信任模型结果，反复校验。本质上就是他复合模型调用的路径不同导致的。

如果是“抡锤娘”，可能锤哥秒过。楼主考虑考虑

如果从生产逻辑的角度上讲，如果你的中间产物已经包含了完美的分镜表、首尾帧、台词、配音配乐方案，其实H3的优势就不大了。

H3的优势主要还是一站式。

综上，其实随着模型的迭代进化，其实本质上最优工作流也在不停变化，究竟是追求最优，还是追求生产稳定，其实是两个问题。

H3主要的优势是一个是配音、配乐都带，一个是有很强大的参考生成（r2v）。
wan一个是没有参考生成（只有i2v），一个是没有配音配乐。这就导致二者其实本质上的视频生产逻辑有区别。

H3爆火的原因，也是开源界当时没有 qwen image2.1。

然后就是H3和wan2.2，如果只是官方参数对比的话，我个人理解他们的画质其实没本质差距。
包括参数上，H3其实也是只支持24fps*15秒。

配音配乐方面H3也只能说是聊胜于无，尤其是配乐bgm能力。跟目前最新的开源yue2等没法比。

所以关键还是要看你对于最终产物的品质要求。
我的观察是，开源模型的甜区是做一个大概45~50分的视频（百分制）。假设你需要一个65分以及以上的视频，其实使用开源模型你的时间成本和精力成本会陡增。

目前闭源甜区大概能做到70~75分。

导致以上差距的原因，除了模型能力本身以外，还有一个就是H3的提示词处理其实不会开源。闭源模型包装的是一整个生产流程。开源模型其实只开源了模型本身。

大致预算多少？同时要热保留多少session？需要多少prefill和decode速度？

这种打中下层市场空白的产品，很难想象他的场景究竟是如何的。以及和395相比优势在哪里……

价格和395趋同，性能稍强于395，但是完全没有对应生态……