前言
近期老笔记本不堪重负,换了MacBook Pro M5Max ,买它的原因除了体验苹果操作系统外,最主要还是因为其为 AI 任务打造的强大算力,相关芯片架构升级、硬件参数说明网上有很多文章,本文不再赘述。本文主要记录本地模型推理的相关实践内容和遇到的知识盲点。
语音输入
2026 年了,语音输入法早已迎来了质的飞跃,就目前手头已有的相关软件验证了下,结论如下:
- 微信输入法,效果好,最便捷,直接在光标位置输入。
- 千问 APP,效果也不错,就是不能在光标位置收入需要点击复制再粘贴(毕竟不是输入法)。
- 苹果自带听写转录,效果没有上面二者惊艳。
bash
# 千问
Case1:你好呀,床前明月光,疑是地上霜。举头望明月,低头思故乡
Case2:Computer science和LLM大模型有什么关系?
# 微信输入法
Case1:你好呀,床前明月光,疑是地上霜。举头望明月,低头思故乡。
Case2:Computer science 和 LLM 大模型有什么关系?
# 苹果语音备忘录
Case1:你好呀 ,床前明月光疑似地上霜举头望明月低头思故乡。
Case2:Computer sins和 LIM大模型是什么关系 ?
推理工具选型
结论先行
- 文本模型推理:综合考虑主要使用oMLX。
- 文生图:主要使用ComfyUI 或者 大厂提供的免费入口。
- TTS:oMLX、VoiceBox
- ASR:oMLX中的Qwen3-ASR、 Whisper、GLM-ASR-Nano
oMLX
专为 Apple Silicon 深度优化的原生 MLX 推理服务器,主打极致的长上下文处理和 Agent 场景。它的目标用户是需要构建复杂、高性能本地AI应用的专业开发者。
优点
- 极致性能与缓存机制:采用创新的"分层 KV 缓存"技术(热数据留内存 RAM,冷数据存 SSD),跨会话和重启均可恢复缓存。在第二轮对话时,首字延迟(TTFT)可从几十秒降至 5 秒以内。
- 并发与 API 兼容:支持连续批处理(最高 8× 并发加速),同时兼容 OpenAI 和 Anthropic 双 API。
- Mac 原生体验:提供 macOS 菜单栏应用及 Web 管理面板,方便监控和管理多模型。
- 专业级功能: 支持多模型同时服务、Web管理界面、模型别名等高级功能
缺点
- 平台限制严格:仅支持搭载 Apple Silicon (M系列) 且系统为 macOS 15.0+ 的设备。
- 硬件门槛高:官方建议至少 64GB 统一内存以获得最佳体验,16GB 设备只能跑小参数模型。
- 模型生态较小:依赖 Hugging Face 上的 MLX 社区模型,不如 Ollama 丰富。
- 使用门槛较高: 面向专业开发者,配置和使用比Ollama和LM Studio复杂。
模型支持与格式
- 主打苹果自家的 MLX 格式。支持文本大语言模型(LLMs)、视觉语言模型(VLMs)、TTS 模型、OCR 模型(如 DeepSeek-OCR)、嵌入模型和重排器等多模态模型。
适用场景
- 本地多Agent系统: 为需要同时运行多个智能体的复杂应用提供后端支持。
- 高性能推理API服务: 在本地搭建一个性能媲美云端服务的推理API,供团队内部或其他应用调用。
- 资源极限探索: 在内存有限的Mac上尝试运行尽可能大的模型。
附上接口端点说明
| 端点 | 请求方法 | 说明 |
|---|---|---|
/v1/chat/completions |
POST | 聊天补全(支持流式) |
/v1/completions |
POST | 文本补全(支持流式) |
/v1/messages |
POST | Anthropic Messages API |
/v1/embeddings |
POST | 文本嵌入 |
/v1/rerank |
POST | 文档重排序 |
/v1/models |
GET | 列出可用模型 |
/v1/audio/transcriptions |
POST | 语音转文本 (STT - Speech-to-Text) |
/v1/audio/speech |
POST | 文本转语音 (TTS - Text-to-Speech) |
/v1/audio/process |
POST | 语音处理 (STS - Speech-to-Speech / 音频增强) |
rapid-mlx
rapid-mlx的核心在于对MLX框架的深度定制和激进优化。它可能采用了更高效的内核实现、更精简的代码路径以及专门为低延迟优化的调度策略。它的一切设计都服务于尽快生成第一个token(TTFT)和尽可能快地生成后续token。
优点
- 极致的推理速度: 可能是目前macOS上单次推理速度最快的工具。
- 极低的TTFT: 对延迟敏感型应用非常友好。
- 轻量化: 代码库和资源占用可能非常小。
- API兼容: 同时兼容 OpenAI 和 Anthropic 双 API。
缺点
- 平台锁定: 严格限定于Apple Silicon,没有任何跨平台能力 。
- 社区和文档: 作为一个新兴的个人或小团队项目,其社区支持和文档可能不如成熟项目。
模型支持与格式
- 主打苹果自家的 MLX 格式。支持文本大语言模型(LLMs)、视觉语言模型(VLMs)、TTS 模型、嵌入模型等多模态模型。
适用场景
- 基于苹果 Mac 生态的本地化、高性能、高兼容性 AI 应用开发与部署。
LM Studio
面向非技术用户的图形界面(GUI)本地推理客户端,底层主要依赖 llama.cpp。
优点
- 顶级用户体验: 直观、美观的图形界面,无需任何命令行知识。
- 强大的模型管理: 一站式搜索、下载、管理模型的体验无出其右。
- 出色的格式兼容性: 同时支持GGUF和MLX,提供了灵活性和高性能的选择。
- 深度硬件加速: 对MLX的良好支持确保了在M5 Max上的优异性能。
- 内置聊天和API服务: 自带聊天界面和OpenAI兼容API,功能全面。
缺点
- 性能瓶颈:受限于 GUI 渲染开销和单槽 KV Cache 设计,高并发能力弱(最多 1 路并发)。在处理 100K 长上下文冷启动时速度较慢。
- 闭源商业软件: 虽然有功能齐全的免费版本,但其本质是商业产品,未来可能推出更昂贵的付费版,且无法审查其源代码 。
- 资源占用: 作为一个功能丰富的Electron应用,其自身的资源占用高于轻量级的CLI工具。
- 后台服务能力较弱: 其设计更偏向于一个前台交互应用,而非像Ollama那样设计为持久运行的后台服务。
模型支持与格式
- 深度集成Hugging Face: 其内置的模型浏览器可以直接搜索Hugging Face模型库,并清晰地列出每个模型的不同量化版本(主要是GGUF),用户可以根据自己的硬件配置选择下载 。
- 双格式引擎:GGUF与MLX : 这是LM Studio相比Ollama的一大核心优势。它不仅支持基于
llama.cpp运行GGUF模型,更重要的是,它很早就原生支持了苹果的MLX格式模型(v0.3.12及之后版本)。
适用场景
- 第一次体验本地大模型的普通用户、日常轻量级对话、模型效果评测。
- 非技术用户与教育: 是向普通人介绍和展示本地大模型能力的最佳工具。
- 模型评估与快速实验: 研究人员和开发者可以方便地下载和切换不同模型,调整各种参数(如温度、top-p等),直观地比较它们的输出差异 。
- 隐私敏感的个人应用: 完全离线运行的特性,使其成为处理个人文档、邮件等敏感信息的安全选择。
Ollama
以极简和跨平台为核心的模型管理与服务工具,它的核心价值在于"简化",通过一条命令ollama run llama3,用户就能完成过去需要复杂环境配置和手动下载的整个流程。
优点
- 极简易用: 安装和使用门槛极低。
- 庞大社区与模型库: 拥有最活跃的社区之一和极其丰富的预置模型。
- 开源免费: 完全开源,采用MIT许可证,商业使用友好。
- API兼容性: 标准化的API接口便于集成。
- 跨平台: 支持macOS, Windows, Linux。
- 近期0.19预览版已整合 Apple MLX 框架。
缺点
- 原生格式单一: 强依赖GGUF,对其他格式支持不便。
- 性能依赖后端 : 其性能上限完全取决于后端(
llama.cpp或MLX)的更新,自身优化空间有限;纯 RAM 缓存,不支持 SSD 持久化,每次新对话或重启仍需重新计算前缀。 - 图形界面缺失: 原生为CLI工具,对非开发者不够友好(尽管有众多第三方GUI客户端)。
- 资源控制粒度粗: 对内存、CPU等资源的精细化控制选项较少。
模型支持与格式
- Ollama生态系统的基石是GGUF (GPT-Generated Unified Format) 格式 。GGUF是
llama.cpp项目推出的模型文件格式,它将模型架构、权重、分词器等所有信息打包在单个文件中,并支持多种量化方式(如4-bit, 8-bit等),非常适合分发和本地部署。Ollama的模型库中几乎所有模型都是GGUF格式。这既是优点也是缺点:优点是标准化和便捷;缺点是模型格式支持相对单一,对于那些以Hugging Face原生格式(如PyTorch的safetensors)发布,或采用其他量化方案(如GPTQ, AWQ)的模型,需要手动转换才能在Ollama中使用 。
适用场景
- 开发者快速集成: Ollama提供了与OpenAI API兼容的HTTP端点,开发者可以轻松地将现有的AI应用从调用云端API切换到调用本地Ollama服务,极大地便利了开发和调试 。
- 入门与学习: 对于初次接触本地大模型的学生和爱好者,Ollama的"一键运行"体验无疑是最佳的入门途径。
- 轻量级后台服务: 它的后台服务进程稳定,可以设置为开机自启,适合作为系统中一个常驻的AI能力提供者 。
本地模型推理设置
推理参数设置
Qwen3.6-27B 下,AI Coding Agent 的推荐配置
| 参数名称 | 重点推荐值 | 可选范围 | 核心作用 |
|---|---|---|---|
| 温度 (Temperature) | 0.6 | 0.6 - 1.0 | 核心 :在确定性和少量创造性之间取得最佳平衡,是 Agent 任务的首选。 |
| Top P (核采样) | 0.95 | 0.9 - 0.95 | 搭配温度使用,保证输出稳定性的同时,保留必要的词汇多样性。 |
| Top K | 20 | 20 - 40 | 限制每一步的候选词池,提高推理速度并稳定输出质量。 |
| Presence Penalty | 0 | 0 - 1.5 | Agent 任务推荐为 0 。创造性任务可提高至 1.5。 |
| Min P | 0 | 0 - 0.05 | 推荐保持为0以避免过度限制,使用 Top-P 控制多样性即可。 |
| 重复惩罚 (Repetition Penalty) | 1.0 | 1.0 - 1.1 | 推荐保持为1.0。过高的值可能导致代码逻辑断裂或不连贯。 |
| 最大 TOKEN 数 (Max Tokens) | 按需 | 1,000 - 8,000 | 控制每次生成的最大长度。Agent 任务建议不低于4,000个 Token。 |
| 上下文窗口 (CTX WINDOW) | 越大越好 | 32K - 262K | Agent 任务的核心。窗口越大,模型处理复杂任务的能力越强。 |
推理加速与优化技术
四种技术对比
| 技术 | 核心手段 | 主要加速阶段 | 典型加速倍数 |
|---|---|---|---|
| TurboQuant KV Cache | 压缩 KV Cache 显存 | Prefill + Decode | 内存占用降低 3-7 倍 |
| SpecPrefill | 筛选输入 Token | Prefill | TTFT 降低 7.66 倍 |
| DFlash | 草稿模型一次性生成块 | Decode | 最高 6 倍(无损) |
| Native MTP | 主模型预测多个 Token | Decode | 1.5-2 倍 |
在 oMLX中的模型设置可根据实际需要启用下面实验性功能。
- 长文本场景可以启用 DFlash 提升 tg TPS,自己电脑用 oMLX的基准性能测试大概有 2~4 倍的提升。
- 长文本场景可以启用TurboQuant KV Cache 降低 KV Cache 的内存(注意不是 Peak Memory),默认推荐采用 3-bit以获得最大压缩比,显存充足的情况,可以使用 4-bit。
Qwen3.6-27B-4bit

Qwen3.6-35B-A3B-4bit

开源模型选型
下面是之前搜索整理的主流开源模型,还未能一一使用验证,也可能当前有更好的替代者出现,列出目前用过觉得好用的模型:
- 文本模型:qwen3.6-35B-A3B(工具调用、文本摘要、分类、代码生成等)、qwen3.6-27B(代码生成)
- Text2Image:z-image(文章配图)
- TTS:Qwen3-TTS
- ASR:Qwen3-ASR、fun-ASR、Whisper-Turbo
- OCR:只知道PaddleOCR遥遥领先,暂未深入使用。
OCR
- glm-ocr:速度快、成本低、结构化输出,比如票据、银行流水
- PaddleOCR-VL-1.5:处理复杂版式、物理形变文档,理解能力强,比如照片、手写稿
- MinerU:学术论文、硕博论文、教材或财报,或者做 RAG 知识库构建。
- Unlimited OCR:长程文档解析。
Text2Image
- GLM-Image: 适合大量精准文字、逻辑复杂的图像(如海报、图文教程)。
- 造相-Z-Image-Turbo:快,6B参数,逼真画质,双语文本渲染。
- qwen-image:慢,40B参数,人像真实感、精细细节、改进的文字渲染。
TTS
- VoxCPM2:影视配音、有声书、数字人、需要高度情感表达和创意声音设计的场景。
- Qwen3-TTS:阿里开源,实时对话机器人、智能客服、需要兼顾英文表现和多语言跨国业务的场景。
- Fun-CosyVoice 3:阿里开源,跨语言翻译配音、多语种内容出海、跨语种声音复刻。
- IndexTTS-2:B 站开源,有声书、动漫配音等强烈戏剧张力场景;适合专业内容创作者。
ASR/STT
- Qwen3-ASR:绝对精度领先,复杂场景鲁棒性强。支持中文、英语等 11 种语言,以及四川话、粤语等方言,具备自动语种识别功能。
- GLM-ASR-Nano:中文为主的会议、方言地区客服、医疗记录(医生口述声音轻)、图书馆等静音环境下的语音输入。
- Fun-ASR-Nano-2512:中文场景,包括7种方言(吴语、粤语、闽语、客家话、赣语、湘语、晋语);国内政企会议、新闻采访整理、法律笔录、国学教育、以及需要降低后期人工编辑成本的办公文秘场景。
- whisper-turbo:国际化业务、多语种翻译、跨国会议记录,以及需要成熟社区文档支持的通用场景。
VLM
- 做高精度"硬骨头"任务 (如金融报表、科研图表)选 Qwen3.6-27B ;做轻量级"快节奏"应用 (如个人知识库、本地 Agent)选 GLM-4.6V-Flash。
- Qwen3.6-27B :处理极其复杂 的视觉任务,如高精度的表格/公式识别、长文档理解。
- GLM-4.6V-Flash :9B ,日常的图文问答 、网页内容提取 、简单的 Agent 工具调用。速度快,响应延迟低。
LLM
- Qwen3.6:追求准确率,选 27B ,显存充足使用 Q8_0,质量基本无损。适合养小龙虾。
- Qwen3.6-35B-A3B,追求深度思考 和本地全能部署。
- GLM-4.7-Flash: 精准工具,严格执行指令,极致速度 和代码/上网能力 。
- 4bit精度不行,题目:9.9 和 9.11 哪个大直接死循环输出。
- 8bit精度可以。
Embedding
- bge-m3:需要混合检索 和轻量部署 ,选 BGE-M3 ;需要长文本处理 和极致精度 ,选 Qwen3-Embedding-4B。
Rerank
- bge-reranker:追求稳定高效 和多语言支持 ,选 BGE-Reranker ;追求逻辑推理 和极致精度 ,选 Qwen3-Reranker。
实践场景
本地开发软件安装
- 推理工具:oMLX
- 模型:Qwen3.6-35B-A3B
markdown
帮我在这台 mac(M 系列芯片) 上搭建开发环境,按顺序执行
1. 安装开发语言:pyenv+Python3.11、rust(rustup)、jdk25(Eclipse Temurin)+mvnd
2. 安装uv(Python 包管理器)
3. 安装 iTerm2、Docker
4. 安装字体:JetBrains Mono Nerd Font
每步完成后验证是否成功,遇到报错自行处理
上面看着很智能,实际遇到以下坑
- 软件制品默认连国外网络,如果梯子太慢还不如手动安装。
- 需要具体指明安装的软件的发行者、版本号,否则可能不是你想要的结果。
- 如需团队内分享,建议将安装成功的结果让AI制程shell脚本,分享shell脚本更稳定、省事。
Skill调用
- 推理工具:oMLX
- 模型:Qwen3.6-35B-A3B
- 场景:调用自研的微信公众号文章排版cli工具

端午节祝福页
- 推理工具:oMLX
- 模型:Qwen3.6-27B-4bit
- 场景:单 html 祝福页
- 轮次:1

设计文档配置提取
- 推理工具:oMLX
- 模型:Qwen3.6-35B-A3B(需要启用思考模式,未启用的情况效果很差)
- 场景:核心信息提取
批量处理脚本
为了效率和稳定性考量,批量调用使用 shell 脚本遍历,仅在配置提取阶段使用 LLM,JIRA 的设计内容获取使用的是自研的jira-cli工具(便于后续给 LLM 制作skill)。
sh
#!/usr/bin/env bash
set -euo pipefail
# ==================== 配置区 ====================
JQL_FILTER='project in (DEV) AND (fixVersion = 1.0) AND (
Bug阶段 = 生产阶段 AND issuetype = Bug OR issuetype in (开发,Improvement)) ORDER BY issuetype DES
C'
FIELDS='fixVersions,summary'
CSV_OUTPUT='./output/result.csv'
MD_OUTPUT='./output/result.md'
AI_PROMPT='你是一个软件需求分析设计专家,任务:请提取设计文档中的数据库选项表、属性配置文件和明确需要手动执
行的升级脚本(没有指明手动执行的脚本包括新增字段、存储过程、函数、视图、升级脚本等,不需要包含在内)的变动
内容, 包含新增、修改、删除项,按"选项-新增、选项-修改、选项-删除、属性配置-新增、属性配置-修改-属性配置删
除"这样的分类,依次输出,仅输出变化的内容,当所有分组无变更内容时就输出"无配置变化",使用markdown格式,Issu
e:{issue_info}'
# ==================== 步骤一:导出 CSV ====================
mkdir -p "$(dirname "$CSV_OUTPUT")"
if [[ "${FORCE_EXPORT:-0}" == "1" ]] || [[ ! -s "$CSV_OUTPUT" ]]; then
echo "正在导出 CSV 到 $CSV_OUTPUT ..."
jira search "$JQL_FILTER" --fields "$FIELDS" --csv "$CSV_OUTPUT"
echo "CSV 导出完成"
else
echo "CSV 已存在且非空,跳过导出(设置 FORCE_EXPORT=1 可强制重新导出)"
fi
# ==================== 步骤二:遍历生成摘要 ====================
mkdir -p "$(dirname "$MD_OUTPUT")"
> "$MD_OUTPUT"
count=0
while IFS=, read -r key _; do
count=$((count + 1))
echo "[$count] 正在处理: $key"
{
echo "## $key"
echo ""
jira ai-summarize "$key" --prompt "$AI_PROMPT"
echo ""
echo ""
} >> "$MD_OUTPUT"
done < <(tail -n +2 "$CSV_OUTPUT")

音/视频总结会议纪要
使用claude code 制作了一个meeting-cli,便于离线/保密场景下制作会议纪要,功能如下:
- 语音转录:将音频/视频文件转为带时间戳的文本
- 说话人分离:自动识别不同发言者并标注
- 会议纪要:通过 LLM 自动生成结构化纪要(议题、决策、行动项)
- 多种 API 支持:FunASR、OpenAI Whisper 等多种 STT 服务;OpenAI Chat Completions 兼容的 LLM 服务做总结会议纪要
- 长音频处理:自动分块处理超长录音
- 视频支持:自动从视频文件提取音频

文章信息图
- 推理工具:Comfy-UI
- 模型:z-image
暂时用的界面操作的方式,相关教程很多,不再赘述。后续待有时间对接其 API 调用对应的工作流,为后续可能的自动化 skill 场景做准备。
目前体验下来这个模型稳定性还是不够好,中文文字容易出现乱码,静待更优秀开源模型的出现。文章信息图提示词参考:
scss
整体风格:Hand-drawn educational infographic on warm cream paper texture (#F5F0E8)。所有线条和形状带轻微手绘抖动感(slight hand-drawn wobble),整体干净清晰,像高质量演示文稿的单页视觉摘要。无写实元素。
图形优先:用图标、简笔画卡通形象、示意图承载信息,文字仅用于标注和点睛,能用图说清的绝不用文字。像好的 slides 一样------一眼看懂结构,细看理解细节。
信息结构:根据内容自动选择最佳视觉布局(流程→箭头串联,对比→左右分栏,循环→环形,组成→并列卡片,层级→嵌套等)。用圆角色块、气泡、虚线框等容器分区,区域间用手绘波浪箭头(hand-drawn wavy arrows)连接并标注简短关系词。
文字层次:标题顶部居中,粗体大号手绘字(bold, large, hand-drawn lettering);区域内用粗体关键词 + 暖灰小字短标签(2-5 词)区分层次。
渲染细节:马卡龙色块不完全填满轮廓(colors do not completely fill outlines),涂鸦装饰点缀(小星星、下划线、小箭头等),充足留白,干净构图。
画下面的内容:
{文章总结要点}
术语说明
MLX
由苹果公司机器学习研究团队开发并开源的机器学习阵列框架,于2023年12月正式发布。它专为 Apple Silicon 芯片(M 系列)设计,旨在为苹果设备提供官方的机器学习解决方案,降低开发门槛,使开发者能够高效地在苹果芯片上训练和部署 AI 模型。
推理指标
TTFT(首 Token 时间)
- 定义:模型开始响应前的延迟。衡量提示词处理(预填充)速度。
- 指标:越低越好。
TPOT(每输出 Token 时间)
- 定义:每个生成 Token 之间的平均时间。衡量解码速度。
- 指标:越低越好。
tg TPS(Token 生成 TPS)
- 定义:每秒生成的输出 Token 数。TPOT 的倒数。
- 指标:越高越好。 pp TPS(提示词处理 TPS)
- 定义:预填充阶段每秒处理的输入/提示词 Token 数。
- 指标:越高越好。
端到端延迟(End-to-End)
- 定义:从提交请求到完整响应的总时间。包含预填充与生成阶段。
总吞吐量
- 定义:每秒处理的总 Token 数(输入 + 输出)。衡量系统整体利用率。
批量大小(Batch Size)
- 定义:同时处理的并发请求数。批量越大总吞吐量越高,但每个请求的延迟会增加。
加速比(Speedup)
- 定义:相对于单请求基准(1x)的 Token 生成吞吐量倍数。
- 指标:越高越好。
pp TPS/req(每请求提示词处理 TPS)
- 定义:提示词处理吞吐量除以批量大小。显示批量负载下每个请求的预填充速度。
推理参数
上下文窗口(CTX WINDOW)
- 定义 :模型一次推理所能处理的 输入 token 总数(包括用户输入、系统提示、历史对话等)。例如 8K、32K、128K 等。
- 作用:决定了模型能够"看到"多长的历史信息。超出窗口的内容会被截断或遗忘,影响长文本理解与对话连贯性。
最大 TOKEN 数(Max Tokens)
- 定义 :单次推理中 模型生成的最大输出 token 数量。
- 作用 :控制回答的长度。设置过短可能截断有用信息,过长则增加延迟与成本。需要确保
输入token数 + 输出token数 ≤ 上下文窗口。
温度 (Temperature)
- 定义:一个缩放 softmax 输出概率分布的系数,通常取值 (0, 2]。
- 作用 :调节生成文本的随机性。
温度 → 0:趋向于总是选择最高概率 token,输出确定、保守。温度 → 1:保持原始概率分布。温度 > 1:降低高概率 token 与低概率 token 的差距,输出更随机、多样。
Top-p(核采样)
- 定义:从累积概率和达到 p(如 0.9)的最小 token 集合中采样。
- 作用:动态选择概率最高的若干 token(数量可变),既过滤了极低概率的杂乱选项,又保留了适度的多样性。与温度配合使用,优先于 Top‑k 时更平滑。
Top-k
- 定义:只从概率最高的 k 个 token 中采样,其余 token 概率置零。
- 作用:强制限制候选集大小,防止生成完全离谱的 token。通常与温度或 Top‑p 搭配(先 Top‑k 截断,再按概率分布采样)。
MIN P
- 定义 :保留所有概率 ≥
max_prob * min_p的 token(其中 max_prob 是最高概率 token 的概率)。 - 作用:相比于固定的 Top‑p,Min‑p 能自适应地剔除"长尾低概率"token,同时在高置信度情况下让候选集很小,在低置信度时保持适当多样性。常用于提升生成质量和控制幻觉。
重复惩罚 (Repetition Penalty)
- 定义 :对已经出现在生成文本中的 token 施加概率惩罚。通常形式为
logits /= penalty(penalty > 1 则降低概率)。 - 作用:减少模型不断重复相同短语或句子的倾向。过高的惩罚可能导致语无伦次,过低则容易陷入循环。
存在惩罚(Presence Penalty )
- 定义 :对所有 至少出现过一次 的 token 施加一个固定减法(与频率无关)。常见于 OpenAI API 的
presence_penalty,范围 -2, 2。 - 作用:正数惩罚使模型更愿意引入新话题,避免重复相同的概念或实体;负数惩罚则鼓励模型停留在已有话题上。
区别:重复惩罚通常与出现次数成正比(频率惩罚),而存在惩罚只看是否出现(二值)。有的框架将两者合并为一个参数。
TTL (秒) -- Time To Live
- 定义 :推理请求或 缓存的生存时间,以秒为单位。
- 作用 :
- 在服务端(如 vLLM、TGI)中,TTL 用于控制 KV cache 或 前缀缓存 的保留时长。当相同请求在 TTL 内再次到达,可直接返回缓存结果,节省算力。
- 在 API 调用中,TTL 也可表示 请求超时时间:若推理超过该秒数仍未完成,则中断并返回错误,防止长时间阻塞。
推理优化
TurboQuant KV Cache
| 项目 | 说明 |
|---|---|
| 定义 | 一种针对 Transformer 推理中 KV Cache 的量化压缩算法,显著降低显存占用。 |
| 原理 | 使用两步压缩策略: 1. PolarQuant :将 KV 向量变换到极坐标空间(半径+角度),保留关键结构信息。 2. QJL(1-bit 投影):进一步压缩并校正误差,保证注意力计算的精度。 |
| 作用 | 以极低精度损失实现 3-7 倍 KV Cache 压缩,使消费级 GPU 能够运行超长上下文模型(如 32K→200K+)。 |
| 对应推理阶段 | Prefill 阶段 (构建 Cache)和 Decode 阶段(读取 Cache)均受益,尤其是显存瓶颈明显的长文本生成场景。 |
SpecPrefill
| 项目 | 说明 |
|---|---|
| 定义 | 一种降低 首 Token 延迟(TTFT) 的优化技术,通过重要性筛选输入 Prompt 中的 Token。 |
| 原理 | 使用一个轻量级模型快速评估每个输入 Token 的重要性(如指令词、函数名),仅将关键 Token 传递给主模型进行预填充计算。 |
| 作用 | 减少 Prefill 阶段需要计算的有效 Token 总数,使 TTFT 最高降低 7.66 倍,显著改善用户体感的响应速度。 |
| 对应推理阶段 | 仅作用于 Prefill 阶段(输入处理阶段)。 |
DFlash
| 项目 | 说明 |
|---|---|
| 定义 | 一种 推测解码(Speculative Decoding) 方法,使用轻量级草稿模型一次性生成整个 Token 块,供主模型并行验证。 |
| 原理 | 草稿模型在一次前向传播中直接输出一个 Token 块(而非自回归逐个生成),主模型并行验证该块的所有 Token,接受正确的部分,实现"跳步"生成。 |
| 作用 | 在保证输出分布与原模型完全一致(无损 )的前提下,实现最高 6 倍 的解码加速,是目前推测解码技术的性能标杆之一。 |
| 对应推理阶段 | Decode 阶段(输出生成阶段)。 |
Native MTP(Multi‑Token Prediction)
| 项目 | 说明 |
|---|---|
| 定义 | 一种让主模型在训练时学习 同时预测多个未来 Token 的能力,推理时直接用于加速。 |
| 原理 | 在训练阶段增加额外的输出头,要求模型预测当前 Token 之后的多个 Token。推理时,模型可以一次前向生成多个候选 Token,无需外部草稿模型。 |
| 作用 | 在仅增加约 15-20% 计算量的前提下,带来 1.5-2 倍 的稳定解码加速。例如,Qwen3.6-27B 在 RTX 3090 上可从 38 tokens/s 提升至 65 tokens/s。 |
| 对应推理阶段 | Decode 阶段(输出生成阶段)。 |