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 单流串行」改成「小模型 + 批处理 + 校验」，总效率翻倍很容易。

1）输出先锁死。温度 0，给固定 JSON schema（每条 = fact / source_quote / span），用 grammar 或结构化输出强制字段（llama.cpp 的 GBNF、vLLM 的 guided_json），禁止自由发挥。要求每条事实必须附原文引用，抽不到就返回空——允许「不知道」，幻觉会掉一大截。

2）抽取 + 校验两步走。第一步只让模型「定位」，第二步用程序核对每条 quote 是否真在原文里（精确/近似匹配），对不上的直接丢。跨段落合并、多事实合并放在第二步做，别指望一次 prompt 同时干完。

3）长文走 map-reduce。按段/块抽，再合并去重；别为了跨段把整篇塞进去，既贵又容易漏。合并阶段再上长上下文模型。

模型（中文、本地、7B 级别就够）：

• Qwen3 系列：4B/8B Instruct 做抽取很稳，0.6B/1.7B 适合极简任务；Qwen2.5-7B 也可。
• 纯实体/关系抽取，GLiNER、spaCy 这类专用模型比通用 LLM 更不容易编，适合先打底。
• 量化 Q4_K_M/Q5_K_M 足够，抽取对量化不敏感。

经验：把任务拆成「可验证的小步」+ 强制引用，比换更大的模型有效。你说清文档规模、语言、要抽哪些字段，我可以给更具体的 prompt + schema。