MacBook Pro M5Max 本地大模型推理实践

前言

近期老笔记本不堪重负,换了MacBook Pro M5Max ,买它的原因除了体验苹果操作系统外,最主要还是因为其为 AI 任务打造的强大算力,相关芯片架构升级、硬件参数说明网上有很多文章,本文不再赘述。本文主要记录本地模型推理的相关实践内容和遇到的知识盲点。


语音输入

2026 年了,语音输入法早已迎来了质的飞跃,就目前手头已有的相关软件验证了下,结论如下:

  1. 微信输入法,效果好,最便捷,直接在光标位置输入。
  2. 千问 APP,效果也不错,就是不能在光标位置收入需要点击复制再粘贴(毕竟不是输入法)。
  3. 苹果自带听写转录,效果没有上面二者惊艳。
bash 复制代码
# 千问
Case1:你好呀,床前明月光,疑是地上霜。举头望明月,低头思故乡
Case2:Computer science和LLM大模型有什么关系?

# 微信输入法
Case1:你好呀,床前明月光,疑是地上霜。举头望明月,低头思故乡。
Case2:Computer science 和 LLM 大模型有什么关系?

# 苹果语音备忘录
Case1:你好呀 ,床前明月光疑似地上霜举头望明月低头思故乡。
Case2:Computer sins和 LIM大模型是什么关系 ?

推理工具选型

结论先行

  1. 文本模型推理:综合考虑主要使用oMLX。
  2. 文生图:主要使用ComfyUI 或者 大厂提供的免费入口。
  3. TTS:oMLX、VoiceBox
  4. 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中的模型设置可根据实际需要启用下面实验性功能。

  1. 长文本场景可以启用 DFlash 提升 tg TPS,自己电脑用 oMLX的基准性能测试大概有 2~4 倍的提升。
  2. 长文本场景可以启用TurboQuant KV Cache 降低 KV Cache 的内存(注意不是 Peak Memory),默认推荐采用 3-bit以获得最大压缩比,显存充足的情况,可以使用 4-bit。

Qwen3.6-27B-4bit

Qwen3.6-35B-A3B-4bit


开源模型选型

下面是之前搜索整理的主流开源模型,还未能一一使用验证,也可能当前有更好的替代者出现,列出目前用过觉得好用的模型:

  1. 文本模型:qwen3.6-35B-A3B(工具调用、文本摘要、分类、代码生成等)、qwen3.6-27B(代码生成)
  2. Text2Image:z-image(文章配图)
  3. TTS:Qwen3-TTS
  4. ASR:Qwen3-ASR、fun-ASR、Whisper-Turbo
  5. 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

每步完成后验证是否成功,遇到报错自行处理

上面看着很智能,实际遇到以下坑

  1. 软件制品默认连国外网络,如果梯子太慢还不如手动安装。
  2. 需要具体指明安装的软件的发行者、版本号,否则可能不是你想要的结果。
  3. 如需团队内分享,建议将安装成功的结果让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 阶段(输出生成阶段)。

参考资料

相关推荐
倾颜1 小时前
AI 聊天刷新后记录全丢?用浏览器本地存储给 AI Chat 加一层"离线记忆"
前端·aigc
刘棕霆1 小时前
企业测试造数为什么这么难?我把熟手经验做成了一个可交付的造数 Skill
aigc·agent·测试
武子康1 小时前
HunyuanVideo 全家族选型:原版 13B / I2V / Avatar / Foley / 1.5 8.3B 怎么分工
人工智能·llm·aigc
一孤程2 小时前
AI辅助测试用例生成实战——用大模型把测试设计效率提升300%
人工智能·测试工具·ai·aigc·测试用例·测试·测试覆盖率
怕浪猫2 小时前
AI Agent 应用开发实战封面大集合
aigc·openai·ai编程
x-cmd12 小时前
Mac 涨价后,本地 AI 还能千元入门吗?
linux·人工智能·macos·ai·agent·amd·本地ai入门
wangruofeng12 小时前
8 小时 10000 星,xAI 把内部编码 Agent 开源了:Grok Build 的架构拆解
开源·github·aigc
Sirius Wu12 小时前
OpenClaw Skill:Matplotlib 可视化技能 + 沙箱双层隔离完整详解
服务器·网络·人工智能·安全·ai·架构·aigc