Reading view

There are new articles available, click to refresh the page.

如何高效率高质量利用 LLM 翻译一本文字版 pdf 书籍(几百页)?

SGL: 有一些不错的书籍没有国内译本,鉴于个人英语水平不支持高效率地阅读英文书籍。

因此想要把文字版的 pdf 书籍自己翻译成中文手稿。

目前想象的思路就是:

1. 利用 pdf 工具把所每页都处理成 markdown ,图片提取出来也用 markdown 格式进行排版。
2. 调用 LLM API 逐个文档翻译。
3. 为了便于校对翻译质量,采取一段一段的上英下中的对照式翻译。

上面的方案中唯一不确定性的在于:
1. pdf 解析库是否能力足够高质量的把 pdf 解析成 markdown?
2. 至于 llm 翻译的部分,翻译本身就不需要太长的上下文,就一段一段的慢慢放到后台调 api 并发翻译,然后拼接起来就好了。

写屏障,概念混淆?

SGL: 最近在看左书祺的《 Go 语言设计与实现》

这个是开源的网页书的原文:

“内存屏障技术是一种屏障指令,它可以让 CPU 或者编译器在执行内存相关操作时遵循特定的约束,目前多数的现代处理器都会乱序执行指令以最大化性能,但是该技术能够保证内存操作的顺序性,在内存屏障前执行的操作一定会先于内存屏障后执行的操作 6 。”

这个是不是有所概念混淆了。

内存屏障技术好像和 go 的三色标记法中的混合写屏障技术在概念上就不相干?

48+512 不是一个合理的配置

SGL: 仅在此给要入苹果家电脑的朋友提个醒。

不要过多相信网络上说的 48+512 是性价比之选之类的。

1. 首先选择了 Mac 以及 48G 这类大内存,则不应再存什么“性价比”之类的想法,如果要性价比,就应该去选合适的 Windows 。(信仰除外)

2. 其次,从合理性上来说,如果内存达到 32,36,48 这种层级,从使用场景上,512G 的外存是配不上 32 ~ 48 这种容量的内存的,是一种不匹配。拿一个场景举例来说,如果你的高内存的后台是需要跑许多的 docker 容器设置一些轻量虚拟机(譬如 orbstack 中的 machine),甚至 parallel 这些重量级虚拟机。那么高内存固然可以满足需求了,那么接下来你需要担心的事情就是日积月累的虚拟磁盘占用,容器卷的占用,镜像的占用。这些东西的占用,我相信在一定的时间内,一定会积累到一两百 G 的样子。那么这个时候你可能就需要时不时的惦记着清理你的磁盘。

3. 关于扩容,选择 48+512 的人大多大底是有些拧巴的人,你让他买了立刻扩容,首先未必肯舍得保修,其次它未必肯放得下心中的“洁癖”和“强迫症”,即————我花了不菲的价钱(富哥除外),还要再去破坏“完美”的产品去改装。在心理上未必接受的来。最后,才是扩容的风险性问题。万一扩容的商家手抖了,用的颗粒就是有问题了,等等,这种情况概率大小我不知道,暂未不表。

4. 关于挂尿袋,这个我个人目前只有一个看法,“你尿袋能挂 100T 那也是挂尿袋,和内置是两码事”。除非这个尿袋是如意金箍袋,能变大变小塞进 Macbook 的 sd 卡槽里。

所以,我的建议和教训就是,当你已经考虑了买 Mac ,并且是上高性能,高内存的配置的时候,狠狠心上 1T 吧。再高的外存我也不做点评,因为确实太特么贵了。但是 1T 还是有必要咬咬牙的。只有内存和外存作为一个整体的配置相得益彰了,才能发挥机器的最大价值。

当你觉得 512G 绰绰有余的时候,那么,你还需要额外的考虑一下,你的 32G+的大内存是否同样过于冗余。

除非是较为极端的小众的情况,其内存需求立竿见影的大于外存。
❌