在两块 Tesla P40 上运行双模型文学翻译流水线：gemma-4-26B-A4B 达到约 40 词元/秒，配合 MTP 规范解码的 Qwen3.6-35B-A3B 则达到 50-70 词元/秒——完整 llama-server 参数见下文。

先声明：此工具（开源项目"Sunny Narrator"）由我构建，我是作者——本文旨在分享推理配置方案而非广告。若你关注性能指标，可直接跳过说明部分。背景：我运行了一套本地EN→RU小说全本翻译流水线，流程包括：分块→术语表→章节滚动摘要→翻译→审校注释→修正→校对→分块摘要。全书处理约需150-200万token，硬件配置为两张Tesla P40显卡（各24GB显存，Pascal架构，来自"反正有闲置"的架子）。经过一年运行，现已形成足够稳定的启动配置：日均处理2-3本小说。关键发现：单一模型仅能处理半部文本，双模型协同方可完成整本书。擅长翻译的模型文笔优美但校对能力差；精通校对的模型编辑精准但翻译平淡。因此流水线为两种角色分别部署专用服务器： 翻译模型：gemma-4-26B-A4B（MoE架构，A4B激活参数） 校对模型：Qwen3.6-35B-A3B（MoE架构，A3B激活参数） 两者均为紧凑型MoE模型——这使得P40显卡得以胜任：尽管总参数量超出舒适范围，但激活参数量适配吞吐需求。采用量化无损动态（UD）GGUF格式，双模型均启用MTP推测解码，上下文窗口设为64K以容纳分块+术语表+摘要。 我的最佳启动命令（llama-server） Gemma-4-26B-A4B作为翻译器——P40上持续输出约40 tok/s： llama-server -m gemma-4-26B-A4B-it-UD-Q5_K_XL.gguf \ --model-draft mtp-gemma-4-26B-A4B-it.gguf \ --host 192.168.0.55 --port 6155 \ --ctx-size 65535 -ngl 99 \ -ctk q8_0 -ctv q8_0 \ --no-context-shift \ --parallel 1 -np 1 --threads-http 2 \ --load-mode mlock \ --jinja \ --spec-type draft-mtp --spec-draft-n-max 6 --spec-draft-p-min 0.8 \ --top-k 64 --top-p 0.95 --min-p 0.02 \ --repeat-penalty 1.0 --repeat-last-n 512 --presence-penalty 0 \ --predict 32567 \ --reasoning off \ -fa on \ --ctx-checkpoints 32 --checkpoint-min-step 1024 \ --cache-ram 8192 \ --ubatch-size 2048 Qwen3.6-35B-A3B作为校对器——相同双卡环境下输出50-70 tok/s： llama-server -m Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf \ --host 192.168.0.55 --port 6150 \ --ctx-size 65535 -ngl 99 -fa on \ -ctk q8_0 -ctv q8_0 \ --no-context-shift \ --parallel 1 -np 1 --threads-http 2 \ --load-mode mlock \ --spec-type draft-mtp --spec-draft-n-max 4 \ --top-k 20 --top-p 0.95 --min-p 0.05 \ --presence-penalty 1.5 \ --predict 32576 \ --reasoning off \ --jinja --chat-template-file chat_template.jinja \ --ubatch-size 2048 \ --ctx-checkpoints 32 --checkpoint-min-step 1024 \ --cache-ram 8192 参数调优原理 MTP推测解码是核心突破： --spec-type draft-mtp配合捆绑的MTP草稿模型，使Pascal架构显卡得以胜任长文本生成。Gemma模型采用--spec-draft-n-max 6 --spec-draft-p-min 0.8（激进设置，因基础模型能力扎实故接受度高）；Qwen模型更适配n-max 4设置。禁用MTP则无法达到当前效率。 -kv缓存采用q8_0量化（-ctk q8_0 -ctv q8_0）——在显存限制内实现64K上下文（分块+系列术语表+滚动摘要），评估显示质量损失可忽略。 --load-mode mlock——双服务器共48GB显存零交换余量，锁定模型权重避免运行时延迟尖峰。 --parallel 1 -np 1——此工作负载为单批次处理（长生成序列，非并发请求），单槽位效率最高。 --reasoning off配合角色特化采样——翻译器采用top-k 64 / min-p 0.02 / repeat-penalty 1.0（适度创造性但需抑制重复文本，--repeat-last-n 512参数关键）；校对器采用严格top-k 20 / min-p 0.05 / presence-penalty 1.5（确保编辑指令的确定性）。 --ctx-checkpoints 32 --checkpoint-min-step 1024——流水线本身每分块生成检查点（断电可从第51/100分块恢复而非重头开始，该特性为年度节省），但服务器内上下文检查点能降低阶段复用成本。 --predict 32567——分块单次生成完毕；强制模型中断续写会损耗吞吐并破坏风格一致性。 --jinja配合显式聊天模板——流水线全阶段JSON结构化输出依赖模板正确往返，外部chat_template.jinja文件解决了我的解析边界情况。 非llama.cpp相关但影响效率的流水线说明 长度检测作为免费错误检波器：译文块偏差>原文块10%时触发重分（对半分割后分别重译）。EN→RU转换块级波动通常<±2%，显著错误（段落缺失/幻觉/重复）可通过长度偏差直接定位。最终成书长度收敛于原文±5%以内。 术语表决定80%质量：人名/术语/性别词典（基于spaCy命名实体识别初始化并人工清理）随分块同步传输。模型选择次于一致性；小说翻译中术语统一至关重要。 输出成果为人工润色准备的高完成度初稿，非出版级译文——大语言模型消除机械劳动，人工保留文字创意与双关妙趣。 仓库地址（代码+上述配置+Ollama/Docker示例）：github.com/NW15D/sunny-narrator ——是的，我知晓自我宣传规则，故开篇声明；开发此流水线源于现有工具无法承载书级术语上下文，一年前的概念验证帖可见于Habr（俄语技术社区）。 向社区征询： - 是否有人在Pascal架构上进一步优化MTP推测解码？Gemma模型的draft-n-max 6 / p-min 0.8是否接近极限？采用更低p-min值时更深草稿能否保持接受率？ - -ctk q8_0配置下的--ctx-checkpoints机制在连续运行一周以上时是否存在潜在风险？ - 相比"巨型系列术语表"，图数据库/基于角色状态的检索增强生成（RAG）能否更好实现跨卷一致性？是否有实战经验分享？