[25年8月]本地部署 LLM 日语翻译能力实测

测试时间：2025年8月

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

显存： 24G

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	较差	较好
Sakura-Galtransl-14B	60	400	好	不支持
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
Sakura-Galtransl-14B	Sakura-Galtransl-14B-v3.7-Q5_K_S	llama.cpp	64	128	9.5G	17G
Sakura-14B	sakura-14b-qwen2.5-v1.0-q6k	llama.cpp	64	128	11.5G	19G

说明

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

附录

Q：为什么想要测日译中场景？

A：目前，开源小模型越来越喜欢在英/中评测集上面当跑分王，所以英语能力都自然很不错，而国产LLM的中文一般也不成问题...但是，这些模型在特定的其它语言场景如 日译中 时，能力要显著逊色于宣传页面中的“高分”，因此实际好不好用，在特定场景中试过才知道

其它推理工具

• 用 vllm 推理 GGUF 模型：不适配，慢

• sglang、LMDeploy：没试过

• LMStudio：快（对使用者而言）但是慢（对模型运算而言）

• ollama： 感觉不如 LMStudio 、vllm、 llama.cpp 。。。

其它开源LLM

• Seed-X ，文本补全模型，不支持多轮对话，还没人去做前端的适配。。。
• Magistral-Small-2507 ，试过，一般，中文能力烂
• deepseek-R1 ，试过，还行，当时同尺寸的开源SOTA，但强制思考，不适合自动化机翻
• 腾讯 Hunyuan-7B，没试过
• 快手 KAT-V1-40B，卡在了显存塞得下的边缘。。。
• openai gpt-oss-20B，新鲜出炉，还没来得及试
• 既不在测试表中也没有在上面列出的模型：太旧/太大/太小/我不知道

显存不够 (G)

• \([0,16)\)：目前，该尺寸的通用LLM不太可用

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