大模型后端从演示到验证的落差
单用户演示能证明请求、模型和页面之间的最小链路已经接通。它不能证明多用户排队可控、长上下文不会耗尽资源，也不能证明供应商限流、客户端取消和输出异常时系统仍能收尾。
发布前的验证要回答四类问题：输入边界是否清楚，负载增加时队列是否收敛，失败与取消能否贯穿链路，以及单位完成任务的成本是否在预算内。模型回答看起来不错只是其中一项。
先把推理链路拆成可观察阶段
一次 RAG 或 Agent 请求通常包含鉴权、检索、重排、上下文组装、模型排队、Prefill、逐步生成和输出校验。首个可见结果之前的时间与完整任务时间要分别记录，流式传输中的停顿也要观察。只看接口最终耗时，会把排队、模型生成和网关缓冲混在一起。
输入长度、输出上限、并发和批处理都会影响显存与延迟，具体关系还取决于模型架构、推理引擎和硬件。不要用一个固定公式外推容量。使用当前模型与版本做分组基准，报告每组输入、输出和并发条件。
用户取消后，浏览器关闭连接、网关停止转发、应用取消模型请求和引擎释放任务必须串起来验证。如果只有最外层结束，后台仍生成 Token，用户看不到结果，资源却继续消耗。
Mock 验证协议，不模拟真实模型性能
本地 Mock 很适合测试 SSE 格式、慢首包、中途断开和错误处理，但它不能准确模拟 GPU 调度、KV Cache、批处理或真实 Token 速度。因此，场景参数应显式配置，不把字符长度伪装成模型 Token，也不要从 Mock 结果推导生产吞吐。
下面的 FastAPI 示例提供可重复的首包等待、分块间隔和中途失败。输出使用合法 JSON，并在客户端断开后停止生成。
import asyncio import json from collections.abc import AsyncIterator from fastapi import FastAPI, Request from pydantic import BaseModel, Field from starlette.responses import StreamingResponse app = FastAPI() class Scenario(BaseModel): first_chunk_delay_ms: int = Field(ge=0, le=30_000) chunk_delay_ms: int = Field(ge=0, le=5_000) chunks: list[str] = Field(max_length=200) fail_after: int | None = Field(default=None, ge=0) async def stream( request: Request, scenario: Scenario, ) -> AsyncIterator[str]: await asyncio.sleep(scenario.first_chunk_delay_ms / 1_000) for index, text in enumerate(scenario.chunks): if await request.is_disconnected(): return if scenario.fail_after is not None and index == scenario.fail_after: payload = {"event": "error", "code": "mock_stream_failure"} yield f"data: {json.dumps(payload, ensure_ascii=False)}\n\n" return payload = {"event": "chunk", "index": index, "text": text} yield f"data: {json.dumps(payload, ensure_ascii=False)}\n\n" await asyncio.sleep(scenario.chunk_delay_ms / 1_000) yield "data: [DONE]\n\n" @app.post("/test/stream") async def test_stream(request: Request, scenario: Scenario) -> StreamingResponse: return StreamingResponse( stream(request, scenario), media_type="text/event-stream", headers={ "Cache-Control": "no-cache, no-transform", "X-Accel-Buffering": "no", }, )这个 Mock 可以验证网关是否缓冲、客户端能否处理错误事件、取消后连接是否释放。它没有模拟模型质量、Token 计数或设备内存。容量测试仍要在目标推理引擎上进行，并限制测试范围，避免影响其他工作负载。
队列必须有容量和过期时间
推理引擎达到并发边界时，后续请求不能无限堆在网关内存里。排队策略至少需要最大长度、最长等待、取消和拒绝返回。请求预计排不到时尽早返回繁忙状态，用户可以稍后重试；让它等待到客户端超时，会产生无结果的资源占用。
限流不只按请求数。长上下文和高输出上限的任务占用不同，可以根据已验证的资源权重分组，交互请求和后台批任务使用不同队列。权重只是调度近似，仍需从真实引擎指标校正。
多副本部署时，进程内队列只能看到本实例，扩缩容或重启还会丢失等待任务。是否使用外部队列取决于任务是否允许异步、是否需要持久化和用户如何查询状态。实时对话不一定适合持久排长队，直接拒绝往往更诚实。
上下文预算基于模型 Tokenizer
Pythonlen(text)统计字符，不是模型 Token。预算要使用目标模型匹配的 Tokenizer，并为系统指令、工具定义、当前问题、检索片段和输出分别留空间。模型或模板升级后重新计算，不能永久沿用旧上限。
裁剪历史时按完整对话轮次处理，不拆散工具调用与返回，也不丢掉仍然有效的约束。较早内容需要摘要时，摘要本身也可能遗漏，应保存来源并在高影响任务中让用户确认。当前问题与系统安全规则无法放入预算时，直接拒绝或要求缩小输入，不要硬截断到语义不完整。
检索内容先去重，再按证据需要选择，记录舍弃原因。减少上下文会降低资源，但可能损害回答依据，性能测试必须和正确性评估一起做。
语义缓存先过权限和时效检查
两个问题向量相似，不代表答案可以复用。用户权限、地区、产品版本、知识库版本和时间都会改变结果。缓存键与命中判断要包含这些边界，缓存内容按原数据权限保存。
相似度阈值不能直接从示例复制。用当前 Embedding 模型和业务样本评估误命中，尤其检查看似接近、答案却相反的问题。涉及个性化、实时数据或外部动作的请求，通常不适合复用完整生成结果。
缓存命中时也要保留结果来源和生成版本。知识更新后通过版本切换或显式失效清理旧值。命中率只是资源指标，不能替代错误复用率和最终任务质量。
故障验证覆盖整个链路
测试集应包含短输入、长输入、空检索、非法工具参数、模型超时、限流、中途断流和用户取消。每个场景写出预期：拒绝、降级、继续等待还是人工接管。写操作再加幂等和状态未知场景，避免超时后重复执行。
模型输出通过 Schema 校验后，仍要经过权限和业务状态机。结构错误可以在预算内尝试修复，权限拒绝和参数缺失不应原样重试。失败日志记录模型与协议版本、错误类别、步骤和预算，不默认保存 Prompt、检索正文或完整输出。
恢复测试同样重要。限流解除后逐步放量，确认旧队列已清理、取消任务不再运行、缓存没有混入错误结果。只验证故障能触发，不验证恢复，很容易让系统长期停在降级状态。
CI 检查稳定行为，容量测试放在受控环境
共享 CI 的机器性能会波动，不适合用一个固定 P99 或内存增量作为绝对门禁。CI 可以稳定检查：并发超过上限会拒绝，取消能结束后台任务，SSE 格式正确，错误不会触发无限重试，队列最终归零。
性能回归放在资源固定的专用环境，固定镜像、模型、样本和并发阶梯。与经过多次运行建立的基线比较，并保留原始数据。差异超出预期时先调查，不要把一次噪声自动解释为性能退化。
最终验收同时给出任务完成质量、首结果与完成延迟、取消、错误、排队和单位完成任务成本。结论注明模型、引擎、硬件和样本范围。演示回答“这条路径能否工作”，验证则回答“在什么条件下可靠，超过边界时如何停止”。两者之间的落差，正是后端工程需要补齐的部分。
