【LLM】本地 LLM 日语能力 实测

测试时间：2025年9月

实验条件：

操作系统：Ubuntu24，显卡：RTX3090 x 1，24G 显存

测试方式：本地部署单实例LLM服务器，直接跑实际的任务

1.游戏文本日译中：

用 LinguaGacha 作为LLM的 前端 翻译 日语游戏文本，任务长度阈值=128，参考上文行数阈值=0

2.日语词义分析：

用 KeywordGacha V0.14.0 提取 日语游戏文本 的实体词并向 LLM 请求词义分析任务

性能测试结果

日译中能力
好 > 较好 > 一般 > 较差 > 不支持
评价点：文风（人眼感觉）、假名残留程度（任务的完成程度）、跟随指令的能力（术语表指令、格式化输出指令）

模型	最大单线程输出速度 tokens/s	最大并发输出速度 tokens/s	日译中	词义分析（启用引导解码）
Qwen3-32B	30	300	一般	好
Qwen3-A3B	100	1400	一般	较好
Qwen3-4B	65	1700	较差	较差
Hunyuan-MT-7B	45	1050	较好	较差
Sakura-Galtransl-14B	60	450	好	不支持
Sakura-14B	55	350	好	不支持

详细配置表

模型	具体版本	后端	后端并发数	前端并发数	最小显存	实际显存
Qwen3-32B	Qwen3-32B-AWQ	vLLM	32	32	19G	24G
Qwen3-A3B	Qwen3-30B-A3B-Instruct-2507-AWQ	vLLM	128	128	16.5G	24G
Qwen3-4B	Qwen3-4B-Instruct-2507	vLLM	256	256	8.5G	24G
Hunyuan-MT-7B	Hunyuan-MT-7B	vLLM	256	192	16G	24G
Sakura-Galtransl-14B	Sakura-Galtransl-14B-v3.7-Q5_K_S	llama.cpp	64	128	9.5G	14.5G
Sakura-14B	sakura-14b-qwen2.5-v1.0-q6k	llama.cpp	64	128	11.5G	15.5G

说明

• 设置的原则：1. 能塞的全部塞进显存，2. 最大化每秒吞吐量
• 测速时，只计模型输出过程，忽略前端处理过程与模型输入过程；数值已经过舍入，仅为区分速度档次
• 后端并发数：传给 vllm 、llama.cpp 的参数， vllm 对该参数无限制，而 llama.cpp 只支持最多 64
• 前端并发数：即 LinguaGacha 的 并发阈值 参数，该参数为 吞吐量最大时 的最小值
• 关于显存：
• • 最小显存 ：成功运行时所需最小配置（该值仅做指示，由上下文预算设置为零得到）
• • 实际显存 ：本任务中的实际占用
• • llama.cpp 并发数有限（即便显存足够），本任务中，最多需要 64并发数 * 单次512上下文 = 32768 总上下文 的 KVcache 上限，这不一定能吃满 24G 显存
• • vllm 可以吃满显存，最大化并发
• • 实践中，显存预算 - 最小显存 ≈ 能支持多长上下文/多少并发数

附录

本文动机：为什么想要测日译中场景？

目前，开源小模型总是在英/中评测集上面当跑分王，然而，在评测不常覆盖的其它特定场景如 日译中 时，能力很可能显著地逊色于宣传页面中的“评测时高分”，因此，LLM好不好用，在各自的特定场景，实际测过才知道

其它推理姿势

• 用 vllm 推理 GGUF 模型：别这么干，不适配，极慢

• sglang、LMDeploy：没试过

• LMStudio：快（对用户学习使用而言）但是慢（对模型推理而言）

• ollama： 意义不明的东西。。。论适用域，感觉不如 \(\{\) LMStudio \(\and\) vllm \(\and\) llama.cpp \(\}\)

其它开源LLM

• gpt-oss，初步测试了一下，作为思考模型在这个参数量下面表现意外地还不错，明显感到原生MXFP4量化确实有点东西的，可惜无法关闭思考；此外目前vllm对它的支持好像有和显存管理相关的恶性bug，不建议现在（2025.8.17）就用，不确定它啥时候修好；我短期内不会打算用它进行进一步测试了。。。

• 字节 Seed-X ，文本补全模型，不支持多轮对话，遗憾的是还没人去做前端的适配。。。测试了一下，翻译能力比较优秀，能保留一定的格式，缺点是不支持自定义的提示词（术语表），也很难通过提示词来改进它会犯的错误；然后不支持在长上下文内保持翻译能力，上下文接近3k时模型表现就会下降，从翻译模型变成了文本总结模型；官方在开源社区里面还算活跃

• Magistral-Small-2507 ，试过，很一般，中文能力烂。最牛的是这个尺寸的模型居然还能被指令问到退化。。。给我干哪来了，这还是2025年7月吗？

• deepseek-R1 ，试过，还行，半年前 （约等于上个世纪） 同尺寸的开源SOTA，但还是因为强制思考，不适合自动化机翻

• 腾讯 Hunyuan-7B，肉眼可见，这个7B模型在HF上的下载量并不算太大。。。懂的都懂

• 快手 KAT-V1-40B，尺寸太大，塞不下。。。

• 字节 Seed-OSS-36B 尺寸太大，即便4位量化后24G单卡塞得下也没有足够KVcache。。。

• 既不在测试表中也没有在上面列出的模型：太旧/太大/太小/我不知道

关于Hunyuan-MT

Update in 2025.9.9
9月1日腾讯开源了翻译特化模型 Hunyuan-MT-7B，试了一下，确实挺不错的，可作为正式选手加入上文的表格，并值得单列一段：
除了它自身的专业能力（多语言翻译），我认为它的独特优点在于：
（1）作为小尺寸特化模型，它“即插即用”的能力很强，接近同尺寸通用LLM。一方面它直接作为对话模型而非文本补全模型（点名seed-X），使得当前的主流前端都能“在接口形式上”兼容它；另一方面，“在实际使用上”，笔者简单地在cherrystudio、linguagacha、沉浸式翻译等前端上直接验证，发现基本可用，可见还是有一定智商
（2）自定义的prompt大概率有效，因此它能在不同前端上直接工作（但不一定工作得很好），不需要与官方推荐的提示词逐字一致
（3）指令中的额外要求，也有概率生效，例如格式化输出指令、术语遵循指令
因此完全可以探索如何适配具体场景来更充分地释放能力
注意： 腾讯的Hunyuan系列模型通过专门的 Hunyuan社区许可 来授权，它比其它模型所常用的开源协议如 Apache 2.0 要多了一些限制，例如：限制大规模商用（1亿月活）、不能用Hunyuan模型 训练或改进 “其它”LLM（否则将视作Hunyuan的衍生作品，受到该协议具体约束），并且该协议没有授权给英国、欧盟和韩国 这份协议大概是Hunyuan系列模型在HF上下载量普遍较低的重要原因

如果显存不够

• 显存 \(\in [0,16)\)：目前，该尺寸的通用LLM 一定 是不可用的，必须自行寻找甚至自己微调一个做特定任务的小型LLM（例如SakuraLLM和Sugoi）

• 显存 \(\in [16,24)\) ：可以尝试上述模型的更低位量化/更小尺寸版本