抡锤者

50 tps 想再快 50%，先别换卡，按「先定位瓶颈，再选手段」走： 1）先确认是 dense 还是 MoE。27B dense 5bit 权重约 16–17GB，50 t/s 基本已经贴着单卡带宽天花板（3090 936GB/s 理论也就 ~55 t/s）。这种情况调参挤不出 50%，只能换量化或换模型。 2）「抽取」这个任务，降规格比超频有效： 量化 5bit → Q4_K_M，权重少约 20%，decode 约 +15–20%；抽取质量掉得小，用你现有「第二步程序核对 quote」兜底即可。 直接换 8B 级 Q4，速度通常 3–5 倍。抽取要的是稳定结构输出，不需要 27B 的推理能力，配 2 步校验后大多数文档够用。 3）想榨单流：上投机解码（优先模型自带 MTP 头），别只看 t/s，看「接受长度」；k=3–4 通常最划算，再大验证开销反噬。 4）抽取是吞吐型任务，真正的 50%+ 来自批处理：llama-server 开多 slot 或 vLLM 连续批处理，多文档并行喂，单请求延迟不变、聚合吞吐接近线性；长文再加 q8_0 KV + 前缀缓存避免重复 prefill。 5）架构上二段式：小模型先定位给 span，只有低置信度段落才升级到 27B 复核，平均成本直接下来。 一句话：单流 50→75 很难（除非 MTP），但把「27B 单流串行」改成「小模型 + 批处理 + 校验」，总效率翻倍很容易。

这种用途 非新卡都可排除了。建议 AMD R 9700 32G。24G显存的话得看你个人的编程水平了。我已经服软。花钱了事上的9700

推推!!有這裡這好~~!

可不可以说，即使是用伤寒体系这种公式化的辩证体系，也会因为一个‘证‘的多可能性，会导致多个‘证‘的更多可能性指数级别地让路由节点爆炸，最后是机器采用自认为的高confidence的答案认为一级棒，实际上有经验的从业者一眼尴尬，因为即使比对‘经验‘信息后，也是变成了一次引入更多噪音的处理-毕竟经验本身在中医体系里没有量化的golden cases？可能这个方向整体很危险，因为面对现代化生活的各种乱七八糟，和百年前都已经十万八千里了，更不要说一两千年前，现代化的各种奇奇怪怪的病，早超出了古人‘病‘的范畴了，这导致回归调教又是一个不可知的问题。

我正好有个开源项目适合大佬的需求 你可以试试 我做了封装 直接安装就能用 知识入网里面有协议 直接用agent自己读协议工作比较省力https://github.com/superalp1985/fame-knowledge-agent-gateway

嘿嘿，我也是科班出身的，我是计科的 ，20年+的工作经历。很早我们就自己干了，我一直是叛军架构师，现在AI的发展，我只能说大公司要难受了。架构能力和判断能力自己自定义吧，适合你的就是最好的，包括模型选型，这个没法交流。根据我的了解，很多事情从公司层面根本没法想到现在的发展是相当的迅速，从展示层一直穿到汇编层，慢慢看后面更精彩。我们还是有底线的，至少守法，但是没底线的也有很多大神，肯定会越来越热闹了。

@kop-wang 法庭判决的决定性因素确实大量存在于文本之外:法官自由裁量习惯、本地司法惯例、庭审表现、程序博弈.这些与法条之间几乎没有统计学关联，RAG根本够不着。RAG正好是在解决”LLM上下文窗口有限”的工程问题，不是在解决"世界模型不完整”的认知问题。

默默的留个小脚印。能看懂。看懂是完全超出我的知识面。

哈哈, 英雄所见略同, 以后普通程序员,就是很廉价. 就是一般打字员的工资, 也就8k. 但是顶级资深程序员,就很贵, 核心就是判断力和经验.

@Bukong-Li 说: @terry 剧本写作需要多轮复杂对话，可能涉及几十万字的长文本记忆。线上模型我试过Gemini，claud，gpt。免费版对话几句就没token了。付费版我没试，但是感觉也不会够用吧。 另外，想做rag是想沉淀自己的写作风格，让ai能从自己放进rag的资料进行有控制的生成。rag不只是剧本，可能有小说，编剧工具书等。可能放进去几千部电影剧本，不同题材会分类。人物性格，人物关系等。所以做rag没必要吗？ 730xd对3090，4090具体哪里支持不够呢？我是 想先给730配个显卡，做文字剧本生成。后期生视频在升级整体硬件。不知道行不行。还是说直接升级硬件？ 1, 公开的知识没有太大必要放在RAG里, 在线大模型只要参数够多, 他们基本都能覆盖. 你自己的笔记, 灵感等放在RAG里有意义. 2, RAG每次只能召回相关的一部分内容, 适合你搜索分析总结等, 对你的创作肯定有帮助, 但它没法帮你保持你整个剧本的长期记忆. 3, 如果想沉淀自己的写作风格, 可以用自己的文本去训练一个LORA. 这个是 @terry 教我的, 文本LORA我没训练过, 我只训练过视觉的LORA. 4, 多轮对话和上下文的控制, 可能需要一些技巧. 比如你不要通过一次性的多轮对话来生成全部内容. 而是通过设置好整个背景设定+已经写出的所有内容, 来生成一段新的内容, 这段内容稍微短一些, 比如一章, 比如 4096个token. 然后针对这段内容进行多轮对话修改. 满意之后再开始新对话进行下一轮, 新对话还要包括全部背景设定和已经生成的内容, 这样它不会忘记. ---- 这一段是我的想象, 我没有做过长篇内容的生成, 不过我觉得是有优化空间的.因为你的剧本预计全部只有3万字, 每次全部内容加载, 再加上一段4096 tokens 的多轮滚动, 256k上下文我觉得应该是够用的. 5, 没有隐私内容的话, 还是建议购买在线大模型试一下, 在线大模型很多都支持1M以上的上下文.

@566656661 假設你輸入"Find me the content related to ABC12383" (幫我找一下有關ABC12383的内容), 首先你可以給基本模型把這個請求標準化(Normalize), 模型正常情況下會幫你把有關内容拆解成字串 (三字串trigram或者兩字串bigram), 然後幫你在分塊好的内容選出來, 假設你的文件中包含有關於ABC123, ABC23, ABC83, ABC128, ABC238, ABC12383(這個才是想要的) 这个例子中, 就像你说的, 由于ABC123, ABC23, ABC83, ABC128, ABC238, ABC12383 的向量相似度都很高, 所以真正的 ABC12383 的返回优先级并不高. 但在关键词搜索中, ABC12383的优先级往往就很高, 所以召回的chunk中, 会优先返回. 对于准确的内容, 比如产品型号、错误码、文件编号等等，单纯依赖 Embedding 确实容易召回错误的 Chunk, 所以可以结合 BM25 等关键词搜索，然后再交给 Rerank 做最终排序。