摘要

端侧算力弱大模型跑不动、压缩后长尾能力骤降、离线场景能力归零、端侧发热降频性能断崖。本文从某实时翻译App真实复盘切入，剖析端侧推理性能、模型压缩失真、离线兜底、发热降级四个痛点，给出端云协同动态切分、关键能力保底蒸馏+混合精度、轻量兜底+优雅降级、热状态检测主动降级的量化方案。

1. 端侧推理性能：手机IoT算力弱大模型塞不下跑不动

痛点现场

某App要在端侧跑1.5B模型做实时翻译，旗舰手机端推理延迟3秒/句，中低端机8秒/句，用户体验极差——用户说完话等3秒才出翻译，对话节奏全断。换成0.5B模型延迟压到1秒但翻译质量暴跌，专有名词全错，"应收账款"翻成"accounts receivable"正确，但"递延所得税资产"翻成"deferred tax"漏关键信息，金融场景用户投诉。

更隐蔽的是内存峰值OOM。1.5B模型INT4量化后约800MB，加载时内存峰值1.2GB（含KV cache和中间激活），中端机4GB内存被其他App占2GB后，加载直接OOM崩溃。团队按旗舰机测试通过，上线后中端机崩溃率15%，差评集中在"装上就闪退"。

最典型的是端侧模型版本碎片化。团队OTA推送模型更新，但用户更新率30%/周，2周后仍有50%用户跑旧版模型。线上同时存在5个版本模型，效果差异大，A/B测试失真——新模型效果提升10%，但50%用户跑旧版整体提升只有5%。版本碎片化让端侧迭代效果打折。

根因剖析

延迟与质量矛盾的根因是端侧算力固定而模型能力随参数增长。1.5B模型能力够但算力跑不动（3秒/句），0.5B跑得动但能力不足（专有名词错）。端侧算力（手机NPU约10TOPS）比云端GPU（数百TFLOPS）差2个数量级，大模型在端侧天生算力受限。这是物理约束，单靠端侧优化无法突破。

内存峰值OOM的根因是模型加载时需全量读入内存+分配KV cache和中间激活，峰值远超模型权重本身。中端机内存被其他App抢占后剩余不足，加载即OOM。团队按旗舰机测试通过是幸存者偏差——旗舰机内存大（8-12GB）不代表中端机（4-6GB）能用。这是测试覆盖不全，没按目标机型矩阵测试。

版本碎片化的根因是OTA更新依赖用户主动触发或后台静默，两者都有滞后。用户主动更新率低（嫌麻烦），后台静默受系统限制（iOS后台限制严、Android厂商定制差异大）。2周50%更新率已是较高水平，版本碎片化是端侧分发的固有难题，无法完全消除。

组织割裂：算法团队按旗舰机效果开发（懂模型不懂机型分布），客户端团队管集成（懂机型不懂模型能力），运维团队管OTA（懂分发不懂效果差异）。三方对"端侧可用性"的标准不一致，算法觉得"旗舰机能跑就行"，客户端觉得"中端机崩溃要兜底"，扯皮上线节奏。

工程方案：端云协同动态切分+机型分级+内存预算

三招组合：端云协同按任务复杂度动态切分（简单端侧全搞定、复杂端云分工、极端全云端）、机型分级按算力内存匹配模型大小（旗舰跑1.5B中端跑0.5B）、内存预算加载前检查可用内存不足则降级。核心是"端侧能跑就端侧跑不动就云端"，而非"全端侧或全云端"二元选择。

// 来源：mlc-llm 0.1 + llama.cpp 0.2 + 自研端云协同

import psutil
from dataclasses import dataclass
from enum import Enum

class DeviceTier(Enum):
    FLAGSHIP = "flagship"   # 旗舰机8GB+内存NPU 10TOPS+
    MID_RANGE = "mid"       # 中端机4-6GB内存
    LOW_END = "low"         # 低端机4GB以下

class TaskComplexity(Enum):
    SIMPLE = "simple"       # 短句日常翻译
    MEDIUM = "medium"       # 长句含专有名词
    COMPLEX = "complex"     # 专业文档多句

@dataclass
class InferencePlan:
    path: str               # edge_only/edge_cloud/full_cloud
    edge_model: str = None  # 端侧用哪个模型
    need_cloud: bool = False

class EdgeCloudCollaborator:
    """端云协同+机型分级+内存预算"""
    def __init__(self, edge_models: dict, cloud_model, device_tier: DeviceTier):
        # edge_models: {1.5B: model, 0.5B: model, 0.3B: model}
        self.edge_models = edge_models
        self.cloud = cloud_model
        self.tier = device_tier
        self.memory_budget = {DeviceTier.FLAGSHIP: 1.5, DeviceTier.MID_RANGE: 0.8, DeviceTier.LOW_END: 0.4}

    def plan(self, prompt: str) -> InferencePlan:
        """按机型+任务复杂度规划推理路径"""
        complexity = self._assess_complexity(prompt)
        # 机型分级选端侧模型大小
        if self.tier == DeviceTier.FLAGSHIP:
            edge_model = "1.5B"
        elif self.tier == DeviceTier.MID_RANGE:
            edge_model = "0.5B"
        else:
            edge_model = "0.3B"
        # 内存预算检查
        available_mem = self._get_available_memory()
        required = self._estimate_model_memory(edge_model)
        if available_mem < required:
            # 内存不足降级到更小模型或走云端
            if complexity == TaskComplexity.SIMPLE:
                edge_model = "0.3B"  # 降到最小模型
            else:
                return InferencePlan(path="full_cloud", need_cloud=True)
        # 端云协同按复杂度切分
        if complexity == TaskComplexity.SIMPLE:
            return InferencePlan(path="edge_only", edge_model=edge_model)
        elif complexity == TaskComplexity.MEDIUM:
            return InferencePlan(path="edge_cloud", edge_model=edge_model, need_cloud=True)
        else:
            return InferencePlan(path="full_cloud", need_cloud=True)

    async def infer(self, prompt: str) -> str:
        """执行推理计划"""
        plan = self.plan(prompt)
        if plan.path == "edge_only":
            return await self.edge_models[plan.edge_model].infer(prompt)
        elif plan.path == "edge_cloud":
            # 端侧prefill + 云端decode，兼顾延迟与质量
            kv_cache = await self.edge_models[plan.edge_model].prefill(prompt)
            # KV cache压缩后传云端继续decode
            compressed = self._compress_kv(kv_cache)
            return await self.cloud.decode(compressed, max_tokens=200)
        else:
            return await self.cloud.infer(prompt)

    def _assess_complexity(self, text: str) -> TaskComplexity:
        """评估输入复杂度"""
        proper_noun_ratio = self._count_proper_nouns(text) / max(len(text.split()), 1)
        if len(text) < 50 and proper_noun_ratio < 0.1:
            return TaskComplexity.SIMPLE
        elif proper_noun_ratio > 0.2 or len(text) > 200:
            return TaskComplexity.COMPLEX
        return TaskComplexity.MEDIUM

    def _get_available_memory(self) -> float:
        """获取当前可用内存GB"""
        return psutil.virtual_memory().available / (1024**3)

    def _estimate_model_memory(self, model_size: str) -> float:
        """估算模型加载内存峰值GB（含KV cache和激活）"""
        weights = {"1.5B": 0.8, "0.5B": 0.3, "0.3B": 0.2}
        # 峰值约权重1.5倍含KV cache和激活
        return weights[model_size] * 1.5

    def _compress_kv(self, kv_cache) -> bytes:
        """KV cache压缩传输，约10MB→2MB"""
        import zlib
        serialized = kv_cache.serialize()
        return zlib.compress(serialized, level=6)

量化指标与边界

某翻译App落地后，旗舰机60%简单任务端侧1.5B延迟<500ms高质量，中端机端侧0.5B延迟1秒中等质量可接受，复杂任务端云协同延迟1.5秒保质量。内存预算检查后中端机OOM崩溃率从15%降到1%（不足时降级到0.3B或走云端）。端云协同让中端机也能用，不再"装上就闪退"。

边界与踩坑：端侧模型OTA更新有版本碎片化，需兼容多版本——API要向后兼容旧版模型的输入输出格式。KV cache跨端云传输需压缩但解压有延迟（约100ms），端云协同的延迟优势在小输入时不明显。端侧发热降频导致推理性能断崖下跌，需配热状态检测主动降级（见第4节）。机型分级需维护机型数据库（算力内存NPU能力），新机型上市要及时更新。内存预算检查本身有开销（约10ms），高频调用需缓存机型判定结果。

2. 模型压缩失真：蒸馏剪枝量化后长尾能力骤降

痛点现场

某端侧模型用INT4量化+蒸馏从7B压到0.5B，通用对话掉点5%可接受，但专业术语识别掉点40%不可接受——金融专有名词几乎全错。“递延所得税资产"翻成"deferred tax assets"漏了"递延”，"坏账准备"翻成"bad debt"漏了"准备金"含义。压缩的trade-off被低估，平均指标掩盖长尾，通用能力掉5%专业能力掉40%，平均看掉8%“可接受”，实际专业场景已废。

更隐蔽的是量化敏感层失真。INT4量化对大部分层影响小，但某些注意力层量化后精度损失大，导致长文本理解能力骤降——短句翻译正常，长段落（超200词）翻译连贯性崩塌，前后指代错乱。团队只测短句没测长段落，上线后长文档翻译投诉集中爆发。

最典型的是蒸馏数据偏差。教师模型70B在通用数据上蒸馏学生0.5B，通用能力传承好，但领域数据占比不足（蒸馏集95%通用5%领域），学生模型的领域能力几乎没传承。团队按通用benchmark评测学生模型分数达标，上线后领域场景暴露问题。蒸馏数据偏差让压缩后的模型在领域场景"失忆"。

根因剖析

长尾能力骤降的根因是压缩对高频通用能力影响小对低频领域能力影响大。量化本质上是用更少位数表示权重，高频出现的模式有足够数据学得量化后的近似，低频模式数据少量化后失真严重。专业术语在训练数据中是低频长尾，量化后首当其冲掉点。这是压缩的固有偏置——保高频牺牲低频，平均指标掩盖长尾损失。

量化敏感层失真的根因是不同层对量化敏感度不同。注意力层权重分布范围大（有极端值），INT4量化后极端值截断损失大；FFN层权重分布集中量化损失小。一刀切INT4量化所有层，敏感层失真放大。混合精度量化（敏感层用INT8其他用INT4）能缓解，但团队用一刀切图省事。

蒸馏数据偏差的根因是团队按"通用比例"配蒸馏数据，领域数据占比低。教师模型在通用数据上学到的能力传承给学生，领域能力因数据少没传承。这是数据配比的设计缺陷——压缩领域能力应加大领域数据比例，而非沿用通用比例。团队按通用benchmark评测掩盖了领域短板，评测指标设计不全。

组织割裂：算法团队做压缩（懂量化蒸馏不懂领域长尾），领域团队用模型（懂领域能力不懂压缩），中间无领域专项评测。算法觉得"平均掉8%可接受"，领域觉得"专业能力掉40%不可用"，双方对"可接受掉点"标准不同。

工程方案：关键能力保底蒸馏+混合精度量化+长尾专项评测

三招组合：关键能力保底蒸馏（领域数据加权70%保长尾）、混合精度量化（敏感层INT8其他INT4平衡精度和体积）、长尾专项评测（专业术语+长文本专项测试不靠平均指标掩盖）。核心是"压缩时保长尾"而非"压缩后查长尾"——蒸馏阶段就加权领域数据，量化阶段就分敏感层，评测阶段就专项测长尾。

// 来源：distilabel 0.1 + AutoGPTQ 0.7 + 自研长尾评测

import torch
import torch.nn.functional as F
from dataclasses import dataclass

@dataclass
class DistillConfig:
    domain_ratio: float = 0.7       # 领域数据占比
    temperature: float = 2.0        # 蒸馏温度
    kd_weight: float = 0.7          # KL损失权重
    ce_weight: float = 0.3          # 硬标签损失权重

class KeyAbilityDistiller:
    """关键能力保底蒸馏+混合数据配比"""
    def __init__(self, teacher, student, config: DistillConfig):
        self.teacher = teacher
        self.student = student
        self.config = config

    def distill(self, domain_data, general_data):
        """混合蒸馏数据：70%领域+30%通用保长尾能力"""
        # 领域数据加权采样
        domain_weighted = self._oversample(domain_data, self.config.domain_ratio)
        general_weighted = self._oversample(general_data, 1 - self.config.domain_ratio)
        mixed = domain_weighted + general_weighted
        # 教师模型生成软标签
        self.teacher.eval()
        for batch in mixed:
            with torch.no_grad():
                teacher_logits = self.teacher(batch.inputs)
            # 学生模型学习软标签分布
            student_logits = self.student(batch.inputs)
            # KL散度损失学教师的知识分布
            kd_loss = F.kl_div(
                F.log_softmax(student_logits / self.config.temperature, dim=-1),
                F.softmax(teacher_logits / self.config.temperature, dim=-1),
                reduction="batchmean",
            ) * (self.config.temperature ** 2)  # 温度T的KL损失需乘T²
            # 硬标签损失保基础能力
            ce_loss = F.cross_entropy(student_logits, batch.labels)
            loss = self.config.kd_weight * kd_loss + self.config.ce_weight * ce_loss
            loss.backward()
            self.optimizer.step()

    def _oversample(self, data, target_ratio):
        """过采样使领域数据达到目标比例"""
        return data  # 实际按target_ratio调整采样权重

class MixedPrecisionQuantizer:
    """混合精度量化：敏感层INT8其他INT4"""
    def __init__(self, model, calibration_data):
        self.model = model
        self.cal_data = calibration_data

    def quantize(self):
        """分析各层量化敏感度，敏感层用INT8"""
        sensitivity = self._analyze_layer_sensitivity()
        # 敏感层（注意力层）用INT8保精度，其他用INT4省体积
        for name, layer in self.model.named_modules():
            if isinstance(layer, torch.nn.Linear):
                bits = 8 if sensitivity[name] > 0.05 else 4
                self._quantize_layer(layer, bits)
                log(f"层{name}量化为INT{bits}，敏感度{sensitivity[name]:.3f}")

    def _analyze_layer_sensitivity(self) -> dict:
        """分析各层量化后输出变化，变化大的敏感"""
        sensitivity = {}
        for name, layer in self.model.named_modules():
            if not isinstance(layer, torch.nn.Linear):
                continue
            # 校准数据上对比INT4量化前后的输出差异
            with torch.no_grad():
                original_out = layer(self.cal_data)
                quantized_layer = self._pseudo_quantize(layer, bits=4)
                quantized_out = quantized_layer(self.cal_data)
                # 输出MSE衡量敏感度
                sensitivity[name] = F.mse_loss(original_out, quantized_out).item()
        return sensitivity

    def _quantize_layer(self, layer, bits):
        """量化指定层为INT4或INT8"""
        # AutoGPTQ分组量化
        from auto_gptq import GPTQQuantizer
        quantizer = GPTQQuantizer(bits=bits, group_size=128)
        quantizer.quantize(layer, self.cal_data)

class LongTailEvaluator:
    """长尾专项评测：专业术语+长文本不靠平均指标"""
    def __init__(self, term_test_set, long_text_test_set):
        self.term_set = term_test_set      # 专业术语翻译对
        self.long_text_set = long_text_set  # 长段落翻译对

    def evaluate(self, model) -> dict:
        """专项评测长尾能力"""
        term_acc = self._eval_terms(model)
        long_text_acc = self._eval_long_text(model)
        return {
            "term_accuracy": term_acc,
            "long_text_coherence": long_text_acc,
            # 长尾掉点超阈值标记不达标
            "term_pass": term_acc >= 0.85,
            "long_text_pass": long_text_acc >= 0.80,
        }

    def _eval_terms(self, model) -> float:
        """专业术语翻译准确率"""
        correct = 0
        for term, expected in self.term_set:
            result = model.infer(f"翻译：{term}")
            if expected.lower() in result.lower():
                correct += 1
        return correct / len(self.term_set)

    def _eval_long_text(self, model) -> float:
        """长文本翻译连贯性（前后指代一致性）"""
        # 用LLM裁判评估连贯性
        scores = []
        for text, ref in self.long_text_set:
            result = model.infer(text)
            score = self._llm_judge_coherence(result, ref)
            scores.append(score)
        return sum(scores) / len(scores)

量化指标与边界

某金融翻译App落地后，0.5B学生模型通用掉点5%可接受，专业术语掉点从40%压到12%（领域数据70%加权蒸馏），长文本连贯性掉点从25%压到10%（注意力层INT8混合精度）。长尾专项评测让压缩质量可见——不再"平均掉8%可接受"掩盖专业能力掉40%。混合精度量化后模型体积0.3GB（纯INT4是0.2GB），体积增加0.1GB换长文本能力保底值得。

边界与踩坑：领域数据权重0.7是经验值，过低关键能力保不住过高通用能力跌——需按业务调，金融场景宁高勿低。混合精度量化增加模型体积（INT8层比INT4层大一倍），体积敏感场景需权衡。长尾专项评测集需业务方持续维护，新术语新场景及时补充。蒸馏训练成本高（70B教师模型推理慢），可配批量蒸馏降低成本。蒸馏温度T=2是经验值，过高软标签太平学生学不到区分度，过低接近硬标签失去蒸馏意义，需实验调优。

3. 离线兜底能力差：无网弱网场景体验崩塌

痛点现场

某App在地铁弱网场景下AI功能直接不可用，云端请求超时后白屏，用户投诉"离线就废"。根因是端侧无兜底模型，网络断则AI全断。竞品用端侧0.3B小模型做离线兜底，虽效果差但不白屏，用户体感"还能用"。团队只设计了在线链路，离线时无任何兜底，体验断崖。

更隐蔽的是弱网场景的伪在线。用户在地铁网络时断时续，App判定"在线"走云端，但网络实际不通请求超时10秒才报错，用户等10秒看到"网络错误"。网络状态判定不准（只看是否连接不看是否可达），导致弱网时既不能用端侧又等云端超时，体验最差——比纯离线还差，离线至少立刻兜底。

最典型的是离线兜底无能力分级。团队加了0.3B兜底模型，但所有任务都走兜底，复杂任务（长文档翻译）0.3B能力极差输出乱码，用户投诉"离线模式还不如不出"。离线兜底应按任务复杂度分级——简单任务兜底可用，复杂任务明确提示"离线模式不支持，请联网后使用"，而非硬兜底输出垃圾。

根因剖析

离线白屏的根因是团队只设计在线链路，离线时无fallback。云端是主路径，端侧模型仅作"在线时的低延迟补充"，没设计成"离线时的兜底"。这是架构设计的单链路思维——只考虑主路径不设计降级路径。工业系统都有降级设计（主备切换、兜底返回），端侧AI同样需要。

伪在线的根因是网络状态判定不准。App通常用"是否有网络连接"判定在线，但弱网时"有连接不可达"，判定为在线走云端却超时。正确判定需做"可达性探测"（实际请求测试endpoint），但探测有延迟团队为省延迟不做。这是可用性感知的缺陷——用静态状态判定动态可达性。

硬兜底输出垃圾的根因是离线兜底无能力边界认知。0.3B模型能力有限，复杂任务超出能力范围输出乱码，但兜底逻辑不判断任务复杂度硬兜底。这是兜底设计的粗放——只管"有输出"不管"输出可用"。优雅降级应是"能力范围内兜底，能力外明确提示"，而非"无差别硬兜底"。

组织割裂：客户端团队管网络判定（懂连接不懂AI能力），算法团队管模型（懂能力不懂离线兜底设计），产品团队管体验（懂体感不懂技术兜底）。三方对"离线体验"的预期不一致，客户端觉得"断网报错就行"，产品觉得"不能白屏要有兜底"，算法觉得"0.3B能力差兜底也没用"，中间无统一降级设计。

工程方案：网络可达性探测+轻量兜底+能力分级优雅降级

三招组合：网络可达性探测（实际请求判定可达而非静态连接状态）、轻量兜底+异步重试（弱网时端侧先给答案后台重试云端成功后更新）、能力分级优雅降级（简单任务兜底复杂任务明确提示不支持）。核心是"离线不白屏弱网不等待复杂任务不硬兜底"。

// 来源：自研网络探测+离线兜底+能力分级

import asyncio
import threading
from dataclasses import dataclass
from enum import Enum

class NetworkState(Enum):
    ONLINE = "online"       # 可达
    WEAK = "weak"           # 有连接不可达
    OFFLINE = "offline"     # 无连接

@dataclass
class TaskCapability:
    simple: bool = True     # 简单任务0.3B可兜底
    medium: bool = False    # 中等任务0.3B兜底质量差
    complex: bool = False   # 复杂任务0.3B无法兜底

class OfflineFallback:
    """网络可达性探测+轻量兜底+能力分级优雅降级"""
    def __init__(self, cloud_model, edge_model, tiny_model, probe_endpoint):
        self.cloud = cloud_model
        self.edge = edge_model        # 0.5B弱网用
        self.tiny = tiny_model        # 0.3B离线兜底
        self.probe_url = probe_endpoint  # 可达性探测端点

    async def infer(self, prompt: str) -> str:
        """按网络状态和任务复杂度选择路径"""
        network = await self._probe_network()
        if network == NetworkState.ONLINE:
            return await self.cloud.infer(prompt)
        elif network == NetworkState.WEAK:
            # 弱网：端侧0.5B先给答案，后台异步重试云端
            edge_result = await self.edge.infer(prompt)
            self._async_cloud_retry(prompt, edge_result)
            return edge_result
        else:
            # 离线：按任务复杂度能力分级兜底
            return await self._offline_graded_fallback(prompt)

    async def _probe_network(self) -> NetworkState:
        """网络可达性探测，非静态连接状态判定"""
        try:
            # 实际请求探测端点判定可达性，超时2秒
            await asyncio.wait_for(
                self._http_head(self.probe_url), timeout=2.0
            )
            return NetworkState.ONLINE
        except asyncio.TimeoutError:
            # 有连接但不可达判定为弱网
            return NetworkState.WEAK
        except ConnectionError:
            return NetworkState.OFFLINE

    async def _offline_graded_fallback(self, prompt: str) -> str:
        """离线能力分级优雅降级"""
        capability = self._assess_tiny_capability(prompt)
        if capability.simple:
            # 简单任务0.3B可兜底，标注离线模式管理预期
            result = await self.tiny.infer(prompt)
            return f"[离线模式，可能不够准确]\n{result}"
        else:
            # 复杂任务明确提示不支持，避免硬兜底输出垃圾
            return ("[离线模式不支持此类复杂任务]\n"
                    "请联网后使用获得完整功能。当前网络不可用。")

    def _assess_tiny_capability(self, prompt: str) -> TaskCapability:
        """评估0.3B模型对当前任务的能力边界"""
        cap = TaskCapability()
        # 短句简单任务0.3B可兜底
        if len(prompt) < 100 and not self._has_specialist_terms(prompt):
            cap.simple = True
        elif len(prompt) < 300:
            cap.medium = True  # 中等任务兜底质量差
        else:
            cap.complex = True  # 复杂任务无法兜底
        return cap

    def _async_cloud_retry(self, prompt: str, edge_result: str):
        """弱网时后台异步重试云端，成功后推送更新"""
        def retry():
            try:
                cloud_result = self.cloud.infer(prompt, timeout=30)
                # 成功后推送云端结果覆盖端侧结果
                self._push_update(cloud_result)
            except Exception:
                pass  # 重试失败保持端侧结果
        threading.Thread(target=retry, daemon=True).start()

    def _push_update(self, cloud_result: str):
        """推送云端结果更新用户看到的端侧结果"""
        # 通过WebSocket或推送通知更新UI
        log("弱网重试云端成功，推送高质量结果更新")

量化指标与边界

某App落地后，离线场景AI可用率从0%提到80%（0.3B兜底简单任务），弱网场景端侧先给答案后台更新用户无感等待。网络可达性探测后伪在线消失——弱网时直接走端侧不再等云端超时10秒。能力分级优雅降级后复杂任务离线时明确提示而非输出乱码，用户投诉"离线乱码"降90%。0.3B模型约100MB离线体验差但可用，标注"离线模式"管理预期。

边界与踩坑：网络可达性探测有2秒延迟，高频调用需缓存探测结果（5秒内复用）。弱网异步重试云端可能产生重复推理成本，需配去重（相同prompt不重复重试）。能力分级阈值（100字简单300字中等）需按业务调，翻译场景可放宽到200字简单。离线兜底模型0.3B能力有限，标注"离线模式可能不准"是必要预期管理，不能假装与在线同质量。后台异步重试成功后推送更新，UI需支持结果替换（用户已看到端侧结果后被云端结果覆盖），交互设计要平滑。

4. 端侧发热降频：推理性能断崖式下跌

痛点现场

某App连续推理10分钟后手机发热严重，CPU降频后推理延迟从500ms飙到3秒——性能断崖式下跌。用户连续使用体验从"流畅"变"卡顿"，投诉"用一会儿就卡"。根因是手机温控策略，CPU/GPU超阈值降频保护硬件，推理是高负载任务持续触发降频。

更隐蔽的是降频无感知。系统降频时不通知App，App按正常频率调度推理任务，实际硬件已降频任务积压延迟飙升。团队监控推理延迟发现P99从500ms飙到3秒，排查2小时才发现是发热降频，期间用户体验已受损。降频对App是透明事件，需主动检测温度而非被动等延迟飙升。

最典型的是降级策略缺失。团队发现降频后无应对策略，继续按正常负载推理，手机越用越热越降频越卡，恶性循环到App卡死被系统杀掉。正确做法是检测到发热时主动降级——减少推理频率、切换更小模型、提示用户休息，而非硬撑到卡死。

根因剖析

发热降频的根因是推理是持续高负载任务，CPU/GPU长时间高频运行产热超散热能力，触发热保护降频。手机被动散热无风扇，持续推理必然升温降频。这是移动设备的物理约束，推理越重发热越快降频越早。

降频无感知的根因是系统降频对App透明，不主动通知。App按正常调度推理，实际硬件降频后单次推理耗时增加，任务积压延迟飙升。团队靠延迟监控被动发现降频，发现时已影响用户体验。这是系统事件感知的缺失——App应主动检测热状态而非等延迟异常反推。

降级策略缺失的根因是团队把推理当"恒定负载"而非"可调节负载"。恒定负载下发热降频只能硬撑到卡死，可调节负载下可主动降级（减频率换小模型）保可持续。这是负载管理的缺失——推理频率和模型大小应按热状态动态调节，而非固定不变。

工程方案：热状态检测+主动降级+散热策略

三招组合：热状态检测主动感知温度而非等延迟飙升、主动降级按温度分级切换模型大小和并发数、散热策略提示用户休息或暂停避免恶性循环。核心是"发热前主动降级"而非"降频后被动硬撑"。

// 来源：iOS ThermalState API + Android PowerManager + 自研热管理

import time
from dataclasses import dataclass
from enum import IntEnum

class ThermalState(IntEnum):
    """热状态分级，对应iOS thermalState和Android throttlingStatus"""
    NOMINAL = 0       # 正常<38度全速
    FAIR = 1          # 温热38-42度降频
    SERIOUS = 2       # 过热42-45度最小模型
    CRITICAL = 3      # 危险>45度暂停

@dataclass
class ThrottleConfig:
    model: str          # 该热状态下用哪个模型
    max_concurrency: int  # 最大并发推理数
    cooldown_hint: bool   # 是否提示用户休息

class ThermalAwareInferencer:
    """热状态检测+主动降级+散热策略"""
    def __init__(self, models: dict, thermal_api):
        self.models = models  # {1.5B, 0.5B, 0.3B}
        self.thermal = thermal_api  # 平台热状态API
        self.throttle_plan = {
            ThermalState.NOMINAL: ThrottleConfig("1.5B", 4, False),
            ThermalState.FAIR: ThrottleConfig("0.5B", 2, False),
            ThermalState.SERIOUS: ThrottleConfig("0.3B", 1, True),
            ThermalState.CRITICAL: ThrottleConfig("0.3B", 0, True),  # 并发0即暂停
        }
        self.current_state = ThermalState.NOMINAL
        self.state_history = []  # 温度趋势用于预测降频

    async def infer(self, prompt: str) -> str:
        """按热状态选择模型和并发限制"""
        state = await self.thermal.get_state()
        self._update_state(state)
        config = self.throttle_plan[state]
        # 危险状态暂停推理+散热提示
        if config.max_concurrency == 0:
            return ("[设备过热已暂停AI功能]\n"
                    "请让手机冷却后再使用，避免硬件损伤。")
        # 过热状态提示休息
        if config.cooldown_hint:
            self._show_cooldown_hint()
        # 按热状态选模型
        model = self.models[config.model]
        # 并发限制（实际用信号量控制）
        async with self._concurrency_limit(config.max_concurrency):
            return await model.infer(prompt)

    def _update_state(self, state: ThermalState):
        """更新热状态+记录趋势预测降频"""
        if state != self.current_state:
            log(f"热状态变化: {self.current_state.name} -> {state.name}")
            self.current_state = state
        self.state_history.append((time.time(), state))
        # 预测降频：温度上升趋势时提前降级
        if self._is_heating_trend() and state == ThermalState.NOMINAL:
            log("检测到温度上升趋势，提前降级到FAIR")
            self.current_state = ThermalState.FAIR  # 主动提前降级

    def _is_heating_trend(self) -> bool:
        """分析近5分钟温度趋势，上升则预测降频"""
        recent = self.state_history[-10:]  # 最近10次采样
        if len(recent) < 3:
            return False
        # 状态值递增表示升温趋势
        values = [s for _, s in recent]
        return values[-1] > values[0] and len(set(values)) > 1

    def _show_cooldown_hint(self):
        """提示用户休息散热"""
        # UI提示"设备温度较高，AI已切换节能模式，建议休息片刻"
        log("显示散热提示")

    from contextlib import asynccontextmanager
    @asynccontextmanager
    async def _concurrency_limit(self, max_concurrent: int):
        """并发数限制信号量"""
        import asyncio
        sem = asyncio.Semaphore(max_concurrent)
        async with sem:
            yield

class PlatformThermalAPI:
    """平台热状态API抽象，iOS和Android各自实现"""
    async def get_state(self) -> ThermalState:
        """获取当前热状态，子类按平台实现"""
        # iOS: ProcessInfo.thermalState
        # Android: PowerManager.isThermalStatusModerate等
        raise NotImplementedError

class iOSThermalAPI(PlatformThermalAPI):
    async def get_state(self) -> ThermalState:
        # 通过pyobjc或native bridge获取thermalState
        # 返回nominal/fair/serious/critical映射到ThermalState
        pass

class AndroidThermalAPI(PlatformThermalAPI):
    async def get_state(self) -> ThermalState:
        # 通过jni获取PowerManager.getThermalStatus
        # 映射到ThermalState分级
        pass

量化指标与边界

某App落地热状态检测+主动降级后，发热降频不再断崖式卡顿——温度38度时提前降级到0.5B+减并发，避免升到42度过热档。用户连续使用时长从10分钟卡顿延长到30分钟可接受（降级后质量略降但不卡）。过热暂停+散热提示避免了恶性循环到App被杀，用户按提示休息后恢复全速。温度趋势预测让降级提前1分钟，用户体感更平滑（从"突然卡"变"逐渐降质量"）。

边界与踩坑：热状态API在不同平台精度不同，iOS thermalState分4档清晰，Android厂商定制差异大需适配。温度趋势预测有误报（短时升温后又降），提前降级会不必要牺牲质量——可配确认机制连续3次升温才降级。降级到0.3B模型质量明显下降，需向用户说明"节能模式"管理预期。过热暂停是保硬件手段，但频繁暂停影响体验，需平衡——可设最低推理保障（关键场景即使过热也用0.3B兜底）。热管理增加每推理前的状态检测开销（约5ms），高频调用需缓存状态（1秒内复用）。

总结

边缘与端侧层的本质是算力约束下的质量-延迟-可用性-热约束四方博弈。端云协同按机型和复杂度动态切分让算力弱机型也能用，关键能力保底蒸馏+混合精度量化让压缩后长尾不掉点，网络可达性探测+能力分级优雅降级让离线弱线不白屏不硬兜底，热状态检测+主动降级让发热降频不再断崖卡顿。四招共同把物理约束下的端侧AI锻造成可持续可用的工程接口。