Boas Práticas de ML em Rust

Q: Tratamento de erros?

Result através de tarefas de bloqueio; mapeie para o status HTTP sem vazar erros de forma de tensor para os clientes.

Inferência e serviço de ML reproduzíveis, rápidos e com segurança de memória em Rust.

Como Usar Esta Lista

Aplique A-B ao adicionar um novo modelo ao repositório.
Percorra C-D antes de expor qualquer endpoint HTTP.
Revise E após OOM da GPU, regressões de precisão ou incidentes de latência.

A - Ciclo de Vida do Modelo

Fixe a revisão do modelo, tokenizer.json e versões de crates em um único arquivo de manifesto de bloqueio. Desvios quebram silenciosamente no momento da decodificação.
Armazene checksums ONNX/GGUF ao lado dos artefatos. Rejeite downloads que falham na verificação de hash.
Documente o pré-processamento (média/std, NCHW, comprimento máximo) no cartão do modelo. O serviço deve espelhar o treinamento exatamente.
Execute testes de lote dourados contra saídas de referência Python. Limiares de epsilon em logits ou embeddings.
Versionar respostas da API com o campo model_version. Os clientes sabem quando o comportamento mudou.

B - Correção da Inferência

Valide as formas de entrada antes de alocar tensores. Retorne 400, não pânico, em dados de cliente incorretos.
Normalize embeddings para pesquisa de cosseno. Norma L2 nos caminhos de inserção e consulta.
Limite max_tokens e comprimento de contexto no lado do servidor. Parâmetros do cliente são dicas, não políticas.
Aplique modelos de chat antes da tokenização para LLMs. Desvios no modelo embaralham as gerações.
Falhe na inicialização se os arquivos do modelo estiverem ausentes. Não sirva tráfego com erros de carregamento preguiçoso no meio da solicitação.

C - Desempenho e Recursos

Use spawn_blocking ou pool dedicado para forwards. Nunca bloqueie threads de trabalho do Tokio em matmul.
Sonde a GPU na inicialização e registre o fallback para CPU. Operadores precisam de modo degradado visível.
Limite a inferência concorrente com semáforos. Proteja a VRAM contra carimbos de data/hora de solicitação.
Agrupe trabalhos de incorporação durante compilações de índice offline. GPU gosta de lotes > 1.
Ajuste o nível de quantização (Q4/Q8) vs SLA de qualidade. Meça a perplexidade ou métrica da tarefa, não adivinhe.

D - Serviço e Segurança

Autentique as rotas /predict e de geração. GPUs são caras para compartilhar com a internet.
Defina limites e tempos limite para o corpo da solicitação. JSON de vários megabytes é um vetor de DoS.
Separe sondas de liveness e readiness. Readiness executa inferência fictícia barata.
Transmita tokens de LLM para latência percebida. Armazenar em buffer conclusões completas frustra os usuários.
Redija PII dos logs; hasheie prompts se necessário para auditoria. Conformidade supera conveniência de depuração.

E - Cultura de Operações

Acompanhe o tempo de primeiro token e tokens/seg para LLMs. SLOs de produto vivem aqui, não apenas a taxa de HTTP 200.
Registre a memória CPU/GPU após o carregamento do modelo nas métricas. Capture vazamentos entre implantações.
Teste com flag de recursos apenas CPU; imagens de GPU separadas. Builds não devem exigir NVIDIA em verificações de PR.
Planeje a reconstrução do índice quando o modelo de incorporação mudar. Vetores antigos são incompatíveis com a nova geometria.
Mantenha o treinamento em Python quando for mais rápido; possua a inferência em Rust. Jogue com os pontos fortes do ecossistema.

FAQs

Qual é o principal erro de produção?

Executar a passagem de modelo síncrona dentro de manipuladores Axum assíncronos sem spawn_blocking, paralisando rotas não relacionadas.

Quantos testes dourados?

Pelo menos uma entrada fixa por cabeça de saída do modelo - logits de classificação, vetor de embedding ou logit do primeiro token.

Rust para treinamento?

Adequado para modelos pequenos e pesquisa; o treinamento de LLM grande geralmente permanece em Python com Rust possuindo a inferência.

Quando usar ort vs candle?

ort para ONNX exportado de qualquer framework; candle para portas HF Rust e pilhas puramente Rust.

Como documentar necessidades de GPU?

VRAM no carregamento, crescimento de KV por solicitação e sessões máximas concorrentes no runbook associado ao SKU de hardware.

Atualizações de Tokenizer?

Trate as alterações de tokenizer.json como alterações de modelo - reexecute os testes dourados e aumente model_version.

Específicos de RAG?

Versionar a política de chunking e o modelo de embedding juntos; mudar um sem o outro prejudica o recall.

CI sem GPU?

Apenas EP de CPU no pipeline de PR; trabalho de GPU noturno para regressão de desempenho em fixtures maiores.

Tratamento de erros?

Result através de tarefas de bloqueio; mapeie para o status HTTP sem vazar erros de forma de tensor para os clientes.

Onde aprender padrões de serviço?

Veja Servindo Modelos com Axum para layout do manipulador.

Relacionados

Servindo Modelos com Axum - inferência HTTP
ONNX Runtime (ort) - runtime de implantação
Inferência e Serviço de LLM - operações de geração
Noções Básicas de ML em Rust - mapa da seção

Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.

Boas Práticas de ML em Rust

Inferência e serviço de ML reproduzíveis, rápidos e com segurança de memória em Rust.

Como Usar Esta Lista

Aplique A-B ao adicionar um novo modelo ao repositório.
Percorra C-D antes de expor qualquer endpoint HTTP.
Revise E após OOM da GPU, regressões de precisão ou incidentes de latência.

A - Ciclo de Vida do Modelo

Fixe a revisão do modelo, tokenizer.json e versões de crates em um único arquivo de manifesto de bloqueio. Desvios quebram silenciosamente no momento da decodificação.
Armazene checksums ONNX/GGUF ao lado dos artefatos. Rejeite downloads que falham na verificação de hash.
Documente o pré-processamento (média/std, NCHW, comprimento máximo) no cartão do modelo. O serviço deve espelhar o treinamento exatamente.
Execute testes de lote dourados contra saídas de referência Python. Limiares de epsilon em logits ou embeddings.
Versionar respostas da API com o campo model_version. Os clientes sabem quando o comportamento mudou.

B - Correção da Inferência

Valide as formas de entrada antes de alocar tensores. Retorne 400, não pânico, em dados de cliente incorretos.
Normalize embeddings para pesquisa de cosseno. Norma L2 nos caminhos de inserção e consulta.
Limite max_tokens e comprimento de contexto no lado do servidor. Parâmetros do cliente são dicas, não políticas.
Aplique modelos de chat antes da tokenização para LLMs. Desvios no modelo embaralham as gerações.
Falhe na inicialização se os arquivos do modelo estiverem ausentes. Não sirva tráfego com erros de carregamento preguiçoso no meio da solicitação.

C - Desempenho e Recursos

Use spawn_blocking ou pool dedicado para forwards. Nunca bloqueie threads de trabalho do Tokio em matmul.
Sonde a GPU na inicialização e registre o fallback para CPU. Operadores precisam de modo degradado visível.
Limite a inferência concorrente com semáforos. Proteja a VRAM contra carimbos de data/hora de solicitação.
Agrupe trabalhos de incorporação durante compilações de índice offline. GPU gosta de lotes > 1.
Ajuste o nível de quantização (Q4/Q8) vs SLA de qualidade. Meça a perplexidade ou métrica da tarefa, não adivinhe.

D - Serviço e Segurança

Autentique as rotas /predict e de geração. GPUs são caras para compartilhar com a internet.
Defina limites e tempos limite para o corpo da solicitação. JSON de vários megabytes é um vetor de DoS.
Separe sondas de liveness e readiness. Readiness executa inferência fictícia barata.
Transmita tokens de LLM para latência percebida. Armazenar em buffer conclusões completas frustra os usuários.
Redija PII dos logs; hasheie prompts se necessário para auditoria. Conformidade supera conveniência de depuração.

E - Cultura de Operações

Acompanhe o tempo de primeiro token e tokens/seg para LLMs. SLOs de produto vivem aqui, não apenas a taxa de HTTP 200.
Registre a memória CPU/GPU após o carregamento do modelo nas métricas. Capture vazamentos entre implantações.
Teste com flag de recursos apenas CPU; imagens de GPU separadas. Builds não devem exigir NVIDIA em verificações de PR.
Planeje a reconstrução do índice quando o modelo de incorporação mudar. Vetores antigos são incompatíveis com a nova geometria.
Mantenha o treinamento em Python quando for mais rápido; possua a inferência em Rust. Jogue com os pontos fortes do ecossistema.

FAQs

Qual é o principal erro de produção?

Executar a passagem de modelo síncrona dentro de manipuladores Axum assíncronos sem spawn_blocking, paralisando rotas não relacionadas.

Quantos testes dourados?

Pelo menos uma entrada fixa por cabeça de saída do modelo - logits de classificação, vetor de embedding ou logit do primeiro token.

Rust para treinamento?

Adequado para modelos pequenos e pesquisa; o treinamento de LLM grande geralmente permanece em Python com Rust possuindo a inferência.

Quando usar ort vs candle?

ort para ONNX exportado de qualquer framework; candle para portas HF Rust e pilhas puramente Rust.

Como documentar necessidades de GPU?

VRAM no carregamento, crescimento de KV por solicitação e sessões máximas concorrentes no runbook associado ao SKU de hardware.

Atualizações de Tokenizer?

Trate as alterações de tokenizer.json como alterações de modelo - reexecute os testes dourados e aumente model_version.

Específicos de RAG?

Versionar a política de chunking e o modelo de embedding juntos; mudar um sem o outro prejudica o recall.

CI sem GPU?

Apenas EP de CPU no pipeline de PR; trabalho de GPU noturno para regressão de desempenho em fixtures maiores.

Tratamento de erros?

Result através de tarefas de bloqueio; mapeie para o status HTTP sem vazar erros de forma de tensor para os clientes.

Onde aprender padrões de serviço?

Veja Servindo Modelos com Axum para layout do manipulador.

Relacionados

Servindo Modelos com Axum - inferência HTTP
ONNX Runtime (ort) - runtime de implantação
Inferência e Serviço de LLM - operações de geração
Noções Básicas de ML em Rust - mapa da seção

Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.

Boas Práticas de ML em Rust

Buscar na documentação

Boas Práticas de ML em Rust