kakaZhui的博客

大型语言模型（LLM）正以前所未有的速度渗透到各行各业，从智能客服、内容创作到代码生成、企业知识库，其应用场景日益丰富。然而，将这些强大的 AI 能力转化为稳定、高效、可大规模应用的服务，却面临着巨大的挑战，其中高并发处理能力和低响应延迟是衡量服务质量的两个核心痛点。想象一下，你的 LLM 应用在用户高峰期卡顿、排队甚至崩溃，或者用户每次提问都需要漫长的等待——这无疑会严重影响用户体验，甚至导致用户流失。如何让你的大模型服务既能“扛得住”海量请求，又能“跑得快”及时响应？这需要一个系统性的优化工程。

大型语言模型 (LLM) 处理长上下文的能力是衡量其智能水平和实用性的关键指标之一。从最初的几千 Tokens 到如今的数十万甚至数百万 Tokens，上下文窗口的扩展一直是 LLM 发展的前沿阵地。然而，标准的 Transformer 注意力机制（Multi-Head Attention, MHA）在处理长序列时面临着计算量和显存占用的平方级增长问题，这成为了制约长上下文能力的主要瓶颈。为了突破这一瓶颈，各种高效注意力机制应运而生。DeepSeek。

并被认为是DeepSeek现高效训练和快速推理的关键之一，MTP 的核心实现是基于当前时刻的隐藏状态，通过多个并行的线性投影层来同时预测未来多个 Tokens。这种设计摒弃了传统自回归模型逐个 Token 生成的严格串行模式，试图在一次模型前向传播中“预见”更远的未来。但这“并行预言”的背后，究竟隐藏着怎样的细节逻辑？它如何在训练中加速学习，又如何在推理中提升效率？这种方案相比其他并行解码技术有何特点和权衡？本文将深入剖析这种“基于现有隐藏状态的多线性投影” MTP 方案的。

大型语言模型（LLM）的推理过程，即模型根据输入（Prompt）生成输出（Response）的过程，是其应用落地的核心环节。然而，这个看似简单的“输入-输出”背后，隐藏着复杂的计算流程和潜在的性能瓶颈。Prefilling（预填充）和Decoding（解码），并针对每个阶段的特性设计了不同的加速策略。理解这两个阶段的差异以及各自的优化技术，对于选择合适的推理引擎、配置部署参数、甚至设计更高效的模型架构都至关重要。本文将深入探讨 Prefilling 和 Decoding 阶段的。

在大型语言模型快速发展的背景下，小米AI团队推出MiMo系列模型，突破性地在7B参数规模上实现卓越推理能力。传统观点认为32B以上模型才能胜任复杂推理任务，而MiMo通过创新的训练范式证明：精心设计的预训练和强化学习策略，可使小模型迸发巨大推理潜力。"system": "你是有10年经验的数学教授","user": "问题：{question}","assistant": "让我们逐步思考："

大型语言模型 (LLM) 已经渗透到我们数字生活的方方面面，从智能问答、内容创作到代码辅助，其能力令人惊叹。然而，驱动这些强大模型的背后，是对计算资源（尤其是 GPU）的巨大需求。在模型推理 (Inference)阶段，即模型实际对外提供服务的阶段，速度 (Latency)和吞吐量 (Throughput)成为了衡量其可用性的关键指标，也是部署时面临的核心挑战。Transformer 架构作为现代 LLM 的基石，其核心的自注意力 (Self-Attention)

想象一下，你部署的 LLM 应用在高峰期响应缓慢、用户请求大量排队甚至超时失败——这不仅严重影响用户体验，更可能直接导致业务损失。造成并发瓶颈的核心原因之一，就是 LLM 推理本身对计算资源（尤其是 GPU 显存和计算单元）的巨大消耗。那么，当我们的 LLM 推理服务并发告急时，该如何应对？除了增加硬件投入（这往往成本高昂），模型量化 (Model Quantization)是一种在不显著牺牲（有时甚至能略微提升）性能的前提下，有效降低模型显存占用、提升推理速度，从而间接提高并发处理能力的关键技术。

生成的文本驴唇不对马嘴，逻辑混乱。无法准确理解用户意图，答非所问。对于特定领域的知识一无所知或“一本正经地胡说八道”（幻觉）。输出不稳定，同样的输入可能得到截然不同的结果。无法完成稍微复杂一点的多步骤任务。你可能投入了大量时间和精力，尝试了最新的模型，精心设计了 Prompt，但结果依然不尽如人意。问题出在哪里？仅仅是模型不够“聪明”吗？答案往往并非如此简单。LLM 应用效果不佳，通常是系统性问题的结果，涉及从任务定义、模型选择、Prompt 设计到评估体系等多个环节。

这篇博客将基于《ChatGLM: A Family of Large Language Models from GLM-130B to GLM-4 All Tools》，深入剖析 GLM-4 系列在**模型架构设计、预训练、后训练（对齐）、以及关键技术创新（如长上下文处理、Agent 能力构建）**等环节的实现逻辑与设计考量，带你全面了解这个强大的国产大模型家族是如何炼成的。

将人工智能应用于金融市场，尤其是股票交易，一直是科技与金融领域的热门话题。让 AI 成为你的专属投研助理，甚至交易助手？想象一下，你可以用自然语言让 AI 总结最新的财经新闻、分析公司财报、筛选符合特定条件的股票、甚至生成用于回测交易策略的代码。DeepSeek API，特别是其 V2 等在代码和推理方面表现优异的模型，以及与 OpenAI 兼容的接口，使得这种想象离现实更近了一步。但是，这是否意味着我们可以直接“让 DeepSeek 替我炒股”？答案远非如此简单。

大型语言模型（LLM）已成为我们获取信息、生成内容的重要工具。但它们的知识大多截止于训练数据的时间点，对于需要实时信息、跨领域知识整合、多角度观点比较的深度研究 (Deep Research)任务，它们往往力有不逮。如何让 LLM 突破自身知识的局限，像人类研究员一样，在浩瀚的互联网中探索、筛选、分析并最终形成有理有据的洞见？答案在于构建LLM Agent，并为其配备强大的工具，其中网络搜索 (Web Search)无疑是最核心的工具之一。

Temperature Scaling (温度缩放)是一种简单、高效且广泛应用的**后处理（post-hoc）**校准技术，它能在不改变模型预测结果（即哪个答案概率最高）的前提下，调整模型输出的概率分布，使其置信度更好地反映其实际的准确率。本文将深入探讨 Temperature Scaling 的设计原理、实现方法。

在大型语言模型（LLM）的演进浪潮中，Transformer 架构凭借其强大的并行计算能力和对长距离依赖的出色捕捉，奠定了核心地位。然而，标准的 Transformer Decoder Block 遵循着一种相对固定的模式：先进行自注意力（Self-Attention）捕捉上下文信息，再通过前馈神经网络（Feed-Forward Network, FFN）进行特征提炼。这种“先注意，后提炼”的串行结构在无数模型中被证明是有效的，但它是否是唯一的选择？

在Transformer 架构中，位置编码（Positional Encoding, PE）是让模型理解 Token 顺序的关键技术。近年来，旋转位置编码（Rotary Positional Embedding, RoPE）因其出色的性能和对相对位置的优雅编码而成为主流选择，被 Llama 系列等众多模型采用。然而，随着对超长上下文（如 128k 甚至更长）的需求日益增长，标准 RoPE 在超出其预训练长度时表现出的外推性（Extrapolation）问题逐渐显现。

温故知新，今天谈一下，Mistral 7B 模型，来自法国的初创公司 Mistral AI 推出的 ，仅 73 亿的参数量，却在当时的众多基准测试中击败了参数量更大的模型（如 Llama 2 13B），甚至在某些任务上逼近 Llama 1 34B，成为了 LLM 领域的一匹黑马，也引领了一股追求“效率与性能平衡”的新风潮。Mistral 7B 的基础架构仍然是标准的 Transformer Decoder-only 结构，但在关键的注意力机制上进行了创新，这正是其高效性能的核心所在。

大多数 LLM 均采用Dense（密集）架构。这意味着，在处理每一个输入 Token 时，模型所有的参数都会被激活和计算。想象一下，为了回答一个简单的问题，你需要阅读整部大英百科全书的每一个字——这显然效率低下。为了突破 Dense 模型的瓶颈，一种名为Mixture of Experts (MoE，专家混合)的架构应运而生，并迅速成为构建前沿 LLM 的关键技术之一。Google 的 GShard、Switch Transformer，开源社区的 Mixtral，以及我们今天重点关注的DeepSeek。

在与大型语言模型（LLM）交互，尤其是进行对话式应用开发和监督式微调（SFT）时，我们总会遇到一个看似琐碎却至关重要的概念——Chat Template（对话模板）。开发者们常常发现，Llama 3 的模板规则是一套，换到 Qwen 模型又是另一套，再看 DeepSeek，格式又变了。这不禁让人疑惑：为什么不能有一个统一的标准？为啥每个模型的“对话语法”都自成一派？这些模板差异往往关联着模型的预训练数据、设计哲学、甚至是网络结构的考量。

对话模板 (Chat Templates)和特殊标记 (Special Tokens)。它们是指导模型如何理解和生成结构化对话的关键“语法规则”。没有正确理解和使用它们，你的微调效果可能会大打折扣，甚至模型会“胡言乱语”。本文将以 Llama 3 为例，深入探讨 Template 和 Special Token 的定义、它们在 SFT 训练过程中的具体应用，以及这样设计背后的目的。

大型语言模型（LLM）处理的是人类的自然语言，但计算机本质上只能理解数字。Tokenizer（分词器）就是架在自然语言和计算机数字表示之间的一座至关重要的桥梁。它负责将我们输入的文本字符串分解成模型能够理解的最小单元——Token，并将这些 Token 转换成对应的数字 ID，反之亦然（将 ID 转换回文本）。那么， LLM Tokenizer如何训练、评估呢？

本文介绍一步步使用轻量级的 Python Web 框架，快速开发一个后端服务，它不仅能调用你的 LLM，还能模拟 OpenAI 的流式接口，让你的前端应用或客户端可以无缝对接。

LLaMA-Factory 作为一个广受欢迎、易于使用的 LLM 微调框架，为开发者提供了便捷的途径来针对特定任务（包括多轮对话）优化模型。本文将深入探讨 LLaMA-Factory 如何支持多轮对话微调，涵盖其基本概念、数据准备、核心机制、评估方法等。简单来说，多轮对话是指包含两个或更多轮次（Turn）的交互过程，其中每一轮通常包含用户的一个输入和模型的一个输出。后续轮次的回应通常依赖于前面轮次的对话内容。模型需要理解并记忆对话历史。

Function Calling 指的是 LLM 在处理用户请求时，能够理解请求中隐含的调用外部工具或函数的需求，生成符合预定义格式的函数调用参数，并在获取外部工具执行结果后，结合该结果生成最终回复的能力。核心流程分解：用户用自然语言提出包含特定任务或信息需求的请求。“给张三发邮件，告诉他会议改到明天下午 3 点了。LLM 分析用户请求，识别出需要调用外部函数来完成任务，并从一系列预定义的可用函数中选择最合适的那个。LLM 识别出需要调用send_email函数。

LLM 推理通常需要较长的计算时间，导致响应延迟高。由于计算资源有限，LLM 服务难以同时处理大量请求。编写高效的 LLM 服务程序通常需要深入了解底层系统和并行计算。**RadixAttention：**一种新的注意力机制, 通过将key和value张量组织成树状结构（基数树）来实现更有效的内存访问. 从而减少内存占用和计算时间。传统批处理需要等待一批请求都完成后才能开始处理，SGLang 的连续批处理允许新的请求随时加入正在处理的批次中，从而减少等待时间，提高吞吐量。

如何基于llama模型进行lora微调

llama源代码中的并行训练方案解析

大模型推理速度太慢？试试量化，加速推理

参数来控制使用多少个 GPU 进行模型加载和推理。GPU 编号从 0 开始。分配的 GPU 顺序一致。

基于llama源码分析flash attention机制

llama源码分析之更长上下文支持的逻辑分析

在深入理解和top_k之前，我们需要先简单了解一下LLM生成文本的基本过程。LLM本质上是一个概率模型。给定一个输入文本序列（prompt），LLM会计算下一个词的概率分布。例如，给定输入 “The cat sat on the”，模型可能会预测下一个词是 “mat” 的概率为 0.6，“sofa” 的概率为 0.2，“chair” 的概率为 0.1，等等。然后，模型会根据这个概率分布进行采样，选择一个词作为输出。这个采样过程就是和top_k发挥作用的地方。

归一化方法RMS Norm是什么？为什么llama使用这个方案？

LLM 的训练是一个复杂而漫长的过程，需要海量的训练数据、庞大的模型参数、强大的计算资源以及高效的训练策略。通过数据准备、模型构建、模型训练和模型评估四个步骤，我们可以训练出一个拥有强大能力的 LLM。希望这篇文章能够帮助你理解 LLM 是如何训练出来的。当然，这只是一个简化的介绍，LLM 的训练涉及到很多复杂的细节和技巧。如果你想深入了解更多信息，建议阅读相关的论文和代码，并动手实践。

本文详细介绍了 LLaMA 模型中使用的 Rotary Embedding 位置编码方法。通过源码分析和对比传统的位置编码，我们了解了 RoPE 的核心原理和优势。RoPE 通过旋转操作高效地编码相对位置信息，为 LLaMA 模型的强大性能提供了重要的基础。希望本文能帮助你更深入地理解 Transformer 模型中的位置编码机制。

SimHash 是一种局部敏感哈希算法，可以将文本映射成一个固定长度的指纹 (例如 64 位)。相似的文本具有相似的指纹，可以通过计算指纹之间的汉明距离 (不同位的数量) 来判断文本的相似性。它通过计算文本的 Jaccard 相似度（交集大小除以并集大小）来估计文本之间的相似性。传统的字符串匹配算法（如编辑距离）在语义层面效果有限且计算成本高。这是最常用的方法，核心思想是将文本转换为向量表示，然后通过计算向量之间的相似度来判断文本的语义相似性。将文本聚类成不同的组，每个组内的文本被认为是相似的。

Llama 如何针对中文进行词表扩展

LLM 推理实现和vLLM 框架的使用

大模型llama源码分析之KV Cache原理和代码分析

LLM 的内部结构是基于 Transformer 架构的，Transformer 通过自注意力机制来捕捉句子中词与词之间的关系。不同的 LLM 会在 Transformer 的基础上进行修改和扩展，例如 GPT 模型只使用了 Transformer 的 Decoder 部分，并采用了自回归的方式生成文本。LLM 的输入是文本序列，输出是下一个 Token 的概率分布。希望这篇文章能够帮助你理解 LLM 的内部结构和工作原理。当然，这只是一个简化的介绍，LLM 的实际实现要复杂得多。

SFT 让 LLM 学会理解和执行指令。RLHF 让 LLM 更加符合人类的价值观和安全准则。通过 SFT 和 RLHF，LLM 不仅能够生成流畅的文本，还能更好地理解人类的意图，生成更符合人类期望的输出，从而在各种应用场景中发挥更大的作用。

已有一个大模型的推理脚本，如何快速开发一个支持openai接口的server呢