首页 / 文章 / 小型语言模型的LLMOps：服务框架与生产实践指南

小型语言模型的LLMOps：服务框架与生产实践指南

为什么SLMs在成本和隐私方面更具优势，vLLM、SGLang、TGI、llama.cpp、Ollama、WebLLM、ONNX和TensorRT-LLM之间的对比如何，以及如何在生产环境中对它们进行量化、评估和调度。

4127 词

面向小型语言模型的实用 LLMOps：何时本地或设备端推理优于前沿 API，哪些服务架构适合何种硬件限制，以及如何在首次成功调用后保持系统稳定运行。

引言

在“为所有任务微调最大规模模型”与“在手机上运行数十亿参数的模型”之间，生产环境的优先级发生了变化。一旦成熟的单语言模型被量化并实现良好服务，许多任务——如意图分类、工具路由、结构化信息提取、RAG 重排序——就不再需要前沿级别的模型。

问题在于：没有相应服务策略的单语言模型仅仅只是磁盘上的一个检查点。在生产环境中运行它会带来 GPU 内存、批量处理、量化精度、回滚机制以及评估等方面的问题，而这些都是传统 MLOps 方法几乎未曾涉及的。

无法部署、监控或回滚的模型并非生产级资产，而只是拥有看似优异基准测试成绩的负担。

本指南将按问题、框架现状以及生产级操作指南的顺序进行阐述。整个流程是连续的：只有通过服务测试、性能评估和运营检测后，某个检查点才能真正具备可用性。

问题所在：为何“更大模型”不再是默认选择

1. 规模扩大时成本与延迟会同步上升

将简单的工单分类查询发送给700亿参数级别的模型会浪费算力资源。额外的参数虽然能提升某些功能，但往往并非必需，同时还会在并发情况下增加GPU使用时间和延迟。在产品规模化运营时，这些成本会占据主导地位。

2. 数据集中性与隐私要求推动推理向边缘转移

医疗、金融以及设备端的消费级工作负载往往无法将原始文本发送到第三方 API。体积仅为几GB 内存的 SLM 可以部署在数据所在的位置——无论是本地 GPU、笔记本电脑还是手机——从而满足云端模型无法达到的驻留要求。

3. 服务基础设施也有其自身的故障模式

模型服务的故障与普通应用漏洞不同：由于简单的 KV 缓存分配方式导致的 GPU 内存碎片化、突发流量下的调度器饥饿问题、量化处理不当造成的质量隐性下降，以及规模缩减到零后的冷启动问题，这些都会使服务性能指标无法达标。

4. LLMOps 是与 MLOps 不同的独立领域

传统的MLOps假设模型结构相对稳定，输出结果具有确定性。而LLMOps则需考虑非确定性的文本生成、不同的提示词和工具版本、令牌经济模型以及安全过滤机制。性能下降不再仅仅表现为“准确率降低2%”，还可能体现在“JSON架构合规性下降”或“驱动程序更新后每秒处理令牌数降至p95阈值以下”等方面。

什么是LLMOps？它与MLOps有何不同？

LLMOps关注的是团队如何将语言模型部署到实时系统中、对其进行托管、固定版本、监控表现并持续优化——其重视程度不亚于任何其他关键服务。

在MLOps关注准确率是否下降的同时，LLMOps还会考虑：

在并发环境下，服务引擎能否高效利用GPU内存？
量化后的模型输出是否仍能满足当前任务的精度要求？
提示词和工具版本是否已固定且可回滚？

是否无需修改客户端代码即可实现流量在不同模型之间的切换？

追踪信息能否显示每条路径的令牌成本和延迟？

本指南的其余部分将专门针对SLM回答这些问题。

SLM部署框架概览

就原始GPU吞吐量而言，vLLM是一种常见的高QPS选择，它具备兼容OpenAI的API，可在NVIDIA或AMD GPU上运行。SGLang则在需要前缀复用和结构化生成时具有竞争力。Hugging Face TGI则适合那些已采用Hub和Helm图表进行标准化的团队。

在便携设备方面，llama.cpp / GGUF可在CPU、Apple Silicon以及众多消费级GPU上运行。Ollama为该技术栈提供了两步指令的本地使用方案。LM Studio则增加了桌面GUI以便进行模型评估。MLC-LLM / WebLLM可编译为适用于浏览器和移动设备的版本。ONNX Runtime GenAI针对Windows/NPU以及企业级ONNX标准进行了优化。TensorRT-LLM + Triton则通过预编译实现，以提升NVIDIA硬件集群的性能。

这些工具都能将模型检查点转换为响应，但它们在硬件要求、运算权重以及并发设计方面存在差异。

框架深度解析

vLLM

vLLM推广了PagedAttention技术，通过类似虚拟内存的方式管理KV缓存，从而减少并发处理时对GPU RAM的占用。连续批处理功能则有助于保持硬件的高利用率。

# Install vLLM
pip install vllm

# Serve using VLLM
vllm serve Qwen/Qwen2.5–1.5B-Instruct - port 8000 # fully OpenAI-compatible endpoint


# Make Request
curl http://localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
  "model": "Qwen/Qwen2.5–1.5B-Instruct",
  "messages": [{"role": "user", "content": "Write a haiku about model quantization"}]
}'

# Python Script for vllm

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
resp = client.chat.completions.create(
    model="Qwen/Qwen2.5–1.5B-Instruct",
    messages=[{"role": "user", "content": "Summarize LLMOps in one sentence."}],
)
print(resp.choices[0].message.content)

最适合场景：需要开放AI兼容端点的高QPS后端及RAG服务。优势：高吞吐量、丰富的模型支持、多种量化格式（AWQ/GPTQ/FP8）。缺点：以GPU为核心；仍需额外编排以实现高可用性。

SGLang

SGLang基于RadixAttention技术，可在相关请求间共享前缀缓存——非常适合需要重复系统提示的智能体循环场景——同时还提供了用于结构化生成的sgl.function DSL。

# Installation
pip install "sglang[all]"

# SGLang launch server
python -m sglang.launch_server \
 - model-path Qwen/Qwen2.5–1.5B-Instruct \
 - port 30000


# CURL Request
curl http://localhost:30000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
  "model": "Qwen/Qwen2.5–1.5B-Instruct",
  "messages": [{"role": "user", "content": "Write a haiku about model quantization"}]
}'

import sglang as sgl

@sgl.function
def classify(s, ticket):
  s += sgl.user(f"Classify this support ticket as billing/technical/other: {ticket}")
  s += sgl.assistant(sgl.gen("label", max_tokens=8))

sgl.set_default_backend(sgl.RuntimeEndpoint("http://localhost:30000"))
state = classify.run(ticket="My invoice charged me twice this month")
print(state["label"])

最适合场景：智能体处理流程及有格式限制的JSON输出。优势：可重复使用前缀、支持结构化输出。缺点：生态系统规模小于vLLM；仅支持GPU。

Hugging Face文本生成推理（TGI）

TGI通过兼容Docker/Kubernetes的打包方式接入Hub生态系统。

docker run - gpus all -p 8080:80 \
-v $PWD/data:/data \
ghcr.io/huggingface/text-generation-inference:latest \
 - model-id microsoft/Phi-3.5-mini-instruct \
 - quantize bitsandbytes-nf4

from huggingface_hub import InferenceClient
client = InferenceClient("http://localhost:8080")
print(client.text_generation("Explain quantization in one line.", max_new_tokens=64))

最适合：以Hub为中心的团队以及需要受支持服务路径的受监管系统。 优点：可与Hub集成，提供量化选项，基于Helm框架。 缺点：部分工作负载在原始吞吐量方面仍更倾向于使用vLLM；需持续关注许可证条款。

llama.cpp / GGUF

专为在MacBook CPU上运行LLaMA而设计，通过GGUF量化技术支撑了大部分本地/边缘端的SLM应用。

# macOS: brew install llama.cpp   |   or build from source:
# git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp && cmake -B build && cmake --build build

# Pull a quantized SLM straight from Hugging Face and serve an OpenAI-compatible endpoint
llama-server -hf Qwen/Qwen2.5-0.5B-Instruct-GGUF:Q4_K_M \
    --port 8090 -c 4096 -ngl 999   # -ngl offloads layers to GPU if available (Metal/CUDA)

curl http://localhost:8090/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"What is GGUF?"}]}'

最适合：CPU服务器、Apple Silicon芯片，以及没有CUDA功能的Pi/边缘设备。 优点：具备良好的可移植性，量化选项成熟，采用MIT许可证。 缺点：并发吞吐量低于原生GPU解决方案。

Ollama

Ollama 将 llama.cpp 打包成一种具备本地 HTTP API 的即拉即用型开发者体验。

ollama pull qwen2.5:1.5b
ollama run qwen2.5:1.5b "Write a haiku about model quantization"

import requests
r = requests.post("http://localhost:11434/api/chat", json={
  "model": "qwen2.5:1.5b",
  "messages": [{"role": "user", "content": "Give me 3 LLMOps metrics to track"}],
  "stream": False,
})
print(r.json()["message"]["content"])

最适合场景：本地开发、原型设计以及小团队自托管。 优点：出色的开发者体验及默认配置完善。 缺点：并不适用于高并发的生产环境调度。

LM Studio

基于类似的本地引擎开发的桌面 GUI，支持模型浏览、下载和聊天功能——同时还提供一键即可使用的兼容 OpenAI 的服务器用于演示。非常适合在编写部署配置文件之前进行评估；并非可用于大规模部署的基础设施组件。

MLC-LLM / WebLLM

基于 Apache TVM 构建，MLC 能为多种后端编译模型；WebLLM 则可在浏览器中完整运行。

pip install mlc-llm

mlc_llm chat HF://mlc-ai/Qwen2.5-1.5B-Instruct-q4f16_1-MLC

// WebLLM: fully in-browser inference, no backend server
import * as webllm from "@mlc-ai/web-llm";

const engine = await webllm.CreateMLCEngine("Qwen2.5-1.5B-Instruct-q4f16_1-MLC");
const reply = await engine.chat.completions.create({
  messages: [{ role: "user", content: "Explain WebGPU inference simply." }],
});
console.log(reply.choices[0].message.content);

最适合用于：移动应用、注重隐私的客户端推理以及离线功能。优点：可跨目标平台编译；WebLLM无需服务器支持。缺点：编译复杂度较高；浏览器中的设备性能受限。

ONNX Runtime GenAI

Microsoft的GenAI API扩展了ONNX Runtime的功能，支持在Windows DirectML和NPU上实现带有KV缓存管理的自回归生成功能。

pip install onnxruntime-genai

python -c "
import onnxruntime_genai as og
model = og.Model('phi-3.5-mini-onnx-directml')
tokenizer = og.Tokenizer(model)
tokens = tokenizer.encode('Explain ONNX Runtime GenAI briefly.')
params = og.GeneratorParams(model)
params.set_search_options(max_length=200)
generator = og.Generator(model, params)
generator.append_tokens(tokens)
while not generator.is_done():
    generator.generate_next_token()
print(tokenizer.decode(generator.get_sequence(0)))
"

最适合用于：Windows原生应用以及采用ONNX标准的企业。优点：导出后具有较好的可移植性。缺点：转换过程较为繁琐；相关社区规模小于PyTorch原生引擎的社区。

NVIDIA TensorRT-LLM + Triton Inference Server

TensorRT-LLM可提前编译带有融合内核的引擎；Triton则用于管理多个模型集群。

# Build a TensorRT-LLM engine for a small model (simplified)
trtllm-build --checkpoint_dir ./qwen2.5-1.5b-checkpoint \
    --output_dir ./qwen2.5-1.5b-engine \
    --gemm_plugin float16

# Serve via Triton
tritonserver --model-repository=/models

最佳适用场景：需要最大化NVIDIA集群处理能力以及对延迟要求极高的应用路径。优点：编译完成后可达到最佳性能。缺点：引擎针对特定SKU和架构设计；硬件或批次配置变更时需重新编译。

选择框架：决策指南

思维模型：三个问题，而非功能清单

问题1：模型必须在何处运行？无网络连接的浏览器或手机 → WebLLM/MLC。没有CUDA的CPU/Apple/edge设备 → llama.cpp/Ollama。只有在这些情况之后才考虑GPU数据中心引擎。

问题2：这是用于生产环境还是仅作测试探索？探索用途 → LM Studio或Ollama。生产环境API接口 → 根据下一个问题选择vLLM/SGLang/TGI/TensorRT。

问题3（仅限GPU生产）：流量模式是怎样的？工程预算有多少？ 独立一次性完成任务 → 默认使用vLLM。高度重复的智能体前缀/结构化输出 → 使用SGLang。需要最大程度优化NVIDIA性能且需平台投入的方案 → TensorRT-LLM + Triton。追求Hub/Helm生态兼容性的方案 → 使用TGI。

简化对照表：

GPU API最大吞吐量 → vLLM（若为重复性智能体任务则用SGLang）
在编译预算允许下实现NVIDIA最佳性能的方案 → TensorRT-LLM + Triton
CPU/Apple设备/边缘设备 → llama.cpp；DX封装工具 → Ollama
浏览器/离线客户端 → WebLLM/MLC
Windows系统/NPU设备/ONNX标准 → ONNX Runtime GenAI
点击即可评估的方案 → LM Studio

企业级智能体系统与其他方案的对比

单次请求/响应型的任务非常适合在vLLM上采用连续批处理方式。企业级智能体可能每项任务就需要调用模型数十次——包括规划、工具选择、数据观察以及重新规划——因此前缀缓存和结构化输出显得尤为重要。这类部署通常会在自托管的GPU上使用SGLang或TensorRT-LLM + Triton，而当集成Hub的重要性高于峰值处理能力时，则会选择TGI作为替代方案。

多租户智能体平台还需要为每个用户设置配额、追踪各工具调用间的关联信息，以及能够同时清晰回滚提示词与模型组合——这些都是超越单一引擎层面的LLMOps考量问题。

生产环境部署指南

让系统运行起来仅占工作量的五分之一左右，其余部分则在于确保其准确性、低成本运行以及安全性。

应将量化处理、模型注册、性能评估、灰度发布以及路由机制视为每个模型版本都需要经历的完整流程环节：

1. 量化策略。在许多生产环境中的SLM流程中，默认采用AWQ-4bit或GGUF Q4_K_M格式——经过仔细评估后，其性能通常仅比FP16格式低几个百分点——并且需确认所选引擎支持该格式。量化并非一次性转换操作，它在评估环节结束，而非在转换命令执行时结束。

2. 模型版本控制与注册表。应将微调后的模型及量化后的结果视为不可更改的版本化对象，绝不能直接覆盖原文件。只要在部署清单中固定好校验值，使用MLFlow、带有哈希值的Hugging Face Hub仓库，或是内部的OCI模型注册表都是可行的方案。

3. 评估标准。为该任务设定核心评估指标：分类任务的F1值、信息提取的字段准确率、模式有效性比例、拒绝响应的正确性以及延迟上限。即便演示效果再好，只要有任何一项评估标准未达标，就不得将模型升级到生产环境。

4. 服务架构。在有必要时将 CPU 端的分词/预处理模块与 GPU 工作节点分开；根据队列长度和 GPU 利用率自动扩展资源，而不仅依据每秒请求数。如果冷启动导致服务水平协议无法满足，则需保留备用资源池。

5. 可观测性。需导出请求延迟、输入/输出token数、缓存命中率、批次大小以及内存不足或重试次数等数据。在遵守隐私政策的前提下谨慎选择需要采集的提示词样本。

6. 回滚机制。以模型版本及提示词版本为整体，采用蓝绿部署或金丝雀发布模式。一旦质量出现异常，可立即将两者恢复到之前的状态。

7. A/B测试与多模型路由

根据任务类型选择对应模型：分类和信息提取任务使用小型语言模型，开放式生成任务则使用更大型的模型。在正式切换前，先让候选模型处理部分流量进行测试。应统计每项成功任务的成本，而不仅仅是token数，这样避免因某个更便宜但需要多次重试的模型而出现错误的“胜出”结果。

特性标志应将客户端路由与网关后的命名模型端点绑定，这样进行切换时无需发布新应用。

领域方案

消费级/移动应用

优先选择基于设备或靠近设备的SLM，可使用MLC/WebLLM或在设备上运行的GGUF格式。需谨慎控制内存使用；为提升用户体验应采用分块传输令牌的方式；对于复杂查询，则需在获得明确用户同意的前提下启用云端备用方案。

其他领域（如辅助智能体、内部RAG系统、边缘网关）也遵循相同框架：首先确定硬件条件，再选择引擎，最后设计量化与评估流程。

常见错误模式

仅因追求“更高质量”就直接使用FP16格式，却未在实际任务中测试量化后的性能基准
在需要高QPS的生产环境中使用Ollama/LM Studio架构，却未选用专为并发处理设计的服务器引擎
直接覆盖模型文件，导致后续回滚变得极为困难

仅通过氛围检测进行评估，而非使用黄金数据集
在生产环境中GPU内存不足之前一直忽略KV缓存和批量指标
将提示词修改视为免费操作，同时固定模型版本——或反之

核心要点

当任务范围较窄、数据无法离开特定环境，或成本/延迟限制使得无法使用前沿模型时，序列语言模型更具优势。
LLMOps通过提升服务效率、量化精度、提示词/工具版本管理以及令牌经济模型，扩展了传统MLOps的功能。
应根据部署位置（设备/CPU/GPU）、阶段（探索阶段与服务阶段）以及流量特征（单次请求与智能代理模式）来选择合适的引擎。
生产环境的成功运作是一个循环：量化→注册→评估→小范围测试→观察→回滚。
将稳定的模型摘要与类似门铃式的路由机制结合使用，以便在后端不断演变时保持客户端的稳定性。

参考资料

请查阅各项目的官方文档，了解其安装参数及版本要求：vLLM、SGLang、Hugging Face TGI、llama.cpp、Ollama、LM Studio、MLC-LLM/WebLLM、ONNX Runtime GenAI以及NVIDIA TensorRT-LLM/Triton。在调整批量大小和量化级别时，NVIDIA的硬件指南与Apple Metal文档可作为引擎README的补充。

应制定内部操作手册，记录哪些GPU型号支持哪些数据集——这正是将上述指南转化为可实际使用的平台的关键。

附录：SLM运行第二周至第二十周

在首次成功通过curl连接本地服务器后，一系列棘手问题随之出现：谁负责值班、如何安排CUDA驱动程序的升级，以及当营销活动使每秒查询量在夜间增加两倍时该如何应对？必须在首个测试版本推出之前以书面形式回答这些问题。

SLM的容量规划仍需为上下文长度增加带来的KV缓存增长预留空间。在2k上下文长度下看似很小的1.5B模型，当客户端打开32k个窗口时就会对内存造成压力。应单独跟踪p95上下文令牌数量，而非仅关注请求频率。

安全审查应涵盖模型供应链：下载时的校验和验证、谁有权限将模型发布到注册表，以及包含敏感信息的系统提示是否会被纳入客户端包中。设备端模型也需要与移动应用发布流程一样严谨的更新渠道。

成本评估应比较总拥有成本：GPU租赁费用、重新构建TensorRT所需的工程师时间，以及过度量化带来的质量问题。有时，采用8位精度且稍大一些的SLM，比那些需要人工介入处理的微型模型更经济。

对团队进行培训非常重要。为应用工程师铺平发展道路：提供 Helm chart 或 Compose 文件、标准的 OpenAI 兼容基础 URL，以及已配置好的控制面板。同时为机器学习工程师提供便捷途径，以便他们发布能够通过各项检测的摘要。大多数问题都发生在这两个团队之间的交接环节。

最后，每季度都要用数据来重新评估采用“更大模型”的诱惑。如果随着用户任务难度增加，SLM 的黄金集得分停滞不前，则应选择性地升级——按特定路径逐步进行，而非一夜之间全部更换。SLM 的 LLMOps 不仅关乎加速，同样重要的是控制节奏。

操作注意事项：在锁文件中指定 CUDA 库的精确版本，同时在每次成功的测试版本旁记录驱动程序版本，这样在出现问题时就能在软件层和固件层之间精准定位故障根源。

操作注意事项：在锁定文件中明确指定CUDA堆栈的精确版本，同时在每个成功的测试版本旁记录驱动程序版本，以便在出现问题时能够区分是软件层还是固件层出现了问题。

操作注意事项：在锁定文件中指定CUDA堆栈的精确版本，同时在每个成功的测试版本旁记录驱动程序版本，以便在出现问题时能够区分是软件层还是固件层出现了问题。

操作注意事项：在锁文件中指定CUDA堆栈的精确版本，同时在每个成功的测试版本旁记录驱动程序版本，以便在出现问题时能够区分是软件层还是固件层出现了问题。

全部文章发送简报